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

[Alessandro Vesely <[e-mail]>]

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
--