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@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%40gma...

Security Policy: http://wiki.list.org/x/QIA9