Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 03 Jun 2020 00:45:54 GMT

I don't understand why this topic is debatable.

We are faced with a constant stream of mail which we do not want. We need to block the nuisance stuff as well as the dangerous stuff, so that the important stuff gets processed in a timely manner, and so that our labor efforts can be spent on things more productive than reading nuisance emails. Ergo, if a message contains a lie, I want to block it. If the identifier is a lie, the content will not be any better. IETF settled on standards for filtering identifiers because it is simply more feasible than filtering free-form text.

As to consequences: Was no one present during the 2016 election cycle, when a phony GMAIL password reset compromised a U.S. Presidential campaign? I'll admit that I have not seen that specific message's From header, but supposedly it convinced John Podesta and his I.T. person, so I am pretty confident the From domain was "@gmail.com", not [email-masked]"

Someone said that the Sender Address is all we can trust. Nonsense. The only thing that is "true" in an email header is the IP Address, and that is true only if the recipient assumes that no nation state has a NAT-translating device in front of their internet connection. Everything else can and will be fraudulent at times.

As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From Header represents the "speaker", the person whose ideas are being represented by the content. It matters if someone puts words in someone else's mouth, and From fraud is exactly that type of fraud.

It is reasonable to require senders to demonstrate authority to speak on behalf of someone else. DMARC provides two ways to demonstrate that authority: if there is domain alignment, the implication is that the security environment of the sender domain has chosen to allow one sender to act as agent for another, because it would be in their power to prevent him from doing so. Therefore intra-domain agency is not a significant concern to the recipient. However, when the sender address (login account) represents a different security domain than the sender address, the recipient has no reason to ignore the discrepancy. The DKIM signature is the alternative credential which demonstrates authority to send on behalf of the From address entity..

I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibits authorship, or creates any other attribution problem. This assertion was simply not explained.

Feel free to do this test to see if From address matters: Start sending inflammatory stuff with a From address @WHITEHOUSE.GOV to major news organizations or foreign governments around the world. See how long it takes the Secret Service to pay you a visit.

As to visibility: The business world still runs on Microsoft Outlook, and Outlook presents the From Address when a message is read. So it is odd to assert that no one ever sees that data. The real scandal is that the Sender Address is never displayed. It would be very interesting if MUAs would say
From: [email-masked]
by: [email-masked]
Whose ideas was it to keep the sender secret?

If the integrity of identifiers does not matter, why are we here?

Doug Foster

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Jun 2020 23:28:08 -0400

On 6/2/2020 8:45 PM, Douglas E. Foster wrote:

> Someone said that the Sender Address is all we can trust. Nonsense.

+1
>
> As to identifiers: The RFC 5321 MAILFROM sender is intended, at least
> in my understanding, to represent the login account used to create the
> message, while the RFC 5322 From Header represents the "speaker", the
> person whose ideas are being represented by the content. It matters if
> someone puts words in someone else's mouth, and From fraud is exactly
> that type of fraud.

You bring up a basic fundamental reason what the 5322.From field is 
the only signature binding requirement for DKIM.  When it comes to 
exclusive mail, it is the anchor that is associated with:

- Login Account
- The Alias or Display Name,
- The Default From name for local messages

and if the message is exported for a network mail system then we have 
the additional related identities:

- 5322.From
- 5321.Mail From

In the restrictive DKIM Policy Model, all these identities are closely 
tied together. They are usually represented and traceable to one 
person and thus illustrating the long time "Proof Of Concept" that a 
restrictive DKIM Policy is so powerful, "It's Scary!"  A break or 
deviation from this expectation is a strong candidate for rejection.

> I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322,
> inhibits authorship, or creates any other attribution problem. This
> assertion was simply not explained.

I believe they are simply catching up with the list problem. Thats all.

The problem was recognized long ago with SSP, ADSP. But when ADSP was 
abandoned for these lists problem and replaced with DMARC, the list 
problem was no longer a concern but DMARC did not resolve the list 
problem and it appears DMARC "Proposed Standard" will not try to 
address it.

-- 
HLS

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 04 Jun 2020 10:31:51 GMT

MAILING LISTS.

