draft-ietf-dmarc-psd-13.txt   draft-ietf-dmarc-psd-14.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services Internet-Draft fTLD Registry Services
Intended status: Experimental T. Wicinski, Ed. Intended status: Experimental T. Wicinski, Ed.
Expires: October 3, 2021 April 1, 2021 Expires: November 27, 2021 May 26, 2021
Experimental DMARC Extension For Public Suffix Domains Experimental DMARC Extension For Public Suffix Domains
draft-ietf-dmarc-psd-13 draft-ietf-dmarc-psd-14
Abstract Abstract
Domain-based Message Authentication, Reporting, and Conformance Domain-based Message Authentication, Reporting, and Conformance
(DMARC) permits a domain-controlling organization to express domain- (DMARC) permits a domain-controlling organization to express domain-
level policies and preferences for message validation, disposition, level policies and preferences for message validation, disposition,
and reporting, which a mail-receiving organization can use to improve and reporting, which a mail-receiving organization can use to improve
mail handling. mail handling.
DMARC distinguishes the portion of a name that is a Public Suffix DMARC distinguishes the portion of a name that is a Public Suffix
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 3, 2021. This Internet-Draft will expire on November 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 46 skipping to change at page 6, line 46
".co.uk") name components, depending on PSD policy. ".co.uk") name components, depending on PSD policy.
2.7. Non-existent Domains 2.7. Non-existent Domains
For DMARC purposes, a non-existent domain is a domain for which there For DMARC purposes, a non-existent domain is a domain for which there
is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This
is a broader definition than that in [RFC8020]. is a broader definition than that in [RFC8020].
3. PSD DMARC Updates to DMARC Requirements 3. PSD DMARC Updates to DMARC Requirements
To participate in this experiment, implementations should interept To participate in this experiment, implementations should interpret
RFC7489 as follows: RFC7489 as follows:
3.1. General Updates 3.1. General Updates
References to "Domain Owners" also apply to PSOs. References to "Domain Owners" also apply to PSOs.
3.2. Changes in Section 6.3 "General Record Format" 3.2. Changes in Section 6.3 "General Record Format"
If this experiment is successful, this paragraph is added to this If this experiment is successful, this paragraph is added to this
setion. A new tag is added after "fo": section. A new tag is added after "fo":
np: Requested Mail Receiver policy for non-existent subdomains np: Requested Mail Receiver policy for non-existent subdomains
(plain-text; OPTIONAL). Indicates the policy to be enacted by the (plain-text; OPTIONAL). Indicates the policy to be enacted by the
Receiver at the request of the Domain Owner. It applies only to Receiver at the request of the Domain Owner. It applies only to
non-existent subdomains of the domain queried and not to either non-existent subdomains of the domain queried and not to either
existing subdomains or the domain itself. Its syntax is identical existing subdomains or the domain itself. Its syntax is identical
to that of the "p" tag defined below. If the "np" tag is absent, to that of the "p" tag defined below. If the "np" tag is absent,
the policy specified by the "sp" tag (if the "sp" tag is present) the policy specified by the "sp" tag (if the "sp" tag is present)
or the policy specified by the "p" tag, if the "sp" tag is not or the policy specified by the "p" tag, if the "sp" tag is not
present, MUST be applied for non-existent subdomains. Note that present, MUST be applied for non-existent subdomains. Note that
skipping to change at page 8, line 46 skipping to change at page 8, line 46
Note: Because the PSD policy query comes after the Organizational Note: Because the PSD policy query comes after the Organizational
Domain policy query, PSD policy is not used for Organizational Domain policy query, PSD policy is not used for Organizational
domains that have published a DMARC policy. Specifically, this is domains that have published a DMARC policy. Specifically, this is
not a mechanism to provide feedback addresses (RUA/RUF) when an not a mechanism to provide feedback addresses (RUA/RUF) when an
Organizational Domain has declined to do so. Organizational Domain has declined to do so.
3.6. Changes in Section 7 "DMARC Feedback" 3.6. Changes in Section 7 "DMARC Feedback"
If this experiment is successful, this paragraph is added to this If this experiment is successful, this paragraph is added to this
setion. section.
Operational note for PSD DMARC: For PSOs, feedback for non-existent Operational note for PSD DMARC: For PSOs, feedback for non-existent
domains is desirable and useful, just as it is for org-level DMARC domains is desirable and useful, just as it is for org-level DMARC
operators. See Section 4 of [this document] for discussion of operators. See Section 4 of [this document] for discussion of
Privacy Considerations for PSD DMARC. Privacy Considerations for PSD DMARC.
4. Privacy Considerations 4. Privacy Considerations
These privacy considerations are developed based on the requirements These privacy considerations are developed based on the requirements
of [RFC6973]. Additionally, the Privacy Considerations of [RFC7489] of [RFC6973]. Additionally, the Privacy Considerations of [RFC7489]
skipping to change at page 13, line 21 skipping to change at page 13, line 21
B.2. DMARC Public Suffix Domain (PSD) Registry B.2. DMARC Public Suffix Domain (PSD) Registry
[psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD)
Registry as a stand-alone DNS query service. It follows the contents Registry as a stand-alone DNS query service. It follows the contents
and structure described below. There is a Comma Separated Value and structure described below. There is a Comma Separated Value
(CSV) version of the listed PSD domains which is suitable for use in (CSV) version of the listed PSD domains which is suitable for use in
build updates for PSD DMARC capable software. build updates for PSD DMARC capable software.
PSDs that are deploying DMARC and are participating in PSD DMARC must PSDs that are deploying DMARC and are participating in PSD DMARC must
be register their public suffix domain in this new registry. The register their public suffix domain in this new registry. The
requirement has to be documented in a manner that satisfies the terms requirement has to be documented in a manner that satisfies the terms
of Expert Review, per [RFC8126]. The Designated Expert needs to of Expert Review, per [RFC8126]. The Designated Expert needs to
confirm that provided documentation adequately describes PSD policy confirm that provided documentation adequately describes PSD policy
to require domain owners to use DMARC or that all domain owners are to require domain owners to use DMARC or that all domain owners are
part of a single organization with the PSO. part of a single organization with the PSO.
The initial set of entries in this registry is as follows: The initial set of entries in this registry is as follows:
+-------------+---------------+ +-------------+---------------+
| PSD | Status | | PSD | Status |
 End of changes. 7 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/