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

[Jim Popovitch]

On Thu, Nov 7, 2013 at 1:23 PM, J. Trent Adams <jtrentadams at 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.