The mailing list problem can be stated as follows:
Domain B wants to operate a mailing list.The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C.List owner B wants the mail filter for member C to guarantee that his list messages are granted the same trust level as a message sent directly from A to C without alteration.
This problem is unsolvable because it is unreasonable.   The options for creating trust in indirect mail have been discussed in another RFC.   Applied to this issue, the options are:

1) Make List B the originator by changing the RFC 5321 sender address as well as the RFC 5322 Message From.   Ideally add a DKIM signature for B, in case the message is forwarded downstream.   This is the IETF list behavior and the only one that is feasible in practice.
.
2) Require all submitting domains to make List B a trusted sender for their domain by including B in their SPF record

3) Configure the list to make no changes, then require all senders to include DKIM signatures for their own domain.

4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B.   This is feasible, but specific to each participants incoming email filter.

DKIM and IDENTIFIERS

A large portion of legitimate mail is generated by third parties acting as agents.   The problem being addressed by SPF / DKIM / DMARC is:  
"How can a sender provide information so that a recipient can distinguish between an authorized agent and an unauthorized identity thief?"

A subset of this issue is "How do we expect recipient systems to behave?"    This is a rather important detail which this group has explicitly chosen to not pursue.   But I can provide these observations based on experience with mail filtering:
To avoid false positives on desired messages, messages from some senders must be given some filtering exceptions.   For those exceptions to be applied safely, the sender must be verified to a degree acceptable to the recipient.  Depending on the situation, there are multiple ways that a sender can be identified.   These include, but are not limited to, SPF, DKIM, and DMARC.  In the general case, SPF, DKIM, and DMARC simplify this problem for the recipient.

Although SPF, DKIM, and DMARC are often assumed to be tools for discarding fraudulent messages, this is extraordinarily difficult to implement in practice.   Too many senders have errors in their SPF / DKIM / DMARC configurations, and too many legitimate senders do things that violate a domain owner's SPF / DKIM / DMARC policies.   Policy failure has not proven to be a reliable indicator of unwanted content.

Without DMARC, SPF and DKIM configuration errors persist because the sender obtains no feedback about those errors.  DMARC fixes the feedback problem. 
I still do not understand how DMARC does anything other than enhance prior work on SPF and DKIM, or how there is any conflict with prior standards.   

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 5 Jun 2020 12:34:23 +0200

On Thu 04/Jun/2020 12:31:51 +0200 Douglas E. Foster wrote:
>   * Domain B wants to operate a mailing list.
>   * The list owner will accept messages from domain A, alter them, then
>     re-transmit the altered message to member C.
>   * List owner B wants the mail filter for member C to guarantee that his list
>     messages are granted the same trust level as a message sent directly from A
>     to C without alteration.
> 
> This problem is unsolvable because it is unreasonable.

Starting a message by posing an ill-defined problem does not help clarity.

> The options for creating trust in indirect mail have been discussed in
> another RFC.   Applied to this issue, the options are:
> 
> 1) Make List B the originator by changing the RFC 5321 sender address as well
> as the RFC 5322 Message From.   Ideally add a DKIM signature for B, in case the
> message is forwarded downstream.   This is the IETF list behavior and the only
> one that is feasible in practice.

This is the *de-facto* standard.  As the OP noted, the agent responsible for
the transmission should be set in the Sender: field.  Instead, mailing lists
are forced to rewrite the From: field because of DMARC.  IOW, DMARC hijacked
From: thereby violating RFC 5322.

I agree this point should be fixed, making a real standard of it.  I think that
would take more than one RFC.

> 2) Require all submitting domains to make List B a trusted sender for their
> domain by including B in their SPF record

This never was an option.  Mailing lists used to practice some form of VERP
long before SPF.

> DKIM signatures for their own domain.

Many lists do so, for example opendkim-users, that some of us are subscribed
to.  Note that this set-up does not prevent posters from writing
"[opendkim-users]" in the Subject: of new messages.  Nobody does so, since
posts are accepted even without a subject tag, yet it could be easily enforced.

> 4) Require all recipient systems to make special policy accommodations to grant
> trust to messages from List B, simply because it comes from List B.   This is
> feasible, but specific to each participants incoming email filter.

