draft-ietf-dmarc-psd-04.txt | draft-ietf-dmarc-psd-05.txt | |||
---|---|---|---|---|
Network Working Group S. Kitterman | Network Working Group S. Kitterman | |||
Internet-Draft fTLD Registry Services | Internet-Draft fTLD Registry Services | |||
Intended status: Experimental May 27, 2019 | Intended status: Experimental July 17, 2019 | |||
Expires: November 28, 2019 | Expires: January 18, 2020 | |||
DMARC (Domain-based Message Authentication, Reporting, and Conformance) | DMARC (Domain-based Message Authentication, Reporting, and Conformance) | |||
Extension For PSDs (Public Suffix Domains) | Extension For PSDs (Public Suffix Domains) | |||
draft-ietf-dmarc-psd-04 | draft-ietf-dmarc-psd-05 | |||
Abstract | Abstract | |||
DMARC (Domain-based Message Authentication, Reporting, and | DMARC (Domain-based Message Authentication, Reporting, and | |||
Conformance) is a scalable mechanism by which a mail-originating | Conformance) is a scalable mechanism by which a mail-originating | |||
organization can express domain-level policies and preferences for | organization can express domain-level policies and preferences for | |||
message validation, disposition, and reporting, that a mail-receiving | message validation, disposition, and reporting, that a mail-receiving | |||
organization can use to improve mail handling. DMARC policies can be | organization can use to improve mail handling. DMARC policies can be | |||
applied at the individual domain level or for a set of domains at the | applied at the individual domain level or for a set of domains at the | |||
organizational level. The design of DMARC precludes grouping | organizational level. The design of DMARC precludes grouping | |||
skipping to change at page 1, line 43 | skipping to change at page 1, line 43 | |||
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 November 28, 2019. | This Internet-Draft will expire on January 18, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 | 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 | |||
2.1. Conventions Used in This Document . . . . . . . . . . . . 4 | 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 | |||
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4 | 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 | |||
2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 | 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 | |||
2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 | 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 | |||
2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 | 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 | |||
3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5 | 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5 | |||
3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5 | 3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 6 | |||
3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5 | 3.3. Section 6.3 General Record Format . . . . . . . . . . . . 6 | |||
3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 6 | 3.4. Section 6.5. Domain Owner Actions . . . . . . . . . . . 6 | |||
3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6 | 3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 6 | |||
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 | 3.6. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 7 | |||
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6 | 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 7 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | ||||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 8 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 8 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 9 | 7.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 10 | Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 10 | |||
B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 10 | A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 10 | |||
B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 10 | A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 11 | |||
Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 11 | Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 11 | |||
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 11 | B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 11 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 | B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 12 | |||
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 12 | ||||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
DMARC [RFC7489] provides a mechanism for publishing organizational | DMARC [RFC7489] provides a mechanism for publishing organizational | |||
policy information to email receivers. DMARC [RFC7489] allows policy | policy information to email receivers. DMARC [RFC7489] allows policy | |||
to be specified for both individual domains and sets of domains | to be specified for both individual domains and sets of domains | |||
within a single organization. For domains above the organizational | within a single organization. For domains above the organizational | |||
level in the DNS tree, policy can only be published for the exact | level in the DNS tree, policy can only be published for the exact | |||
domain. There is no method available to such domains to express | domain. There is no method available to such domains to express | |||
lower level policy or receive feedback reporting for sets of domains. | lower level policy or receive feedback reporting for sets of domains. | |||
skipping to change at page 3, line 38 | skipping to change at page 3, line 45 | |||
in a mail delivery decision, but is not generally treated as | in a mail delivery decision, but is not generally treated as | |||
definitive on its own. | definitive on its own. | |||
This memo provides a simple extension to DMARC [RFC7489] to allow | This memo provides a simple extension to DMARC [RFC7489] to allow | |||
operators of Public Suffix Domains (PSDs) to express policy for | operators of Public Suffix Domains (PSDs) to express policy for | |||
groups of subdomains, extends the DMARC [RFC7489] policy query | groups of subdomains, extends the DMARC [RFC7489] policy query | |||
functionality to detect and process such a policy, describes receiver | functionality to detect and process such a policy, describes receiver | |||
feedback for such policies, and provides controls to mitigate | feedback for such policies, and provides controls to mitigate | |||
potential privacy considerations associated with this extension. | potential privacy considerations associated with this extension. | |||
This memo also provides a new DMARC [RFC7489] tag to indicate | ||||
requested handling policy for non-existent subdommains. This is | ||||
provided specifically to support phased deployment of PSD DMARC, but | ||||
is expected to be useful more generally. Undesired rejection risks | ||||
for mail purporting to be from domains that do not exist are | ||||
substantially lower than for those that do, so the operational risk | ||||
of requesting harsh policy treatment (e.g. reject) is lower. | ||||
As an additional benefit, the PSD DMARC extension will clarify | As an additional benefit, the PSD DMARC extension will clarify | |||
existing requirements. Based on the requirements of DMARC [RFC7489], | existing requirements. Based on the requirements of DMARC [RFC7489], | |||
DMARC should function above the organizational level for exact domain | DMARC should function above the organizational level for exact domain | |||
matches (i.e. if a DMARC record were published for 'example', then | matches (i.e. if a DMARC record were published for 'example', then | |||
mail from example@example should be subject to DMARC processing). | mail from example@example should be subject to DMARC processing). | |||
Testing had revealed that this is not consistently applied in | Testing had revealed that this is not consistently applied in | |||
different implementations. PSD DMARC will help clarify that DMARC is | different implementations. PSD DMARC will help clarify that DMARC is | |||
not limited to organizational domains and their sub-domains. | not limited to organizational domains and their sub-domains. | |||
There are two types of Public Suffix Operators (PSOs) for which this | There are two types of Public Suffix Operators (PSOs) for which this | |||
skipping to change at page 5, line 43 | skipping to change at page 6, line 11 | |||
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. Section 6.1 DMARC Policy Record | 3.2. Section 6.1 DMARC Policy Record | |||
PSD DMARC records are published as a subdomain of the PSD. For the | PSD DMARC records are published as a subdomain of the PSD. For the | |||
PSD ".example", the PSO would post DMARC policy in a TXT record at | PSD ".example", the PSO would post DMARC policy in a TXT record at | |||
"_dmarc.example". | "_dmarc.example". | |||
3.3. Section 6.5. Domain Owner Actions | 3.3. Section 6.3 General Record Format | |||
A new tag is added after fo: | ||||
np: Requested Mail Receiver policy for non-existent subdomains | ||||
(plain-text; OPTIONAL). Indicates the policy to be enacted by the | ||||
Receiver at the request of the Domain Owner. It applies only to | ||||
non-existent subdomains of the domain queried and not to either | ||||
existing subdomains or the domain itself. Its syntax is identical | ||||
to that of the "p" tag defined below. If absent, the policy | ||||
specified by the "sp" (if present) and then the "p" tag, if not, | ||||
MUST be applied for non-existent subdomains. Note that "np" will | ||||
be ignored for DMARC records published on subdomains of | ||||
Organizational Domains and PSDs due to the effect of the DMARC | ||||
policy discovery mechanism described in DMARC [RFC7489] | ||||
Section 6.6.3. | ||||
3.4. Section 6.5. Domain Owner Actions | ||||
In addition to the DMARC [RFC7489] domain owner actions, PSOs that | In addition to the DMARC [RFC7489] domain owner actions, PSOs that | |||
require use of DMARC ought to make that information available to | require use of DMARC ought to make that information available to | |||
receivers. | receivers. | |||
3.4. Section 6.6.3. Policy Discovery | 3.5. Section 6.6.3. Policy Discovery | |||
A new step between step 3 and 4 is added: | A new step between step 3 and 4 is added: | |||
3A. If the set is now empty and the longest PSD (Section 2.3) of the | 3A. If the set is now empty and the longest PSD (Section 2.3) of the | |||
Organizational Domain is one that the receiver has determined is | Organizational Domain is one that the receiver has determined is | |||
acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for | acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for | |||
a DMARC TXT record at the DNS domain matching the longest PSD | a DMARC TXT record at the DNS domain matching the longest PSD | |||
(Section 2.3) in place of the RFC5322.From domain in the message | (Section 2.3) in place of the RFC5322.From domain in the message | |||
(if different). A possibly empty set of records is returned. | (if different). A possibly empty set of records is returned. | |||
skipping to change at page 6, line 29 | skipping to change at page 7, line 11 | |||
(Section 2.3). The receiver would check to see if that PSD is listed | (Section 2.3). The receiver would check to see if that PSD is listed | |||
in the DMARC PSD Registry, and if so, perform the policy lookup at | in the DMARC PSD Registry, and if so, perform the policy lookup at | |||
"_dmarc.compute.cloudcompany.com.cctld". | "_dmarc.compute.cloudcompany.com.cctld". | |||
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 [RFC7489] policy. Specifically, | domains that have published a DMARC [RFC7489] policy. Specifically, | |||
this is not a mechanism to provide feedback addresses (RUA/RUF) when | this is not a mechanism to provide feedback addresses (RUA/RUF) when | |||
an Organizational Domain has declined to do so. | an Organizational Domain has declined to do so. | |||
3.5. Section 7. DMARC Feedback | 3.6. Section 7. DMARC Feedback | |||
Operational note for PSD DMARC: For PSOs, feedback for non-existent | Operational note for PSD DMARC: For PSOs, feedback for non-existent | |||
domains is desired and useful. See Section 4 for discussion of | domains is desired and useful. See Section 4 for discussion of | |||
Privacy Considerations. | Privacy Considerations. | |||
4. Privacy Considerations | 4. Privacy Considerations | |||
These privacy considerations are developed based on the requiremetns | These privacy considerations are developed based on the requirements | |||
of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this | of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this | |||
document. | document. | |||
4.1. Feedback leakage | 4.1. Feedback leakage | |||
Providing feedback reporting to PSOs can, in some cases, create | Providing feedback reporting to PSOs can, in some cases, create | |||
leakage of information outside of an organization to the PSO. This | leakage of information outside of an organization to the PSO. This | |||
leakage could be potentially be utilized as part of a program of | leakage could potentially be utilized as part of a program of | |||
pervasive surveillance (See [RFC7624]). There are roughly three | pervasive surveillance (See [RFC7624]). There are roughly three | |||
cases to consider: | cases to consider: | |||
o Single Organization PSDs (e.g., ".google"), RUA and RUF reports | o Single Organization PSDs (e.g., ".google"), RUA and RUF reports | |||
based on PSD DMARC have the potential to contain information about | based on PSD DMARC have the potential to contain information about | |||
emails related to entities managed by the organization. Since | emails related to entities managed by the organization. Since | |||
both the PSO and the Organizational Domain owners are common, | both the PSO and the Organizational Domain owners are common, | |||
there is no additional privacy risk for either normal or non- | there is no additional privacy risk for either normal or non- | |||
existent Domain reporting due to PSD DMARC. | existent Domain reporting due to PSD DMARC. | |||
skipping to change at page 7, line 24 | skipping to change at page 8, line 6 | |||
compliance with PSD policy. Data on non-existent cousin domains | compliance with PSD policy. Data on non-existent cousin domains | |||
would be sent to the PSO. | would be sent to the PSO. | |||
o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC | o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC | |||
usage: Privacy risks for Organizational Domains that have not | usage: Privacy risks for Organizational Domains that have not | |||
deployed DMARC within such PSDs are significant. For non-DMARC | deployed DMARC within such PSDs are significant. For non-DMARC | |||
Organizational Domains, all DMARC feedback will be directed to the | Organizational Domains, all DMARC feedback will be directed to the | |||
PSO. PSD DMARC is opt-out (by publishing a DMARC record at the | PSO. PSD DMARC is opt-out (by publishing a DMARC record at the | |||
Organizational Domain level) vice opt-in, which would be the more | Organizational Domain level) vice opt-in, which would be the more | |||
desirable characteristic. This means that any non-DMARC | desirable characteristic. This means that any non-DMARC | |||
organizational domain would have it's feedback reports redirected | organizational domain would have its feedback reports redirected | |||
to the PSO. The content of such reports, particularly for | to the PSO. The content of such reports, particularly for | |||
existing domains, is privacy sensitive. | existing domains, is privacy sensitive. | |||
PSOs will receive feedback on non-existent domains, which may be | PSOs will receive feedback on non-existent domains, which may be | |||
similar to existing Organizational Domains. Feedback related to such | similar to existing Organizational Domains. Feedback related to such | |||
cousin domains have a small risk of carrying information related to | cousin domains have a small risk of carrying information related to | |||
an actual Organizational Domain. To minimize this potential concern, | an actual Organizational Domain. To minimize this potential concern, | |||
PSD DMARC feedback is best limited to Aggregate Reports. Feedback | PSD DMARC feedback is best limited to Aggregate Reports. Feedback | |||
Reports carry more detailed information and present a greater risk. | Reports carry more detailed information and present a greater risk. | |||
skipping to change at page 8, line 7 | skipping to change at page 8, line 37 | |||
[RFC7489] and [RFC7960]. | [RFC7489] and [RFC7960]. | |||
The risks of the issues identified in [RFC7489], Section 12.5, | The risks of the issues identified in [RFC7489], Section 12.5, | |||
External Reporting Addresses, are amplified by PSD DMARC. By design, | External Reporting Addresses, are amplified by PSD DMARC. By design, | |||
PSD DMARC causes unrequested reporting of feedback to entities | PSD DMARC causes unrequested reporting of feedback to entities | |||
external to the Organizational Domain. This is discussed in more | external to the Organizational Domain. This is discussed in more | |||
detail in Section 4. | detail in Section 4. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document does not require any IANA actions. | This section describes actions requested to be completed by IANA. | |||
6.1. Subdomain Policy Tag | ||||
IANA is requested to add a new tag to DMARC Tag Registry in the | ||||
Domain-based Message Authentication, Reporting, and Conformance | ||||
(DMARC) Parameters Registry. | ||||
The entry is as follows: | ||||
+----------+-----------+---------+-------------------------------+ | ||||
| Tag Name | Reference | Status | Description | | ||||
+----------+-----------+---------+-------------------------------+ | ||||
| np | this | current | Requested handling policy for | | ||||
| | document | | non-existent subdomains | | ||||
+----------+-----------+---------+-------------------------------+ | ||||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 9, line 25 | skipping to change at page 10, line 25 | |||
and Conformance (DMARC) and Indirect Email Flows", | and Conformance (DMARC) and Indirect Email Flows", | |||
RFC 7960, DOI 10.17487/RFC7960, September 2016, | RFC 7960, DOI 10.17487/RFC7960, September 2016, | |||
<https://www.rfc-editor.org/info/rfc7960>. | <https://www.rfc-editor.org/info/rfc7960>. | |||
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is | [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is | |||
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, | Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, | |||
November 2016, <https://www.rfc-editor.org/info/rfc8020>. | November 2016, <https://www.rfc-editor.org/info/rfc8020>. | |||
Appendix A. The Experiment | Appendix A. The Experiment | |||
There are two experimental questions addressed in this document: one | ||||
regarding mitigation of PSD related privacy concerns and the other on | ||||
the utility of specifying separate DMARC policies for non-existent | ||||
sub-domains. | ||||
A.1. PSD DMARC Privacy Concern Mitigation | ||||
To mitigate the privacy concerns associated with Multi-organization | To mitigate the privacy concerns associated with Multi-organization | |||
PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to | PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to | |||
indicate which PSDs do not present this privacy risk is appropriate. | indicate which PSDs do not present this privacy risk is appropriate. | |||
There are multiple approaches that are possible. | There are multiple approaches that are possible. | |||
The experiment is to evaluate different possible approaches. The | The experiment is to evaluate different possible approaches. The | |||
experiment will be complete when there is rough consensus on a | experiment will be complete when there is rough consensus on a | |||
technical approach that is demonstrated to be operationally usable | technical approach that is demonstrated to be operationally usable | |||
and effective at mitigating the privacy concern. | and effective at mitigating the privacy concern. | |||
skipping to change at page 10, line 15 | skipping to change at page 11, line 22 | |||
As of this writing, three approaches have been proposed. None of | As of this writing, three approaches have been proposed. None of | |||
them are ideal: | them are ideal: | |||
o An extension to the Public Suffix List at [PSL] | o An extension to the Public Suffix List at [PSL] | |||
o A dedicated registry queried via DNS - an example of such a | o A dedicated registry queried via DNS - an example of such a | |||
service is described in Appendix B.1 below | service is described in Appendix B.1 below | |||
o An IANA registry | o An IANA registry | |||
A.2. Non-Existent Subdomain Policy | ||||
PSOs that plan to implement PSD DMARC have indicated that the ability | ||||
to describe distinct policies for existing and non- existing sub- | ||||
domains would facilitate PSD DMARC deployment. There are also | ||||
suggestions that it would be more generally useful for DMARC. | ||||
During the period of the experiment, uptake of the new 'np' tag will | ||||
be evaluated to support assessment of the utility of including 'np' | ||||
in a future, non-experimental update. | ||||
Appendix B. DMARC PSD Registry Examples | Appendix B. DMARC PSD Registry Examples | |||
To faciliate experimentation around data leakage mitigation, samples | To facilitate experimentation around data leakage mitigation, samples | |||
of the DNS based and IANA like registries are available at | of the DNS based and IANA like registries are available at | |||
[psddmarc.org]. | [psddmarc.org]. | |||
B.1. DMARC PSD DNS Query Service | B.1. DMARC PSD DNS Query Service | |||
A sample stand-alone DNS query service is available at | A sample stand-alone DNS query service is available at | |||
[psddmarc.org]. It was developed based on the contents suggested for | [psddmarc.org]. It was developed based on the contents suggested for | |||
an IANA registry in an earlier revision of this draft. Usage of the | an IANA registry in an earlier revision of this draft. Usage of the | |||
service is described on the web site. | service is described on the web site. | |||
End of changes. 18 change blocks. | ||||
32 lines changed or deleted | 94 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |