Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker <[e-mail]>]

If everyone liked using the PSL and making it integral to DMARC, then 
that would be fine.  But they don't; so it isn't.

The suggested revisions to Barry's suggested revisions, below, primarily 
serve to reference the PSD construct without needing to reference the 
PSL.  And, of course, there are various other suggested wording tweaks...


On 2/24/2021 9:10 PM, Barry Leiba wrote:
> — Abstract —
>
>
> NEW
>     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.
>
>     DMARC uses a Public Suffix List (PSL) to determine what part of a
>     domain name is the Public Suffix Domain (PSD), below which
>     organizational domain names are created.  DMARC allows organizational
>     domains to specify policies that apply to their subdomains, but it
>     does not give that flexibility to PSDs.
>
>     This document describes an extension to DMARC to fully enable DMARC
>     functionality for PSDs.  This document also addresses implementations
>     that consider a domain on a public Suffix list to be ineligible for
>     DMARC enforcement.

The major intention is removal of reference to /how/ it does the hierarchy distinction.  In case it ever uses a different mechanism that people like better...

EVEN NEWER
    Domain-based Message Authentication, Reporting, and
    Conformance (DMARC) permits a mail-originating
    organization to express domain-level policies and preferences for
    message validation, disposition, and reporting, which a mail-receiving
    organization can use to improve mail handling.

    DMARC distinguishes the portion of a name that is a
       Public Suffix Domain (PSD), below which
    organizational domain names are created.  The basic DMARC capability allows organizational
    domains to specify policies that apply to their subdomains, but it
    does not give that capability to PSDs. This document describes an extension to DMARC to
       fully enable DMARC
    functionality for PSDs.

    Some implementations of DMARC consider a PSD to be ineligible for
    DMARC enforcement.  This specification addresses that case.




> — Section 1 —
>
> NEW
>     DMARC as specified presumes that domain names present in a Public
>     Suffix List (PSL) — Public Suffix Domains (PSDs) — are not
>     organizational domains and are thus not subject to DMARC processing.
>     In DMARC, domains fall into one of three categories: organizational
>     domains, sub-domains of organizational domains, or PSDs.  For PSDs,
>     policy can only be published for the exact domain: no mechanism is
>     available for PSDs to express policy or receive feedback reporting
>     for sub-domains.  The lack of such a mechanism allows for the abuse
>     of non-existent organizational-level domains and hampers
>     identification of domain abuse in email.

EVEN NEWER

NEW
    In the basic DMARC model, PSDs are not
    organizational domains and are thus not subject to DMARC processing.
    In DMARC, domains fall into one of three categories: organizational
    domains, sub-domains of organizational domains, or PSDs.  A PSD
    can only publish DMARC policy for itself, and not for any sub-domains under it.
       In some cases, this limitation allows for the abuse
    of non-existent organizational-level domains and hampers
    identification of domain abuse in email.




> — Section 1.1 —
>
> OLD
>     As an example, imagine a country code TLD (ccTLD) which has public
>     subdomains for government and commercial use (".gov.example" and
>     ".com.example").  A PSL whose maintainer is aware of this country's
>     domain structurewould include entries for both of these in the PSL,
>     indicating that they are PSDs below which registrations can occur.
>     Suppose further that there exists a domain "tax.gov.example",
>     registered within ".gov.example", that is responsible for taxation in
>     this imagined country.
>
> NEW
>     As an example, imagine a Top-Level Domain (TLD), ".example", that has
>     public subdomains for government and commercial use (".gov.example"
>     and ".com.example").  A PSL whose maintainer is aware of this TLD’s
>     domain structure would include entries for both of these in the PSL,
>     indicating that they are PSDs below which organizational domains can
>     be registered.  Suppose further that there exists a legitimate domain
>     called "tax.gov.example", registered within ".gov.example".


EVEN NEWER
    As an example, imagine a Top-Level Domain (TLD), ".example", that has
    public subdomains for government and commercial use (".gov.example"
    and ".com.example").  The maintainer of a list of such a PSD structure
    would include entries for both of these sub-domains, thereby
    indicating that they are PSDs, below which organizational domains can
    be registered.  Suppose further that there exists a legitimate domain
    called "tax.gov.example", registered within ".gov.example".




> NEW
>     This DMARC record provides policy and a reporting destination for
>     mail sent from @gov.example.  Similarly, "tax.gov.example" will have
>     a DMARC record that specifies policy for mail sent from addresses
>     @tax.gov.example.  However, due to DMARC's current method of
>     discovering and applying policy at the organizational domain
>     level, the non-existent organizational domain of @t4x.gov.example
>     does not and cannot fall under a DMARC policy.

darn.  couldn't find anything to suggest changing for this one...


d/

  

-- 
Dave Crocker
[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[e-mail]