Subject: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

From: Todd Herr <[email-masked]>
Date: Tue, 18 Aug 2020 15:48:46 -0400

Greetings.

I want to revisit something that was originally discussed in the
"non-mailing list use case for differing header domains" thread, because I
don't think there was any sort of consensus reached, and because I think
it's pretty important in determining whether or not the proposed document
will achieve any level of successful adoption. If this topic was discussed
in a different thread, please forgive me for beating what I'm sure must be
a dead horse.

Section 5.2, Determine Handling Policy, reads in part:

The steps are as follows:

   1.

       Sender:   Extract the RFC5322.Sender domain from the message.

          Query the DNS for a DMARC policy record.

          Perform remaining, numbered steps, if one is found and it
          contains an "snd" tag.

       AND

       From:   Extract the RFC5322.From domain from the message.

          Query the DNS for a DMARC policy record

          Perform remaining, numbered steps, if one is found.

       Terminate:   Otherwise terminate DMARC evaluation.

   2.  Perform DKIM signature verification checks.  A single email could
       contain multiple DKIM signatures.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       value of the "d=" tag from each checked DKIM signature.
Crocker                 Expires January 28, 2021                [Page
6]Internet-Draft                    DMARC                        July
2020

   3.  Perform SPF validation checks.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       domain name used to complete the SPF check.

   4.  Conduct Identifier Alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks to see
       if Authenticated Identifiers fall into alignment.  If one or more
       of the Authenticated Identifiers align with the RFC5322.From (or
       with the RFC5322.Sender field, if permitted by the domain owner)
       domain, the message is considered to pass the DMARC mechanism
       check.  All other conditions (authentication failures, identifier
       mismatches) are considered to be DMARC mechanism check failures.

   5.  Apply policy.  Emails that fail the DMARC mechanism check are
       disposed of in accordance with the discovered DMARC policy of the
       Domain Owner.  See Section 6.3 for details.

The race condition here is in item 5, "Emails that fail the DMARC mechanism
check are disposed of in accordance with the discovered DMARC policy of the
Domain Owner", specifically when both the Sender and From headers are
present, the domains are different, both publish DMARC policies, and only
one of the two domains passes DMARC validation checks for that message. In
that case, the question of "Which policy to apply?", or more precisely,
"Which validation check should be honored?" will really matter to the
disposition of the message; if, for example, the From domain is at p=reject
and fails, while the Sender domain publishes a policy with the required
"snd" tag and passes, should the message be rejected or accepted?

When I first posed this, the answers I got were along the lines of
"Receivers will do what they want, like they've always done", and that's
certainly true if the behavior isn't mandated in the RFC (and maybe even if
it is). That's cool and all, but doesn't "Receiver's Choice" risk
continued, or perhaps even worse, breakage of the primary problem that this
document is trying to fix?

Unless I'm misunderstanding things, a primary idea behind the Sender header
with the DMARC policy is to make things easier for intermediaries, like
this mailing list. I'm posting to this list from a domain that publishes a
p=reject policy, and so to allow my post to make it to all subscribers, the
MLM rewrites the From address something that looks kind of VERP-ish
(todd.herr=[email-masked]), DKIM signs it using the ietf.org
domain, and sends it along with a MAIL FROM domain ending in ietf.org.

If this change becomes standard, then I imagine that future mail sent
through this MLM will look something like this:

  From: [email-masked]
  Sender: [email-masked]
  DKIM-Signature domain (d=ietf.org)
  Return-Path domain: ietf.org

There may still be a DKIM signature header with d=valimail.com attached to
the message, but DMARC for valimail.com won't validate because of the
footer attached to the message, and so we'll be in a situation at best
where the Sender DMARC check passes and the From DMARC check fails, with
the From domain being at p=reject.

What if the receiver bounces the message because of this failure of DMARC
validation on the From field? We're playing "Receiver's Choice" here, so
there's nothing to stop them from doing so, right?

