Koha ILS

When anti-spam measures go too far?

by Larry Baerveldt on Apr 15, 2014

There’s been a recent event that has many systems administrators up in arms. No, I don’t mean Heartbleed. I’m talking about Yahoo and how they have broken pretty much every mailing list in existence.

Some background:

There are a number of techniques out there for combating SPAM. They range from filters looking for keywords, to blacklisting servers, to Internet standards such as SPF and DKIM. Well now Yahoo has taken it a big step further with DMARC.

DMARC is a new anti-spoofing technical specification (no, it has nothing to do with libraries or MARC records, despite the coincidental acronym). DMARC stands for “Domain-based Message Authentication, Reporting & Conformance” (http://www.dmarc.org/). DMARC is not an international standard yet, but many mail vendors are already supporting it. Like most technical specifications, it’s complicated and pretty dry reading, but in a nutshell what DMARC says is this:

When an email is sent, it includes a number of headers, in addition to the visible fields like “To”, “From”, “Subject”, etc. Among these headers is the domain name of the server that sent the message. DMARC requires that the domain in the “From” field must be in the same domain as the sending server. So for example, if the originating server of an email message is “mail.my-server-domain.com”, but the “From” address is “random.user@yahoo.com”, that violates DMARC.

When a vendor implements DMARC they create a DMARC policy record for their domain that specifies what they want done if the “From” address is different than the mail server domain. This policy record includes a “p=” statement, where the value of “p” can be either “none” (do nothing, accept the email) or “reject” (reject the message).

Now surely anything vendors can do to cut down on spam is a good thing, right? But let’s think about that for a minute. When you subscribe to a mailing list, and then post a message to it, your message goes out with your address in the “From” field. But, the server hosting the mailing list is what is actually sending the message out to the subscribers, and so now the originating server will be that of the mailing list provider, not your original email vendor. The domain name in the “From” field will now be different than mail server domain, and according to DMARC, that’s a no-no. Using a mailing list is a completely legitimate thing to do, and for a mailing list to rewrite headers is also quite normal and a reasonable thing to do. The commonality of this practice is surely one of the reasons why most vendors who currently have a DMARC policy record have it set to “p=none”.

So what happened? Last weekend (sometime between April 4-6) Yahoo changed their policy from “p=none” (accept messages) to “p=reject”. Yahoo is now saying, “nope, we will not accept any message with a yahoo.com ‘From’ address did not originate from a yahoo.com server.”

And the problem isn’t just contained to Yahoo. Other mail vendors that perform DMARC checks see Yahoo’s policy and will ALSO reject email messages sent to their subscribers that purport to come from yahoo.com. So for example, if a message from a Yahoo user goes through a mailing list, Gmail will respond with a message that reads: “smtp;550 5.7.1 Unauthenticated email from yahoo.com is not accepted due to domain’s DMARC policy. Please contact administrator of yahoo.com domain if this was a legitimate mail.”

So Yahoo updated their policy to “reject”, and just like that, thousands and thousands of email messages all over the world suddenly started bouncing back. And mailing list administrators are inundated with rejection notices.

Okay, so you might say to yourself, “I don’t operate a mailing list, how does this affect me?” Let’s take an example closer to home. In Koha, you have the ability to set the KohaAdminEmailAddress system preference, which serves as the general “From” address for messages sent by Koha. In addition, you can define an email address for each branch library in your system. These email addresses can be anything, and may range from something in your local domain, to gmail accounts, hotmail accounts, and even yahoo accounts. But, the mail server that is sending this message may NOT be in your local domain. For example if you host with us, your server’s “official” name will be in the “bywatersolutions.com” domain, but your “From” addresses will not be a ByWater address. So technically pretty much every email sent by a Koha server that is hosted outside of your local domain will be in violation of DMARC.

I’ll pause for a moment to let that sink in.

…

Okay, let’s take a breath; things are not totally hopeless. Right now Yahoo appears to be the only mail vendor who’s using a DMARC policy of “reject”. That means that as long as you don’t use a yahoo.com address for your KohaAdminEmailAddress or branch email addresses, you should be okay. (And cross your fingers that Gmail doesn’t change their DMARC policy.) And in fact, this is the very advice being given by a number of mailing list administrators out there; don’t use Yahoo. But that is a short-term solution.

For the long-term, a development idea has been submitted to the Koha Community to address this. You can follow the Bug report here: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9530

What this development seeks to do is allow for a separate “Reply to” setting in Koha, in addition to the current “From” setting. This should address the problems of DMARC, since at this time DMARC is only concerned with the “From” address. How this would work is, you would still have to use a “From” address that matches the domain of your Koha server, and this is what will show up in the “From” field of messages sent to your borrowers. You might end up using something like “No_Reply@my_koha.domain.com”. But with this development you would also have a “Reply to” header in your email that can be a real address, outside of the hosting domain. So even though the email message would say that it’s from “No_Reply@my_koha.domain.com” bouncebacks would return to your local email account.

At the moment, this development has just been submitted, so I don’t know how much work as been done on it yet. But hopefully something can be done with this before the next big mail vendor decides to change their DMARC policy as well. If any of you out there want to help with this development, by all means, get involved: http://koha-community.org/get-involved/