On Sun 31/Oct/2021 16:27:14 +0100 Scott Kitterman wrote:
On October 31, 2021 11:29:41 AM UTC, Alessandro Vesely <[email protected]> wrote:
On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote:
On October 30, 2021 8:47:51 PM UTC, John Levine <[email protected]> wrote:
According to Scott Kitterman <[email protected]>:
That usage has proven to work quite well. And some respect for the installed
base wouldn't hurt.
The alternative I suggested is 100% compatible with the installed base.
If a domain has published DMARC policy per RFC 7489, the proposed new
approach will still find it.
Yes, but would PSL-based DMARC filters have to be re-written, re-tested,
re-installed?
I don't think so. Because, modulo the backwards compatibility note mentioned
below (which I think is primarily a theoretical concern), existing
implementations would find policies published under the new design, they
wouldn't need to be changed to support this new policy discovery definition.
Since policy publishing is 100% compatible, so is designing it. An organization
shouldn't publish an intermediate record just to "help" DMARC filters.
Another criterion, beside tree-walk and PSL, could be to look at the d= tag of
the DKIM signatures that are aligned with the From: domain. Would that be
semantically equivalent to the procedure described in the current Section 6.7.2?
Sorry, 6.7 doesn't have numbered sub- paragraphs. Did you mean 6.6.2?
No and yes, I meant
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-03#section-6.7.2
Once you dig into 6.6.2 you end up at 3.1 identifier alignment. For strict
alignment, it works unchanged. For relaxed, there's a potential for an issue.
Since since both 3.1.1 (DKIM) and 3.1.2 (SPF) define relaxed based on a common
org domain, we would have to come up with a new definition.
We can't, under the new design, use the policy domain as a substitute for org
domain since that would potentially allow unrelated entities to generate
aligned results if records are published above the current org domain level (as
a totally hypothetical example, messages could be sent signed by state.gov From
maryland.gov and they would align).
That might happen only because they're under an "experimental" public suffix
domain.
The old spec obviously assumes that the policy domain and the From: domain are
aligned.
I think that if we changed the relaxed definition to the same as or a
sub-domain of the From domain it would avoid potential issues like that without
practical impact. I don't think I have ever seen legitimate mail where Mail
From or DKIM signing domain wasn't either the same or a sub-domain of From that
were in the same org domain.
From: [email protected], signed by example.org which also publishes a policy
has to be valid. We have to work out the PSD case.
I think it would be appropriate to have some kind of note warning not to assume
intermediate domains are queried for policy due to legacy code
Agreed. Intermediate domains, the ones between the From: domain and its
Organizational Domain, would be considered like some kind of proxy, or even a
more specific alternative to the Organizational Domain or the possible PSD.
Still, checking each and every intermediate domain may remain optional.
As a practical matter, it would be optional since no one is likely to publish
records for those domains, but we wouldn't specify it that way. It would be a
local optimization an implementer might choose.
We can say that any policy found at the From: domain or any parent thereof is
valid, even at TLD.
The concept of Organizational Domain is still useful for receivers, as it helps
setting up reputation databases. In this respect, the PSL is also useful
outside the DMARC protocol; for example, to get the organizational domain of
HELO arguments.
Perhaps, but if it's not DMARC related, it's out of scope for our
consideration. In any case, none of those uses require commonality to support
interoperability, they're all local functions. I don't think we need any RFC
definition to enable those uses.
Having a useful concept defined by an RFC is a Good Thing.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
