On Tue 12/Jul/2022 17:12:40 +0200 John Levine wrote:
A.6 seems to be dealing with a different subject. I can still
sketch some text to be added there, though. I attach the diff.
I realize this is getting repetitive but:
-- PSDs are very, very rare, and users will generally never see them
That doesn't entail developers can generally skip considering them.
-- long discussions of PSDs will just confuse people
You keep reiterating this concern, to which I try and conform without
fully understanding it. At the same time, the opposite concern, that
people acting as PSD won't publish as needed, is neglected.
The lack of a full explanation will motivate people to write
interpretations and suggestions of their own --the same reaction which
is motivating me now.
-- I don't even think these examples get the tree walk right.
I tried to interpret the current draft. Please correct me where I'm
wrong. For convenience, I paste the relevant text below.
Hence, this change is not an improvement. I don't plan to argue
further unless we see more support for this very bad idea.
Even if it's not an improvement, I think some points deserve a bit of
discussion. For example, the current draft allows psd.example.com to
skip defining any DMARC record at all, which wouldn't work.
The text (minor change: s/NODATA// and fix a typo):
A.6.2. Tree Walk Example
Let's now make a corner case example, where "psd.example.com"
operates as a public suffix domain. That is, it delegates subdomains
to third parties. "Example.com" itself is a regular domain and has
its own DMARC record:
_dmarc.example.com IN TXT
"v=DMARC1; p=reject; rua=mailto:dmarc-feedb...@example.com";
"Psd.example.com" is the kind of domain that the PSL would list as
private domains, as opposed to ICANN domains. Most public suffix
domains (PSD) don't publish a DMARC record. In this example,
"psd.example.com" should publish a record, declaring its role as a
PSD:
_dmarc.psd.example.com IN TXT
"v=DMARC1; psd=y; p=reject"
Finally, let's consider a customer "rockabilly.psd.example.com".
This is a regular domain, register under a private PSD. It can have
a DMARC record too:
_dmarc.rockabilly.psd.example.com IN TXT
"v=DMARC1; p=none; rua=mailto:el...@rockabilly.psd.example.com";
Now, assuming that any other subdomain of "example.com" has no DMARC
record,let's consider some message cases:
Case 1:
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
To verify alignment, the receiver looks up the records for all three
labels, getting NXDOMAIN for "_dmarc.mail.example.com" and for
"_dmarc.com". "Example.com" is the organizational domain of all
three identifier. Therefore they are all aligned.
Case 2:
Author Domain: psd.example.com
SPF-authenticated Identifier: mail.psd.example.com
DKIM-authenticated Identifier: rockabilly.psd.example.com
This message won't pass, because it is badly engineered as if
"psd.example.com" were an independent organization. It is not. It
is a subdomain of "example.com", albeit its being used as a base for
independent domains.
For the Author Domain, "psd.example.com" is the starting point, so
the tree walk doesn't stop even if it finds psd=y. Lookups for the
remaining labels bring to the conclusion that the organizational
domain is "example.com".
For SPF, "mail.psd.example.com" is the organizational domain, as it
is the label before the one with psd=y. It is not aligned.
Similarly, "rockabilly.psd.example.com" is --correctly-- considered
the organizational domain and is not aligned.
Case 3:
Author Domain: rockabilly.psd.example.com
SPF-authenticated Identifier: mail.rockabilly.psd.example.com
DKIM-authenticated Identifier: rockabilly.psd.example.com
TBD
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
