On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <dcroc...@gmail.com> wrote:
> > Abstract > > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. The design of DMARC > presumes that domain names represent either nodes in the tree below > which registrations occur, or nodes where registrations have > > DMARC does not have 'registrations'. > It's referring to domain name registrations, not DMARC registrations. Also the occur/occured contrast has no obvious meaning to me. Really, I > have no idea what's intended by it. > "exist"? "take place"? "are made"? "are done"? > > occurred; it does not permit a domain name to have both of these > > "both" of what? registration? > It's describing properties of nodes in the domain name tree. DMARC's current design stipulates that every node is either (a) a node below which registrations can occur, or (b) a node at which a registration has occurred. An example of the former is "org", and an example of the latter is "ietf.org" and its entire subtree. properties simultaneously. Since its deployment in 2015, use of > DMARC has shown a clear need for the ability to express policy for > these domains as well. > > Which domains? > The intent is to augment DMARC's ability to describe the domain name tree such that a node can be both (a) and (b) at the same time, for the purposes of policy expression. So those are the nodes (domains) of interest. > Domains at which registrations can occur are referred to as Public > Suffix Domains (PSDs). This document describes an extension to DMARC > to enable DMARC functionality for PSDs. > > This is the definition of public suffix provided by the PSL folk: > > "A public suffix is a set of DNS names or wildcards concatenated with > dots. It represents the part of a domain name which is *not* under the > control of the individual registrant." > That seems to say the same thing to me, though perhaps more crisply. > > This document also seeks to address implementations that consider a > domain on a public Suffix list to be ineligible for DMARC > enforcement. > > seeks? > [...] > Hmm. Maybe that sentence can be struck entirely. Is this a problem with certain implementations only, or with DMARC as specified in 7489? If the latter, I think we can drop this because the main paragraph already says this. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
