[Mailman-Developers] Fixing DMARC problems with .invalid munge

[Mark Rousell]

Hi,

This is my first post here so please be gentle. I know I am risking
telling certain people how to suck eggs.

I'm not currently a Mailman user but will probably begin to use it soon.
I've followed the Mailman-Developers list for some time to familiarise
myself with how Mailman works.

Apologies also for the long message.

On 04/05/2014 19:08, Stephen J. Turnbull wrote:
>  > Advantages:
>  > 
>  > * Really fixes DMARC problems
> 
> That's a matter of opinion.  The DMARC-using domains will disagree, I
> think, as it still means that you are "impersonating" their users (see
> below), and making DMARC ineffective as a means of reducing spam and
> phishing.  But we'll see about that soon enough.

Surely that is a case of "so be it". DMARC (well, to be precise, Yahoo's
particular implementation of it combined with Yahoo's size in the
market) has broken longstanding and valid usage patterns and, for simple
practical purposes, needs to be routed around in a way that still
retains interoperability with Yahoo.

I do not think that this method of working around Yahoo's DMARC
implementation will necessarily impact the usefulness of DMARC as an
impersonated-spam/spoofing reduction tool. Whilst it can be argued that
adding ".INVALID" (or something similar, see also below) is still
impersonating Yahoo users, it can also be argued (more persuasively in
my opinion) that "yahoo.com.INVALID" or "yahoo.com.REMOVEME" or similar
is quite clearly not impersonating any valid Yahoo user *when sent from
a mail list*.

> Disadvantages:
> 
> The big one is that we can only guess what the long-run consequences
> are going to be.  In particular, I think in the short-run we can
> definitely foresee (1) spreading invalid addresses, which will bounce
> if automatically inserted as destination addresses, all over the net,
> possibly creating more backscatter

But who is going to be emailing using those addresses? Surely the only
people who would be emailing from such addresses for the purposes of
spoofing are spammers and any additional backscatter from such a source
would surely only be an incremental additional to the problem of
spamming. DMARC is, in any case, intended to reduce such backscatter.

> and (2) a tendency for people to
> see "@yahoo.com.invalid" as a *valid* form of Yahoo! address
> ("computers are so weird").

To my mind this is a valid criticism of the choice of words (i.e.
".invalid" can quickly start to be taken to be valid!) but not of the
idea in general.

Perhaps a better form of words can be found. For example:

.REMOVEME
.ThisMailProvidersDMARCImplementationIsBroken
.RemoveThisToEmail
.MungedForDMARCPleaseRemoveToEmail

In other words, something that non-technical end users will not so
easily become inured to.

> Tools, most of them simple, will be
> created to hide and to strip ".invalid" automatically, meaning you can
> hide any arbitrary domain from DMARC behind ".invalid".  Spammers and
> phishers will pick up on this

This is surely going to happen anyway if spammers want to harvest mail
lists as spam target sources or to harvest identities for spoofing
(which, as I understand it, is what DMARC is particularly intended to
prevent).

I don't see why it should affect mail lists and I don't see why it
should prevent DMARC from working to prevent impersonated/spoofed spam.
Indeed, it is the *removal* of suffixes like ".INVALID" (or whatever)
that DMARC is intended to eventually make worthless (not the addition of
them).

> Yahoo! gets what conspiracy theorists (Hi, Lindsay!) 
> think they want, namely locking their users into Yahoo! groups, but I
> think they're going to find that the opposite effect (of annoying
> their users so they move to a more flexible domain) is more important,
> and DMARC will fall of its own weight without leaving too much of a
> mark on the rest of the mail system.

Sadly I suspect that the vast majority Yahoo users will be entirely
oblivious to it.

Out of the very few (relatively speaking) Yahoo users who use services
which are impacted by Yahoo's p=reject DMARC implementation many will
blame the services themselves. The remaining few who understand the
issue will move away to better providers, but I suspect this will be a
negligible proportion of Yahoo's user base.

As far as I can see, DMARC is set to work as Yahoo and its other backers
intend for it. They have the market size to push it through regardless
of standards.

> OTOH, the natural response of the DMARC folks is going to be to try to
> control this.  I can't imagine, if they succeed in agreeing on how to
> do so, that it will cause less damage to interoperability than their
> current behavior.

But do they actually need to? As I understand it, they wish to use DMARC
to prevent spam that impersonates or spoofs their users or clients.
Spammers who strip off munged email suffixes and spoof-send using the
unmunged email address will indeed be blocked by DMARC.

By munging email addresses we are surely going along with the aim of not
meaningfully impersonating users of DMARC-using mail providers. We are
making it clear who the original sender is but in a form that does not
make it look like the email was sent by a third party spoofing the
original sender in question.

> and if
> we must we should limit it to what the "owners" of those addresses
> recommend.

The recommendations that dmarc.org makes for mailing list providers at
http://dmarc.org/faq.html#s_3 could be helpful in some cases but do not
address the full issue that adding a suffix is intended to work around
(and it is an issue which *needs* be to worked around somehow). That
said, adding a suffix is simply a variation of the suggestion in section
3 of the linked FAQ.

The reference in the FAQ to Original Authentication Results at
http://tools.ietf.org/html/draft-kucherawy-original-authres-00 looks
rather interesting too.

> Remember, the DMARC people are by and large employed by companies with
> *no vested interest* in the continued success of the email system,
> especially for forums: in most cases they'd be happier if mailing lists
> (and newsgroups) went away and their users were locked into their web
> forums.  We, on the other hand, depend very much on the smooth working
> of the email system -- the only effect of fighting fire with fire is
> to increase the damage *we* suffer from first- to second-degree burns.

And yet we need somehow to route around the problem they have caused us.
Adding suffixes seems like a kludge but a not unreasonable one and it is
also one that should not negatively impact DMARC or users of DMARC, as
far as I can see.

> If third parties' experiments with .invalid become overwhelmingly
> popular, then practically speaking Mailman will cave on an option to
> munge From by appending ".invalid" the same way it had to cave on
> Reply-To munging.

Would this really be a problem? If it become a de facto standard the all
well and good (but let's get the wording right). Mail providers such as
Yahoo could even play along with it by recognising it and it would not
negatively impact the effectiveness of DMARC from their perspective or
spam filtering, from what I can see.





-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162