Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

[Hector Santos <[e-mail]>]

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