If the spec doesn't mandate behavior in cases where there are conflicting
DMARC validation results, then it doesn't seem to achieve the goal it set
out to accomplish:

      If:

      *  the original From: field is covered by DMARC, and

      *  the message goes through a Mediator that breaks aligned
         authentication, and

      *  the receiving DMARC engine only uses the original version of
         DMARC,

      then it will produce a DMARC fail.

      It does not appear to be possible to handle this case safely,
      except by modifying the From: header field so that it does not
      trigger an alignment failure.  Unless there comes a time at which
      concern for this case is eliminated, Mediators will continue to
      have to deal with this, such as by modifying the From: field.

      To that end, this version of the specification has been modified,
      to make Sender: an _additional_ DMARC alignment possibility,
      rather than an alternative one.

In the absence of spec guidance that states, for example, DMARC validation
passes override failures when conflicts occur[*], I guess an answer here
could be universal adoption of ARC, to mean that all mediators record
authentication results in ARC header sets (something this MLM doesn't yet
do, as far as I can tell) and that all receivers ingest and make proper use
of ARC header sets (for some definition of "proper"). However, with a
universal adoption of ARC, is there a need for additional DMARC alignment
possibilities?

[*] Such guidance would likely open up quite a number of abuse vectors, so
let's not speak of the idea of inserting such guidance for now.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2020 17:53:26 -0400

In article <[email-masked]> you write:
>[What to do when From and Sender DMARC have different results ?]
>

You're right, the sender tweak only makes sense if the sender result
is preferred. Otherwise a sender result can only make it less likely
that a message is delivered, and that wouldn't be very useful.

As always, a successful result doesn't mean not spam, it just means it
didn't fail DMARC. I expect some non-normative advice would be
helpful, pointing out that this is useful for third party senders, and recipient
systems will have to come up with their own idea about which third parties are
credible.

It occurs to me it's likely to be the same list of third parties whose ARC seals
are credible.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Aug 2020 15:05:09 -0700

On 8/18/2020 12:48 PM, Todd Herr wrote:
> The race condition here is in item 5, "Emails that fail the DMARC 
> mechanism check are disposed of in accordance with the discovered 
> DMARC policy of the Domain Owner", specifically when both the Sender 
> and From headers are present, the domains are different, both publish 
> DMARC policies, and only one of the two domains passes DMARC 
> validation checks for that message. In that case, the question of 
> "Which policy to apply?", or more precisely, "Which validation check 
> should be honored?" will really matter to the disposition of the 
> message; if, for example, the From domain is at p=reject and fails, 
> while the Sender domain publishes a policy with the required "snd" tag 
> and passes, should the message be rejected or accepted?

So, yeah, the text for that needs significant changes.  Thanks for 
raising this.

I was under some time pressure and merely copied that from the existing 
DMARC spec.  In fact, I think that text in the DMARC spec isn't very 
good, so this would be a nice excuse for thinking through reasonable 
language carefully.

The basic issue, which creates the language challenge, is the receivers 
actually can and do do whatever they want.  Language that pretends to 
dictate receiver action for this is unrealistic.

So the language should be cast in terms of the semantics of the 
information it is tossing into the receiver's analysis engine, rather 
than claiming to dictate receiver disposition of the message.  IMO.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dotzero <[email-masked]>
Date: Tue, 18 Aug 2020 19:14:14 -0400

On Tuesday, August 18, 2020, Dave Crocker <[email-masked]> wrote:

>> mechanism check are disposed of in accordance with the discovered DMARC
>> policy of the Domain Owner", specifically when both the Sender and From
>> headers are present, the domains are different, both publish DMARC
>> policies, and only one of the two domains passes DMARC validation checks
>> for that message. In that case, the question of "Which policy to apply?",
>> or more precisely, "Which validation check should be honored?" will really
>> matter to the disposition of the message; if, for example, the From domain
>> is at p=reject and fails, while the Sender domain publishes a policy with
>> the required "snd" tag and passes, should the message be rejected or
>> accepted?
>>
>
>
> So, yeah, the text for that needs significant changes.  Thanks for raising
> this.
>
> DMARC spec.  In fact, I think that text in the DMARC spec isn't very good,
> so this would be a nice excuse for thinking through reasonable language
> carefully.
>
> information it is tossing into the receiver's analysis engine, rather than
> claiming to dictate receiver disposition of the message.  IMO.
>
> d/
>
> --
> Dave Crocker
This is just wrong. While I appreciate the enthusiasm for using the Sender
field, unless there is a mechanism for establishing a relationship between
the From domain and the Sender domain then we have basically broken DMARC.
Using what has been described above, any malicious actor can bypass the
wishes of the From domain and send whatever they want. I fail to see how
this would be considered a feature. It is precisely why I proposed a
separate signature of the Sender field by the From domain to at least
provide a way to show a relationship between the Two domains.

