I was just working on merging Barry's comments with Dave's and Kurt's.
I attached what should be correct. I would like someone to just double
check my work.
tim
On Sun, Feb 28, 2021 at 4:35 PM Murray S. Kucherawy <[email protected]>
wrote:
> These all work for me. Thanks for the contributions.
>
> Scott, please work your magic with a revision so the chairs can request
> publication and we can get this on its way.
>
> -MSK
>
> On Thu, Feb 25, 2021 at 9:13 AM Dave Crocker <[email protected]> wrote:
>
>> On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote:
>>
>> Especially in the case of the PSD policies, one should not expect that
>> the controlling organization would necessarily be "a mail-originating
>> organization". Generally the idea is to *disavow* being such :-)
>>
>> Suggested alternate text:
>>
>> Domain-based Message Authentication, Reporting, and Conformance (DMARC)
>> permits a domain-controlling
>> 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.
>>
>> +1
>>
>> d/
>>
>> --
>> Dave [email protected]
>> 408.329.0791
>>
>> Volunteer, Silicon Valley Chapter
>> American Red [email protected]
>>
>> _______________________________________________
>> dmarc mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
— Abstract —
OLD
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. The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have
occurred; it does not permit a domain name to have both of these
properties simultaneously. Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.
Domains at which registrations can occur are referred to as Public
Suffix Domains (PSDs). This document describes an extension to DMARC
to enable DMARC functionality for PSDs.
This document also seeks to address implementations that consider a
domain on a public Suffix list to be ineligible for DMARC
enforcement.
NEW
Domain-based Message Authentication, Reporting, and Conformance
(DMARC) permits a domain-controlling 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 —
OLD
DMARC as specified presumes that domain names present in a PSL are
not organizational domains and thus not subject to DMARC processing;
domains are either organizational domains, sub-domains of
organizational domains, or listed on a PSL. For domains listed in a
PSL, i.e., TLDs and domains that exist between TLDs and organization
level domains, policy can only be published for the exact domain. No
method is available for these domains to express policy or receive
feedback reporting for sub-domains. This missing method allows for
the abuse of non-existent organizational-level domains and prevents
identification of domain abuse in email.
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"). 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".
OLD
This DMARC record provides policy and a reporting destination for
mail sent from @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.
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.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
