Roller Network’s colocation facility is not located in a flood risk area; our activities related to the flood in Sparks are only to assist our customers in affected areas.
UPDATE (13:34): Other than a possible power outage no impact is expected to our POP in Sparks. All of the customers it serves are idle/evacuated at this point. Sparks has now closed roads for 24 hours. Our special office hours today will now end as well; customers should use the hotline if needed.
We will have special office hours this morning, Sunday, January 8th until 1PM local time in order to potentially assist our customers affected by (or potentially affected by) flooding in Sparks, NV. If you are a Roller Network customer and need to temporarily relocate servers or other equipment needed for your business to maintain operations, emergency temporary colocation will be available at our facility.
After 1PM local time the City of Sparks plans to close all road access to the flood risk areas and no traffic will be allowed into the area. As such, we expect any emergency requests from customers will have been satisfied before this time, and we will not be able to go into the closed area for emergency service calls after 1PM.
Roller Network does operate one POP in the closed area which we’ll inspect before the roads are closed, but current maps do not show its location as a flood risk and it’s equipment is mounted several feet above ground level. The biggest risk will be loss of power and UPS discharge since we won’t be able to make it into the area to connect a generator, but since it only serves customers in the closed area the expected impact to operations is minimal to none.
We’re adding Cloudmark Authority back into our system for mail filtering. The CMAE_1 rule for SpamAssassin will return and new features for the account control center will be developed. (See our previous announcement here.)
The difference this time around is that we’re not using a SpamAssassin integration. We’re integrating it directly into our content filtering module which is account control center aware and SpamAssassin is configured to look for the presence of a header added if a message is determined to be spam.
More updates to come.
UPDATE (Dec. 23, 2016): Scoring is now enabled. The CMAE_1 rule is currently configured with a score of 1 if detected as spam and X-CMAE-* headers will be added for all messages. We may change the default score in the future. You can adjust the CMAE_1 score in the SpamAssassin preferences section of the control center, if desired.
We’ve added two new SpamAssassin tests using on our spamtrap data.
RCVD_IN_ROLLERNET_TRAP – This test means that an IP address matched one that was seen in the headers of a message submitted to a spamtrap. Since this includes all headers it’s possible for a faked IP to end up on this list, but at the same time that faked IP is being used as part of a spam run. Useful for scoring but possibly not outright blocking due to all headers being considered. Default score is 1.5
CLIENT_ROLLERNET_TRAP – This test means that the client IP address has submitted to a spamtrap. This should generally be safe for blocking and scoring since the IP is the actual connecting client address when it submitted something to a spamtrap. Default score is 3.
The spamtrap will exclude an IP address if it’s listed on DNSWL.org, but we do not check any further to see who the IP address belongs to. For example: if Gmail started spewing spam into the trap their IP addresses would be listed (unless it’s on DNSWL), so if gmail.com is critical to you and you want to use the spamtrap data you would want to add your own whitelist entry for gmail.com.
Starting on December 19th we’re no longer going to accept mail submitted to our SMTP AUTH system with a URI classified as black, grey, red, or gold on URIBL. These categories contain domains that are either actively used by spammers or found in unsolicited bulk mail. This is currently being treated as a trial change.
The “grey” category is a special case. It contains domains that are used by bulk or commercial mail, which may not be spammers in the strict sense, but are nevertheless against our policy for SMTP AUTH submissions (no bulk or marketing mail).
Our goal is quality of mail through our submission system in order to maintain a high reputation for our customers that depend on us for routine communication. Because we are not a “bulk mail” outfit we are unfortunately unable to accommodate bulk mail use cases. For example, “constantcontact.com” would be listed/rejected, and it would be more appropriate to use their service to send bulk mail instead of ours.
If you find you’re having trouble submitting messages after this change, contact support so we can investigate.
We’ve added a new header to mail we handle called “X-Rollernet-Client”. This header will contain the IP address of the server that connected to us without having to handle “Received” headers. This will put the client IP at the fingertips of customers that want post-process their mail and need the client address for any reason.
The IP address will be formatted in square brackets and IPv6 addresses will be fully expanded. An error is indicated by empty square brackets.
Normal IPv4 client example:
Normal IPv6 client example: