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
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
