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=40valimail....@dmarc.ietf.org), 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: todd.h...@valimail.com
Sender: l...@dmarc.ietf.org
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:* todd.h...@valimail.com
*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.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