There currently is no race condition because Sender is not currently a part
of DMARC. It appears that people want to introduce the same problem that
existed in SenderID and PRA. Please don't.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2020 20:47:24 -0400

In article <CAJ4XoYcue16VU6otKOzQBFy_59nD8DGcDQb8H=[email-masked]> you write:
>wishes of the From domain and send whatever they want.

Aw, come on.  Surely you of all people know that DMARC aligned doesn't mean
it's not spam.

the whole reason we're here is that we have abundant evidence that at
least where mailing lists are involved, the policy published in DMARC
often doesn't express the actual wishes of the domain publishing it.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Aug 2020 11:41:32 +0200

On Tue 18/Aug/2020 21:48:46 +0200 Todd Herr wrote:
> [...]

I fully agree with Michael on this point.

Check #1 above is completely useless.  What is it worth publishing the 
"snd" for?  Do we aim at running statistics about how many domains 
plan to sign as Sender:?

Instead, the "snd" tag should appear on the From: domain's DMARC 
record, so that, in the case described, a receiver can check whether 
that domain authorizes the Sender:.

Better yet, the value of snd= should somehow relate the two domains, 
so that not /any/ Sender: can send on behalf of a given From:.  IOW, 
the From: domain still has control.

> document is trying to fix?

Indeed, if all receivers knew what they want to do based on domains or 
IP addresses, why would senders publish policies at all?

> the From domain being at p=reject.

There is clearly a gap.  The list can send as above when all, or at 
least most aggregate reports say that they *would have accepted* the 
messages based on Sender: *even if From: weren't rewritten*.  Current 
aggregate report format doesn't provide for that.

> [...]

This kind of considerations suggest that the spec be well integrated 
with DMARC core, IMHO.

Best
Ale
--

---

From: Dotzero <[email-masked]>
Date: Wed, 19 Aug 2020 06:30:17 -0400

> Aw, come on.  Surely you of all people know that DMARC aligned doesn't mean
Aw, come on. Surely you of all people know that DMARC broken doesn't mean
it's good and real. 🤔 You are presenting a false dichotomy that centers
only on mailing lists.

> often doesn't express the actual wishes of the domain publishing it.

You paint with a broad brush. As one of the creators of DMARC, I fully
intended that ANY messages purporting to be from the domains I set p=reject
for to be rejected if they failed to pass either aligned DKIM or SPF. No
user accounts at those domains other than direct support accounts and
billions of emails served with no intermediary problems other than a few
vanity domains on the receiver side. Our position from the beginning was
that they are not authorized by us to use our domains in that manner. For
us,protecting end users,most who were not even our customers was much more
important than the small fraction of a percentage of dropped mail. And yes,
we tracked all sorts of metrics on an ongoing basis.

Please don't tell me that our published policy did not represent our actual
wishes. Your representation that you know better than ALL people/domains
which publish DMARC what they wish is akin to saying you know better than
all people screwing up their DNS records what they actually want. You
sidestep a lot of important issues by reducing everything to the one edge
case you are concerned about.

If the people you claim don't want the outcome they have as a result of the
DMARC policy that they published then maybe they should publish a different
policy. Have you considered contracting them, any of them, to tell them you
know their wishes better than they do?

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 19 Aug 2020 10:53:41 -0400

> know their wishes better than they do?

Ericsson publishes p=reject over the objections of their employees, some 
fairly high in the hierarchy, who they subsidize to participate in the 
IETF and its mailing lists.  I've coached some of them on what to say, 
didn't help.

Of course you personally know what DMARC policies mean and what they 
imply.  But every time a list has to rewrite a From line, we have evidence 
that someone else doesn't or at best doesn't care.*

