LISTSERV mailing list manager LISTSERV 16.0

Help for ARSCLIST Archives


ARSCLIST Archives

ARSCLIST Archives


ARSCLIST@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ARSCLIST Home

ARSCLIST Home

ARSCLIST  May 2014

ARSCLIST May 2014

Subject:

DMARC - back story ...

From:

CJB <[log in to unmask]>

Reply-To:

Association for Recorded Sound Discussion List <[log in to unmask]>

Date:

Thu, 15 May 2014 14:14:09 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (143 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager