Subject: Re: [dmarc-ietf] Mandatory Sender Authentication

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 03 Jun 2019 10:29:44 -0400

-------- Original message --------From: "Douglas E. Foster" <[email-masked]> Date: 6/3/19  9:59 AM  (GMT-05:00) To: [email-masked] Subject: [dmarc-ietf] Mandatory Sender Authentication Our real goal needs to be mandatory sender authentication.    Any secure email gateway must go through these steps:

	Source Analysis:  Filter message from unwanted sources
	Sender Authentication:  Filter messages that are attempting impersonation
	Content Analysis:  Filter messages with unwanted content

Content filtering always requires exceptions, and those exceptions are granted based on the sender.   Such exceptions are only safe and appropriate if the sender is verifiable.    If the exception is applied to an unverified sender, it is possible for a spamming impersonator to gain the elevated trust and reduced filtering which was only intended for the trusted sender.

So Sender Authentication needs to become mandatory:

	Senders MUST implement SPF or DKIM,  and SHOULD implement both.  Although the MX list becomes a default SPF list for those who do not publiish a policy.
	MTAs MUST ensure that DKIM signatures remain verifiable.  If they are unwilling or uinable to do so, they should reject the message with a PermError.
	Forwarders MUST either forward with breaking DKIM signatures, rewrite messages under their own identity, refuse the message, or discard the message as spam.
	IETF MUST provide a way for intermediate systems (both spam filters and list fowarders) to insert content under their own signature, without breaking original signatures.    This will have implications for MUAs..

Sure it will be hard, but has this not been what you have been trying to achieve for 15 years?  SPF and DKIM provided the enabling technology, but they were deployed as sender options.

Doug Foster

---

From: "John R. Levine" <[email-masked]>
Date: 3 Jun 2019 16:44:05 +0200

> Our real goal needs to be mandatory sender authentication.

No, that's a well known FUSSP.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Mon, 03 Jun 2019 16:04:10 -0400

On 6/3/2019 10:29 AM, Douglas E. Foster wrote:

>   * Senders MUST implement SPF or DKIM,  and SHOULD implement both.
>     Although the MX list becomes a default SPF list for those who do
>     not publiish a policy.
>   * MTAs MUST ensure that DKIM signatures remain verifiable.  If they
>     are unwilling or uinable to do so, they should reject the message
>     with a PermError.
>   * Forwarders MUST either forward with breaking DKIM signatures,
>     rewrite messages under their own identity, refuse the message, or
>     discard the message as spam.
>   * IETF MUST provide a way for intermediate systems (both spam
>     filters and list fowarders) to insert content under their own
>     signature, without breaking original signatures.    This will have
>     implications for MUAs..
>
> Sure it will be hard, but has this not been what you have been trying
> to achieve for 15 years?  SPF and DKIM provided the enabling
> technology, but they were deployed as sender options.

Hi Douglas,

It's ideal, but not the SMTP realities.

- In certain areas, some things are already "mandatory" depending on 
the business, for example, a Bank may be required by their auditor to 
use SPF Hard Fail -ALL policy in the same way a bank must be PCI 
compliant via the web which basically means SSL, session management 
and other security-related requirements.

- You can't enforce anything beyond legacy RFC821/5321 transactions 
under Port 25 SMTP operations.  You can only raise the email bar with 
NON-PORT 25 operations like when using the Message Submission protocol 
(RFC6409) which is port 587.  For example, the Extended SMTP (ESMTP) 
AUTH protocol is not required under Port 25. It is optional to 
implement and optional to use by the client.  Under Port 587,  ESMTP 
AUTH is a requirement among other things the receiver can enforce 
which are not required under port 25 operations.

- We can not have a mandate for DKIM POLICY because there is no 
official IETF standard here and even if there was, it would not be 
enforcible under Port 25.  That's not the same as a domain having a 
restrictive policy, it fails and the receiver honors and rejects the 
mail.  The Receiver can not enforce the sender to have a DKIM or any 
sort of policy above and beyond legacy SMTP port 25 operations.  It 
can not reject a message on the basis the sender does not have SPF or 
DKIM or DMARC.

- Keep in mind, SPF Hard Failures are generally good enough and can be 
mutually exclusive of a restrictive DKIM Policy.  For example, I just 
did some emailing with a bank which uses SPF -ALL (Hard Fail) but has 
no DKIM signature nor DMARC policy. For exclusive high value domains, 
an SPF -ALL is often good enough.  Even if it had a DKIM/DMARC 
p=reject policy, how will that change a -ALL failure?  Why would a 
bank override a SPF -ALL failure with with DMARC (or ARC) and raise 
the fussiness of the transaction?  I am sure there is possible a 
scenario where a SPF -ALL defined IP is doing something different with 
the PAYLOAD and could fail a DKIM signature.  But the reason you may 
see a domain with SPF -ALL and not DKIM is because it is good enough.

- Without port 25 operations, we would no longer be able to receive 
unsolicited messages from anyone, good or bad which is the blessing 
and the curse of standard SMTP port 25 operations.

The general rule of thumb for SMTP has been that for unsolicited mail 
from "unknown" addresses, authenticated and/or authorization is not 
required when targeting a local recipient or locally hosted domain. 
But for relaying mail (receiving a message to be routed, relayed to a 
remote target), some level of authentication is required and in the 
history of SMTP, that has been:

  - Having some form of an "Allow IP Relay" database/table.

Your network provider saves the connection IP in a table allowing for 
relay.

But as the roaming user problem began where the client's IP can 
change, an early method called POP B4 SMTP was common.

  - POP b4 SMTP worked on the basis a MUA will generally pop first 
before sending
    email and this allowed a small temporary "Allow IP" window for the 
SMTP client
    to send mail.  So the POP3 client connected to a host, the IP was 
saved while any
    new mail was picked up.  If the MUA had mail to send out, the 
client IP would
    be known by the SMTP receiver and allow the client to relay mail.

This was a god-send for tech support before ESMTP AUTH came along and 
becamewide spread:

  - ESMTP AUTH allows a way to login with ID and Password from 
anywhere. No IP required.

Since ESMTP AUTH is an extension for PORT 25, it is not requirement.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Tue, 4 Jun 2019 09:23:23 +0200

On 6/3/2019 4:29 PM, Douglas E. Foster wrote:
> 
> Our real goal needs to be mandatory sender authentication.    Any secure 
> email gateway must go through these steps:

1. By 'sender', which actor in the sequence do you mean?  The term is 
highly ambiguous.

2. Your certitude presumes an empirical foundation, given how often good 
theory does not make good practice.  People have been working in this 
space for a very long time and one might have expected the industry to 
have latched on such a simple requirement were it that clear it was 
/the/ essential requirement.  Please document the basis for your certitude.

3. What made you think that 'sender' authentication is not already 
happening at a sufficient level?  What is the basis for believing it 
isn't already being used by filtering agents well enough?

4. Consider the limitations to 'sender' authentication.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 6 Jun 2019 13:09:02 -0400

highly ambiguous.
  
 By Sender Authentication, I mean message "From Address" authentication.   
This involves two rules:
  	The sending IP address is known to be authorized to send for the SMTP 
Sender-Address because of MX or SPF, and  	the SMTP Sender-Address is known 
to be authorized to send for the message from Address because of either  	 
		domain alignment or  		a verifiable DKIM signature for the domain of the 
message From-Address.   	

 The message From-Address is what the user sees, so it seems important to 
know that the user is not being deceived by an impersonator.

 What I actually intend is that "a recipient has a viable option to 
implement mandatory sender authentication."
 This i equivalent to enforcing basic DMARC rules whether the sender has a 
DMARC policy or not.   This requires:
  	An email filter that understands SPF, DKIM, and DMARC. 	An email filter 
that provides local policy options to detect, evaluate, and override false 
positives. 	A sufficiently low level of false positives that the recipient 
organization is willing to commit the administrative resources to 
investigating and correcting false positives. 
 These conditions are sorely lacking, as explained in the next section.

 I have been doing a market survey, and it suggests that many vendors do 
not understand the problem or do not believe it needs to be solved.  I 
began with these minimal screening requirements:
  
 Source filtering:
    Able to block based on both IP address and Reverse DNS. 
  
 A surprising number of vendors only supported one of these filters.
  
 Sender authentication:
    Able to enforce sender DMARC policies.   (No requirement to support 
feedback processing)
    Able to override an incorrect SPF policy using a multi-factor rule 