R's,
John

* - I have on excellent authority that when Yahoo published p=reject to 
outsource the costs of their security breaches, Marissa Meyer said she 
knew it would break everyone's mailing lists and she didn't care.

---

From: Dotzero <[email-masked]>
Date: Wed, 19 Aug 2020 12:27:10 -0400

On Wednesday, August 19, 2020, John R Levine <[email-masked]> wrote:

> fairly high in the hierarchy, who they subsidize to participate in the IETF
> and its mailing lists.  I've coached some of them on what to say, didn't
> help.

Then Ericcson as an organization has made a decision regardless of the
objections of those employees. The correct thing for Ericcson as an
organization to do is to publish an internal policy that employees should
not use company mail for participating in mailing lists. An alternative to
that would be for them to hire someone to help them come up with a workable
approach. We both know plenty of people who could help them.

> that someone else doesn't or at best doesn't care.*

I'm going to guess that more often than not it is the latter. *I heard the
same. Too big to care?

> outsource the costs of their security breaches, Marissa Meyer said she knew
> it would break everyone's mailing lists and she didn't care.
>

 Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 19 Aug 2020 12:33:19 -0400

> approach. We both know plenty of people who could help them.

No doubt, but they're not going to do that.  They want their employees to 
work on the IETF, the publish p=reject and they apparenty believe the 
contradiction is not their problem.  So we're stuck with it.

> I'm going to guess that more often than not it is the latter. *I heard the

Yup.  They want phishes, or in Yahoo's case expensive user complaints, to 
go away, they don't care about discussion lists one way or the other

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dotzero <[email-masked]>
Date: Wed, 19 Aug 2020 13:07:27 -0400

> contradiction is not their problem.  So we're stuck with it.

For some definition of stuck. I happen to believe that validators/receivers
SHOULD generally respect policy assertions. Mail list operators should as
well. Absent a functional and meaningful mechanism for authorization of
specific intermediaries by domains, that is the way to go. If things break
and users complain then those users should be told to contact their mail
administrator. Just saying.

> go away, they don't care about discussion lists one way or the other

Perhaps they would care if users/customers complained and or walked. Again,
just saying.

Michael Hammer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Aug 2020 11:48:23 -0700

On Wed, Aug 19, 2020 at 10:08 AM Dotzero <[email-masked]> wrote:

> For some definition of stuck. I happen to believe that
> validators/receivers SHOULD generally respect policy assertions.. Mail list
> operators should as well. Absent a functional and meaningful mechanism for
> authorization of specific intermediaries by domains, that is the way to go.
> If things break and users complain then those users should be told to
> contact their mail administrator. Just saying.
>

If this only interfered with Ericsson's users, I might agree.  But it
recklessly interferes with third parties.  To me, that's significant.

> Perhaps they would care if users/customers complained and or walked.
> Again, just saying.
>

Perhaps.  But if they don't, is the current status quo implicitly okay?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 Aug 2020 15:11:06 -0400

> recklessly interferes with third parties.  To me, that's significant.

Right.

>> Perhaps they would care if users/customers complained and or walked.

Sheesh, we went through this a decade ago.  Approximately none of AOL or 
Yahoo's mail users pay for the service -- they're the product, not the 
customer.  I know a fair number of people with AOL accounts, they're not 
super thrilled about AOL, but the cost of switching and telling all of 
their correspondents is huge.

It is abundantly clear that Ericsson and AOL and Yahoo do not object to 
their users sending mail through discussion lists.  Ericsson doesn't want 
their execs to be phished, AOLhoo doesn't want complaints "why am I 
getting spam from people I know."  In each case we know from experience 
that their published p=reject doesn't describe their actual policy.

Regards,

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 19 Aug 2020 15:31:24 -0700

> that their published p=reject doesn't describe their actual policy.

When domains have only three sizes of DMARC policy hammers, there aren't a
lot of options to handle loose screws...though I still haven't heard any
wormhole protocol suggestions which seem like viable mechanisms at scale or
which would allow the organizations you cite to express the nuances of
their presumptive "actual polic[ies]".

--Kurt

---

