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

[[e-mail]]

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.

Dale