On Sat 30/Oct/2021 19:42:01 +0200 John Levine wrote:
It appears that Alessandro Vesely <[email protected]> said:
IMHO, we shouldn't throw away the PSL. Most importantly, we should stick to
the concept of Organizational Domain. We can give an abstract definition of
the latter in terms of affiliation of some kind. Then the spec can leave it to
developers to decide how to find it: tree-walk, PSL, dbound or whatever thing
like it will eventually come about, or even a mix of those. That way, code
using the PSL wouldn't be obsoleted. For new code, some configuration stuff to
skip useless queries to _dmarc.com would be useful anyway.
The problem with that approach is that different people evaluating the
same message will get different answers, unless you carefully figure
out every possible way one might look for an organizational domain and
be sure that you publish whatever every option needs. When we're
writing standards, options are bad since more options mean more bugs
and more ways not to interoperate. Pick one method and tell people to
use it.
The example on the other thread, [email protected], illustrates this variability
well. As you say, it shouldn't make much difference in practice. Of course,
if an organization publishes inconsistent DMARC records, they can get
surprisingly different results.
On the other hand, even if we deprecate the PSL, there will be number of old
implementations around for years.
I can't get too worried about the query to _dmarc.com. For one thing, for the
stuff Scott is doing, while _dmarc.com is unlikely to exist, _dmarc.bank is
on the roadmap. For another, in 99.99% of cases the _dmarc.com query will
be answered from a local cache so it's fast and cheap.
Comparing against a list of six PSDs is even faster and cheaper.
The PSL is over 200K and has over 9000 entries, so you can do a lot of
local DNS queries in the time it takes to read and parse the PSL.
Yes. I downloaded a copy from publicsuffix.org now, and found:
19,268 4,817 trie_nodes of size 4 +
18,884 9,442 num_strings of size 2 +
9,442 9,442 flags of size 1 +
52,701 total string table size =
-------
100,295
I think the tree walk is likely to be at least as fast, maybe faster than
using the PSL.
No. After compiling the list —which is not done every day— a binary search is
lightning fast. At least, it is comparable to a DNS cache lookup. And if you
don't hit the cache, you must spend the extra time to send a query, receive a
response and possibly check DNSSEC.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