From: Joseph Brennan <[email-masked]>
Date: Wed, 19 Aug 2020 20:06:48 -0400

I've been running email servers for 25 years. My number 1 priority is that
legitimate mail gets through. Stopping the bad stuff is very important but
not number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's
a fail.

I can understand the transactional mail case, as I stated in
previous messages. The burden is on the businesses implementing DMARC
protection to inform customers to give their real end-point email addresses
and not any vanity forwarding services. Any two sides can agree between
them on some optional additional security measure. It's a good thing.

For general end-user mail? It's a bad thing. It will cause email to fail,
and it will cause people not drinking the DMARC kool-aid to implement crazy
non-standard things with From headers to make email work the way it
should work without crazy workarounds. I see no reason that the DMARC
standard should not spell out explicitly the use case that it is intended
to meet, and recommend against using it for other use cases.

I realize that this was said ten years ago (or whatever it was) when
yahoo/aol began abusing DMARC. But see how that went. The problem was not
really DMARC at all, it was abuse of DMARC.

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 20 Aug 2020 02:34:42 GMT

For incoming mail, you determine what constitutes legitimate mail.    You choose whether to enforce DMARC generally.  If you enforce DMARC at all, you also choose what exceptions to apply.

But outgoing mail is different.   The sender has no guarantee of delivery.   The sender has to convince the recipient that the message is legitimate and desirable.  (Plenty of advertising messages are sent legitimately, but still get blocked by my spam filters.)

For mailing list mail, there are two messages.   The first one goes from your user to the mailing list.  The mailing list has various rules about whether the message is acceptable or not.   For openers, the sender must be a registered subscriber to the list.   Additionally, there may be limits on attachments or limits on swear words.    The subscriber knows these rules, or learns them quickly, and complies.

The second message is from the mailing list to the subscribers.   As with every other message, the mailing list sender needs to determine host to satisfy the requirements of the recipient system.   Maybe the recipient system has a longer list of swear words.   Or maybe the recipient system enforces DMARC.   Whatever the rule, the burden is on the sending mailing list to get the message delivered by satisfying the screening criteria of the recipient systems.

One important way to demonstrate legitimacy is to provide a verifiable identity.  Verified identity allows a reputation to be assigned, which then determines which content filtering rules will (or will not) be applied.   If a mailing list knows that the recipient requires a verified identity, but fails to provide a verifiable identity, whose fault is it when the message does not get delivered?

The working assumptions are that a mailing list must alter the received content, the mailing list must not reformat the From address, and nonetheless the recipient system must assume, without supporting evidence, that the message is legitimate.   

Assuming that mailing lists deserve a privileged role, we still need a way to demonstrate that any specific message deserves that role because it is from a trusted mailing list and not from an attacker.

Doug Foster

----------------------------------------
From: Joseph Brennan <[email-masked]>
Sent: 8/19/20 8:07 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

I've been running email servers for 25 years. My number 1 priority is that legitimate mail gets through. Stopping the bad stuff is very important but not number 1. Does DMARC causes legitimate mail to fail? Yes, so to me it's a fail.

I can understand the transactional mail case, as I stated in previous messages. The burden is on the businesses implementing DMARC protection to inform customers to give their real end-point email addresses and not any vanity forwarding services. Any two sides can agree between them on some optional additional security measure. It's a good thing.

For general end-user mail? It's a bad thing. It will cause email to fail, and it will cause people not drinking the DMARC kool-aid to implement crazy non-standard things with From headers to make email work the way it should work without crazy workarounds. I see no reason that the DMARC standard should not spell out explicitly the use case that it is intended to meet, and recommend against using it for other use cases.

I realize that this was said ten years ago (or whatever it was) when yahoo/aol began abusing DMARC. But see how that went. The problem was not really DMARC at all, it was abuse of DMARC.

-- 

Joseph Brennan

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 20 Aug 2020 11:46:25 +0200

On Thu 20/Aug/2020 02:06:48 +0200 Joseph Brennan wrote:
> The problem was not really DMARC at all, it was abuse of DMARC.

Again, in that case we should devise a new protocol which 
/potentially/ allows all email domains to be protected.

And I'd still call such new protocol DMARC...

Best
Ale
--