A friend running a list-server spent some time yesterday and today reading up on the recent AOL/Yahoo DMARC fiasco and what it means for mailing lists and their subscribers, and thought it would be interesting to some of you at least to hear more about it. If you're not interested, please hit DELETE now. -=-=-=-=-=-=- EXECUTIVE SUMMARY: AOL and Yahoo are abusing DMARC to try to paper over security breaches in their services. Users of these services who subscribe to mailing lists suffer bad consequences (even though here on [redacted] serverwe try to mitigate them as best we can) but AOL and Yahoo don't care. If you subscribe to either and want to use mailing lists, move to a better e-mail provider NOW. -=-=-=-=-=-=- By way of introduction, DMARC is a method for securing e-mail. In essence, DMARC is a way of checking that a message claiming to be »From: [log in to unmask]« was actually sent by an accredited mail server for the example.com domain, and was not tampered with by anyone in transit. DMARC is not an Internet standard like the ones that actually codify how e-mail works, and it is unlikely to become one, but that doesn't really matter in practice because some of the biggest e-mail providers of this world have got together and decided that DMARC is what they want to use. They will tell you DMARC is about avoiding spam, but that is not actually true (since spammers are perfectly capable of using throwaway domains to send spam that passes DMARC checks for those domains). In reality, DMARC is mostly about preventing random people from sending messages purporting to be from DMARC-using domains that aren't. This is of considerable interest to outfits like PayPal or your bank, who have a huge problem with »phishing«, i.e., random crooks sending you messages that look like requests from @paypal.com to enter your account name and password somewhere where the crook can retrieve it. DMARC does this reasonably well if PayPal and your bank jump through all the required burning hoops to enable it for their domains, and your mail provider jumps through all the required burning hoops to actually check incoming messages according to the DMARC rules, but in the process DMARC completely breaks the way mailing lists (such as [redacted] server) have worked basically since the last Ice Age. The DMARC people don't worry about this because in their view of how e-mail works, mailing lists are not a use case that they consider important. (The mailing-list problem is incidentally one of the reasons why DMARC is probably never going to be a formal Internet standard, not that that matters to the DMARC cartel in any way.) The idea behind DMARC is that as a domain owner you (a) put tricky cryptographic signatures on your legitimate mail that will prove to other DMARC users that the mail comes from your domain, and (b) you publish a »policy« that will let other DMARC users know what you would like them to do with mail that claims to come from you but doesn't have the correct tricky cryptographic signatures, so in reality doesn't come from you. ISPs that support DMARC will retrieve that policy when they receive mail claiming to be from you, and act on it. There is a variety of policies to choose from, ranging from »none« (i.e., don't do anything with the message that you wouldn't do otherwise) to »reject« (i.e., refuse to accept the message, and also rat on its sender to the owner of the domain apparently being misused). The »reject« policy is useful for companies like PayPal, which have strict policies concerning what employees get to do with their @paypal.com company e-mail addresses, such as »Don't subscribe to mailing lists«, and can afford that kind of restriction. Such companies usually either make another, less strictly controlled, domain available to their employees so they can participate in work-related mailing lists, or else leave it to their employees to use a non-company address to participate in mailing lists on their own time. It is also useful to companies which do legitimate bulk e-mailing on behalf of other companies (think getting special offers from online merchants you patronise) and which would also like to prevent their addresses from being misused by spammers, as well as companies like Facebook which every so often will send you notifications that new kitten pictures have been posted to your wall, but don't want anyone to send you genuine-looking phishing-type messages in order to get at your user credentials. But on the other hand the »reject« policy is NOT useful for ISPs like AOL and Yahoo, where people take out @aol.com or @yahoo.com addresses to use for whatever they like (subject to the ISP's terms of use, of course), which presumably includes subscribing to mailing lists if your employer with their DMARC »reject« policy won't let you. The problems we've been seeing during the last few days stem from the fact that Yahoo and AOL have recently chosen to publish a »reject« policy for their main domains (like aol.com). This was done in response to a number of security breaches that let crooks retrieve large swathes of Yahoo and AOL user data (i.e., names, e-mail addresses, and so on, and in particular AOL users' address books), and is a fairly desperate attempt on the part of the ISPs to prevent the crooks from sending mail purporting to come from AOL users to people in those users' address books, but via different e-mail servers. This is something spammers like to do because people are more likely to open their messages if the sender looks familiar. (And it incidentally explains the spam-type messages we've been seeing from AOL-based [redacted] server subscribers like [name redacted] – who we all know is the upstanding type who would never actually send spam herself, so they're easy to ignore.) By publishing the »reject« policy, AOL tells all other members of the DMARC cartel to refuse to accept mail with a, say, »From: [log in to unmask]« header that doesn't actually come from an official AOL mail server. The DMARC cartel of course includes AOL itself, so after AOL published their new policy, any message to [redacted] server from an AOL subscriber wouldn't be seen by other AOL subscribers. (This happened back in April, but I didn't find out about it until one AOL user wondered why they weren't getting copies of their own messages back.) This move essentially prevents AOL (and Yahoo) users from participating in mailing lists such as [redacted] server unless the list operators do something to work around DMARC. It also causes messages from AOL/Yahoo users to generate large numbers of bounces from other AOL/Yahoo addresses, which can in turn cause those addresses to be unsubscribed from the list (because this is what list managers do; if your address generates bounces you get thrown out), which makes things even worse. What AOL and Yahoo are doing is abusing the DMARC »reject« policy, which as discussed above was originally intended to stop phishing and impersonation attacks on users of outfits such as Facebook, PayPal, banks, or industrial bulk-mailing companies, to paper over their own security issues, and hurting their own users in the process as well as making life more difficult for mailing list operators and the rest of the world. John Levine, a noted Internet mail expert, says »Unfortunately, in the process of slamming the barn door after the horse left, AOL and Yahoo have crushed a lot of small animals on the way.« [1] Incidentally, the official recommended way of dealing with the DMARC mailing list problem, if you're running a mailing list, is to prevent users with @aol.com or @yahoo.com addresses (or for that matter any domain that publishes a DMARC »reject« policy) from subscribing to the list in the first place, and of course throwing out all existing users with such addresses once that rule goes into effect. This is something I'm not yet prepared to do. The fix I'm using instead – rewriting the »From:« address to let [redacted] server take ownership of messages from the domains in question – has various downsides that we can probably live with, for the time being anyway, but I'm going to have to keep an eye on this to see how it plays out in the end. In the meantime I would still recommend that people move from AOL or Yahoo to reasonable e-mail providers who actually understand DMARC policies and use them correctly if at all. [1] http://jl.ly/Email/aoldmarc.html