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