Re: DMARC: perspectives from a listadmin of large open-source lists

> differ from the envelope sender. That's why the extra DMARC header
> X-Original-Authentication-Results [1] is needed sadly :-(.
Several people have proposed that, but a few minutes' thought reveals that 
it wouldn't actually help, becuase bad guys can add fake X-O-A-R headers 
just as easily as good guys can add real ones.  You would have to track 
which forwarders are well behaved and add valid X-O-A-R headers, but if 
you can do that, you can skip the header analysis and just whitelist the 
mail from the well behaved forwarders.
Note that there are also well behaved things that don't pass DMARC and 
don't have any original authentication results to report, with the usual 
examples being mail-an-article at the NY Times and Wall Street Journal.
Tracking who is well behaved is quite hard.  You can't ask people to 
self-identify, since again, bad guys will lie.  I was under the impression 
that gmail tried to do it, but given the blizzard of bounces I've seen, 
apparently not.
> The problem described WILL vanish when all mailing list apps implement
> DMARC, but until then, it's really broken.
Mailing list apps can't "implement DMARC" other than by getting rid of 
every feature that makes lists more functional than simple forwarders. 
Given that we haven't done so for any of the previous FUSSPs that didn't 
contemplate mailing lists, because those features are useful to our users, 
it seems unlikely we'll do so now.
If receivers want to implement DMARC policy, they need to make their false 
alarm whitelist first.  This appears to be a substantial, perhaps 
insurmountable, hurdle.
> At the same time, delaying mass usage of the reject policy would limit
> damage.
Reject policy is fine for domains that don't have individual human users, 
or for companies with firm staff policies that all mail goes through the 
company mail server, and employees don't join mailing lists and the like 
using company addresses, or the company provides a separate less strictly 
managed domain for its staff mail. Strict policies will never be 
appropriate for public webmail systems where the users will use their mail 
addresses any way one can use a mail address.  Yahoo appears to understand 
most of this, viz. the different domain for Elizabeth's company mail.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

smime.p7s
Description: S/MIME Cryptographic Signature