On Mon 10/Jun/2019 21:23:26 +0200 Hector Santos wrote: > On 6/10/2019 4:17 AM, Alessandro Vesely wrote: >> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote: >> >>> Except that most users don't actually see that address because these days >>> most >>> MUAs only display the display address. >> >> >> We often came across this realization. Since DMARC hinges on that field, I >> think the spec should include some advice to MUA implementation. >> >> A trust on first use (TOFU) approach would seem to be possible. On getting >> the >> same display name linked to a different domain part, a user would be required >> to configure the MUA's behavior for this particular name / domain. >> >> Does this subject deserve a ticket? >> > > Don't you think we might repeat and come to the same conclusions regarding MUA > considerations in this regard? > > The primary concern would be 5322.From "Display" spoofing with the theoretical > Multiple 5322.From headers potential exploit. A 2010 proof of concept list > message example was showed it was possible to contain a valid DKIM signature > and with a spoofed From display from "President Obama:" > > http://mipassoc.org/pipermail/ietf-dkim/2010q4/014680.html > > This created a long threaded discussion, and if I recall, the topic was > repeated a few years later where I believe we had a consensus this was a > "RFC5322 Boundary Layer" issue where the MSA/MDA or the backend would be > better > at handling the RFC5322 "validity" of an inbound message. It would be a good > idea for receivers to do RFC5322 checking anyway instead of "passing the buck" > to the many different MUA vendors including the many legacy MUAs people still > enjoy today. > > If any protocol guidance is necessary here, IMO, it would be to repeat the > suggestion for RFC5322 validity/security checks SHOULD be done at the backend > to better protect the MUA end users using different Offline, Online and > Hybrids > models of MUAs. An inbound message with multiple 5322.From headers SHOULD be > invalided, rejected or discarded.
+1, waiting until everybody signs From:From: is a bit... long-winded. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
