Mail Filtering - Rethinking Our Reliance on RBLs

Receiving Mail

Like any organisation in charge of running an email service, we have tried a mix of methods over the years to fend off spam. These have included Bayesian filtering, greylisting, various ACL checks, and external, third-party RBLs (Real-time Blackhole Lists). Although each of these methods has helped us defend against spam to an extent, we have found that the RBL service available from zen.spamhaus.org has provided a particularly high level of protection. For this reason, we have now been using Spamhaus RBL for well over a decade.

Recently, one of our members contacted us with concerns about our use of the Spamhaus RBL. And we believe that this member made a number of good points. In particular, we agree that if someone is blacklisted in error, or is in conflict with a blacklist operator, this should in no way affect their ability to contact us. As a neutral organisation committed to contributing to a stable Internet, we have a responsibility to ensure that the channels of communication between us and the rest of the community stay open.

So, shortly, we will implement the following measures:

1. Whitelist our members by making sure any email address subscribed to the ncc-announce@ripe.net mailing list will always reach RIPE NCC support (this being the most efficient way to gather emails for members right now)
2. For any other sender whose email to us is rejected because of RBL filtering they will receive a link to a web form that they can use to contact us 

While not a complete solution, we believe these are good first steps.

In the long term, the solution to all this would involve reducing our reliance on external RBLs for spam filtering. What exact steps this would involve is still to be worked out and will take some work to implement. Simply switching off RBL filtering isn’t an option at this point, especially when you consider that it helped us block 60,000 mails in August this year alone. We welcome input regarding the experiences others in the community and our members have had in their attempts to reduce reliance on third-party sources for filtering incoming emails.

Sending Mail

We also have some news on how we are sending emails. We are generally quite conservative in adopting technologies that are not mature or widely adopted enough to minimise potentially negative effects for our recipients. This we are mainly referring here to email authentication methods.

About a year ago, for instance, we introduced a Sender Policy Framework (SPF) record that allowed remote mail servers to validate that the emails received from us were sent from servers authorised to send on our behalf. Around the same time we wrote about a change in our Mailman configuration, caused by more and more subscribers having email addresses in domains that have configured Domain-based Message Authentication, Reporting and Conformance (DMARC) policies.

To ensure deliverability of emails sent to our mailing lists subscribers, we set a DMARC option in Mailman (dmarc_moderation_action) that rewrites (munges) the From: header field to include the list address and the original sender’s name “via the list”, but only for those messages with the original domain having a DMARC policy p=reject or p=quarantine. In short, this enabled us to ensure that anyone subscribed to our mailing lists would receive emails from all other subscribers.

These changes will stay in place and now it is the time to take an additional step. Shortly we will also start signing our outgoing mails with a DomainKeys Identified Mail (DKIM) signature and we will be publishing a DMARC record with the policy p=none. Thus emails we send out will contain an extra DKIM signature header and the DMARC aggregate reports will offer us visibility on the SPF and DKIM alignment and produce failure reports. 

Feedback

Please leave a comment if you have any questions or believe any of the issues or proposed changes described about affect you in any way.