Re: [Gen-art] [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

[Scott Kitterman <[e-mail]>]

On Wednesday, April 15, 2020 10:32:32 PM EDT Dale R. Worley wrote:
> Todd Herr <[e-mail]> 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 "[e-mail]", 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