This is a hindrance to DMARC adoption.  The need to catch and mark all the
mailing list domains that don't rewrite From: can prevent an MTA from blindly
conforming to all DMARC policies.  Alternatively, an MTA can mark highly abused
domains and conform to DMARC policies in those cases only.

For completeness, I'd also mention conditional signatures, as a fifth point.
They were specified, implemented and then abandoned in lieu of ARC.

> [...]
> 
> I still do not understand how DMARC does anything other than enhance prior work
> on SPF and DKIM, or how there is any conflict with prior standards.   

The OP quoted the passage of RFC 5322 where the roles of From: and Sender: are
specified.

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Fri, 05 Jun 2020 07:32:42 -0400

On 6/4/2020 6:31 AM, Douglas E. Foster wrote:
>   * The list owner will accept messages from domain A, alter them,
>     then re-transmit the altered message to member C.
>   * List owner B wants the mail filter for member C to guarantee that
>     his list messages are granted the same trust level as a message
>     sent directly from A to C without alteration.
>

Hi Douglas

-1.  I have to respectfully disagree with this.

Using the proper protocol, Domain A can reasonably declare, with 
certainty, to explicitly and deterministically authorize the Domain B 
resigner where the Domain C receiver can verify whether Author Domain 
A 3rd party policy allows Domain B to resign.

It is done with DMARC with the add-on ATPS by adding an extended tag 
"atps=y" to your DMARC record.  My DMARC record for my domain isdg.net is:

v=DMARC1; p=reject; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];"

