On Tue 18/Aug/2020 21:48:46 +0200 Todd Herr wrote:
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.
[...]
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?
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.
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?
Indeed, if all receivers knew what they want to do based on domains or
IP addresses, why would senders publish policies at all?
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
([email protected]), 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 protected]
Sender: [email protected]
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.
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.
[...]
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.
This kind of considerations suggest that the spec be well integrated
with DMARC core, IMHO.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
