While we were discussing making draft-kitterman-dmarc-psd a working group item, the main discussion point was about the use of an IANA registry to identify participating public suffix domains. I think it would be useful to consider what problems we were trying to solve and see if there are alternative approaches that address those requirements.
Also, while I think the discussion about a DMARC specific public boundary discovery mechanism was useful, and we should consider taking on that work, I think it's not closely coupled to Public Suffix Domains and should be discussed as a separate work item. Goals: 1. Minimize additional verifier burden for adding PSD DMARC support. Currently it requires consulting a locally stored, infrequently changing list and one additional DNS lookup only for participating public suffixes when there is no organizational domain DMARC record. 2. Externalize signaling about PSD participation. As discussed in the Privacy Considerations (section 4.1), we were concerned about the privacy implications of feedback on organizational domain traffic for organizational domains that don't participate in DMARC being inappropriately captured by public suffix operators. In order to avoid this, we identified criteria for which public suffixes PSD DMARC would be appropriate for and require an external review to ensure those criteria are met. No solution that's in DNS will address this part of the problem. I believe that if there are alternatives that support both these requirements, then they should be seriously considered, we just didn't think of one when working up the draft. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
