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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]