It would be helpful to understand why people want to climb into the publicsuffix.org list. My guess: An ISP, such as "ISP.TLD" allows customers to create websites under their parent. They need to be able to indicate that website JohnSmith.ISP.TLD is independent of website IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should treat them as two organizations rather than one. This scenario needs a flag that says "No alignment for XSS purposes", and the set of names that need that flag may be very different from the set of names that need a DMARC non-alignment flag. So a set of feature-specific DNS flags will indeed be a better long-term design than a simple "I'm a PSL" flag.
I can't answer whether PSLs will cooperate by publishing DNS entries. My original suggestion was to specify the flag syntax in the RFC, so that deployment negotiations can begin, while recommending that implementers use both. For the same reason that I did not see a threat risk, I would place greater trust in the DNS entry when it is present, so I would check DNS first. But I would also check the publicsuffix.org list to handle the problem of DNS non-participation. Can someone explain the private/public distinction in the PSL list? What does the distinction mean as it relates to the four email-related attributes that I have listed? Doug On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely <[email protected]> wrote: > On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote: > > Ale asks: > > > >> Hm... but PSDs don't seem to gain any extras by letting receivers know > they're > >> a PSD, do they? > > > > I think they do. They get the benefits of name protection which DMARC > > previously afforded only to organizational domains and subdomains, which > I > > would expect them to consider very valuable. While the > publicsuffix.org > > <http://publicsuffix.org> provides some protection, I would think they > should > > prefer transferring control of their status from the volunteers to > themselves. > > > > "I am a PSD means" four things: > > > > 1. "If you see a message with an SMTP address that uses my PSD name, it > is fraudulent and should be blocked." > > > > 2. "If you see a message with a FROM header that uses my PSD name, it is > fraudulent and should be blocked." > > > > 3. "If you see a DKIM signature that uses my PSD name, it will not > verify because the public key will be missing, but it is not merely > unverified material to ignore, it is positive evidence of a fraud attempt." > > > > 4. "If you are doing DMARC alignment testing, don't match on my PSD > name, You are not looking at an organization record." > > > I agree those four make for a commendable behavior, but they are not > really > incentives. IOW, lazy PSD might take years to comply. > > > > A related question is whether there is any incentive for malicious use > of the > > "I'm a PSD" flag by entities that are not actually PSDs. Since the > only > > effect of this flag is to cause mail to be blocked, I do not see any > such > > incentive, so I do not see any risk. > > > I do, because John reported a link to the PSL wiki where they complain of > ISPs > striving to get on the PSL. > > > Best > Ale > -- > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
