On Thursday, April 18, 2019 12:45:42 PM Kurt Andersen wrote: > If we have a boundary that is 6 names deep in the DNS hierarchy (so the org > domain would be 7 names long), then what is a DMARC validator supposed to > do with an email that claims to come from the domain that is only 5 names > long? What happens to the second lookup (org-level)? > > Example: > > priv-org.psd-a.b.c.d.e.example: If an email comes from > sub1.priv-org.psd-a.b.c.d.e.examplepriv-org.psd-a.b.c.d.e.example, then > lookup 1 is for _dmarc.sub1..., lookup 2 is _dmarc.priv-org... and the > proposed lookup 3 (for PSD protection) would be _dmarc.psd-a... > > If the email comes from b.c.d.e.example, then lookup 1 is _dmarc.b... but > what would lookups 2 and 3 be? skipped? > > --Kurt
It's an interesting question, since I think may be a hole in DMARC generally, but we can fill it, if needed. I took a look at the non-comment content of the public portion of the PSL to get an idea of the scope of this problem. Here's the distribution of lengths of public suffixes: one: 3077 two: 3821 three: 1986 four: 3 None longer than that, unless I screwed up my script. Since more than 20% of the currently documented public suffixes are longer than two dots, I think this is a use case worth covering, but I don't think changes are needed. In every case I checked, if c.d.e.example is in the PSL, then d.e.example, e.example, and example are also listed, so the proposed PSD DMARC lookups should succeed just fine in these cases. The privacy implications of these types of public suffixes are no different than the longest public suffix, since we don't know that they are not also used for registering non-public organizational domains. It might be useful to state this as a condition required for PSD DMARC to work correctly, so it's documented rather than just a happy coincidence of the current PSL implementation. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
