We’ve made a couple minor updates to the Secondary DNS system.
- If we see a successful transfer, the back end will automatically send an “enable” flag to the account control center. This addresses a possible condition where a zone can become disabled between update runs due to an error that was fixed before the next run.
- Secondary DNS zones will be automatically disabled if a NOTAUTH (not authoritative) response is received from the configured master. This is similar to the existing behavior of disabling on a REFUSED response. Our system must assume that if the master is not authoritative for a zone that we must not try to be a secondary, and it wastes resources to keep trying.
Virbl was a project of which the idea was born during the RIPE-48 meeting in May 2004. The plan was to get reports of virusscanning mailservers and put the IP-addresses that were reported to send viruses on a blacklist. Since the start, a number of trusted notifiers participated and over the next 10 years Virbl was a great addition to fighting back virus mails on the internet.
However, the internet changed, the techniques used to filter virus mails changed, trusted notifiers stopped reporting about incoming virusses and Virbl became more and more obsolete. This prompted us to decide to ‘pull the plug’ on the project after 12 years of operation.
The Virbl-project site has been replaced by this static message to inform those that find their ways here. The Virbl DNSBL-zone was emptied and will be removed all together at a moment further on in the future. Please remove any DNSBL-lookups against ‘virbl.dnsbl.bit.nl’ from your e-mail configurations. AS-operators will no longer receive the so called ‘Virbl AS-reports’ and it will no longer be possible to look up evidence. Mail sent to the ‘virbl.bit.nl’ domain will be tossed in the endless vacuum called /dev/null.
Please remove any DNSBL-lookups against ‘virbl.dnsbl.bit.nl’ from your e-mail configurations.
Accordingly, we have removed all entries for “virbl.dnsbl.bit.nl” from DNSBL configurations.
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, and it would be more appropriate to use the mailer’s 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. Marketing-type mail should be sent directly to the intended recipient and not rely on forwarding or resending.