(source server + sender domain).
  
 A surprising number of devices that supported DMARC filtering could not do 
ReverseDNS filtering.
  
 More recently, I realized that the only effective way to correct an SPF 
policy is to use SPF syntax.   I have not yet seen any product that does 
so, but I have more products to review.
  
 For the first pass, I had no filtering criteria related to content 
filtering.
  
 Results
 ----------
 These vendors could not meet all four criteria:
  	Barracuda (appliance, hybrid, and cloud products) 	Sophos (3 appliance 
products, 2 cloud products) 	Edgewave 	Forcepoint 	Fortinet 	Trend Micro 
	Dell SonicWall 	Symantec 	SpamExperts / SonicWall Mail 
 Some of these were evaluated based on reviews of the administrative 
manuals, others based on a sales process.
  
 On the higher-end solutions:
  
 I discounted Cisco Talos and Proofpoint because their secure email 
solutions do domain spoofing.
  
 BAE Solutions was dropped because their sales process required me to sign 
a non-disclosure agreement.   Based on what we did discuss, it did not 
appear that they could meet the four requirements.
  
 Kaspersky was ignored because of mistrust of the Russian government.
  
 The following products appeared to meet the minimum requirements, but for 
most of them I do not have access to the administrator manual until I 
commit to a product trial.
  	Cloudswift 	Mimecast 	Fortinet 	FireEye 
 I am in early discussions with AT&T / MessageLabs, but have no asssessment 
yet.

 >> 4. Consider the limitations to 'sender' authentication.

I am spending a lot of time thinking about the limitations of sender 
authentication.   For a spammer domain, SPF / DKIM / DMARC are easy.   For 
impersonation, Friendly Name and embedded logo images can be pretty 
effective without violating SPF / DKIM / DMARC.
  
 This means that Sender Authentication may produce more false positives 
than true positives.   Given the labor cost of addressing the mistakes, it 
is an open question whether the effort is worthwhile.   For the moment, I 
am hoping so.  I manage two very different mail streams, and the one that 
has higher spam levels appears to benefit from enforcing SPF and DMARC.  
Neither environment has products with adequate tools for implementing SPF 
exceptions, so I do not know how long I can leave the features enabled.   
Since you are involved in the Sender Authentication standards process, I 
assume you agree that Sender Authentication has potential to add value.
 
 To minimize false positives, I would like to see:
  	Pressure on list forwarders to either not break signatures, or follow 
the IETF example of replacing the original from with the list domain and 
signing the new message with the list domain.
	  	Advice to senders to reduce signature complexity.   In the general mail 
stream, the purpose of the DKIM signature is to authenticate the sender, 
and the protected data serves the purpose of a unique key for the signature 
process, to prevent replay attacks.   Uniqueness should be achievable using 
three headers:  To, From, and Date.   Subject and Message-ID should not be 
used as they are two fields that are likely to be altered in transit.    
(Using DKIM signatures for content validation is only viable if the sender 
is known with confidence and an exception management process is in place.  
These conditions may exist for specific sender-receiver pairs, but they 
will not exist as a default condition.) 
 But I have already been told that IETF is not interested in Recipient 
product problems, and is not concerned with security, which has left me 
very disappointed.

 Doug Foster

---

From: Dotzero <[email-masked]>
Date: Thu, 6 Jun 2019 18:30:45 -0400

Comments in-line.

On Thu, Jun 6, 2019 at 1:47 PM Douglas E. Foster <
[email-masked]> wrote:

>    - The sending IP address is known to be authorized to send for the
>    SMTP Sender-Address because of MX or SPF, and
>    - the SMTP Sender-Address is known to be authorized to send for the
>    message from Address because of either
>       - domain alignment or
>       - a verifiable DKIM signature for the domain of the message
>       From-Address.
>

This is absolutely incorrect. Making sweeping generalizations leads to bad
outcomes. There are MUAs that show the display name.

>    - An email filter that understands SPF, DKIM, and DMARC.
>    - An email filter that provides local policy options to detect,
>    evaluate, and override false positives.
>    - A sufficiently low level of false positives that the recipient

I think you should create such a product. You can then compete in the
marketplace of ideas.

> began with these minimal screening requirements:

