On Thu, Nov 7, 2013 at 1:23 PM, J. Trent Adams <jtrentad...@gmail.com> wrote: > > 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).
That's good. DMARC does have a purpose in transactional emails. >> 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. Which .... appears to be working well for you, mr jtrentadams@<freemailer.tld> ;-) > 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. To be fair, Mailman doesn't modify the body, it does add footer attachments and follows existing RFC requirements for appending headers. I wouldn't necessarily classify that in the same way as RFC5322 From spoofing. > . . . 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. I'm not convince that email trust and security have any impact whatsoever on Mailman or MLMs in general. I believe you can have secure and trusted email (i.e. ibm.com) yet not break MLMs. -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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
