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