The IETF is focused on interoperability. What you are proposing in this
section is that somehow the IETF can force vendors to implement
features/functionality in their offerings that is not related to
interoperability. If their customer were clamoring for it I guarantee you
that it would be on their product roadmap.

>    Able to block based on both IP address and Reverse DNS.

There's this crazy thing called RPZ. It is commonly used with RBLs. You
might want to take a look at it.

> (source server + sender domain).

A receiving system can implement whatever local policy it wants. As far as
I know, there is no Internet police to enforce your demands on what local
policy is implemented.

>    - Barracuda (appliance, hybrid, and cloud products)
>    - Sophos (3 appliance products, 2 cloud products)
>    - Edgewave
>    - Forcepoint
>    - Fortinet
>    - Trend Micro
>    - Dell SonicWall
>    - Symantec
>    - SpamExperts / SonicWall Mail
>
>    - Cloudswift
>    - Mimecast
>    - Fortinet
>    - FireEye

I'm sorry to burst your bubble, but the Internet is not all about your
personal needs, wants and desires.

> effective without violating SPF / DKIM / DMARC.

Contrary to your opinion, email authentication is not about stopping
spammers. For example, DMARC was created to mitigate direct domain abuse in
the mail stream. In fact, miscreants were quicker to adopt SPF/DKIM and
DMARC than legitimate senders. This did have the effect of allowing the
assignment of reputation to sending domains.

> assume you agree that Sender Authentication has potential to add value.

How large a corpus of mail did you evaluate in making your assertion about
false positives versus true positives? I assume you are aware that there
are people on this list who have examined varieties of different types of
mail streams comprising a corpus of billions of emails.

>    - Pressure on list forwarders to either not break signatures, or
>    follow the IETF example of replacing the original from with the list domain
>    and signing the new message with the list domain.
>
>    - Advice to senders to reduce signature complexity.   In the general
>    mail stream, the purpose of the DKIM signature is to authenticate the
>    sender, and the protected data serves the purpose of a unique key for the
>    signature process, to prevent replay attacks.   Uniqueness should be
>    achievable using three headers:  To, From, and Date.   Subject and
>    Message-ID should not be used as they are two fields that are likely to be
>    altered in transit.    (Using DKIM signatures for content validation is
>    only viable if the sender is known with confidence and an exception
>    management process is in place.  These conditions may exist for specific
>    sender-receiver pairs, but they will not exist as a default condition.)
>
>
I love when someone who self admittedly has little or no experience in a
subject such as email standards and interoperability joins a list and
starts lecturing people on how things should/must be.

> product problems, and is not concerned with security, which has left me

And yet you persist. If you have a product problem you really need to speak
with your vendor. If no vendor supports your needs then perhaps you might
consider it a market opportunity and do a startup. There are participants
and workgroups within IETF that are concerned with security, but perhaps
not with your notion of what security should be. Use TLS much?

Have a good day and good luck with your endeavors.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Sat, 8 Jun 2019 09:49:03 -0700

On 6/6/2019 7:09 PM, Douglas E. Foster wrote:
>   * The sending IP address is known to be authorized to send for the

MX does not 'authorize' sending by an IP address, although some 
receivers do check for MX as a heuristic.  But a heuristic is outside of 
any 'standard'.

SPF does register IP to domain name for sending.

>   * the SMTP Sender-Address is known to be authorized to send for the

Sorry, but the term "SMTP Sender-Address" does not have any specified or 
reliable meaning.

>       o domain alignment or
>       o a verifiable DKIM signature for the domain of the message
>         From-Address.
> 

I assume you mean the RFC5322-level From: field, as opposed to the 
RFC5321-level Mail From command.  Except that most users don't actually 
see that address because these days most MUAs only display the display 
address.

As for end users being deceived, there's quite a bit of experience that 
showing users indicators doesn't alter their behavior.

> implement mandatory sender authentication."

I don't understand what it means to have an option to implement 
something that is mandatory.  It's mandatory.

Also by saying 'recipient' rather than 'receiver' you appear to be 
indicating the end users will do meaningful filtering based on this kind 
of information.  They won't.

> This i equivalent to enforcing basic DMARC rules whether the sender has 
> a DMARC policy or not.   This requires:

That means you are seeking to alter fundamental email semantics by fiat, 
globally.  Surely you jest.

