On Fri 29/Oct/2021 23:29:13 +0200 Scott Kitterman wrote:
On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote:
It appears that Scott Kitterman <skl...@kitterman.com> said:
Until we understand what we want, overall, selecting a specific design to
achieve that goal is premature. Both of those approaches will give a
wrong answer (at least as I'd define it) for less usual cases.
Yup. I think I was the first person to propose a tree-walk, so here is
roughly what I was thinking:
The problem with organizational domain is that it is ill-defined. It waves
its hands and says to use something like the PSL, and in practice everyone
uses the PSL.
That usage has proven to work quite well. And some respect for the installed
base wouldn't hurt.
But the PSL is a moving target, with entries added and deleted on a
regular basis, so this month's organization domain may not be the same as
last month's. The advantage of the tree walk is that the DMARC result now
depends entirely on what is in the DNS, not on a volunteer maintained list
whose volunteers keep reminding us that it's only intended to manage http
cookies.
The whole DNS is a moving target.
Todd's stats confirm my intuition that the DNS is pretty flat, and the
amount of mail that comes from addreses with more than, say, four labels is
miniscule. So if you do a four level tree walk, you will find all of the
DMARC records for all of the real mail.
The question remains what to do about the fake mail with 12 label domains.
My perhaps radical suggestion is to say that if the author domain does not
exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply and
you do whatever you do to mail with fake addresses. Or perhaps you only
say that if it's NXDOMAIN and has more than four labels. That way if you
really want to use 12 label addresses, you have to add a _dmarc record
every four levels. Nobody will do that, but nobody sends mail like that
other than to be perverse, so it doesn't matter.
Based on the longest true PSL entry being 4 labels, we could also just jump to
the 5th and walk up from there. It would give every domain that currently has
the ability to express a domain policy the ability to do so and bound the
total number of lookups you could get stuck with for the perverse case.
Something like the attached.
That sounds much like the poor man's do-it-yourself PSL.
This shows the change from the current 6.6.3. It's largely a merge of text
from the current 3.2 and 6.6.3 adjusted for the proposal. All of 3.2 and any
reference to organizational domain would also be removed.
I disagree. The concept of Organizational Domain has been a winning point of
DMARC. We should keep it. Instead of the pragmatic definition given in
Section 3.2 of RFC 7489, we can say something like the current Section 3.9, but
turning the reference to Section 3.15 into an example rather than a normative
algorithm.
The spec should recall that the DNS is a hierarchy so that an affiliation
between the parent zone and the delegated domain can be assumed, unless the
parent is a public registry or similar entity. Situations like .BANK and
.GOV.UK can be mentioned. A definition of Organizational Domain given in such
abstract terms is semantically solid and makes for a good conceptual guidance.
Suggestions about how to deal with corner cases like >5 labels or TLDs can be
given. According to the above discussion, a programmer cannot code a behavior
outside of the rules, irrespective of her decision to use (part of) the PSL or
any other configuration file to assist tree walking.
Configuration files avoid to hard code stuff like that ">5". Users can adjust
those files instead of waiting for new software releases. And the PSL is just
a kind of configuration file, albeit complex. It assists in walking up the
tree at more than one label at a time.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
