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

[Hector Santos <[e-mail]>]

On 6/11/2019 11:12 AM, Alessandro Vesely wrote:
> On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote:
>> On 6/10/2019 1: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.
>>
>> Unfortunately there is no 'advice' to give that has any utility.
>>
>> If you feel otherwise, please try to formulate it, including the basis for
>> believing it useful, and then try to get community support for it.
>
>
> I'd propose bullets like the following for Section 12.4:
>
>      o  In the MUA, it is safe to only show the display name if its
>         correspondence to the email address can be verified by looking it up in
>         the address book or similar storage.  In case a display name compares
>         equal to one that corresponds to a different email address, such
>         discrepancy should be enhanced unless the two email addresses are
>         established to be equivalent to each other.  Email addresses are
>         equivalent when they correspond to the same person, or to the same role
>         within a given organization, or, in practice, when the user says that
>         they are.
>
>      o  The authentication status of the message should be visible.

These are good for a online MUA system where the backend has both 
verification and display controls.

With an offline MUA, where we have store and forward, there is the 
"who was the verifying domain" trust issue. If the backend is not 
going to clean it up, make it safe for the user's MUA to pick the 
mail, then it has wider chance of user security concerns and issues 
due to lack of persistency and consistency in offline MUA behavior. 
With a hybrid, the MUA is more in sync with the backend operations, so 
rather than the MUA doing the calculations based on the data it has, 
the backend supplies the indicators, public or proprietary, for the 
compliant hybrid MUA to display.

As a developer of MUAs, offline, online and a hybrid, with Native Gui, 
Text-based (ANSI/VT100) and HTML-based Messaging UIs, there has been 
many single sourcing and integration considerations.   Overall, we 
only have open standard RFC5322 protocol to communicate between the 
MSA/MTA/MDA and MUA.  I think the "battle" or "dilemma" has been the 
trust of the A-R header verifying.domain" header created by the MDA 
mail receiving/inbound components performing the DKIM verification. 
Can the MUA trust the verifying.domain?  A possible MUA design tip 
could be to add something equal to:

   [_] Trust the Authentication-Result Verifying Domain IFF it matches the
       the Authentication Login (Mail Pickup) Domain Server.

or something along those lines.  With the MUA I used personally 
(TBIRD), I created a rule to highlight, color tag the  Pass (Green) 
Fail (Red) DKIM results read from my backend verifying domain A-R 
header. Others A-R beader are ignored.

Each MUA can implement this idea their own way. But it is important to 
consider the different MUA designs. With Online, like a Web-Mail 
interface, this offers 100% backend UI design controls, single sourced 
and safer for the end-user.  It is easier to explore the integration 
requirements.  With offline/hybrid MUA system needs are more complex 
and the ideas will need to be translated into a RFC5322 meta-headers. 
   Of course, the offline MUA can do the DKIM verification itself.  It 
has always been in interesting idea to see what comes about.  While I 
recall some earlyr 3rd party Add-on attempts, I personally have not 
see too much in this area with MUA vendors themselves.    We won't see 
persistency and consistency here.   Hybrids is what I expect more to 
happen where the backend can add more "meta-data" designed for the 
proprietary hybrid MUA to understand, and its not just for DKIM 
security but a broad range of MUA A/A concepts.

>>> A trust on first use (TOFU) approach would seem to be possible.
>>
>> In practical terms, what does that mean?  Who does what, exactly?
>
> A discrepancy can be enhanced by bold characters, by a pop-up, or by a beep and
> an alert message.  Anything but silently displaying a familiar name which
> actually stands for something else.
>
> A user can then arrange her address book so as to make it clear to the MUA that
> a class of email addresses are equivalent to one another, in order to avoid
> meaningless alerts.

Good ideas for MUA implementations, not sure how we can standardize 
this though. Lots of psychology involved. In fact, with the Red/Blue 
color tagging I've have in Tbird,  I haven't been paying too much 
attention to the RED tags I see
due to DKIM verification failures.  If I see both a red and blue, that 
tells me most likely an original DKIM signature was broken (RED) but 
it was resigned with 2nd list server signature (GREEN).

For Private 1 to 1 communications, I would not expect to see RED here 
because there should be no middle ware interference, but there are 
non-list related indirect scenarios that can cause this.  I wouldn't 
expect it though.

>
>
>>> Does this subject deserve a ticket?
>>
>> Since it has nothing to do with errors or problems with the current spec, I
>> don't see how to justify a ticket.
>
>
> Section 12.4 seems to have some problems.  The first bullet should be reworked,
> because it can be understood as suggesting that in cases like, for example:
>
>      From: "[e-mail] via Bug Tracker" <[e-mail]>
>
> a _MUA_ should "execute the DMARC mechanism on the domain name found there
> rather than the domain name discovered originally."  That sounds nonsense,
> first, because MUAs should rather base on A-R records added by the MX.

This is what I meant above.  You are proposing a trust concept for the 
MUA on which A-R record to "believe."

The MUA needs trust on the meta-data headers it sees.  In theory, it 
could trust (with higher confidence) the headers added by the user's 
mail hosting provider or the server the user logged into, or basically 
the last processing machine at the hosting provider.

Maybe Murray can comment on this, I don't recall seeing a discussion 
where the A-R verifying.domain was tied to some trusted hosted domain 
we have confidence in.  Can the MX or MDA domains be associated with 
the A-R verifying the domain?

Right now, the only A-R header that can be trusted is the last one 
created by the receiving domain for in-house use, or a Web-mail 
interface or for a hybrid.  For a offline reader, the user will need 
to make that the RFC5322 scripting designs or the advanced MUA can 
offer an option to make that trust association.

-- 
HLS