> authentication.   For a spammer domain, SPF / DKIM / DMARC are easy.  

What do you mean?

>   For impersonation, Friendly Name and embedded logo images can be 
> pretty effective without violating SPF / DKIM / DMARC.

That's correct.  And there has been extensive discussions looking to do 
something about that but there are no proposals on the table, because so 
far none has looked viable.

> This means that Sender Authentication may produce more false positives 

No it doesn't.

The existing authentication mechanisms do a good job of authenticating 
what they are authenticating.

It appears that you are seeking to use the information far beyond what 
is valid.

>   * Pressure on list forwarders to either not break signatures, or
>     follow the IETF example of replacing the original from with the list
>     domain and signing the new message with the list domain.

You want to bring pressure on list processing developers and/or 
operators.  Good luck with that.

>   * Advice to senders to reduce signature complexity.   In the general

What does that mean?  What specific proposal do you have?

>     mail stream, the purpose of the DKIM signature is to authenticate

You appear to misunderstand the semantics of DKIM.  Please re-read its 
specification and supporting document, because they have simple, concise 
language about what it does.

> product problems, and is not concerned with security, which has left me 

I suspect you have been told nothing of the sort.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Jun 2019 10:17:45 +0200

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?

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Jun 2019 15:23:26 -0400

> 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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jun 2019 13:17:01 -0700

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

> A trust on first use (TOFU) approach would seem to be possible. 

In practical terms, what does that mean?  Who does what, exactly?  What 
is the basis for believing anyone will actually do it?

>  On getting the

Specifying user behavior is both outside the usual scope of IETF work 
and a task with frustratingly poor utility.

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

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Jun 2019 17:12:45 +0200

On Mon 10/Jun/2019 22:17:01 +0200 Dave Crocker wrote:
> 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.

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

> 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-masked] via Bug Tracker" <[email-masked]>

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.  Second,
because checking example.org rather than example.com, in the example, would
defeat the only workaround for indirect mail flows which seems to be working
thus far.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Jun 2019 17:24:36 +0200

On Mon 10/Jun/2019 21:23:26 +0200 Hector Santos wrote:
> 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:"
> 
> 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
--

---

From: Hector Santos <[email-masked]>
Date: Tue, 11 Jun 2019 12:38:15 -0400

>      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 class of email addresses are equivalent to one another, in order to avoid

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.

> 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

---

From: Дилян Палаузов <[email-masked]>
Date: Tue, 11 Jun 2019 17:01:30 +0000

Hello Alessandro,

>     o  The authentication status of the message should be visible.

For DMARC policy reject, the failed status will not be visible in the MUA, because the mail will not reach the
recipient.  Likewise for the policy quarantine, because this policy means “do not deliver” (and do not reject, but do
something different).

So if the DMARC evaluation status for policies Quarantine or Reject is shown, it will be PASS.

For policy None, I doubt that showing the authentication status has added value.

So if the MUA shows the status for DMARC it will be PASS.  When will showing the DMARC status to the user have added
value for her?

For SPF status... you know that redirects, if the MUA shows “failed SPF”, what shall the user conclude?

For DKIM evalution, that was not covered by the DMARC policy above, you suggest that the MUA shows "DOMAIN: FAIL/PASS". 
If it passes, then it is good.  But what shall be the conclusion made by the user, if the DKIM for a domain shows FAIL
(or missing DKIM-Signature header)? 

Regards
  Дилян

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Jun 2019 10:28:58 -0700

>      o  In the MUA, it is safe to only show the display name if its

Sorry, but I asked for evidence of utility.  My guess is that you are 
only thinking in terms of information theory, rather than human factors 
usability.  These produce very, very different results.

To my knowledge, there is no empirical evidence at all of what 
RFC5322.From display strings are safe or dangerous to show.

>      o  The authentication status of the message should be visible.

Why?  What's your empirical evidence of utility for this?

> actually stands for something else.

I suspect you are not familiar with a related effort that was pursued 
for the web, distinguishing domain names that had ave been vetted vs. 
those that have not.  It did not go well.

> a class of email addresses are equivalent to one another, in order to avoid

What makes you think users want to do this extra work or that they will. 
  Evidence to date is that they don't and won't.

d/

---

