On Fri 18/Mar/2022 20:30:09 +0100 John R Levine wrote:
You're right, those weren't a good example.
Try these from the PSL:
com.br
users.scale.virtualcloud.com.br
virtualcloud.com.br is not algned with a.users.scale.virtualcloud.com.br
(For the latter name it would start at users.scale.virtualcloud.com.br and find
psd=y)
cz
usr.cloud.muni.cz
cloud.muni.cz is not aligned with a.usr.cloud.muni.cz
co.uk
cust.retrosnub.co.uk
retrosnub.co.uk is not aligned with a.cust.retrosnub.co.uk
Good spot, very clever. In fact, I get: (blank lines inserted)
ale@pcale:~/tmp/zdkimfilter/svn/src$ ./TESTpublicsuffix
../no-svn/public_suffix_list.dat virtualcloud.com.br
a.users.scale.virtualcloud.com.br cloud.muni.cz a.usr.cloud.muni.cz
retrosnub.co.uk a.cust.retrosnub.co.uk
virtualcloud.com.br -> virtualcloud.com.br
a.users.scale.virtualcloud.com.br -> a.users.scale.virtualcloud.com.br
cloud.muni.cz -> muni.cz
a.usr.cloud.muni.cz -> a.usr.cloud.muni.cz
retrosnub.co.uk -> retrosnub.co.uk
a.cust.retrosnub.co.uk -> a.cust.retrosnub.co.uk
That outcome clearly shows that string comparison would fail when applied to
org domains /found via PSL/.
Like I said, there aren't a lot of these but there is no need to break them.
To better understand what those domains are, let me note that if I restrict the
PSL to just the ICANN part, as has been sometimes suggested, I get: (still
inserting blank lines for readability)
ale@pcale:~/tmp/zdkimfilter/svn/src$ ./TESTpublicsuffix
../no-svn/public_suffix_list_ICANN_only.dat virtualcloud.com.br
a.users.scale.virtualcloud.com.br cloud.muni.cz a.usr.cloud.muni.cz
retrosnub.co.uk a.cust.retrosnub.co.uk
virtualcloud.com.br -> virtualcloud.com.br
a.users.scale.virtualcloud.com.br -> virtualcloud.com.br
cloud.muni.cz -> muni.cz
a.usr.cloud.muni.cz -> muni.cz
retrosnub.co.uk -> retrosnub.co.uk
a.cust.retrosnub.co.uk -> retrosnub.co.uk
By the whole PSL, the same domain can be characterized as an org domain and as
a PSD.
The performance issue is insignificant.
Maybe performance doesn't matter. However, what do we expect to find out by a
tree walk? We'd come to the same conclusion as using the ICANN only list
unless their record contains psd=y. Correct?
Then, suppose we have the following:
_dmarc.a.users.scale.virtualcloud.com.br NO DATA
_dmarc.users.scale.virtualcloud.com.br v=DMARC1
_dmarc.scale.virtualcloud.com.br NO DATA
_dmarc.virtualcloud.com.br v=DMARC1; psd=y
If we have From: [email protected], the org domain is
users.scale.virtualcloud.com.br, according to Scott's writing. A signature
with d=virtualcloud.com.br is not aligned.
If, instead, we have From: [email protected], the hybrid org domain is
virtualcloud.com.br. Scott's writing doesn't cover this case. What about a
signature with d=scale.virtualcloud.com.br? It looks like it should be
aligned, since there are no other org domains in between. Otherwise, we could
solve that case by simply stating that hybrid domains can only use strict
alignment. However, we said that dkim.bank cannot sign for whatever.bank. How
do they differ? We must tune the tree walk in order to allow hybrid domains
and their internal subdomains.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
