On Wednesday, April 15, 2020 10:32:32 PM EDT Dale R. Worley wrote: > Todd Herr <toddmherr@xxxxxxxxx> writes: > > Having reviewed the comments, I'm wondering if perhaps the following draft > > rewrite of the Abstract section might be a first step to address many of > > the points raised? > > I heartily endorse the sentiment behind this. I think there are some > minor improvements that could be made, as I've noted below. > > One point is that much of this information might be better put into the > Introduction, and only a skeleton of it put into the Abstract. But as > they say, you write the Introduction after you've written the body of > the work, and you write the Abstract after you write the Introduction. > > > *AbstractDMARC (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 original design of DMARC applies only to domains that are registered > > with a domain name registrar (called "Organizational Domains" in RFC 7489) > > and nodes in the tree below Organizational Domains. Organizational Domains > > are themselves nodes in the tree below domain names reserved for > > registration, with the latter commonly referred to as "Top Level Domains" > > (TLDs) (e.g., '.com', '.co.uk <http://co.uk>', etc.), although in this > > document they will be referred to as Public Suffix Domains (PSDs).* > > In some way it would be useful to flag that RFC 7489 is the base DMARC > RFC. Otherwise, the reader must just infer that, or look up the RFC. > > There's also a point which seems to be very general, as it shows up in > RFC 7489 section 3.2: all the text refers to a "domain" without > explaining *what* domain is extracted from the message under > consideration to determine the policy that applies to the message. My > belief is that this is the From header in the message, but I've never > seen this stated. So e.g. > > "The original design of DMARC applies only to messages with From > addresses containing domain names that are registered ..." > > This paragraph uses the phrase "domain names reserved for registration", > but I've not heard that term used in descriptions of the DNS. And I > would expect say that "ietf.org" is "reserved for registration", not > "org" -- though I've never heard the phrase "reserved for registration". > The phrase that seems obvious to me is "domain names under which domain > names are registered, commonly referred to as 'Top Level Domains'...", > but that's somewhat awkward. > > And Kurt Andersen notes that while .co.uk is clearly intended as one of > these domain names, it isn't, strictly speaking, a TLD. > > > *Since its deployment in 2015, use of DMARC has shown a clear need for the > > ability to express policy for PSDs. This document describes an extension > > to > > DMARC to enable DMARC functionality for PSDs.* > > I'm not sure, but I suspect this could be clarified as "policy for PSDs, > and by inheritance, for domains under PSDs for which no explicit policy > is published." -- My belief is that nobody cares about mail claiming to > come from "person@org", but it's important to have a policy that > applies to "person@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", inherited > from "org". > > > *RFC 7489 describes an algorithm for a mail-receiving organization to use > > in determining the Organizational Domain of an inbound mail message, and > > this algorithm recommends the use of a "public suffix list" (PSL), with > > the > > most common one maintained by the Mozilla Foundation and made public at > > <http://publicsuffix.org/ <http://publicsuffix.org/>>. Use of such a PSL > > by > > a mail-receiving organization will be required in order to discover and > > apply any DMARC policy declared by a PSD.* > > I don't know if this is useful, but I would suggest changing > "determining the Organizational Domain of an inbound mail message" to > "deriving from the domain name of the From address of an inbound mail > message the Organizational Domain to be used for DMARC processing". > > > *This document also seeks to address implementations that consider a > > domain > > on a public Suffix list to be ineligible for DMARC* > > I think you are very close to an Abstract/Introduction that is clearly > comprehensible to people who are not familiar with DMARC. Considering this is an extension to DMARC, I don't think that's the target audience. Scott K -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
