Re: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd

[Alessandro Vesely <[e-mail]>]

Dave and all,

On Tue 10/Mar/2020 23:16:41 +0100 Dave Crocker wrote:
> 
> This is offered as summary comments, focusing on some basic concerns, rather
> than providing a detailed review of the specification.
> 
> My original comments were posted 12 August 2019:
> 
>    https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg
> 
> 
> 
> 0. DMARC use of Organizational Domain
> 
> DMARC specifies use of the Organizational Domain as a fallback for not finding
> a DMARC record at the full domain name under scrutiny.  The need for this is to
> cover slow DMARC adoption among sub-domains and to handle queries about
> non-existent domains.


After so many years of SPF, I would call it lazy adoption, not slow.  It is
apparent that domain owners don't want to clutter their DNS zones with tons of
TXT records.


> 1. These are not 'public' suffixes (1)
> 
> The concept of a 'public' suffix refers to domain names associated with
> registries subject to externally-imposed operational policies.  For want of a
> better term, these operations are regulated.  The domain suffixes that PSD
> attends to are not public registries.


Please, let's not speculate on the multifaceted term "public".  For example,
"public school" means something completely different in the US than the UK.
What about "public enemy" in the 1930s and now?  For "public suffix", I propose
we stick to the definition referred by rfc8499.


>    *  If the company that uses .example.com also gets .example, the latter is
> not a 'public' domain.  It is a private domain, just like example.com.  In
> terms of DMARC, the fact that it is delegated by ICANN rather than a 'regular'
> registry is -- or at least should be -- irrelevant.
> 
>    *  If member-based association that uses association.example gets
> ..association, the latter is not a public domain.  It's private.
> 
>    *  A government-based domain name that want to enforce DMARC onto
> subordinate domain names of subordinate agencies that haven't yet adopted it
> are, of course, pursuing an entirely reasonable goal.  But these, too, are not
> public suffixes and their need is internal to their organization.
> 
> In every case, these are domains at the top of an administrative authority, for
> all of the subordinate domains.  That's the definition of an Organizational
> Domain.


I agree that the term "organizational domain" should cover an administratively
cohesive unit.  To forge a good definition will be a nice topic to discuss.

IMHO, pushing toward having DMARC distance itself from the PSL is the most
important contribution of this series of posts.  Indeed, since we don't control
how the PSL might evolve, doing so seems to be required.

BTW, the PSL itself has varying interpretations.  For example, publicsuffix2[*]
provides a get_public_suffix() function featuring two optional Boolean
parameters, wildcard and strict, which tweak the semantic quite a bit (well, two).


[*] https://pypi.org/project/publicsuffix2/


> 2. Externalizing internal difficulties
> 
> Some organizations have sub-groups to which various administrative
> responsibilities have been delegated.  In general, there can be many levels of
> such delegation.  Not just two.
> 
> For the cases the PSD specification is intended to cover,
> PSD seeks to adapt to slow DMARC adoption or non-existent domains for one of
> its delegated sub-groups, by looking for an even-higher-level encompassing
> record under a next-level Organizational Domain.  That is, PSD is specifying
> using two different Organizational Domains.  The usual one and its parent.


Correct.  The existence of often-abused suffixes derives right from their
specialization.  I think we should favor that different suffixes differ.


> A difficulty within the organization is being externalized to a burden for
> everyone else on the net.


The burden of filtering is on "external" mail receivers, obviously.  The same
is true for DMARC and email in general.


> 3. DMARC wants the Organizational Domain
> 
> The existing DMARC model is a) look under the full domain, and then b) look
> under the Organizational Domain, as a fallback.  My strong suggestion is to
> keep the model as simple as that.
> 
> The argument for adding just this one more layer of Organizational Domain seems
> modest, primarily because it is purpose-built to handle a new, special case,
> rather than because it represents a considered, general case.


Having three levels instead of two sounds quite general.  A very large
organization, such as gov.uk, needs to delegate to many branches, and each
branch uses a number of domain names.  Simply removing gov.uk from the PSL
—that is, considering it a private suffix— would prevent branches from
specifying their own policy.  How would we define a 3rd layer in that case?


> 4. DMARC should not specify how to obtain the Organizational Domain.
> 
> DMARC needs to say 'give me the organizational domain' or perhaps 'give me the
> dmarc record under the organizational domain' and it needs to have nothing to
> do with the method of satisfying the request.
> 
> It's not that the problem being addressed by PSD isn't real.  It's that it
> needs to be viewed more carefully.
> 
> The combination of this being a problem /within/ an organization, along with
> the various continuing challenges of the PSL, mean that all knowledge of this
> needs to be kept away from the DMARC spec.


Fully agreed.  Some kind of statement will have to measure how much the
(current) PSL fits, though.


> 5. There is little engagement with the PSD technical effort
> 
> It is easy to see why owners of some domains would want a mechanism like PSD. 
> As noted, they do have a real and significant problem.  So, statements of
> support from such folk merely confirm their need.  (As an aside I'll note that
> historically the IETF hasn't been all that interested in simplistic statements
> of support but, rather, actual involvement in the engineering discussion.)
> 
> What such statements do /not/ provide is any indication that the broader
> Internet community has an interest in adopting this.


I'd reckon avoiding [e-mail] is every mailbox provider's interest.

Statements by large mailbox provider are welcome!


> 6. The 'experiment' has vague goals and criteria
> 
> In spite of having explicit language covering this specification as an
> 'experiment' the specification does not give me a clear and concrete
> understanding of exactly what will be evaluated, or how, and what constitutes
> satisfactory accomplishment.


I'd let Scott illustrate Appendixes A1 and A2.  They look quite clear to me.


Best
Ale
--