It appears that Scott Kitterman <[email protected]> said: >It's growing on me.
Ooh, cool. >There are, however privacy and security concern differences between processing >a record for _dmarc.example.com and _dmarc.com. We can, and should explain >those differences in the security and privacy considerations sections of the >eventual DMARC RFC, but if com should publish a DMARC policy is really between >the operator of com and ICANN and if ICANN were to allow it, it would be up to >com domain registrants to decide how to deal with it (to be clear, I think it >would be horrible if that happened, but that's not a technical, >interoperability horror, it's about privacy and security). Right - it's not a problem with a technical solution. I know several of the people who run the PSL and while they try very hard to do a good job, they are just volunteers and have no unique insight into DNS policy truth. There are a few places where they have specifically decided to punt, like not including the 15,000 2LDs in .name under which they sell 3LDs. >Technically, the change is: > >Lookup policy and if not found, lookup up the next level (up to 4) instead of >lookup policy and if not found, consult PSL and lookup the org domain. > >For the common case like eml.example.com where there is no DMARC record the >trade is one extra DNS lookup in exchange for getting the PSL out of the >equation. Sounds right. >Assuming I have that right, I think that is a reasonable path forward that >would solve a number of problems. The key is to get the security and privacy >considerations documented so that ICANN and ccTLD operators are informed and >can set their own rules appropriate. I would be pretty surprised if ICANN had any interest in this other than using their existing RSTEP process if some TLDs want to publish _dmarc.<tld>. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
