In article <1b0bef4b-61e6-776c-79e8-89631efa8...@dcrocker.net> you write: >So I think that the functional goal of kitterman-dmarc-psd is fully >satisfied by merely doing a version of the 3A update to DMARC, directing >the client to query the immediate parent of the organizational domain, >if the OD has been queried and no DMARC record has been found.
Given that anything we do to handle public suffix defaults will need some code changes, this seems about the simplest change that would do the trick. I am aware of two security or privacy issues that might come up. If we used a DNS scheme like my DBOUND one, whoever runs the DNS policy server can see all the queries and will have some idea of the mail traffic from various names. This approach doesn't have that problem. The DNS operator can tell that someone is asking about a subdomain, but not which subdomain. The other is that the DMARC record might have rua= and ruf= and get detailed reports about subdomains. This is not an unreasonable concern -- I am the legacy registrar for various <geographic>.ny.us domains and my DMARC reports tell me a lot about one of my registrants who sends a lot of mail. (Real mail, they're the county govermnent.) This is easily addressed by clients ignoring the report advice in the OD parent record. One issue that is not our problem but might be Scott's is that in ICANN contracted TLDs, they're not allowed to publish TXT records at _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special permission to do so. I happen to know the people who evaluate the applications (as do many other people here) and I'm sure they would say yes for those two TLDs, but it would involve some time and money. This might actually be a feature, since a similar appplication for _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more scepticism. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