From: "Stan Kalisch" <[email-masked]>
Date: Tue, 11 Jun 2019 16:08:14 -0400

> What makes you think users want to do this extra work or that they will.

Yes. Users have to be 1) made aware of an argument in favor of the extra work in the first place and, and, 2), after that, convinced of that argument in favor of the importance of that extra work. Like it or not, they're not.

I mean, I'm just imagining a stay-at-home parent with three kids who only knows their phone is beeping at them while they're trying to get said kids into the car to go to urgent care because one is throwing up. The beeping is just going to make them mad and you're not even going to make it past step 1.

> Evidence to date is that they don't and won't.

Indeed.

Stan

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Jun 2019 10:54:46 +0200

On Tue 11/Jun/2019 18:38:15 +0200 Hector Santos wrote:
> 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?

To verify domain hierarchy might be possible, but cumbersome.  Section 1.6 of
the rfc says "valid use of the header field requires removing any occurrences
of it that claim to be associated with the ADMD".  IMHO that is the minimal
requirement.  I find it handy to remove /all/ existing A-R fields[*].  That
way, you can tell the MUA to just trust A-R in the messages retrieved from such
account.

[*] Actually, the server renames them Old-Authentication-Results, so they're
visible when you manually watch the headers.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Jun 2019 10:58:07 +0200

On Tue 11/Jun/2019 19:28:58 +0200 Dave Crocker wrote:
>>>>> Except that most users don't actually see that address because these days
>>>>> most MUAs only display the display address.
>>>>
>>>>
> Sorry, but I asked for evidence of utility.  My guess is that you are only
> thinking in terms of information theory, rather than human factors usability. 
> These produce very, very different results.
> 
> To my knowledge, there is no empirical evidence at all of what RFC5322.From
> display strings are safe or dangerous to show.

I relied on the exception raised in the first quote above.

Actually, the reason why DMARC requires alignment of SPF identifiers is because
"These may be different domains, and they are typically not visible to the end
user."[*]  If the RFC5322.From domain is also not visible to the end user, that
argument is moot.  Yes, that's just theory...

[*] Section 3.1.  Identifier Alignment

> Why?  What's your empirical evidence of utility for this?

Well, I personally use it and sometimes find it useful.[†]  For a better
statistics, I have a DKIM add-on whose purpose is just to display some
authentication status.  With 10,107 users, it ranks 61st of 1,339 in
Thunderbird's most popular extensions.

[†] I tag _nopass_ messages not matching /^Authentication-Results:.*pass/ and
color them gray in the thread pane.  Many of them can be deleted w/o opening.
(But then I have more pass'es than DMARC provides for.)

> Evidence to date is that they don't and won't.

I imagined the MUA would prompt the user something like so:

     __________________________________________________
    |                                                  |
    |  "John" appears to be the same in                |
    |                                                  |
    |  <[email-masked]>, <[email-masked]>,  |
    |  and 23 other addresses.                         |
    |   _                                              |
    |  [_]  They're all the same person                |
    |  [_]  Always display the address of "John"       |
    |                                                  |
    |                                                  |
    |     [ FRAUD ]                     [  OK  ]       |
    |__________________________________________________|

The user can thus arrange the address book with two clicks.
Would that work?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Jun 2019 10:58:41 +0200

On Tue 11/Jun/2019 19:01:30 +0200 Дилян Палаузов wrote:

> So if the MUA shows the status for DMARC it will be PASS.
If there's nothing but DMARC-validated messages, then the spec can't get any
better than that.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 12 Jun 2019 17:14:13 +0800

> (But then I have more pass'es than DMARC provides for.)

Are you suggesting that you are a good proxy for a "typical" user of any
random MUA?

Incredulously,
  Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 Jun 2019 12:15:43 +0200

On Wed 12/Jun/2019 11:14:13 +0200 Kurt Andersen (b) wrote:
> On Wed, Jun 12, 2019 at 4:58 PM Alessandro Vesely
> 
> 
> Are you suggesting that you are a good proxy for a "typical" user of any random
> MUA? 

Ten thousand users are certainly more typical than me.  Yet, it might be
interesting to know how we —the community discussing and implementing email
authentication— are actually using it in our own email accounts.  Do you see
the authentication state of this message?

Best
Ale
--