On Sat 16/Jul/2022 16:43:02 +0200 Scott Kitterman wrote:
On Saturday, July 16, 2022 7:50:04 AM EDT Alessandro Vesely wrote>>
[...]
A mail receiver receives an email with 5322.From domain = example.com,
5322.MailFrom domain = example.com, and a DKIM signature with d =
signing.example.com. _dmarc.example.com and _dmarc.signing.example.com
both have DMARC records (_dmarc.com does not). If SPF or DKIM yield pass
results, they still have to be aligned to support a DMARC pass. Since
not all domains are the same, if the alignment is relaxed then the tree
walk is performed to
determine the organizational domain for each:
Perhaps a table would be more readable?
[...]
Since both SPF and DKIM are aligned, they can be used to determine if the
message has a DMARC pass result. If the result is not pass, then the
policy domain's DMARC record is used to determine the appropriate policy.
In this case, since the 5322.From domain has a DMARC record, that is the
policy domain.
I'd assume all identifiers are validated, so you can simply say
"pass". There is nothing to do with failed DKIM/SPF results.
[...]
How's that?
I'd try and expose the cases more synoptically, to ease reading.
The more cases the better. Mail.notyourbank.example, "private" PSDs,
d=. and other corner cases?
Regarding a table, I don't have a strong opinion on format. If someone wants
to rework these into a different format that might be more readable, I'd say go
for it and we'll see what the WG thinks.
Albeit the examples differ, consider my attempt in the last part of message:
https://mailarchive.ietf.org/arch/msg/dmarc/L9kHlE_zre3sOKn-m6p400yJDuw
It features an initial description of the DNS landscape and a synoptic table
for each case.
Those tables could be bettered by adding the alignment status of each
identifier.
Regarding failed SPF/DKIM, I don't think you can assume for purposes of the
example that both pass, since it's only in the failure case that DMARC policy
is relevant.
Right, but here we're exemplifying the tree walk, not policy application.
(More in the d= case below.)
Finally, I disagree that more examples is unequivocally better. I think that
an example for every single case we can think of would lead to more confusion.
What if you're developing the spec and are dealing with a dubious case? The
ability to find the right example is key.
I selected the examples I included to demonstrate:
1. Most common case with a bit of subdomain usage added to demonstrate the
basics of the tree walk.
2. A deep tree case to show the jump. This is an important concept for DoS
resistance, since I can easily see attackers trying a large number of sub-
labels to see if that causes the DMARC check to be skipped.
3. A PSD example, since that's a new concept relative to RFC 7489.
Consider Case 2 in the examples I made in the aforementioned message. Cannot
one find it dubious?
By d=, I expect you mean a DKIM signature with an empty d=? I don't think
that has anything to do with DMARC. To be relevant for DMARC a DKIM signature
has to verify. With no signing domain, that won't happen.
Correct. (Hence you can assume SPF and DKIM verification passed.)
However, if you're coding the tree walk, d=; forces you to consider the
assumptions you need to put on the input domain. Namely, it must neither be
the root nor a PSD. Right?
I think examples should be illustrative without being overwhelming. If
someone wants to work out the examples for every single case they can think of
and publish on a web site somewhere, I think that would be great. I don't
think it belongs in the RFC. In addition to the potential for confusion with
too many examples, I also think it's likely if we attempt to be comprehensive
we'll miss something so an attempt at being comprehensive is better located
somewhere that it can be revised.
Hm.. maybe. In any case, it'd be preferable to draft many examples and
eventually eliminate the ones which are obviously bad. In the mean time, they
might be useful for the WG to better focus on the tree walk, until we all stop
switching between ducks and rabbits.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
