[Mailman-Developers] Mailman DMARC Support (it's not what you think!)

[J. Trent Adams]

Jim -

On 10/20/13 4:17 PM, Jim Popovitch wrote:
> Hello,
>
> Having read the archives, I see that (at least 6 of) you are aware of
> DMARC, or as I like to call it YAPFS. (Yet Another Panacea For Spam)
> :-)

Heh - If only DMARC was as successful at stopping spam as it is in
shutting down spoofed domain mail! Wow, that'd be fantastic. . . I'd
love to stop receiving unwanted solicitations. But that's not what it does.

As it turns out, DMARC has proven so remarkably successful at
eliminating spoofed domain phishing attacks. So much so that it's
already saving us a huge, non-trivial, amount of money per year (with a
trend line of savings that's continuing to increase). I wish we could
share the actual dollar value we're saving by protecting our customers,
but that information isn't public. Suffice it to say that it works (and
works tremendously well).

>
> Earlier this year Mark asked me to run by MM-Dev a patch that Phil
> Pennock and I collaborated on.  Mark, thank you for your valuable
> feedback, I have addressed all but 1 of those issues.
>
> Phil's and my take is that mailing lists, like MTAs, have no business
> modifying the From header; nor should mailing lists accept mail that
> they knowingly can't reflect.  To that end, we have added support for
> testing the From domain for a DMARC p=reject policy, and if it exists,
> allowing lists to Accept/Hold/Reject/Discard the message.

Here's my problem with this solution: it forces participants of mailing
lists to send from domains that do not have adequate protection against
spoofed domain attacks. Doing so then opens a hole in the defenses which
can then be abused.

I can speak to this from experience on email security for one of the
most phished brands (the most phished, if you trust APWG's reporting).
We set up an unprotected domain specifically for mailing lists, and we
watched that as our DMARC protection across our other domains came
online, the abuse on our unprotected domains increased. Finally, we'd
locked everything down other than the mailing list domain, and then it
became a primary target of abuse. . . which resulted in us having to
shut it down.

Now we're left participating on mailing lists using personal mail
accounts. As you can imagine, that makes many departments in the
organization really nervous for a variety of obvious reasons.

Sure, we're slightly unique in that we're highly susceptable to phishing
attacks, and a common abuse vector is domain spoofing. . . but as we
lock down our doors, we're seeing shifts by the attackers to other, less
protected targets. So, the problems that vex us today are beginning to
nip at the heels of the victims of tomorrow.

. . . and given the rampant problem of password reuse, any credentials
phished from an unprotected domain can easily be used to attack a domain
that is protected. Again, I wish I could share the numbers of these
types of attacks, but they're staggeringly large. And it's incredibly
annoying that our hands are tied since humans will do what humans do
(e.g. reuse passwords everywhere). Not good, that.

It's unfortunate that the real world infringes on the perfection of a
pure "reflector" architecture. I wish that solutions were beautiful and
unblemished. Sadly, reality is messy, and some consideration for
compromise is necessary for solutions to be effective.

Besides, mailing lists modify messages they "reflect" all the time. They
pre-pend list identifiers to the subject line (which makes my life much
easier), and also post-pend list management options (which is a
regulatory requirement in some jurisdictions).

So, if we want to be purists, no modifications should be allowed. But
that's taking the argument to an extreme. Instead, we should consider a
benefit analysis for each proposed change. And in this particular case,
as more senders are adopting DMARC each and every day for entirely valid
security and economic reasons, I believe that modifying the RFC5322.From
field is a perfectly reasonable option.

. . . unless someone can think of another clever way to maintain
effective end-to-end email authentication in a novel way? Perhaps
through the broader adoption of transitive trust (e.g. the Original
Authentication Results header)?

Anyway, thanks for your careful consideration, and I do look forward to
continuing to discuss viable options for keeping email as trusted and
secure as possible.

Yours,
Trent

>
> Here is the LP diff for your perusal:
> http://bazaar.launchpad.net/~jimpop/mailman/dmarc-reject/revision/1379?remember=1379&compare_revid=1374
>
> I will soon be porting this to 3.0, and I will return here for input
> on that as well.
>
> Thank you everyone for your valued opinions,
>
> -Jim P.
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/jtrentadams%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9