The isdg.net domain zone has authorized the following domains with the 
ATPS records:

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT	( "v=atps01; 
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
lykm653kj7yxeia665va7lszzthcx7jj._atps TXT	( "v=atps01; 
d=beta.winserver.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT	( "v=atps01; d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT	( "v=atps01; 
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT	( "v=atps01; 
d=santronics.com;" )

It works very well.  If you wish to explore this, this wizard is 
available:

https://secure.winserver.com/public/wcDmarc

Use the simulator in the wizard to show proof of concept.

> The options for creating trust in indirect mail have been discussed in another
> RFC.

Which one?

With the exception of VBR, I am not aware of any IETF-based Signer 
Domain DKIM Trust/Vouching Protocol. Until we have a 3rd party 
authorization system in play, the Signer Trust can not be established. 
  It would be unreasonable for Domain C to blindly use some unknown 
Trust Authority to all incoming domain As coming from Domain Bs.  On 
the other hand, if the Domain A, explicitly said something in the 
DMARC record such as:

v=DMARC1; p=reject; trust=trust1.example,trust2.example; .....

Then Domain C can check for some "trust" protocol where it will look 
up poll a trust service, trust1.example or trust2.example. Maybe the 
trust service will give DOMAIN A some zone records specific to the 
trusted resigners. Either way, the process model would be:

  trust.result = DKIM_TRUST(Author.Domain, Sender.Domain[, 
User.Agent.Identity])

Is this unreasonable?  I don't think so, but we don't have it.  Again, 
VBR is similar to this.  It has a lookup method where you combine the 
author domain with the signer domain plus other spam-based tags 
specific to the type of mail, or something like that.
Note, it was always my technical opinion, DKIM std incorrectly 
attempted to remove the Author Domain Identity from the DKIM base 
protocol, but instead it attempted to replace the DKIM Policy model 
was a DKIM Trust model, so the process prototype would be:

  trust.result = DKIM_TRUST(Sender.Domain[, User.Agent.Identity])

But as expected, this trust model never materialize but instead the 
self-signing DKIM Policy model was too strong to eliminate from the 
DKIM picture.  Add ATPS or a similar 3rd party authorization protocol, 
and we will get a lot further than we have been since DMARC replaced 
ADSP without addressing and resolving the 3rd party resigner issue.

Finally, my DKIM modeling contention has always been, DKIM is a two 
pass layer model:

- Pass 1, DKIM Policy check using the Author Domain
- Pass 2, iff pass 1 is successful, check the signer domain trust.

I believe that is what the DKIM Service Overview attempt to depict, by 
combining two assessment inputs - signing practice/policy and trust info.

DomainKeys Identified Mail (DKIM) Service Overview
https://tools.ietf.org/html/rfc5585#page-14

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Hector Santos <[email-masked]>
Date: Fri, 05 Jun 2020 07:45:18 -0400

> domains and conform to DMARC policies in those cases only.

It doesn't have to be all mailing list, just the ones authorized to 
resign on your behalf.  Of course, there are scalability issue with 
the "bigger guy" but that should not preclude the "smaller guy" from 
leveraging this method.

> They were specified, implemented and then abandoned in lieu of ARC.

hmmmm, interesting. Where was the "Conditional Signature" proposal 
implemented? I have never come across a conditional signature header. 
  I was not aware ARC was a "conditional signature" or "3rd Party 
Authorization" protocol. IMO, ARC has a high barrier of entry with an 
awful amount of complexity to implement in order to authorize a 3rd 
party domain.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 5 Jun 2020 17:35:34 +0200

On Fri 05/Jun/2020 13:45:18 +0200 Hector Santos wrote:
> hmmmm, interesting. Where was the "Conditional Signature" proposal implemented?

OpenDKIM implemented it "conditionally", that is configure --enable-conditional

> I have never come across a conditional signature header.  I was not aware ARC
> was a "conditional signature" or "3rd Party Authorization" protocol. IMO, ARC
> has a high barrier of entry with an awful amount of complexity to implement in
> order to authorize a 3rd party domain.

ARC has nothing to do with conditional signatures, except for the fact that it
seemed to contend by which end, sending or receiving, should the mailing list
problem be tackled.  In May 2016 John wrote:

    One approach to what we can oversimplify as the mailing list problem is
    to do it from the sending end, with the sender using something like
    conditional double signatures to say mutated messages are OK.  The other
    is to provide data that the recipient can use to decide these mutations
    are OK.

    ARC is definitely in the latter camp, and it would be painful to have
    both ends arguing about how OK stuff is.
    [https://mailarchive.ietf.org/arch/msg/dmarc/BUmNmm9aODMhY_6jdM7Y52S-o7E/]

Best
Ale
--

---

From: Steven M Jones <[email-masked]>
Date: Fri, 12 Jun 2020 21:37:42 -0700

On 6/2/20 5:45 PM, Douglas E. Foster wrote:
>
> As to visibility: The business world still runs on Microsoft Outlook, 
> and **Outlook presents the From Address** when a message is read. So 
> it is odd to assert that no one ever sees that data.

[Emphasis added]

Regarding this and a subsequent message in this thread from Ale, that 
may be true in the message body display, but usually not in folder 
views. Once the message is opened the body pane may show the full fields 
or not, but often a hasty or preoccupied user is busy reading and 
engaging with the content, and it's too late.

Also, I believe this is relatively recent behavior for Outlook. My 
recollection is that for many years Outlook was notorious for only 
showing the display name (or perhaps in some cases certain Active 
Directory fields it looked up) even in the body view. This has changed 
at some point but I believe it was true during the original DMARC 
effort, and I believe it was still true while this WG was working on the 
drafts that led to RFC7489.

However, the versions of Outlook I just checked (Outlook/macOS and 
Outlook Web Access) do show both rfc5322.From display name and address 
field in the body view  some of the time, perhaps most of the time -- 
but not all of the time. Viewing two messages from the same mailing list 
in OWA, one showed both fields and one only showed the display name. 
Window size did not appear to be a factor. The same applied for a 
periodic message sent from a vendor - both fields displayed in 
Outlook/macOS, only the display name in OWA.

And consider the fact that today mobile devices are the MUA of choice 
for many/most end users. Mobile MUAs are much less likely to show an 
rfc5322.From address field even in the message body view.

--S.

---

From: Hector Santos <[email-masked]>
Date: Sat, 13 Jun 2020 01:32:17 -0400

> rfc5322.From address field even in the message body view.

On my iPhone, All I had to do is tap the from field and it shows up.
On Tbird, I hover of the From and its shown.

I think the concern with this is a bit overblown, however, if we 
continue to do allow and accept things like Rewriting in lieu of 
simply honoring the policy, then we have open the door for "bad guy" 
do the same thing.

Honor the policy.