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.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
