< draft-dmarc-base-00-02.txt | draft-kucherawy-dmarc-base-00.txt > | |||
---|---|---|---|---|
DMARC.org M. Kucherawy, Ed. | Network Working Group M. Kucherawy, Ed. | |||
Cloudmark | Internet-Draft March 31, 2013 | |||
March 30, 2012 | Intended status: Standards Track | |||
Expires: October 2, 2013 | ||||
Domain-based Message Authentication, Reporting and Conformance (DMARC) | Domain-based Message Authentication, Reporting and Conformance (DMARC) | |||
draft-kucherawy-dmarc-base-00 | ||||
Abstract | Abstract | |||
The email ecosystem currently lacks a cohesive mechanism through | The email ecosystem currently lacks a cohesive mechanism through | |||
which email senders and receivers can make use of multiple | which email senders and receivers can make use of multiple | |||
authentication protocols in an attempt to establish reliable domain | authentication protocols in an attempt to establish reliable domain | |||
identifiers. This lack of cohesion prevents receivers from providing | identifiers. This lack of cohesion prevents receivers from providing | |||
domain-specific feedback to senders regarding the accuracy of | domain-specific feedback to senders regarding the accuracy of | |||
authentication deployments. Inaccurate authentication deployments | authentication deployments. Inaccurate authentication deployments | |||
preclude receivers from safely taking deterministic action against | preclude receivers from safely taking deterministic action against | |||
skipping to change at page 2, line 5 | skipping to change at page 1, line 37 | |||
policies and preferences for message validation, disposition, and | policies and preferences for message validation, disposition, and | |||
reporting with predictable and accurate results. | reporting with predictable and accurate results. | |||
The enclosed proposal is not intended to introduce mechanisms that | The enclosed proposal is not intended to introduce mechanisms that | |||
provide elevated delivery privilege of authenticated email. The | provide elevated delivery privilege of authenticated email. The | |||
proposal presents a mechanism for policy distribution that enables a | proposal presents a mechanism for policy distribution that enables a | |||
continuum of increasingly strict handling of messages that fail | continuum of increasingly strict handling of messages that fail | |||
multiple authentication checks, from no action, through silent | multiple authentication checks, from no action, through silent | |||
reporting, up to message rejection. | reporting, up to message rejection. | |||
Status of this Memo | ||||
This Internet-Draft is submitted in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
This Internet-Draft will expire on October 2, 2013. | ||||
Copyright Notice | ||||
Copyright (c) 2013 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | ||||
to this document. Code Components extracted from this document must | ||||
include Simplified BSD License text as described in Section 4.e of | ||||
the Trust Legal Provisions and are provided without warranty as | ||||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. License . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. License . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.2. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.3. Towards An Authenticated Future . . . . . . . . . . . . . 7 | 2.3. Towards An Authenticated Future . . . . . . . . . . . . . 8 | |||
2.4. Experiment Team . . . . . . . . . . . . . . . . . . . . . 8 | 2.4. Experiment Team . . . . . . . . . . . . . . . . . . . . . 9 | |||
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 8 | 3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 9 | |||
3.2. Security Dependencies . . . . . . . . . . . . . . . . . . 9 | 3.2. Security Dependencies . . . . . . . . . . . . . . . . . . 10 | |||
3.3. DMARC Discovery Requirements . . . . . . . . . . . . . . 9 | 3.3. DMARC Discovery Requirements . . . . . . . . . . . . . . 10 | |||
3.4. Detailed Requirements . . . . . . . . . . . . . . . . . . 10 | 3.4. Detailed Requirements . . . . . . . . . . . . . . . . . . 11 | |||
3.5. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . 12 | 3.5. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . 13 | |||
4. Terminology and Definitions . . . . . . . . . . . . . . . . . 13 | 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 14 | |||
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 16 | |||
4.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 15 | 4.2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.2.1. DKIM-authenticated Identifiers . . . . . . . . . . . 16 | 4.3. Identifier Alignment . . . . . . . . . . . . . . . . . . 16 | |||
4.2.2. SPF-authenticated Identifiers . . . . . . . . . . . . 16 | 4.3.1. DKIM-authenticated Identifiers . . . . . . . . . . . 17 | |||
4.2.3. Alignment and Extension Technologies . . . . . . . . 17 | 4.3.2. SPF-authenticated Identifiers . . . . . . . . . . . . 18 | |||
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.3.3. Alignment and Extension Technologies . . . . . . . . 18 | |||
6. DMARC Policy Record . . . . . . . . . . . . . . . . . . . . . 18 | 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
6.1. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 18 | 6. DMARC Policy Record . . . . . . . . . . . . . . . . . . . . . 19 | |||
6.2. General Record Format . . . . . . . . . . . . . . . . . . 19 | 6.1. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
6.3. Formal Definition . . . . . . . . . . . . . . . . . . . . 21 | 6.2. General Record Format . . . . . . . . . . . . . . . . . . 20 | |||
7. Policy Enforcement Considerations . . . . . . . . . . . . . . 23 | 6.3. Formal Definition . . . . . . . . . . . . . . . . . . . . 23 | |||
8. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 23 | 7. Policy Enforcement Considerations . . . . . . . . . . . . . . 25 | |||
8.1. Feedback Considerations . . . . . . . . . . . . . . . . . 23 | 7.1. Policy Fallback Mechanism . . . . . . . . . . . . . . . . 26 | |||
8.2. Verifying External Destinations . . . . . . . . . . . . . 24 | 8. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
8.3. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 25 | 8.1. Feedback Considerations . . . . . . . . . . . . . . . . . 26 | |||
8.4. Failure Reports . . . . . . . . . . . . . . . . . . . . . 26 | 8.2. Verifying External Destinations . . . . . . . . . . . . . 26 | |||
9. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . . 26 | 8.3. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 28 | |||
10. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . . 27 | 8.4. Failure Reports . . . . . . . . . . . . . . . . . . . . . 30 | |||
11. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 29 | 8.4.1. Reporting Format Update . . . . . . . . . . . . . . . 30 | |||
11.1. Extract Author Domain . . . . . . . . . . . . . . . . . . 29 | 8.5. Failure Reports . . . . . . . . . . . . . . . . . . . . . 31 | |||
11.2. Determine Handling Policy . . . . . . . . . . . . . . . . 29 | 9. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
11.3. Message Sampling . . . . . . . . . . . . . . . . . . . . 30 | 10. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . . 33 | |||
11.4. Store Results of DMARC Processing . . . . . . . . . . . . 30 | 11. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 34 | |||
12. Feedback Mechanism . . . . . . . . . . . . . . . . . . . . . . 31 | 11.1. Extract Author Domain . . . . . . . . . . . . . . . . . . 34 | |||
12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 31 | 11.2. Determine Handling Policy . . . . . . . . . . . . . . . . 34 | |||
12.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 | 11.3. Message Sampling . . . . . . . . . . . . . . . . . . . . 35 | |||
12.2.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 32 | 11.4. Store Results of DMARC Processing . . . . . . . . . . . . 36 | |||
12.2.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 33 | 12. Feedback Mechanism . . . . . . . . . . . . . . . . . . . . . . 36 | |||
12.2.3. Other Methods . . . . . . . . . . . . . . . . . . . . 33 | 12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
12.2.4. Error Reports . . . . . . . . . . . . . . . . . . . . 33 | 12.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
13. Minimum Implementations . . . . . . . . . . . . . . . . . . . 34 | 12.2.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 12.2.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
14.1. Authentication-Results Method Registry Update . . . . . . 35 | 12.2.3. Other Methods . . . . . . . . . . . . . . . . . . . . 39 | |||
14.2. Authentication-Results Result Registry Update . . . . . . 35 | 12.2.4. Error Reports . . . . . . . . . . . . . . . . . . . . 39 | |||
14.3. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 36 | 13. Minimum Implementations . . . . . . . . . . . . . . . . . . . 40 | |||
14.4. DMARC Report Format Registry . . . . . . . . . . . . . . 37 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 14.1. Authentication-Results Method Registry Update . . . . . . 41 | |||
15.1. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . 38 | 14.2. Authentication-Results Result Registry Update . . . . . . 41 | |||
15.2. Display Name Attacks . . . . . . . . . . . . . . . . . . 39 | 14.3. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 42 | |||
15.3. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 39 | 14.4. DMARC Report Format Registry . . . . . . . . . . . . . . 43 | |||
15.4. Issues Specific to SPF . . . . . . . . . . . . . . . . . 40 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 44 | |||
15.5. DNS Load . . . . . . . . . . . . . . . . . . . . . . . . 40 | 15.1. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . 44 | |||
15.6. External Reporting Addresses . . . . . . . . . . . . . . 41 | 15.2. Display Name Attacks . . . . . . . . . . . . . . . . . . 45 | |||
15.7. Feedback Loops . . . . . . . . . . . . . . . . . . . . . 41 | 15.3. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 45 | |||
15.8. Rejecting Messages . . . . . . . . . . . . . . . . . . . 42 | 15.4. Issues Specific to SPF . . . . . . . . . . . . . . . . . 46 | |||
15.9. Capacity Planning . . . . . . . . . . . . . . . . . . . . 42 | 15.5. DNS Load . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
15.10. Privacy Considerations . . . . . . . . . . . . . . . . . 43 | 15.6. External Reporting Addresses . . . . . . . . . . . . . . 47 | |||
15.10.1. Data Exposure Considerations . . . . . . . . . . . . 43 | 15.7. Feedback Loops . . . . . . . . . . . . . . . . . . . . . 47 | |||
15.10.2. Report Recipients . . . . . . . . . . . . . . . . . . 44 | 15.8. Rejecting Messages . . . . . . . . . . . . . . . . . . . 48 | |||
15.10.3. Report Generators . . . . . . . . . . . . . . . . . . 44 | 15.9. Capacity Planning . . . . . . . . . . . . . . . . . . . . 49 | |||
15.10.4. Secure Protocols . . . . . . . . . . . . . . . . . . 44 | 15.10. Privacy Considerations . . . . . . . . . . . . . . . . . 49 | |||
15.11. Identifier Alignment Considerations . . . . . . . . . . . 44 | 15.10.1. Data Exposure Considerations . . . . . . . . . . . . 49 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | 15.10.2. Report Recipients . . . . . . . . . . . . . . . . . . 50 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . 45 | 15.10.3. Report Generators . . . . . . . . . . . . . . . . . . 50 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . 46 | 15.10.4. Secure Protocols . . . . . . . . . . . . . . . . . . 50 | |||
Appendix A. Technology Considerations . . . . . . . . . . . . . . 47 | 15.11. Identifier Alignment Considerations . . . . . . . . . . . 51 | |||
A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47 | 15.12. DNS Security . . . . . . . . . . . . . . . . . . . . . . 51 | |||
A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 48 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 48 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 51 | |||
A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 49 | 16.2. Informative References . . . . . . . . . . . . . . . . . 53 | |||
A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 49 | Appendix A. Technology Considerations . . . . . . . . . . . . . . 54 | |||
A.6. Organizational Domain Discovery Issues . . . . . . . . . 50 | A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 51 | A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 55 | |||
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 51 | A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 55 | |||
B.1. Identifier Alignment examples . . . . . . . . . . . . . . 51 | A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 56 | |||
B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 51 | A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 56 | |||
B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 52 | A.6. Organizational Domain Discovery Issues . . . . . . . . . 57 | |||
B.2. Domain Owner example . . . . . . . . . . . . . . . . . . 53 | A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 58 | |||
B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 53 | Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 58 | |||
B.1. Identifier Alignment examples . . . . . . . . . . . . . . 58 | ||||
B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 59 | ||||
B.2. Domain Owner example . . . . . . . . . . . . . . . . . . 60 | ||||
B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 61 | ||||
B.2.2. Entire Domain, Monitoring Only, Per-Message | B.2.2. Entire Domain, Monitoring Only, Per-Message | |||
Reports . . . . . . . . . . . . . . . . . . . . . . . 54 | Reports . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
B.2.3. Per-Message Forensic Reports Directed to Third | B.2.3. Per-Message Failure Reports Directed to Third | |||
Party . . . . . . . . . . . . . . . . . . . . . . . . 55 | Party . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
B.2.4. Sub-Domain, Sampling, and Multiple Aggregate | B.2.4. Sub-Domain, Sampling, and Multiple Aggregate | |||
Report URIs . . . . . . . . . . . . . . . . . . . . . 56 | Report URIs . . . . . . . . . . . . . . . . . . . . . 64 | |||
B.2.5. Third Party Sender and Identifier Alignment . . . . . 58 | B.2.5. Third Party Sender and Identifier Alignment . . . . . 65 | |||
B.2.6. Sub-Domain Policy, Reporting Interval . . . . . . . . 59 | B.2.6. Sub-Domain Policy, Reporting Interval . . . . . . . . 66 | |||
B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 60 | B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 67 | |||
B.3.1. SMTP-time Processing . . . . . . . . . . . . . . . . 60 | B.3.1. SMTP-time Processing . . . . . . . . . . . . . . . . 67 | |||
B.3.2. Real-time Feedback Processing . . . . . . . . . . . . 62 | B.3.2. Real-time Feedback Processing . . . . . . . . . . . . 69 | |||
B.4. Utilization of Aggregate Feedback example . . . . . . . . 62 | B.4. Utilization of Aggregate Feedback example . . . . . . . . 69 | |||
B.5. mailto Transport example . . . . . . . . . . . . . . . . 62 | B.5. mailto Transport example . . . . . . . . . . . . . . . . 70 | |||
B.6. https Transport example . . . . . . . . . . . . . . . . . 63 | B.6. https Transport example . . . . . . . . . . . . . . . . . 71 | |||
Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 64 | Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 71 | |||
Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 69 | Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 77 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 77 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78 | ||||
1. License | 1. License | |||
As of the date shown at the top right of this page, the Contributors | As of the date shown at the top right of this page, the Contributors | |||
have made this Specification available under the Open Web Foundation | have made this Specification available under the Open Web Foundation | |||
Contributor License Agreement Version 1.0, which is available at: | Contributor License Agreement Version 1.0, which is available at: | |||
http://www.dmarc.org/cla.html | http://www.dmarc.org/cla.html | |||
You can review the signed copies of the Open Web Foundation | You can review the signed copies of the Open Web Foundation | |||
Contributor License Agreement Version 1.0 for this Specification at: | Contributor License Agreement Version 1.0 for this Specification at: | |||
skipping to change at page 5, line 39 | skipping to change at page 6, line 39 | |||
ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING | ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING | |||
AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING | AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING | |||
NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS | NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS | |||
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | |||
2. Introduction | 2. Introduction | |||
For years, various receivers have tried to protect senders who are | For years, various receivers have tried to protect senders who are | |||
known to authenticate their outbound email from phishing by using | known to authenticate their outbound email from phishing by using | |||
[DKIM] and/or [SPF] results to detect and block unauthorized email. | [DKIM] and/or [SPF] results to detect and block unauthorized email. | |||
At the same time, senders have leveraged SPF-authorized and DKIM- | (A detailed discussion of the threats these systems attempt to | |||
signed messages to achieve domain-level email authentication. | address can be found in [DKIM-THREATS].) At the same time, senders | |||
However, a broadly accepted mechanism to assert domain-specific | have leveraged SPF-authorized and DKIM-signed messages to achieve | |||
message-disposition policies, or to request reporting of same, has | domain-level email authentication. However, a broadly accepted | |||
been lacking. | mechanism to assert domain-specific message-disposition policies, or | |||
to request reporting of same, has been lacking. | ||||
The fundamental idea behind these approaches is that if a sender | The fundamental idea behind these approaches is that if a sender | |||
authenticates all legitimate outbound mail using the authentication | authenticates all legitimate outbound mail using the authentication | |||
protocols SPF and DKIM, then receivers can quarantine or reject | protocols SPF and DKIM, then receivers can quarantine or reject | |||
unauthenticated mail purporting to be from that sender. Over time, | unauthenticated mail purporting to be from that sender. Over time, | |||
one-on-one relationships were established between select senders and | one-on-one relationships were established between select senders and | |||
receivers with privately communicated means to assert policy and | receivers with privately communicated means to assert policy and | |||
receive message traffic and authentication disposition reporting. | receive message traffic and authentication disposition reporting. | |||
Although these ad hoc practices have been generally successful, they | Although these ad hoc practices have been generally successful, they | |||
require significant manual coordination between parties. | require significant manual coordination between parties. | |||
This memo defines Domain-based Message Authentication, Reporting and | This memo defines Domain-based Message Authentication, Reporting and | |||
Compliance (DMARC), a mechanism by which email operators leverage | Compliance (DMARC), a mechanism by which email operators leverage | |||
existing authentication and policy advertisement technologies to | existing authentication and policy advertisement technologies to | |||
enable both message-stream feedback and enforcement of policies | enable both message-stream feedback and enforcement of policies | |||
against unauthenticated email. | against unauthenticated email. | |||
DMARC encourages senders and receivers to collaborate by monitoring | DMARC encourages senders and receivers to collaborate by monitoring | |||
skipping to change at page 10, line 24 | skipping to change at page 11, line 26 | |||
3.4. Detailed Requirements | 3.4. Detailed Requirements | |||
DMARC's specification requirements, in detail: | DMARC's specification requirements, in detail: | |||
1. The RFC5322.From domain is the identifier used for all message | 1. The RFC5322.From domain is the identifier used for all message | |||
validation operations, as it is the single identifier in the | validation operations, as it is the single identifier in the | |||
message likely to be visible to the user. | message likely to be visible to the user. | |||
2. Senders can specify a "strict" or "relaxed" mode in terms of | 2. Senders can specify a "strict" or "relaxed" mode in terms of | |||
enforcing identifier checks (see Section 4.2). In "strict" | enforcing identifier checks (see Section 4.3). In "strict" | |||
mode, all identifiers from authentication systems upon which | mode, all identifiers from authentication systems upon which | |||
DMARC is predicated must match the RFC5322.From domain. In | DMARC is predicated must match the RFC5322.From domain. In | |||
"relaxed" mode, the organizational domains (see Section 4) must | "relaxed" mode, the organizational domains (see Section 4) must | |||
match. The "relaxed" mode shall be the default. | match. The "relaxed" mode shall be the default. | |||
3. A sender's policy must be discoverable via DNS queries. | 3. A sender's policy must be discoverable via DNS queries. | |||
4. It must be possible to specify reject or quarantine policies | 4. It must be possible to specify reject or quarantine policies | |||
when none of the underlying authentication systems succeed. | when none of the underlying authentication systems succeed. | |||
skipping to change at page 10, line 50 | skipping to change at page 12, line 5 | |||
the organizational domain itself. | the organizational domain itself. | |||
7. Message disposition requests via DMARC override those requested | 7. Message disposition requests via DMARC override those requested | |||
by any other public mechanism. | by any other public mechanism. | |||
8. Senders should be able to specify a percentage of their messages | 8. Senders should be able to specify a percentage of their messages | |||
to which their policies should be applied, with the rest | to which their policies should be applied, with the rest | |||
unaffected, in order to experiment and to understand and | unaffected, in order to experiment and to understand and | |||
minimize deployment risk. | minimize deployment risk. | |||
9. Receivers should endeavour to reject or quarantine email if the | 9. Reporting configuration in DMARC should override any such | |||
RFC5322.From purports to be from a domain that appears to be | ||||
either non-existent or incapable of receiving mail. | ||||
10. Reporting configuration in DMARC should override any such | ||||
options specified by DKIM or SPF or extensions to them. | options specified by DKIM or SPF or extensions to them. | |||
11. The sender must be able to to specify independent reporting | 10. The sender must be able to to specify independent reporting | |||
addresses for failed message reporting and aggregate data feeds. | addresses for failed message reporting and aggregate data feeds. | |||
12. The aggregate report must contain enough information for the | 11. The aggregate report must contain enough information for the | |||
report consumer to re-calculate DMARC disposition based on the | report consumer to re-calculate DMARC disposition based on the | |||
published policy, message dispositon, and SPF, DKIM, and | published policy, message dispositon, and SPF, DKIM, and | |||
identifier alignment results. | identifier alignment results. | |||
13. The aggregate report must still contain data for each sender | 12. The aggregate report must still contain data for each sender | |||
subdomain separately from mail from the sender's organizational | subdomain separately from mail from the sender's organizational | |||
domain, even if no subdomain policy is applied. The report must | domain, even if no subdomain policy is applied. The report must | |||
indicate any policy applied to subdomains. | indicate any policy applied to subdomains. | |||
14. It must be possible to specify a minimum reporting interval. | 13. It must be possible to specify a minimum reporting interval. | |||
Reporting sites should make a best effort to accommodate that | Reporting sites should make a best effort to accommodate that | |||
request. | request. | |||
15. The sender can specify a time-to-live for policy records. | 14. The sender can specify a time-to-live for policy records. | |||
16. The sender can indicate which domains under its control never | 15. The sender can indicate which domains under its control never | |||
send email, either by omitting them from the DNS entirely or by | send email, either by omitting them from the DNS entirely or by | |||
declaring specific use of DKIM and SPF that no email will ever | declaring specific use of DKIM and SPF that no email will ever | |||
fulfill. | fulfill. | |||
17. The sending and receiving domains should be included in the | 16. The sending and receiving domains should be included in the | |||
aggregate report. | aggregate report. | |||
18. The policy request and the one applied (if different) should be | 17. The policy request and the one applied (if different) should be | |||
included in the aggregate report. | included in the aggregate report. | |||
19. The number of successful authentications should be included in | 18. The number of successful authentications should be included in | |||
the aggregate report. | the aggregate report. | |||
20. The report should be generated based on all messages even if | 19. The report should be generated based on all messages even if | |||
filtering agents such as anti-virus or anti-spam engines | filtering agents such as anti-virus or anti-spam engines | |||
ultimately block delivery. | ultimately block delivery. | |||
21. For real-time reporting of failed messages, including a [URI] to | 20. For real-time reporting of failed messages, including a [URI] to | |||
identify phishing sites and diagnostics on DKIM and SPF failures | identify phishing sites and diagnostics on DKIM and SPF failures | |||
will be recommended. | will be recommended. | |||
22. Static conformance requirements shall be documented to enable | 21. Static conformance requirements shall be documented to enable | |||
testing programs to help ensure consitency of results. (This | testing programs to help ensure consistency of results. (This | |||
will be done in a separate Best Current Practices document.) | will be done in a separate Best Current Practices document.) | |||
23. Aggregate reports should communicate DMARC message disposition | 22. Aggregate reports should communicate DMARC message disposition | |||
regardless of any subsequent action that affects message | regardless of any subsequent action that affects message | |||
disposition or delivery. | disposition or delivery. | |||
24. The mechanism overall should be flexible enough to swap in or | 23. The mechanism overall should be flexible enough to swap in or | |||
out any authentication technology. | out any authentication technology. | |||
Tags throughout the specification part of this document indicate | Tags throughout the specification part of this document indicate | |||
conformance to the above requirements. For example "{R1}" indicates | conformance to the above requirements. For example "{R1}" indicates | |||
a component of the protocol that addresses requirement #1 in the list | a component of the protocol that addresses requirement #1 in the list | |||
above. | above. | |||
3.5. Out Of Scope | 3.5. Out Of Scope | |||
Items specifically not in scope for this work include: | Items specifically not in scope for this work include: | |||
skipping to change at page 13, line 37 | skipping to change at page 14, line 37 | |||
to some third party. This memo does not address the distinctions | to some third party. This memo does not address the distinctions | |||
among such roles; the reader is encouraged to become familiar with | among such roles; the reader is encouraged to become familiar with | |||
that material before continuing. | that material before continuing. | |||
The following terms are also used: | The following terms are also used: | |||
Authenticated Identifiers: Authentication technologies allow | Authenticated Identifiers: Authentication technologies allow | |||
evaluation agents to associate email with domain-level | evaluation agents to associate email with domain-level | |||
identifiers. Domain-level identifiers that are established using | identifiers. Domain-level identifiers that are established using | |||
authentication technologies are referred to as "Authenticated | authentication technologies are referred to as "Authenticated | |||
Identifiers". The following Authenticated Identifiers are | Identifiers". See Section 4.1 for details about the supported | |||
considered in this document: | mechanisms. | |||
* [DKIM] provides a domain-level identifier in the content of the | ||||
"d=" tag of a validated signature. | ||||
* [SPF] can authenticate the domain found in an [SMTP] MAIL | ||||
command. | ||||
Cousin Domain: A DNS domain that, when rendered by a Mail User Agent | Cousin Domain: A DNS domain that, when rendered by a Mail User Agent | |||
(MUA), looks similar to, or can lead users to believe the domain | (MUA), looks similar to, or can lead users to believe the domain | |||
is associated with, another name. For instance, "vendor5.example" | is associated with, another name. For instance, "vendor5.example" | |||
would be a Cousin Domain of "vendors.example". This is a common | would be a Cousin Domain of "vendors.example". This is a common | |||
tool in a homograph attack. | tool in a homograph attack. | |||
Domain Owner: The entity or organization that "owns" a DNS domain. | Domain Owner: The entity or organization that "owns" a DNS domain. | |||
The term "owns" here indicates that the entity or organization | The term "owns" here indicates that the entity or organization | |||
being referenced holds the registration of that DNS domain. | being referenced holds the registration of that DNS domain. | |||
skipping to change at page 15, line 9 | skipping to change at page 16, line 8 | |||
label from the subject domain. This new name is the | label from the subject domain. This new name is the | |||
Organizational Domain. | Organizational Domain. | |||
Thus, since "com" is an IANA-registered TLD, a subject domain of | Thus, since "com" is an IANA-registered TLD, a subject domain of | |||
"a.b.c.d.example.com" would have an Organizational Domain of | "a.b.c.d.example.com" would have an Organizational Domain of | |||
"example.com". | "example.com". | |||
The process of determining a suffix is currently a heuristic one. | The process of determining a suffix is currently a heuristic one. | |||
No list is guaranteed to be accurate or current. | No list is guaranteed to be accurate or current. | |||
4.1. Summary | 4.1. Authentication Mechanisms | |||
The following Authenticated Identifiers are supported in the current | ||||
version of DMARC: | ||||
o [DKIM], which provides a domain-level identifier in the content of | ||||
the "d=" tag of a validated signature. | ||||
o [SPF], which can authenticate the domain found in an [SMTP] MAIL | ||||
command. | ||||
4.2. Summary | ||||
DMARC's filtering component is based on whether or not SPF or DKIM | DMARC's filtering component is based on whether or not SPF or DKIM | |||
can provide an authenticated -- and relevant -- identifier for any | can provide an authenticated -- and relevant -- identifier for any | |||
given message. Messages that purport to be from a Domain Owner's | given message. Messages that purport to be from a Domain Owner's | |||
domain and arrive from servers that are not authorized by SPF and do | domain and arrive from servers that are not authorized by SPF and do | |||
not contain an appropriate DKIM signature can be affected by DMARC | not contain an appropriate DKIM signature can be affected by DMARC | |||
policies. | policies. | |||
DMARC's feedback component involves the collection of information | DMARC's feedback component involves the collection of information | |||
pertaining to received messages, in the aggregate, for periodic | pertaining to received messages, in the aggregate, for periodic | |||
reporting back to the Domain Owner. The parameters and format for | reporting back to the Domain Owner. The parameters and format for | |||
such reports are discussed in later sections of this document. | such reports are discussed in later sections of this document. | |||
A DMARC-enabled Mail Receiver might also generate per-message reports | A DMARC-enabled Mail Receiver might also generate per-message reports | |||
that contain information related to individual messages which fail | that contain information related to individual messages which fail | |||
SPF and/or DKIM. Per-message reports are useful for forensic use in | SPF and/or DKIM. Per-message failure reports are useful for forensic | |||
debugging deployments (if messages can be determined to be legitimate | use in debugging deployments (if messages can be determined to be | |||
albeit failing authentication) or in analyzing attacks. The | legitimate albeit failing authentication) or in analyzing attacks. | |||
capability for such services is enabled by DMARC but defined in other | The capability for such services is enabled by DMARC but defined in | |||
referenced material. | other referenced material. | |||
It is important to note that the authentication mechanisms employed | It is important to note that the authentication mechanisms employed | |||
by DMARC authenticate only a DNS domain, and do not authenticate the | by DMARC authenticate only a DNS domain, and do not authenticate the | |||
local-part of any email address identifier found in a message. | local-part of any email address identifier found in a message. | |||
4.2. Identifier Alignment | 4.3. Identifier Alignment | |||
Email authentication technologies authenticate various (and | Email authentication technologies authenticate various (and | |||
disparate) aspects of an individual message. For example, [DKIM] | disparate) aspects of an individual message. For example, [DKIM] | |||
authenticates the domain that affixed a signature to the message, | authenticates the domain that affixed a signature to the message, | |||
while [SPF] authenticates the domain that appears in the | while [SPF] authenticates either the domain that appears in the | |||
RFC5321.MailFrom portion of [SMTP]. The DMARC mechanism introduces | RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if | |||
the concept of Identifier Alignment to address the possible | the RFC5321.MailFrom is null (in the case of Delivery Status | |||
discrepancy of Authenticated Identifiers supplied by underlying | Notifications). The DMARC mechanism introduces the concept of | |||
authentication technologies. | Identifier Alignment to address the possible discrepancy of | |||
Authenticated Identifiers supplied by underlying authentication | ||||
technologies. | ||||
DMARC uses the RFC5322.From domain to tie together Authenticated | DMARC uses the RFC5322.From domain to tie together Authenticated | |||
Identifiers {R1}. The selection of the RFC5322.From domain as the | Identifiers {R1}. The selection of the RFC5322.From domain as the | |||
central identity of the DMARC mechanism is due to the ubiquity of | central identity of the DMARC mechanism is due to the ubiquity of | |||
this identity and the behavior of most MUAs to represent the | this identity and the behavior of most MUAs to represent the | |||
RFC5322.From field as the originator of the message and to render | RFC5322.From field as the originator of the message and to render | |||
some or all of this header's content to end users. | some or all of this header's content to end users. | |||
To be considered "in alignment" for the purposes of the DMARC | To be considered "in alignment" for the purposes of the DMARC | |||
mechanism, implementors MUST observe the considerations described in | mechanism, implementors MUST observe the considerations described in | |||
the following sections. Domain names in this context are to be | the following sections. Domain names in this context are to be | |||
compared in a case-insensitive manner, per [DNS-CASE]. | compared in a case-insensitive manner, per [DNS-CASE]. | |||
4.2.1. DKIM-authenticated Identifiers | It is important to note that identity alignment cannot occur with a | |||
message that is not valid per [MAIL], particularly one with a | ||||
malformed or absent RFC5322.From field. Handling of such cases is | ||||
left to the discretion of the Mail Receiver. | ||||
4.3.1. DKIM-authenticated Identifiers | ||||
DMARC provides the option of applying DKIM in a strict mode or a | DMARC provides the option of applying DKIM in a strict mode or a | |||
relaxed mode {R2}. | relaxed mode {R2}. | |||
In relaxed mode, the Organizational Domain of the [DKIM]- | In relaxed mode, the Organizational Domain of the [DKIM]- | |||
authenticated signing domain (taken from the value of the "d=" tag in | authenticated signing domain (taken from the value of the "d=" tag in | |||
the signature) and that of the RFC5322.From domain must be equal. In | the signature) and that of the RFC5322.From domain must be equal. In | |||
strict mode, only an exact match is considered to produce identifier | strict mode, only an exact match is considered to produce identifier | |||
alignment. | alignment. | |||
skipping to change at page 16, line 39 | skipping to change at page 18, line 7 | |||
suffix lists, and therefore cannot be an Organizational Domain. | suffix lists, and therefore cannot be an Organizational Domain. | |||
Identifier alignment is required to prevent abuse by phishers that | Identifier alignment is required to prevent abuse by phishers that | |||
send DKIM-signed email using an arbitrary "d=" domain (such as a | send DKIM-signed email using an arbitrary "d=" domain (such as a | |||
Cousin Domain) to pass authentication checks. | Cousin Domain) to pass authentication checks. | |||
Note that a single email can contain multiple DKIM signatures, | Note that a single email can contain multiple DKIM signatures, | |||
raising the possibility of processing multiple signatures in an | raising the possibility of processing multiple signatures in an | |||
attempt to establish an "in alignment" result. | attempt to establish an "in alignment" result. | |||
4.2.2. SPF-authenticated Identifiers | 4.3.2. SPF-authenticated Identifiers | |||
DMARC provides the option of applying SPF in a strict mode or a | DMARC provides the option of applying SPF in a strict mode or a | |||
relaxed mode {R2}. | relaxed mode {R2}. | |||
In relaxed mode, the [SPF]-authenticated RFC5321.MailFrom (commonly | In relaxed mode, the [SPF]-authenticated domain and RFC5322.From | |||
called the "envelope sender") domain and RFC5322.From domain must | domain must have the same Organizational Domain. In strict mode, | |||
have the same Organizational Domain. In strict mode, only an exact | only an exact DNS domain match is considered to produce identifier | |||
DNS domain match is considered to produce identifier alignment. | alignment. | |||
For example, if a message passes an SPF check with an | For example, if a message passes an SPF check with an | |||
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address | RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address | |||
portion of the RFC5322.From field contains "payments@example.com", | portion of the RFC5322.From field contains "payments@example.com", | |||
the Authenticated RFC5321.MailFrom domain identifier and the | the Authenticated RFC5321.MailFrom domain identifier and the | |||
RFC5322.From domain are considered to be "in alignment" in relaxed | RFC5322.From domain are considered to be "in alignment" in relaxed | |||
mode, but not in strict mode. | mode, but not in strict mode. | |||
4.2.3. Alignment and Extension Technologies | 4.3.3. Alignment and Extension Technologies | |||
If DMARC is extended to include the use of other authentication | If DMARC is extended to include the use of other authentication | |||
mechanisms, the extensions will need to allow for domain identifier | mechanisms, the extensions will need to allow for domain identifier | |||
extraction so that alignment against the RFC5322.From domain can be | extraction so that alignment with the RFC5322.From domain can be | |||
verified. | verified. | |||
5. Policy | 5. Policy | |||
DMARC policies are published by Domain Owners and applied by Mail | DMARC policies are published by Domain Owners and applied by Mail | |||
Receivers. | Receivers. | |||
A Domain Owner advertises DMARC participation by adding a DNS TXT | A Domain Owner advertises DMARC participation by adding a DNS TXT | |||
record (described in Section 6) {R3, R15, R16} to one or more sending | record (described in Section 6) {R3, R15, R16} to one or more sending | |||
domains under its direct or indirect control (e.g. operated by a | domains under its direct or indirect control (e.g. operated by a | |||
skipping to change at page 18, line 16 | skipping to change at page 19, line 29 | |||
Domain Owner DMARC preferences are stored as DNS TXT records in | Domain Owner DMARC preferences are stored as DNS TXT records in | |||
subdomains named "_dmarc". For example, the Domain Owner of | subdomains named "_dmarc". For example, the Domain Owner of | |||
"example.com" would post DMARC preferences in a TXT record at | "example.com" would post DMARC preferences in a TXT record at | |||
"_dmarc.example.com". Similarly, a Mail Receiver wishing to query | "_dmarc.example.com". Similarly, a Mail Receiver wishing to query | |||
for DMARC preferences regarding mail with an RFC5322.From domain of | for DMARC preferences regarding mail with an RFC5322.From domain of | |||
"example.com" would issue a TXT query to the DNS for the subdomain of | "example.com" would issue a TXT query to the DNS for the subdomain of | |||
"_dmarc.example.com". The DNS-located DMARC preference data will | "_dmarc.example.com". The DNS-located DMARC preference data will | |||
hereafter be called the "DMARC record". | hereafter be called the "DMARC record". | |||
DMARC records are stored in the DNS for three key engineering | DMARC records are stored in the DNS for two key engineering reasons: | |||
reasons: | ||||
Wildcarding: DNS natively supports wildcarding, enabling child | ||||
domains to inherit parent domain policy easily. | ||||
Overrides: DMARC records published at child domains explicitly | Overrides: DMARC records published at child domains explicitly | |||
override extant parent policy. | override extant parent policy. | |||
Efficiency: DNS caching is a common practice, reducing operational | Efficiency: DNS caching is a common practice, reducing operational | |||
overhead of a new DNS-based mechanism. | overhead of a new DNS-based mechanism. | |||
Per [DNS], a TXT record can comprise several "character-string" | Per [DNS], a TXT record can comprise several "character-string" | |||
objects. Where this is the case, the module performing DMARC | objects. Where this is the case, the module performing DMARC | |||
evaluation MUST concatenate these strings by joining together the | evaluation MUST concatenate these strings by joining together the | |||
objects in order and parsing the result as a single string. | objects in order and parsing the result as a single string. | |||
6.1. DMARC URIs | 6.1. DMARC URIs | |||
[URI] defines a generic syntax for identifying a resource. The DMARC | [URI] defines a generic syntax for identifying a resource. The DMARC | |||
mechanism uses this as the format by which a Domain Owner specifies | mechanism uses this as the format by which a Domain Owner specifies | |||
the destination for either of the two report types that are | the destination for the two report types that are supported. | |||
supported. | ||||
The place such URIs are specified (see Section 6.2) allows a list of | The place such URIs are specified (see Section 6.2) allows a list of | |||
these to be provided, to be tried in order until one of them | these to be provided. A report is to be sent to each listed URI. | |||
successfully receives the report. The list of URIs is separated by | Mail Receivers MAY impose a limit on the number of URIs that receive | |||
commas (ASCII 0x2C). | reports, but MUST support at least two. The list of URIs is | |||
separated by commas (ASCII 0x2C). | ||||
Each URI can have associated with it a maximum report size that may | Each URI can have associated with it a maximum report size that may | |||
be sent to it. This is accomplished by appending an exclamation | be sent to it. This is accomplished by appending an exclamation | |||
point (ASCII 0x21), followed by a maximum size indication, before a | point (ASCII 0x21), followed by a maximum size indication, before a | |||
separating comma or terminating semi-colon. | separating comma or terminating semi-colon. | |||
Thus, a DMARC URI is a URI within which any commas or exclamation | Thus, a DMARC URI is a URI within which any commas or exclamation | |||
points are percent-encoded per [URI], followed by an OPTIONAL | points are percent-encoded per [URI], followed by an OPTIONAL | |||
exclamation point and a maximum size specification, and, if there are | exclamation point and a maximum size specification, and, if there are | |||
additional reporting URIs in the list, a comma and the next URI. | additional reporting URIs in the list, a comma and the next URI. | |||
skipping to change at page 19, line 30 | skipping to change at page 20, line 41 | |||
processed; unknown tags MUST be ignored. To avoid version | processed; unknown tags MUST be ignored. To avoid version | |||
compatibility issues, tags added to the DMARC specification SHOULD | compatibility issues, tags added to the DMARC specification SHOULD | |||
NOT change the semantics of existing records when processed by | NOT change the semantics of existing records when processed by | |||
implementations conforming to prior specifications. | implementations conforming to prior specifications. | |||
The following tags are introduced as the initial valid DMARC tags: | The following tags are introduced as the initial valid DMARC tags: | |||
adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or | adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or | |||
not strict DKIM identifier alignment is required by the Domain | not strict DKIM identifier alignment is required by the Domain | |||
Owner. If and only if the value of the string is "s", strict mode | Owner. If and only if the value of the string is "s", strict mode | |||
is in use. See Section 4.2.1 for details. | is in use. See Section 4.3.1 for details. | |||
aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether or | aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether or | |||
not strict SPF identifier alignment is required by the Domain | not strict SPF identifier alignment is required by the Domain | |||
Owner. If and only if the value of the string is "s", strict mode | Owner. If and only if the value of the string is "s", strict mode | |||
is in use. See Section 4.2.2 for details. | is in use. See Section 4.3.2 for details. | |||
p: Requested Mail Receiver policy (plain-text; REQUIRED). Indicates | fo: Failure reporting options (plain-text; OPTIONAL, default "0")) | |||
the policy to be enacted by the Receiver at the request of the | Provides requested options for generation of failure reports. | |||
Domain Owner. Policy applies to the domain queried and to sub- | Report generators MAY choose to adhere to the requested options. | |||
domains unless sub-domain policy is explicitly described using the | This tag's content MUST be ignored if a "ruf" tag (below) is not | |||
"sp" tag. Possible values are as follows: | also specified. The value of this tag is a colon-separated list | |||
of characters that indicate failure reporting options as follows: | ||||
0: Generate a DMARC failure report if all underlying | ||||
authentication mechanisms failed to produce an aligned "pass" | ||||
result. | ||||
1: Generate a DMARC failure report if any underlying | ||||
authentication mechanism failed to produce an aligned "pass" | ||||
result. | ||||
d: Generate a DKIM failure report if the message had a signature | ||||
that failed evaluation, regardless of its alignment. DKIM- | ||||
specific reporting is described in [AFRF-DKIM]. | ||||
s: Generate an SPF failure report if the message failed SPF | ||||
evaluation, regardless of its alignment. SPF-specific | ||||
reporting is described in [AFRF-SPF]. | ||||
p: Requested Mail Receiver policy (plain-text; REQUIRED for policy | ||||
records). Indicates the policy to be enacted by the Receiver at | ||||
the request of the Domain Owner. Policy applies to the domain | ||||
queried and to sub-domains unless sub-domain policy is explicitly | ||||
described using the "sp" tag. This tag is mandatory for policy | ||||
records only, but not for third-party reporting records (see | ||||
Section 8.2). Possible values are as follows: | ||||
none: {R5} The Domain Owner requests no specific action be taken | none: {R5} The Domain Owner requests no specific action be taken | |||
regarding delivery of messages. | regarding delivery of messages. | |||
quarantine: {R4} The Domain Owner wishes to have email that fails | quarantine: {R4} The Domain Owner wishes to have email that fails | |||
the DMARC mechanism check to be treated by Mail Receivers as | the DMARC mechanism check to be treated by Mail Receivers as | |||
suspicious. Depending on the capabilities of the Mail | suspicious. Depending on the capabilities of the Mail | |||
Receiver, this can mean "place into spam folder", "scrutinize | Receiver, this can mean "place into spam folder", "scrutinize | |||
with additional intensity", and/or "flag as suspicious". | with additional intensity", and/or "flag as suspicious". | |||
reject: {R4} The Domain Owner wishes for Mail Receivers to reject | reject: {R4} The Domain Owner wishes for Mail Receivers to reject | |||
email that fails the DMARC mechanism check. Rejection SHOULD | email that fails the DMARC mechanism check. Rejection SHOULD | |||
occur during the SMTP transaction. See Section 15.8 for some | occur during the SMTP transaction. See Section 15.8 for some | |||
discussion of SMTP rejection methods and their implications. | discussion of SMTP rejection methods and their implications. | |||
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; | pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; | |||
default is 100). {R8} Percentage of messages from the DNS domain's | default is 100). {R8} Percentage of messages from the DNS domain's | |||
mail stream to which the DMARC mechanism is to be applied. | mail stream to which the DMARC mechanism is to be applied. | |||
However, this MUST NOT be applied to the DMARC-generated reports, | However, this MUST NOT be applied to the DMARC-generated reports, | |||
all of which must be sent and received unhindered. The purpose of | all of which must be sent and received unhindered. The purpose of | |||
the "pct" tag is to allow Domain Owners to slowly roll out | the "pct" tag is to allow Domain Owners to enact a slow rollout | |||
enforcement of the DMARC mechanism. The prospect of "all or | enforcement of the DMARC mechanism. The prospect of "all or | |||
nothing" is recognized as preventing many organizations from | nothing" is recognized as preventing many organizations from | |||
experimenting with strong authentication-based mechanisms. | experimenting with strong authentication-based mechanisms. See | |||
Section 7.1 for details. | ||||
rf: Format to be used for message-specific forensic information | rf: Format to be used for message-specific failure reports (comma- | |||
reports (comma-separated plain-text list of values; OPTIONAL; | separated plain-text list of values; OPTIONAL; default "afrf"). | |||
default "afrf"). The value of this tag is a list of one or more | The value of this tag is a list of one or more report formats as | |||
report formats as requested by the Domain Owner to be used when a | requested by the Domain Owner to be used when a message fails both | |||
message fails both [SPF] and [DKIM] tests to report details of the | [SPF] and [DKIM] tests to report details of the individual | |||
individual failure. The values MUST be present in the registry of | failure. The values MUST be present in the registry of reporting | |||
reporting formats defined in Section 14; a Mail Receiver observing | formats defined in Section 14; a Mail Receiver observing a | |||
a different value SHOULD ignore it, or MAY ignore the entire DMARC | different value SHOULD ignore it, or MAY ignore the entire DMARC | |||
record. Initial default values are "afrf" (defined in [AFRF]) and | record. Initial default values are "afrf" (defined in [AFRF]) and | |||
"iodef" (defined in [IODEF]). | "iodef" (defined in [IODEF]). See Section 8.4 for details. | |||
ri: Interval requested between aggregate reports (plain-text, 32-bit | ri: Interval requested between aggregate reports (plain-text, 32-bit | |||
unsigned integer; OPTIONAL; default 86400). {R14} Indicates a | unsigned integer; OPTIONAL; default 86400). {R14} Indicates a | |||
request to Receivers to generate aggregate reports separated by no | request to Receivers to generate aggregate reports separated by no | |||
more than the requested number of seconds. DMARC implementations | more than the requested number of seconds. DMARC implementations | |||
MUST be able to provide daily reports and SHOULD be able to | MUST be able to provide daily reports and SHOULD be able to | |||
provide hourly reports when requested. However, anything other | provide hourly reports when requested. However, anything other | |||
than a daily report is understood to be accommodated on a best- | than a daily report is understood to be accommodated on a best- | |||
effort basis. | effort basis. | |||
skipping to change at page 21, line 5 | skipping to change at page 22, line 42 | |||
list delimiter or an OPTIONAL size limit. Section 8.2 discusses | list delimiter or an OPTIONAL size limit. Section 8.2 discusses | |||
considerations that apply when the domain name of a URI differs | considerations that apply when the domain name of a URI differs | |||
from that of the domain advertising the policy. See Section 15.6 | from that of the domain advertising the policy. See Section 15.6 | |||
for additional considerations. Any valid URI can be specified. A | for additional considerations. Any valid URI can be specified. A | |||
Mail Receiver MUST implement support for a "mailto:" URI, i.e. the | Mail Receiver MUST implement support for a "mailto:" URI, i.e. the | |||
ability to send a DMARC report via electronic mail. If not | ability to send a DMARC report via electronic mail. If not | |||
provided, Mail Receivers MUST NOT generate aggregate feedback | provided, Mail Receivers MUST NOT generate aggregate feedback | |||
reports. URIs not supported by Mail Receivers MUST be ignored. | reports. URIs not supported by Mail Receivers MUST be ignored. | |||
The aggregate feedback report format is described in Section 8.3. | The aggregate feedback report format is described in Section 8.3. | |||
ruf: Addresses to which message-specific forensic information is to | ruf: Addresses to which message-specific failure information is to | |||
be reported (comma-separated plain-text list of DMARC URIs; | be reported (comma-separated plain-text list of DMARC URIs; | |||
OPTIONAL). {R11} If present, the Domain Owner is requesting Mail | OPTIONAL). {R11} If present, the Domain Owner is requesting Mail | |||
Receivers to send detailed forensic reports about messages that | Receivers to send detailed failure reports about messages that | |||
fail [SPF] and/or [DKIM] evaluation. The format of the message to | fail the DMARC evaluation in specific ways (see the "fo" tag | |||
be generated MUST follow that specified in the "rf" tag. | above). The format of the message to be generated MUST follow | |||
Section 8.2 discusses considerations that apply when the domain | that specified in the "rf" tag. Section 8.2 discusses | |||
name of a URI differs from that of the domain advertising the | considerations that apply when the domain name of a URI differs | |||
policy. A Mail Receiver MUST implement support for a "mailto:" | from that of the domain advertising the policy. A Mail Receiver | |||
URI, i.e. the ability to send a DMARC report via electronic mail. | MUST implement support for a "mailto:" URI, i.e. the ability to | |||
If not provided, Mail Receivers MUST NOT generate forensic | send a DMARC report via electronic mail. If not provided, Mail | |||
reports. See Section 15.6 for additional considerations. | Receivers MUST NOT generate failure reports. See Section 15.6 for | |||
additional considerations. | ||||
sp: {R6} Requested Mail Receiver policy for subdomains (plain-text; | sp: {R6} Requested Mail Receiver policy for subdomains (plain-text; | |||
OPTIONAL). Indicates the policy to be enacted by the Receiver at | OPTIONAL). Indicates the policy to be enacted by the Receiver at | |||
the request of the Domain Owner. It applies only to subdomains of | the request of the Domain Owner. It applies only to subdomains of | |||
the domain queried and not to the domain itself. Its syntax is | the domain queried and not to the domain itself. Its syntax is | |||
identical to that of the "p" tag defined above. If absent, the | identical to that of the "p" tag defined above. If absent, the | |||
policy specified by the "p" tag MUST be applied for subdomains. | policy specified by the "p" tag MUST be applied for subdomains. | |||
v: Version (plain-text; REQUIRED). Identifies the record retrieved | v: Version (plain-text; REQUIRED). Identifies the record retrieved | |||
as a DMARC record. It MUST have the value of "DMARC1". The value | as a DMARC record. It MUST have the value of "DMARC1". The value | |||
of this tag MUST match precisely; if it does not or it is absent, | of this tag MUST match precisely; if it does not or it is absent, | |||
the entire retrieved record MUST be ignored. It MUST be the first | the entire retrieved record MUST be ignored. It MUST be the first | |||
tag in the list. | tag in the list. | |||
Note that addition of a new tag into the registered list of tags does | A DMARC policy record MUST comply with the formal specification found | |||
not itself require a new version of DMARC to be generated (with a | in Section 6.3 in that the "v" and "p" tags MUST be present and MUST | |||
corresponding change to the "v" tag's value), but a change to any | appear in that order. Unknown tags MUST be ignored. Syntax errors | |||
existing tags does require a new version of DMARC. | in the remainder of the record SHOULD be discarded in favour of | |||
default values (if any) or ignored outright. | ||||
Note that given the rules of the previous paragraph, addition of a | ||||
new tag into the registered list of tags does not itself require a | ||||
new version of DMARC to be generated (with a corresponding change to | ||||
the "v" tag's value), but a change to any existing tags does require | ||||
a new version of DMARC. | ||||
6.3. Formal Definition | 6.3. Formal Definition | |||
The formal definition of the DMARC format using [ABNF] is as follows: | The formal definition of the DMARC format using [ABNF] is as follows: | |||
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] | dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] | |||
; "URI" is imported from [URI]; commas (ASCII 0x2c) | ; "URI" is imported from [URI]; commas (ASCII 0x2c) | |||
; and exclamation points (ASCII 0x21) MUST be encoded | ; and exclamation points (ASCII 0x21) MUST be encoded | |||
dmarc-record = dmarc-version dmarc-sep | dmarc-record = dmarc-version dmarc-sep | |||
dmarc-request | [dmarc-request] | |||
[dmarc-sep dmarc-srequest] | [dmarc-sep dmarc-srequest] | |||
[dmarc-sep dmarc-auri] | [dmarc-sep dmarc-auri] | |||
[dmarc-sep dmarc-furi] | [dmarc-sep dmarc-furi] | |||
[dmarc-sep dmarc-adkim] | [dmarc-sep dmarc-adkim] | |||
[dmarc-sep dmarc-aspf] | [dmarc-sep dmarc-aspf] | |||
[dmarc-sep dmarc-ainterval] | [dmarc-sep dmarc-ainterval] | |||
[dmarc-sep dmarc-rfmt] | [dmarc-sep dmarc-rfmt] | |||
[dmarc-sep dmarc-percent] | [dmarc-sep dmarc-percent] | |||
[dmarc-sep] | ||||
; components other than dmarc-version and | ; components other than dmarc-version and | |||
; dmarc-request may appear in any order | ; dmarc-request may appear in any order | |||
dmarc-sep = *WSP %3b *WSP | dmarc-version = "v" *WSP "=DMARC1" | |||
dmarc-version = %x76 *WSP "=" %x44.4d.41.52.43 | dmarc-sep = *WSP %3b *WSP | |||
dmarc-request = %x70 *WSP "=" *WSP ( "none" / | dmarc-request = "p" *WSP "=" *WSP ( "none" / | |||
"quarantine" / "reject" ) | "quarantine" / "reject" ) | |||
dmarc-srequest = %x73.70 *WSP "=" *WSP ( "none" / | dmarc-srequest = "sp" *WSP "=" *WSP ( "none" / | |||
"quarantine" / "reject" ) | "quarantine" / "reject" ) | |||
dmarc-auri = %x72.75.61 *WSP "=" *WSP | dmarc-auri = "rua" *WSP "=" *WSP | |||
dmarc-uri *(*WSP "," *WSP dmarc-uri) | dmarc-uri *(*WSP "," *WSP dmarc-uri) | |||
dmarc-ainterval = %x72.69 *WSP "=" *WSP | dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT | |||
dmarc-furi = %x72.75.66 *WSP "=" *WSP | dmarc-furi = "ruf" *WSP "=" *WSP | |||
dmarc-uri *(*WSP "," *WSP dmarc-uri) | dmarc-uri *(*WSP "," *WSP dmarc-uri) | |||
dmarc-rfmt = %x72.66 *WSP "=" *WSP | dmarc-rfmt = "rf" *WSP "=" *WSP | |||
( "afrf" / "iodef" ) | ( "afrf" / "iodef" ) | |||
dmarc-percent = %x70.63.74 *WSP "=" *WSP | dmarc-percent = "pct" *WSP "=" *WSP | |||
1*3DIGIT | 1*3DIGIT | |||
dmarc-adkim = %x61.64.6b.69.6d *WSP "=" *WSP | dmarc-adkim = "adkim" *WSP "=" *WSP | |||
( "r" / "s" ) | ( "r" / "s" ) | |||
dmarc-aspf = %x61.73.70.66 *WSP "=" *WSP | dmarc-aspf = "aspf" *WSP "=" *WSP | |||
( "r" / "s" ) | ( "r" / "s" ) | |||
A size limitation in a dmarc-uri, if provided, is interpreted as a | A size limitation in a dmarc-uri, if provided, is interpreted as a | |||
count of units followed by an OPTIONAL unit size ("k" for kilobytes, | count of units followed by an OPTIONAL unit size ("k" for kilobytes, | |||
"m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a | "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a | |||
unit, the number is presumed to be a basic byte count. | unit, the number is presumed to be a basic byte count. Note that the | |||
units are considered to be powers of two; a kilobyte is 2^10, a | ||||
megabyte is 2^20, etc. | ||||
Tag and value matching is case-insensitive. | ||||
7. Policy Enforcement Considerations | 7. Policy Enforcement Considerations | |||
Mail Receivers MAY choose to reject or quarantine email even if email | Mail Receivers MAY choose to reject or quarantine email even if email | |||
passes the DMARC mechanism check. The DMARC mechanism does not | passes the DMARC mechanism check. The DMARC mechanism does not | |||
inform Mail Receivers whether an email stream is "good". Mail | inform Mail Receivers whether an email stream is "good". Mail | |||
Receivers are encouraged to maintain anti-abuse technologies to | Receivers are encouraged to maintain anti-abuse technologies to | |||
combat the possibility of DMARC-enabled criminal campaigns. | combat the possibility of DMARC-enabled criminal campaigns. | |||
Mail Receivers MAY choose to accept email that fails the DMARC | Mail Receivers MAY choose to accept email that fails the DMARC | |||
mechanism check even if the Domain Owner has published a "reject" | mechanism check even if the Domain Owner has published a "reject" | |||
policy. Mail Receivers SHOULD make a best effort not to increase the | policy. Mail Receivers need to make a best effort not to increase | |||
likelihood of phishing if it chooses not to reject, against policy. | the likelihood of phishing if it chooses not to reject, against | |||
policy. At a minimum, addition of the Authentication-Results header | ||||
field (see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing | ||||
mail is done. When this is done, the DNS domain name thus recorded | ||||
MUST be encoded as an A-label, as described in Section 2.3 of [IDNA]. | ||||
Mail Receivers are not obligated to report reject or quarantine | Mail Receivers are not obligated to report reject or quarantine | |||
policy actions in aggregate feedback reports that are not due to | policy actions in aggregate feedback reports that are not due to | |||
DMARC policy, but are instead the result of local policy. If local | DMARC policy, but are instead the result of local policy. If local | |||
policy information is exposed, abusers can gain insight into the | policy information is exposed, abusers can gain insight into the | |||
effectiveness and delivery rates of spam campaigns. | effectiveness and delivery rates of spam campaigns. | |||
DMARC-compliant Mail Receivers MUST disregard any mail directive | DMARC-compliant Mail Receivers SHOULD disregard any mail directive | |||
discovered as part of an authentication mechanism (e.g., ADSP, SPF) | discovered as part of an authentication mechanism (e.g., ADSP, SPF) | |||
where a DMARC policy is also discovered. {R7} Mail Receivers SHOULD | where a DMARC policy is also discovered that specifies a policy other | |||
also implement reporting instructions of DMARC in place of any | than "none". {R7} To enable Domain Owners to receive DMARC feedback | |||
extensions to SPF or DKIM that might enable such reporting. {R10} | without impacting existing mail processing, discovered policies of | |||
"p=none" SHOULD NOT modify existing mail disposition processing. | ||||
Note that some Mail Receivers may reject email based upon SPF policy | ||||
mechanisms before email enters DMARC-specific processing. | ||||
Mail Receivers SHOULD also implement reporting instructions of DMARC | ||||
in place of any extensions to SPF or DKIM that might enable such | ||||
reporting. {R10} | ||||
7.1. Policy Fallback Mechanism | ||||
If the "pct" tag is present in a policy record, application of policy | ||||
is done on a selective basis. The stated percentage of messages that | ||||
fail the DMARC test MUST be subjected to whatever policy is selected | ||||
by the "p" or "sp" tag (if present). Those that are not thus | ||||
selected MUST instead be subjected to the next policy lower in terms | ||||
of severity. In decreasing order of severity, the policies are | ||||
"reject", "quarantine", and "none". | ||||
For example, in the presence of "pct=50" in the DMARC policy record | ||||
for "example.com", half of the mesages with "example.com" in the | ||||
RFC5322.From field which fail the DMARC test would be subjected to | ||||
"reject" action, and the remainder subjected to "quarantine" action. | ||||
8. DMARC Feedback | 8. DMARC Feedback | |||
The DMARC mechanism requires highly accurate authentication | The DMARC mechanism requires highly accurate authentication | |||
deployments to allow Mail Receivers to safely and scalably enforce | deployments to allow Mail Receivers to safely and scalably enforce | |||
Domain Owner policies. Providing Domain Owners with visibility into | Domain Owner policies. Providing Domain Owners with visibility into | |||
how Mail Receivers implement and enforce the DMARC mechanism in the | how Mail Receivers implement and enforce the DMARC mechanism in the | |||
form of feedback is critical to establishing and maintaining accurate | form of feedback is critical to establishing and maintaining accurate | |||
authentication deployments. | authentication deployments. | |||
skipping to change at page 24, line 29 | skipping to change at page 27, line 13 | |||
When a Mail Receiver discovers a DMARC policy in the DNS, and the | When a Mail Receiver discovers a DMARC policy in the DNS, and the | |||
domain at which that record was discovered is not identical to the | domain at which that record was discovered is not identical to the | |||
host part of the authority component of a [URI] specified in the | host part of the authority component of a [URI] specified in the | |||
"rua" or "ruf" tag, the following verification steps SHOULD be taken: | "rua" or "ruf" tag, the following verification steps SHOULD be taken: | |||
1. Extract the host portion of the authority component of the URI. | 1. Extract the host portion of the authority component of the URI. | |||
Call this the "destination host". | Call this the "destination host". | |||
2. Prepend the string "_report._dmarc". | 2. Prepend the string "_report._dmarc". | |||
3. Prepend the domain name from which the policy was retrieved. | 3. Prepend the domain name from which the policy was retrieved, | |||
after conversion to an A-label if needed. | ||||
4. Query the DNS for a TXT record at the constructed name. If the | 4. Query the DNS for a TXT record at the constructed name. If the | |||
result of this request is a temporary DNS error of some kind | result of this request is a temporary DNS error of some kind | |||
(e.g., a timeout), the Mail Receiver MAY elect to temporarily | (e.g., a timeout), the Mail Receiver MAY elect to temporarily | |||
fail the delivery so the verification test can be repeated later. | fail the delivery so the verification test can be repeated later. | |||
5. If the result includes no TXT resource records or multiple TXT | 5. For each record returned, parse the result as a series of | |||
resource records, a positive determination of the external | "tag=value" pairs, i.e., the same overall format as the policy | |||
reporting relationship cannot be made; stop. | record (see Section 6.3). In particular, the "v=DMARC1" tag is | |||
mandatory and MUST appear first in the list. Discard any that do | ||||
not pass this test. | ||||
6. Parse the result, if any, as a series of "tag=value" pairs, i.e., | 6. If the result includes no TXT resource records that pass basic | |||
the same overall format as the policy record. In particular, the | parsing, a positive determination of the external reporting | |||
"v=DMARC1" tag is mandatory and MUST appear first in the list. | relationship cannot be made; stop. | |||
If at least that tag is present and the record overall is | ||||
syntactically valid per Section 6.3, then the external reporting | ||||
arrangement was authorized by the destination ADMD. | ||||
7. If a "rua" or "ruf" tag is thus discovered, replace the | 7. If at least one TXT resource record remains in the set after | |||
parsing, then the external reporting arrangement was authorized | ||||
by the destination ADMD. | ||||
8. If a "rua" or "ruf" tag is thus discovered, replace the | ||||
corresponding value extracted from the domain's DMARC policy | corresponding value extracted from the domain's DMARC policy | |||
record with the one found in this record. This permits the | record with the one found in this record. This permits the | |||
report receiver to override the report destination. However, to | report receiver to override the report destination. However, to | |||
prevent loops or indirect abuse, the overriding URI MUST use the | prevent loops or indirect abuse, the overriding URI MUST use the | |||
same destination host from the first step. | same destination host from the first step. | |||
For example, if a DMARC policy query for "blue.example.com" contained | For example, if a DMARC policy query for "blue.example.com" contained | |||
"rua=mailto:reports@red.example.net", the host extracted from the | "rua=mailto:reports@red.example.net", the host extracted from the | |||
latter ("red.example.net") does not match "blue.example.com", so this | latter ("red.example.net") does not match "blue.example.com", so this | |||
procedure is enacted. A TXT query for | procedure is enacted. A TXT query for | |||
skipping to change at page 26, line 24 | skipping to change at page 29, line 16 | |||
o The policy requested by the Domain Owner and the policy actually | o The policy requested by the Domain Owner and the policy actually | |||
applied (if different) {R18} | applied (if different) {R18} | |||
o The number of successful authentications {R19} | o The number of successful authentications {R19} | |||
o The counts of messages based on all messages received even if | o The counts of messages based on all messages received even if | |||
their delivery is ultimately blocked by other filtering agents | their delivery is ultimately blocked by other filtering agents | |||
{R20} | {R20} | |||
Note that Domain Owners or their agents may change the published | ||||
DMARC policy for a domain or subdomain at any time. From a Mail | ||||
Receiver's perspective this will occur during a reporting period and | ||||
may be noticed during that period, at the end of that period when | ||||
reports are generated, or during a subsequent reporting period, all | ||||
depending on the Mail Receiver's implementation. Under these | ||||
conditions it is possible that a Mail Receiver could do any of the | ||||
following: | ||||
o generate a single aggregate report for such a reporting period | ||||
that includes message dispositions based on the old policy, or a | ||||
mix of the two policies, even though the report only contains a | ||||
single "policy_published" element; | ||||
o generate multiple reports for the same period, one for each | ||||
published policy occurring during the reporting period; | ||||
o generate a report whose end time occurs when the updated policy | ||||
was detected, regardless of any requested report interval. | ||||
Such policy changes are expected to be infrequent for any given | ||||
domain, whereas more stringent policy monitoring requirements on the | ||||
Mail Receiver would produce a very large burden at Internet scale. | ||||
Therefore it is the responsibility of Report Consumers and Domain | ||||
Owners to be aware of this situation and allow for such mixed reports | ||||
during the propagation of the new policy to Mail Receivers. | ||||
Aggregate reports are most useful when they all cover a common time | ||||
period. By contrast, correlation of these reports from multiple | ||||
generators when they cover incongruous time periods is difficult or | ||||
impossible. Report generators SHOULD, wherever possible, adhere to | ||||
hour boundaries for the reporting period they are using. For | ||||
example, starting a per-day report at 00:00; starting per-hour | ||||
reports at 00:00, 01:00, 02:00; et cetera. Report Generators using a | ||||
24-hour report period are strongly encouraged to begin that period at | ||||
00:00 UTC, regardless of local timezone or time of report production, | ||||
in order to facilitate correlation. | ||||
8.4. Failure Reports | 8.4. Failure Reports | |||
Message-specific authentication-failure-related forensic reporting | When a Domain Owner requests failure reports for the purpose of | |||
can be used to identify problems with Domain-Owner-controlled | forensic analysis, and the Mail Receiver is willing to provide such | |||
infrastructure and to investigate the sources and causes of failing | reports, the Mail Receiver generates and sends a message using the | |||
messages. They might also be used to aid investigations into the | format described in [AFRF]. This document updates the AFRF format as | |||
sources and objectives of fraudulent messages. | described in Section 8.4.1. | |||
The destination(s) and nature of the reports are defined by the "fo" | ||||
and "ruf" tags as defined in Section 6.2. | ||||
Where multiple URIs are selected to receive failure reports the | ||||
report generator MUST make an attempt to deliver to each of them. | ||||
An obvious consideration is the denial of service attack that can be | ||||
perpetrated by an attacker who sends numerous messages purporting to | ||||
be from the intended victim Domain Owner but which fail both SPF and | ||||
DKIM; this would cause participating Mail Receivers to send failure | ||||
reports to the Domain Owner or its delegate in potentially huge | ||||
volumes. Accordingly, participating Mail Receivers are encouraged to | ||||
aggregate these reports as much as is practical, using the Incidents | ||||
field of the Abuse Reporting Format ([ARF]). Various aggregation | ||||
techniques are possible, including: | ||||
o only send a report to the first recipient of multi-recipient | ||||
messages; | ||||
o store reports for a period of time before sending them, allowing | ||||
detection, collection, and reporting of like incidents; | ||||
o apply rate limiting, such as a maximum number of reports per | ||||
minute that will be generated (and the remainder discarded). | ||||
8.4.1. Reporting Format Update | ||||
[AFRF] is updated to include the following changes: | ||||
1. Section 3.2 is updated to indicate that a DMARC failure report | ||||
includes the following ARF header fields, with the indicated | ||||
normative requirement levels: | ||||
* Identity-Alignment (REQUIRED; defined below) | ||||
* Delivery-Result (OPTIONAL) | ||||
* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the | ||||
message was signed by DKIM) | ||||
* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL | ||||
if the message was signed by DKIM) | ||||
* SPF-DNS (REQUIRED) | ||||
2. Section 3.2 is updated to define the "Identity-Alignment" field | ||||
as containing a comma-separated list of authentication mechanism | ||||
names that produced an aligned identity, or the keyword "none" if | ||||
none did. ABNF: | ||||
id-align = "Identity-Alignment:" [CFWS] | ||||
( "none" / dmarc-method | ||||
*( [CFWS] "," [CFWS] dmarc-method ) ) | ||||
[CFWS] | ||||
dmarc-method = ( "dkim" / "spf" ) | ||||
; each may appear at most once in an id-align | ||||
3. Section 3.3 is updated to add Authentication Failure Type | ||||
"dmarc", which is to be used when a failure report is generated | ||||
because some or all of the authentication mechanisms failed to | ||||
produce aligned identifiers. Note that a failure report | ||||
generator MAY also independently produce an AFRF message for any | ||||
or all of the underlying authentication methods. | ||||
8.5. Failure Reports | ||||
Message-specific authentication-failure-related reporting can be used | ||||
to identify problems with Domain-Owner-controlled infrastructure and | ||||
to investigate the sources and causes of failing messages. They | ||||
might also be used to aid investigations into the sources and | ||||
objectives of fraudulent messages. | ||||
The format for these reports is defined in either [AFRF] or [IODEF] | The format for these reports is defined in either [AFRF] or [IODEF] | |||
depending on the value found in the "rf" tag of the DMARC record (or | depending on the value found in the "ruf" tag of the DMARC record (or | |||
its default). | its default). | |||
These reports SHOULD include the "call-to-action" URI(s) from inside | These reports SHOULD include the "call-to-action" URI(s) from inside | |||
messages that failed to authenticate. {R21} | messages that failed to authenticate. {R21} | |||
9. Policy Discovery | 9. Policy Discovery | |||
As stated above, the DMARC mechanism utilizes DNS TXT records to | As stated above, the DMARC mechanism utilizes DNS TXT records to | |||
advertise policy. Policy discovery is accomplished similar to the | advertise policy. Policy discovery is accomplished similar to the | |||
way SPF records are discovered. Important differences are discussed | way SPF records are discovered. Important differences are discussed | |||
skipping to change at page 27, line 41 | skipping to change at page 32, line 48 | |||
If the set produced by the mechanism above contains no DMARC policy | If the set produced by the mechanism above contains no DMARC policy | |||
record (i.e., any indication that there is no such record as opposed | record (i.e., any indication that there is no such record as opposed | |||
to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC | to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC | |||
mechanism to the message. | mechanism to the message. | |||
If the RFC5322.From domain does not exist in the DNS, Mail Receivers | If the RFC5322.From domain does not exist in the DNS, Mail Receivers | |||
SHOULD direct the receiving SMTP server to reject the message {R9}. | SHOULD direct the receiving SMTP server to reject the message {R9}. | |||
The choice of mechanism for such rejection and the implications of | The choice of mechanism for such rejection and the implications of | |||
those choices are discussed in Section 11 and Section 15.8. | those choices are discussed in Section 11 and Section 15.8. | |||
Handling of DNS errors when querying for the DMARC policy record is | ||||
left to the discretion of the Mail Receiver. For example, to ensure | ||||
minimal disruption of mail flow, transient errors could result in | ||||
delivery of the message ("fail open"), or they could result in the | ||||
message being temporarily rejected (i.e., an SMTP 4yx reply) which | ||||
invites the sending MTA to try again after the condition has possibly | ||||
cleared, allowing a definite DMARC conclusion to be reached ("fail | ||||
closed"). | ||||
10. Domain Owner Actions | 10. Domain Owner Actions | |||
To implement the DMARC mechanism, Domain Owners perform the actions | To implement the DMARC mechanism, Domain Owners perform the actions | |||
enumerated in this section. For a trial operation, a Domain Owner | enumerated in this section. For a trial operation, a Domain Owner | |||
might at first deploy DMARC to cover only a subdomain. | might at first deploy DMARC to cover only a subdomain. | |||
1. Deploy authentication technologies [DKIM] (see also | 1. Deploy authentication technologies [DKIM] (see also | |||
[DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF]. | [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF]. | |||
2. Align identifiers; i.e., audit internal systems so that mail | 2. Align identifiers; i.e., audit internal systems so that mail | |||
skipping to change at page 29, line 15 | skipping to change at page 34, line 28 | |||
Therefore, Domain Owners SHOULD include "mailto" URIs at the end of | Therefore, Domain Owners SHOULD include "mailto" URIs at the end of | |||
the lists of URIs they publish. | the lists of URIs they publish. | |||
11. Mail Receiver Actions | 11. Mail Receiver Actions | |||
This section describes receiver actions in the DMARC environment. | This section describes receiver actions in the DMARC environment. | |||
11.1. Extract Author Domain | 11.1. Extract Author Domain | |||
The domain in the RFC5322.From field is extracted as the domain to be | The domain in the RFC5322.From field is extracted as the domain to be | |||
evaluated by DMARC. | evaluated by DMARC. If the domain is encoded with UTF-8, the domain | |||
name must be converted to an A-label for further processing. | ||||
A message bearing multiple RFC5322.From identifiers is ambiguous | A message bearing multiple RFC5322.From identifiers is ambiguous | |||
under DMARC. This includes messages with multiple RFC5322.From | under DMARC. This includes messages with multiple RFC5322.From | |||
fields (which is also forbidden under [MAIL]) and a message with a | fields (which is also forbidden under [MAIL]) and a message with a | |||
single RFC5322.From field containing multiple entities. Such | single RFC5322.From field containing multiple entities. There can | |||
messages SHOULD be rejected. If they are not, they MUST be ignored | also be From: fields that contain no meaningful values, such as | |||
with respect to all DMARC processing, as reliable alignment of | RFC5322's "group" syntax. Such messages SHOULD be rejected. If they | |||
verified identifiers with what the end user will actually see cannot | are not, the Mail Receiver can either ignore the message entirely | |||
be positively determined. | with respect to DMARC processing, or evaluate DMARC against all | |||
identifiers. In this latter case, it is important to consider the | ||||
set of identifiers that will ultimately be shown to end users, since | ||||
ensuring the legitimate use of those identifiers is at the heart of | ||||
DMARC's goal. This requires an understanding of the end user | ||||
environment, the specification of which is outside of the scope of | ||||
this document. | ||||
11.2. Determine Handling Policy | 11.2. Determine Handling Policy | |||
To arrive at a policy disposition for an individual message, Mail | To arrive at a policy disposition for an individual message, Mail | |||
Receivers MUST perform the following actions or their semantic | Receivers MUST perform the following actions or their semantic | |||
equivalents. The first four steps MAY be done in parallel, whereas | equivalents. The first four steps MAY be done in parallel, whereas | |||
steps 5 and 6 require input from previous steps. | steps 5 and 6 require input from previous steps. | |||
The steps are as follows: | The steps are as follows: | |||
1. Extract the RFC5322.From domain from the message. | 1. Extract the RFC5322.From domain from the message (as above). | |||
2. Query the DNS for a DMARC policy record. Continue if one is | 2. Query the DNS for a DMARC policy record. Continue if one is | |||
found, or abort DMARC evaluation otherwise. See Section 9 for | found, or abort DMARC evaluation otherwise. See Section 9 for | |||
details. | details. | |||
3. Perform DKIM signature verification checks. A single email may | 3. Perform DKIM signature verification checks. A single email may | |||
contain multiple DKIM signatures. The results of this step are | contain multiple DKIM signatures. The results of this step are | |||
passed to the remainder of the algorithm and MUST include the | passed to the remainder of the algorithm and MUST include the | |||
value of the "d=" tag from all DKIM signatures that successfully | value of the "d=" tag from all DKIM signatures that successfully | |||
validated. | validated. | |||
4. Perform SPF validation checks. The results of this step are | 4. Perform SPF validation checks. The results of this step are | |||
passed to the remainder of the algorithm and MUST include the | passed to the remainder of the algorithm and MUST include the | |||
domain name from the RFC5321.MailFrom if SPF evaluation returned | domain name used to complete the SPF check if evaluation returned | |||
a "pass" result. | a "pass" result. | |||
5. Conduct identifier alignment checks. With authentication checks | 5. Conduct identifier alignment checks. With authentication checks | |||
and policy discovery performed, the Mail Receiver checks if | and policy discovery performed, the Mail Receiver checks if | |||
Authenticated Identifiers fall into alignment as decribed in | Authenticated Identifiers fall into alignment as decribed in | |||
Section 4. If one or more of the Authenticated Identifiers align | Section 4. If one or more of the Authenticated Identifiers align | |||
with the RFC5322.From domain, the message is considered to pass | with the RFC5322.From domain, the message is considered to pass | |||
the DMARC mechanism check. All other conditions (authentication | the DMARC mechanism check. All other conditions (authentication | |||
failures, identifier mismatches) are considered to be DMARC | failures, identifier mismatches) are considered to be DMARC | |||
mechanism check failures. | mechanism check failures. | |||
skipping to change at page 30, line 24 | skipping to change at page 35, line 44 | |||
6. Apply policy. Emails that fail the DMARC mechanism check are | 6. Apply policy. Emails that fail the DMARC mechanism check are | |||
disposed of in accordance with the discovered DMARC policy of the | disposed of in accordance with the discovered DMARC policy of the | |||
Domain Owner. See Section 6.2 for details. | Domain Owner. See Section 6.2 for details. | |||
Heuristics applied in the absence of use by a Domain Owner of either | Heuristics applied in the absence of use by a Domain Owner of either | |||
SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be | SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be | |||
the case that the Domain Owner wishes a Message Receiver not to | the case that the Domain Owner wishes a Message Receiver not to | |||
consider the results of that underlying authentication protocol at | consider the results of that underlying authentication protocol at | |||
all. | all. | |||
Handling of messages for which SPF and/or DKIM evaluation encounters | ||||
a DNS error is left to the discretion of the Mail Receiver. Further | ||||
discussion is available in Section 9. | ||||
11.3. Message Sampling | 11.3. Message Sampling | |||
Attention must be paid to the possible presence of the "pct" tag in | Attention must be paid to the possible presence of the "pct" tag in | |||
the DMARC policy record. If the tag is present, the Mail Receiver | the DMARC policy record. If the tag is present, the Mail Receiver | |||
MUST NOT enact the requested policy ("p" tag or "sp" tag") on more | MUST NOT enact the requested policy ("p" tag or "sp" tag") on more | |||
than the stated percent of the totality of affected messages. | than the stated percent of the totality of affected messages. | |||
However, regardless of whether or not the "pct" tag is present, the | However, regardless of whether or not the "pct" tag is present, the | |||
Mail Receiver MUST include all relevant message data in any reports | Mail Receiver MUST include all relevant message data in any reports | |||
produced. | produced. | |||
skipping to change at page 31, line 46 | skipping to change at page 37, line 25 | |||
12.2. Transport | 12.2. Transport | |||
Where the URI specified in an "rua" tag does not specify otherwise, a | Where the URI specified in an "rua" tag does not specify otherwise, a | |||
Mail Receiver generating a feedback report SHOULD apply a secure | Mail Receiver generating a feedback report SHOULD apply a secure | |||
transport mechanism. | transport mechanism. | |||
The Mail Receiver, after preparing a report, MUST evaluate the | The Mail Receiver, after preparing a report, MUST evaluate the | |||
provided reporting URIs in the order given. Any reporting URI that | provided reporting URIs in the order given. Any reporting URI that | |||
included a size limitation exceeded by the generated report (after | included a size limitation exceeded by the generated report (after | |||
compression and after any encoding required by the particular | compression and after any encoding required by the particular | |||
transport mechanism) MUST NOT be used. | transport mechanism) MUST NOT be used. An attempt MUST be made to | |||
deliver an aggregate report to every remaining URI. | ||||
If transport is not possible because the services advertised by the | If transport is not possible because the services advertised by the | |||
published URIs are not able to accept reports (e.g., the URI refers | published URIs are not able to accept reports (e.g., the URI refers | |||
to a service that is unreachable, or all provided URIs specify size | to a service that is unreachable, or all provided URIs specify size | |||
limits exceeded by the generated record), the Mail Receiver SHOULD | limits exceeded by the generated record), the Mail Receiver SHOULD | |||
send a short report (see Section 12.2.4) indicating that a report is | send a short report (see Section 12.2.4) indicating that a report is | |||
available but could not be sent. The Mail Receiver MAY cache that | available but could not be sent. The Mail Receiver MAY cache that | |||
data and try again later, or MAY discard data that could not be sent. | data and try again later, or MAY discard data that could not be sent. | |||
12.2.1. Email | 12.2.1. Email | |||
In the case of a "mailto" URI, the Mail Receiver SHOULD communicate | In the case of a "mailto" URI, the Mail Receiver SHOULD communicate | |||
reports using the method described in [STARTTLS]. | reports using the method described in [STARTTLS]. | |||
The message generated by the Mail Receiver must be a [MIME] formatted | The message generated by the Mail Receiver must be a [MIME] formatted | |||
[MAIL] message. The aggregate report itself MUST be included in one | [MAIL] message. The aggregate report itself MUST be included in one | |||
of the parts of the message. A human-readable portion MAY be | of the parts of the message. A human-readable portion MAY be | |||
included as a MIME part (such as a text/plain part). | included as a MIME part (such as a text/plain part). | |||
The aggregate data MUST be an XML file contained within a ZIP file. | The aggregate data MUST be an XML file subjected to GZIP compression. | |||
The aggregate data MUST be present using the media type "application/ | The aggregate data MUST be present using the media type "application/ | |||
zip", and the filenames SHOULD be constructed using the following | gzip", and the filenames SHOULD be constructed using the following | |||
ABNF: | ABNF: | |||
filename = receiver "!" policy-domain "!" begin-timestamp "!" | filename = receiver "!" policy-domain "!" begin-timestamp "!" | |||
end-timestamp "." extension | end-timestamp [ "!" unique-id ] "." extension | |||
unique-id = token | ||||
; "token" is imported from [MIME] | ||||
receiver = domain | receiver = domain | |||
; imported from [MAIL] | ; imported from [MAIL] | |||
policy-domain = domain | policy-domain = domain | |||
begin-timestamp = 1*DIGIT | begin-timestamp = 1*DIGIT | |||
; seconds since 00:00:00 UTC January 1, 1970 | ; seconds since 00:00:00 UTC January 1, 1970 | |||
; indicating start of the time range contained | ; indicating start of the time range contained | |||
; in the report | ; in the report | |||
end-timestamp = 1*DIGIT | end-timestamp = 1*DIGIT | |||
; seconds since 00:00:00 UTC January 1, 1970 | ; seconds since 00:00:00 UTC January 1, 1970 | |||
; indicating end of the time range contained | ; indicating end of the time range contained | |||
; in the report | ; in the report | |||
extension = "xml" / "zip" | extension = "xml" / "gzip" | |||
For the ZIP file itself, the extension MUST be "zip"; for the XML | For the GZIP file itself, the extension MUST be "gz"; for the XML | |||
report, the extension MUST be "xml". | report, the extension MUST be "xml". | |||
"unique-id" allows an optional unique ID generated by the Mail | ||||
Receiver to distinguish among multiple reports generated | ||||
simultaneously by different sources within the same ADMD. | ||||
No specific MIME message structure is required. It is presumed that | ||||
the aggregate reporting address will be equipped to extract MIME | ||||
parts with the prescribed media type and filename and ignore the | ||||
rest. | ||||
Email streams carrying DMARC feedback data MUST conform to the DMARC | Email streams carrying DMARC feedback data MUST conform to the DMARC | |||
mechanism. That is, the message comprising the report should be | mechanism, thereby resulting in an aligned "pass" (see Section 4.3). | |||
DKIM-signed and originate from a source for which an SPF test would | This practice minimizes the risk of report consumers processing | |||
pass. This practice minimizes the risk of report consumers | fraudulent reports. | |||
processing fraudulent reports. | ||||
The RFC5322.Subject field for individual report submissions SHOULD | The RFC5322.Subject field for individual report submissions SHOULD | |||
conform to the following ABNF: | conform to the following ABNF: | |||
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" | dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" | |||
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" | %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" | |||
domain-name 1*FWS ; from RFC6376 | domain-name 1*FWS ; from RFC6376 | |||
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" | %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" | |||
1*FWS domain-name 1*FWS | 1*FWS domain-name 1*FWS | |||
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" | %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" | |||
skipping to change at page 33, line 32 | skipping to change at page 39, line 29 | |||
This transport mechanism potentially encounters a problem when | This transport mechanism potentially encounters a problem when | |||
feedback data size exceeds maximum allowable attachment sizes for | feedback data size exceeds maximum allowable attachment sizes for | |||
either the generator or the consumer. See Section 12.2.4 for further | either the generator or the consumer. See Section 12.2.4 for further | |||
discussion. | discussion. | |||
12.2.2. HTTP | 12.2.2. HTTP | |||
Where an "http" or "https" method is requested in a Domain Owner's | Where an "http" or "https" method is requested in a Domain Owner's | |||
URI list, the Mail Receiver MAY encode the data using the | URI list, the Mail Receiver MAY encode the data using the | |||
"application/zip" media type or MAY send the Appendix C data | "application/gzip" media type ([GZIP]) or MAY send the Appendix C | |||
uncompressed or unencoded. | data uncompressed or unencoded. | |||
The header portion of the POST or PUT request SHOULD contain a | The header portion of the POST or PUT request SHOULD contain a | |||
Subject field as described in Section 12.2.1. | Subject field as described in Section 12.2.1. | |||
HTTP permits the use of Content-Transfer-Encoding to upload gzip | ||||
content using the POST or PUT instruction after translating the | ||||
content to 7-bit ASCII. | ||||
12.2.3. Other Methods | 12.2.3. Other Methods | |||
Other registered URI schemes may be explicitly supported in later | Other registered URI schemes may be explicitly supported in later | |||
versions. | versions. | |||
12.2.4. Error Reports | 12.2.4. Error Reports | |||
When a Mail Receiver is unable to complete delivery of a report via | When a Mail Receiver is unable to complete delivery of a report via | |||
any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD | any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD | |||
generate an error message. An attempt MUST be made to send this | generate an error message. An attempt MUST be made to send this | |||
skipping to change at page 37, line 18 | skipping to change at page 43, line 18 | |||
| Tag Name | Defined | Status | Description | | | Tag Name | Defined | Status | Description | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| adkim | [THIS MEMO] | current | DKIM alignment mode | | | adkim | [THIS MEMO] | current | DKIM alignment mode | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| aspf | [THIS MEMO] | current | SPF alignment mode | | | aspf | [THIS MEMO] | current | SPF alignment mode | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| pct | [THIS MEMO] | current | Sampling rate | | | pct | [THIS MEMO] | current | Sampling rate | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| p | [THIS MEMO] | current | Requested handling policy | | | p | [THIS MEMO] | current | Requested handling policy | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| rf | [THIS MEMO] | current | Forensic reporting format(s) | | | rf | [THIS MEMO] | current | Failure reporting format(s) | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| ri | [THIS MEMO] | current | Aggregate Reporting interval | | | ri | [THIS MEMO] | current | Aggregate Reporting interval | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| rua | [THIS MEMO] | current | Reporting URI(s) for | | | rua | [THIS MEMO] | current | Reporting URI(s) for | | |||
| | | | aggregate data | | | | | | aggregate data | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| ruf | [THIS MEMO] | current | Reporting URI(s) for | | | ruf | [THIS MEMO] | current | Reporting URI(s) for | | |||
| | | | forensic data | | | | | | failure data | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| sp | [THIS MEMO] | current | Requested handling policy | | | sp | [THIS MEMO] | current | Requested handling policy | | |||
| | | | for subdomains | | | | | | for subdomains | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
| v | [THIS MEMO] | current | Specification version | | | v | [THIS MEMO] | current | Specification version | | |||
+----------+-------------+---------+------------------------------+ | +----------+-------------+---------+------------------------------+ | |||
14.4. DMARC Report Format Registry | 14.4. DMARC Report Format Registry | |||
Names of DMARC forensic reporting formats must be registered with | Names of DMARC failure reporting formats must be registered with | |||
IANA. New entries are assigned only for values that have been | IANA. New entries are assigned only for values that have been | |||
documented in a published RFC that has had IETF Review, per | documented in a published RFC that has had IETF Review, per | |||
[IANA-CONSIDERATIONS]. Each registration must include the tag name, | [IANA-CONSIDERATIONS]. Each registration must include the tag name, | |||
the specification that defines it, a brief description, and its | the specification that defines it, a brief description, and its | |||
status which must be one of "current", "experimental" or "historic". | status which must be one of "current", "experimental" or "historic". | |||
The initial set of entries in this registry is as follows: | The initial set of entries in this registry is as follows: | |||
+--------+-------------+---------+-----------------------------+ | +--------+-------------+---------+-----------------------------+ | |||
| Format | Defined | Status | Description | | | Format | Defined | Status | Description | | |||
skipping to change at page 39, line 5 | skipping to change at page 44, line 49 | |||
reflective of the true originator of the message. | reflective of the true originator of the message. | |||
o The focus of email authentication efforts has been to create | o The focus of email authentication efforts has been to create | |||
mechanisms by which this field, or at least some field in the | mechanisms by which this field, or at least some field in the | |||
message, can be deemed genuine. Thus, this field is not easily | message, can be deemed genuine. Thus, this field is not easily | |||
forged within the context of its use with DMARC. | forged within the context of its use with DMARC. | |||
o The DMARC mechanism confers no additional privilege to the message | o The DMARC mechanism confers no additional privilege to the message | |||
without successful authentication of this identifier. | without successful authentication of this identifier. | |||
The absence of a single, properly-formed RFC5322.From field renders | ||||
the message invalid. This document prescribes no specific action in | ||||
that case, other than to suggest that the message ought to be | ||||
disposed of by the Mail Receiver's infrastructure in a safe manner | ||||
that recognizes and possibly even highlights the malformation. | ||||
15.2. Display Name Attacks | 15.2. Display Name Attacks | |||
A common attack in messaging abuse is the presentation of false | A common attack in messaging abuse is the presentation of false | |||
information in the "display name" portion of the RFC5322.From field. | information in the "display name" portion of the RFC5322.From field. | |||
For example, it is possible for the email address in that field to be | For example, it is possible for the email address in that field to be | |||
an arbitrary address or domain name, while containing a well-known | an arbitrary address or domain name, while containing a well-known | |||
name (a person, brand, role, etc.) in the display name, intending to | name (a person, brand, role, etc.) in the display name, intending to | |||
fool the end user into believing that the name is used legitimately. | fool the end user into believing that the name is used legitimately. | |||
The attack is predicated on the notion that most common Mail User | The attack is predicated on the notion that most common Mail User | |||
Agents (MUAs) will show the display name and not the email address | Agents (MUAs) will show the display name and not the email address | |||
skipping to change at page 41, line 28 | skipping to change at page 47, line 31 | |||
domains that are claimed as external recipients. Negative caching | domains that are claimed as external recipients. Negative caching | |||
will mitigate this problem, but only to a limited extent, mostly | will mitigate this problem, but only to a limited extent, mostly | |||
dependent on the default time-to-live in the domain's SOA record. | dependent on the default time-to-live in the domain's SOA record. | |||
Where possible, external reporting is best achieved by having the | Where possible, external reporting is best achieved by having the | |||
report be directed to domains that can receive mail and simply having | report be directed to domains that can receive mail and simply having | |||
it automatically forwarded to the desired external destination. | it automatically forwarded to the desired external destination. | |||
Note that the addresses shown in the "ruf" tag receive more | Note that the addresses shown in the "ruf" tag receive more | |||
information that might be considered private data, since it is | information that might be considered private data, since it is | |||
possible for actual email content to appear in the forensic reports. | possible for actual email content to appear in the failure reports. | |||
The URIs identified there are thus more attractive targets for | The URIs identified there are thus more attractive targets for | |||
intrusion attempts than those found in the "rua" tag. Moreover, | intrusion attempts than those found in the "rua" tag. Moreover, | |||
attacking the DNS of the subject domain to cause forensic data to be | attacking the DNS of the subject domain to cause failure data to be | |||
routed fraudulently to an attacker's systems may be an attractive | routed fraudulently to an attacker's systems may be an attractive | |||
prospect. Deployment of DNSSEC is advisable if this is a concern. | prospect. Deployment of [DNSSEC] is advisable if this is a concern. | |||
The verification mechanism presented in Section 8.2 is currently not | The verification mechanism presented in Section 8.2 is currently not | |||
mandatory ("MUST") but strongly recommended ("SHOULD"). It is | mandatory ("MUST") but strongly recommended ("SHOULD"). It is | |||
possible that it would be elevated to a "MUST" by later security | possible that it would be elevated to a "MUST" by later security | |||
review. | review. | |||
15.7. Feedback Loops | 15.7. Feedback Loops | |||
Per [ARF-BCP] and [ARF-AS], it is highly advisable to vet the | Per [ARF-BCP] and [ARF-AS], it is highly advisable to vet the | |||
destinations of feedback streams to which Mail Receivers will send | destinations of feedback streams to which Mail Receivers will send | |||
skipping to change at page 42, line 11 | skipping to change at page 48, line 14 | |||
mechanism by which one can request that no more reports be sent in | mechanism by which one can request that no more reports be sent in | |||
case some entity becomes the unwitting recipient of undesired data in | case some entity becomes the unwitting recipient of undesired data in | |||
high volumes. | high volumes. | |||
15.8. Rejecting Messages | 15.8. Rejecting Messages | |||
This proposal calls for rejection of a message during the SMTP | This proposal calls for rejection of a message during the SMTP | |||
session under certain circumstances. This is typically done in one | session under certain circumstances. This is typically done in one | |||
of two ways: | of two ways: | |||
o Full rejection, wherein the SMTP server issues a 5xy reply code | o Full rejection, wherein the SMTP server issues a 5xy reply code as | |||
(550 SHOULD be used) as an indication to the SMTP client that the | an indication to the SMTP client that the transaction failed; the | |||
transaction failed; the SMTP client is then responsible for | SMTP client is then responsible for generating notification that | |||
generating notification that delivery failed (see Section 4.2.5 of | delivery failed (see Section 4.2.5 of [SMTP]). | |||
[SMTP]). | ||||
o A "silent discard", wherein the SMTP server returns a 2xy reply | o A "silent discard", wherein the SMTP server returns a 2xy reply | |||
code implying to the client that delivery (or, at least, relay) | code implying to the client that delivery (or, at least, relay) | |||
was successfully completed, but then simply discarding the message | was successfully completed, but then simply discarding the message | |||
with no further action. | with no further action. | |||
Each of these has a cost. For instance, a silent discard may prevent | Each of these has a cost. For instance, a silent discard may prevent | |||
"backscatter" (the annoying generation of delivery failure reports, | "backscatter" (the annoying generation of delivery failure reports, | |||
which go back to the RFC5321.MailFrom address, about messages that | which go back to the RFC5321.MailFrom address, about messages that | |||
were fraudulently generated), but effectively means the SMTP server | were fraudulently generated), but effectively means the SMTP server | |||
has to be programmed to give a false result, which can confound | has to be programmed to give a false result, which can confound | |||
external debugging efforts. | external debugging efforts. | |||
Similarly, the text portion of the SMTP reply may be important to | Similarly, the text portion of the SMTP reply may be important to | |||
consider. For example, when rejecting a message, revealing the | consider. For example, when rejecting a message, revealing the | |||
reason for the rejection might give an attacker enough information to | reason for the rejection might give an attacker enough information to | |||
bypass those efforts on a later attempt, though it might also assist | bypass those efforts on a later attempt, though it might also assist | |||
a legitimate client to determine the source of some local issue that | a legitimate client to determine the source of some local issue that | |||
caused the rejection. | caused the rejection. | |||
In the latter case, when doing an SMTP rejection, providing a clear | ||||
hint can be useful in resolving issues. A receiver might indicate in | ||||
plain text the reason for the rejection by using the word "DMARC" | ||||
somewhere in the reply text. Many systems are able to scan the SMTP | ||||
reply text to determine the nature of the rejection, thus providing a | ||||
machine-detectable reason for rejection allows automated sorting of | ||||
rejection causes so they can be properly addressed. For example: | ||||
550 5.7.1 Email rejected per DMARC policy for example.com | ||||
If a Mail Receiver elects to defer delivery due to inability to | If a Mail Receiver elects to defer delivery due to inability to | |||
retrieve or apply DMARC policy, this SHOULD be done with a 450 SMTP | retrieve or apply DMARC policy, this is best done with a 4xy SMTP | |||
reply code. | reply code. | |||
15.9. Capacity Planning | 15.9. Capacity Planning | |||
DMARC participants will need to perform capacity planning to support | DMARC participants will need to perform capacity planning to support | |||
their implementations. Some factors to consider include: | their implementations. Some factors to consider include: | |||
Storage: As Mail Receivers process increasing numbers of messages -- | Storage: As Mail Receivers process increasing numbers of messages -- | |||
from increasingly disparate sources -- claiming to be from DMARC- | from increasingly disparate sources -- claiming to be from DMARC- | |||
enabled domains, additional storage of information must be | enabled domains, additional storage of information must be | |||
skipping to change at page 45, line 9 | skipping to change at page 51, line 23 | |||
For example, an attacker who controls the SPF record for | For example, an attacker who controls the SPF record for | |||
"evil.example.com" can send mail with an RFC5322.From containing | "evil.example.com" can send mail with an RFC5322.From containing | |||
"foo@example.com" that can pass both authentication and the DMARC | "foo@example.com" that can pass both authentication and the DMARC | |||
check against "example.com". | check against "example.com". | |||
The Organizational Domain administrator should be careful not to cede | The Organizational Domain administrator should be careful not to cede | |||
control of sub-domains if this is an issue, and to consider using the | control of sub-domains if this is an issue, and to consider using the | |||
"strict" Identifier Alignment option if appropriate. | "strict" Identifier Alignment option if appropriate. | |||
15.12. DNS Security | ||||
The DMARC mechanism and its underlying technologies (SPF, DKIM) | ||||
depend on the security of the DNS. To reduce the risk of subversion | ||||
of the DMARC mechanism due to DNS-based exploits, serious | ||||
consideration should be given to the deployment of DNSSEC in parallel | ||||
to the deployment of DMARC. | ||||
DNSSEC-enabled environments should consider the implication of | ||||
receiving insecure or bogus DNS replies in the DMARC context. | ||||
Operators should understand whether their DMARC implementations will | ||||
behave as expected when DNSSEC-secured queries temporarily fail due | ||||
to attempted exploit. For example, if lookup of a specific domain's | ||||
DMARC record is typically secured using DNSSEC, attention should to | ||||
paid to cases and behaviors when secured lookups fail. The operator | ||||
may consider configuring their DNSSEC-aware resolver to propagate a | ||||
"temporary error" condition to the DMARC mechanism to defer | ||||
acceptance of email until DNSSEC resolution can be restored. | ||||
16. References | 16. References | |||
16.1. Normative References | 16.1. Normative References | |||
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", RFC 5234, January 2008. | Specifications: ABNF", RFC 5234, January 2008. | |||
[AFRF] Fontana, H., "Authentication Failure Reporting using the | [AFRF] Fontana, H., "Authentication Failure Reporting using the | |||
Abuse Report Format", | Abuse Report Format", RFC 6591, April 2012. | |||
I-D draft-ietf-marf-authfailure-report, September 2011. | ||||
[AFRF-DKIM] | ||||
Kucherawy, M., "Extensions to DomainKeys Identified Mail | ||||
(DKIM) for Failure Reporting", RFC 6651, June 2012. | ||||
[AFRF-SPF] | ||||
Kitterman, S., "Sender Policy Framework (SPF) | ||||
Authentication Failure Reporting Using the Abuse Reporting | ||||
Format", RFC 6652, June 2012. | ||||
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys | [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys | |||
Identified Mail (DKIM) Signatures", RFC 6376, | Identified Mail (DKIM) Signatures", RFC 6376, | |||
September 2011. | September 2011. | |||
[DNS] Mockapetris, P., "Domain names - implementation and | [DNS] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
[DNS-CASE] | [DNS-CASE] | |||
Eastlake, D., "Domain Name System (DNS) Case Insensitivity | Eastlake, D., "Domain Name System (DNS) Case Insensitivity | |||
Clarification", RFC 4343, January 2006. | Clarification", RFC 4343, January 2006. | |||
[GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' | ||||
Media Types", RFC 6713, August 2012. | ||||
[IDNA] Klensin, J., "Internationalized Domain Names for | ||||
Applications (IDNA): Definitions and Document Framework", | ||||
RFC 5890, August 2000. | ||||
[KEYWORDS] | [KEYWORDS] | |||
Bradner, S., "Key words for use in RFCs to Indicate | Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
October 2008. | October 2008. | |||
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, November 1996. | Bodies", RFC 2045, November 1996. | |||
skipping to change at page 46, line 46 | skipping to change at page 53, line 46 | |||
[DKIM-DEPLOYMENT] | [DKIM-DEPLOYMENT] | |||
Hansen, T., Siegel, E., Crocker, D., and P. Hallam-Baker, | Hansen, T., Siegel, E., Crocker, D., and P. Hallam-Baker, | |||
"DomainKeys Identified Mail (DKIM) Development, | "DomainKeys Identified Mail (DKIM) Development, | |||
Deployment, and Operations", RFC 5863, May 2010. | Deployment, and Operations", RFC 5863, May 2010. | |||
[DKIM-OVERVIEW] | [DKIM-OVERVIEW] | |||
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys | Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys | |||
Identified Mail (DKIM) Service Overview", RFC 5585, | Identified Mail (DKIM) Service Overview", RFC 5585, | |||
July 2009. | July 2009. | |||
[DKIM-THREATS] | ||||
Fenton, J., "Analysis of Threats Motivating DomainKeys | ||||
Identified Mail (DKIM)", RFC 4686, September 2006. | ||||
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "DNS Security Introduction and Requirements", | ||||
RFC 4033, March 2005. | ||||
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format | [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format | |||
for Delivery Status Notifications", RFC 3464, | for Delivery Status Notifications", RFC 3464, | |||
January 2003. | January 2003. | |||
[EMAIL-ARCH] | [EMAIL-ARCH] | |||
Crocker, D., "Internet Mail Architecture", RFC 5598, | Crocker, D., "Internet Mail Architecture", RFC 5598, | |||
July 2009. | July 2009. | |||
[IANA-CONSIDERATIONS] | [IANA-CONSIDERATIONS] | |||
Narten, T. and H. Alvestrand, "Guidelines for Writing an | Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident | [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident | |||
Object Description Exchange Format", RFC 5070, | Object Description Exchange Format", RFC 5070, | |||
December 2007. | December 2007. | |||
[ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and | [ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and | |||
Functions", RFC 2142, May 1997. | Functions", RFC 2142, May 1997. | |||
URIs | ||||
[1] <http://dmarc.org> | ||||
Appendix A. Technology Considerations | Appendix A. Technology Considerations | |||
This section documents some design decisions that were made in the | This section documents some design decisions that were made in the | |||
development of DMARC. Specifically, addressed here are some | development of DMARC. Specifically, addressed here are some | |||
suggestions that were considered but not included in the design. | suggestions that were considered but not included in the design. | |||
This text is included to explain why they were considered and not | This text is included to explain why they were considered and not | |||
included in this version. | included in this version. | |||
A.1. S/MIME | A.1. S/MIME | |||
skipping to change at page 47, line 42 | skipping to change at page 55, line 6 | |||
DMARC is focused on authentication at the domain level (i.e., the | DMARC is focused on authentication at the domain level (i.e., the | |||
ADMD taking responsibility for the message), while S/MIME is really | ADMD taking responsibility for the message), while S/MIME is really | |||
intended for user-to-user authentication and encryption. This alone | intended for user-to-user authentication and encryption. This alone | |||
appears to make it a bad fit for DMARC's goals. | appears to make it a bad fit for DMARC's goals. | |||
S/MIME also suffers from the heavyweight problem of Public Key | S/MIME also suffers from the heavyweight problem of Public Key | |||
Infrastructure, which means distribution of keys used to verify | Infrastructure, which means distribution of keys used to verify | |||
signatures needs to be incorporated. In many instances, this alone | signatures needs to be incorporated. In many instances, this alone | |||
is a showstopper. There have been consistent promises that PKI | is a showstopper. There have been consistent promises that PKI | |||
usability and deployment will improve, but these have yet to | usability and deployment will improve, but these have yet to | |||
materialize. DMARC can revisit this chouice after those barriers are | materialize. DMARC can revisit this choice after those barriers are | |||
addressed. | addressed. | |||
S/MIME has extensive deployment in specific market segments | S/MIME has extensive deployment in specific market segments | |||
(government, for example), but does not enjoy similar widespread | (government, for example), but does not enjoy similar widespread | |||
deployment over the general Internet, and this shows no signs of | deployment over the general Internet, and this shows no signs of | |||
changing. DKIM and SPF both are deployed widely over the general | changing. DKIM and SPF both are deployed widely over the general | |||
Internet and their adoption rates continue to be positive. | Internet and their adoption rates continue to be positive. | |||
Finally, experiements have shown that including S/MIME support in the | Finally, experiements have shown that including S/MIME support in the | |||
initial version of DMARC would neither cause nor enable a substantial | initial version of DMARC would neither cause nor enable a substantial | |||
skipping to change at page 48, line 23 | skipping to change at page 55, line 35 | |||
Specifically, consider a Domain Owner that has deployed one of the | Specifically, consider a Domain Owner that has deployed one of the | |||
technologies, and that technology fails for some messages, but such | technologies, and that technology fails for some messages, but such | |||
failures don't cause enforcement action. Deploying DMARC would cause | failures don't cause enforcement action. Deploying DMARC would cause | |||
enforcement action for policies other than "none", which would appear | enforcement action for policies other than "none", which would appear | |||
to exclude participation by that Domain Owner. | to exclude participation by that Domain Owner. | |||
The DMARC development team evaluated the idea of policy exception | The DMARC development team evaluated the idea of policy exception | |||
mechanisms on several occasions and invariably concluded that there | mechanisms on several occasions and invariably concluded that there | |||
was not a strong enough use case to include them. The specific | was not a strong enough use case to include them. The specific | |||
target audience for DMARC does not appear to have concerns about the | target audience for DMARC does not appear to have concerns about the | |||
failure modes of one or the other being a barried to DMARC's | failure modes of one or the other being a barrier to DMARC's | |||
adoption. | adoption. | |||
In the scenario described above, the Domain Owner has a few options: | In the scenario described above, the Domain Owner has a few options: | |||
1. Tighten up its infrastructure to minimize the failure modes of | 1. Tighten up its infrastructure to minimize the failure modes of | |||
the single deployed technology. | the single deployed technology. | |||
2. Deploy the other supported authentication mechanism, to offset | 2. Deploy the other supported authentication mechanism, to offset | |||
the failure modes of the first. | the failure modes of the first. | |||
skipping to change at page 49, line 37 | skipping to change at page 57, line 7 | |||
mandatory check of this nature. It was ultimately removed, as the | mandatory check of this nature. It was ultimately removed, as the | |||
method's error rate was too high without substantial manual tuning | method's error rate was too high without substantial manual tuning | |||
and heuristic work. There are indeed use cases this work needs to | and heuristic work. There are indeed use cases this work needs to | |||
address where such a method would return a negative result about a | address where such a method would return a negative result about a | |||
domain for which reporting is desired, such as a registered domain | domain for which reporting is desired, such as a registered domain | |||
name that never sends legitimate mail and thus has none of these | name that never sends legitimate mail and thus has none of these | |||
records present in the DNS. | records present in the DNS. | |||
A.5. Issues With ADSP In Operation | A.5. Issues With ADSP In Operation | |||
DMARC has been chacarterized as a "super-ADSP" of sorts. | DMARC has been characterized as a "super-ADSP" of sorts. | |||
Contributors to DMARC have compiled a list of issues associated with | Contributors to DMARC have compiled a list of issues associated with | |||
ADSP, gained from operational experience, that have influenced the | ADSP, gained from operational experience, that have influenced the | |||
direction of DMARC: | direction of DMARC: | |||
1. ADSP has no support for subdomains, i.e., the ADSP record for | 1. ADSP has no support for subdomains, i.e., the ADSP record for | |||
example.com does not explicitly or implicitly apply to | example.com does not explicitly or implicitly apply to | |||
subdomain.example.com. If wildcarding is not applied, then | subdomain.example.com. If wildcarding is not applied, then | |||
spammers can trivially bypass ADSP by sending from a subdomain | spammers can trivially bypass ADSP by sending from a subdomain | |||
with no ADSP record. | with no ADSP record. | |||
skipping to change at page 54, line 27 | skipping to change at page 61, line 46 | |||
"dmarc-feedback@example.com" | "dmarc-feedback@example.com" | |||
("rua=mailto:dmarc-feedback@example.com") | ("rua=mailto:dmarc-feedback@example.com") | |||
o All messages from this organizational domain are subject to this | o All messages from this organizational domain are subject to this | |||
policy (no "pct" tag present, so the default of 100% applies) | policy (no "pct" tag present, so the default of 100% applies) | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool: | common command-line tool: | |||
% dig +short TXT _dmarc.example.com. | % dig +short TXT _dmarc.example.com. | |||
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com" | "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
creates an entry like the following in the appropriate zone file | creates an entry like the following in the appropriate zone file | |||
(following the conventional zone file format): | (following the conventional zone file format): | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=none; " | _dmarc IN TXT ( "v=DMARC1; p=none; " | |||
"rua=mailto:dmarc-feedback@example.com" ) | "rua=mailto:dmarc-feedback@example.com" ) | |||
B.2.2. Entire Domain, Monitoring Only, Per-Message Reports | B.2.2. Entire Domain, Monitoring Only, Per-Message Reports | |||
The Domain Owner from the previous example has used the aggregate | The Domain Owner from the previous example has used the aggregate | |||
reporting to discover some messaging systems that had not yet | reporting to discover some messaging systems that had not yet | |||
implemented DKIM correctly, but they are still seeing periodic | implemented DKIM correctly, but they are still seeing periodic | |||
authentication failures. In order to diagnose these intermittent | authentication failures. In order to diagnose these intermittent | |||
problems they wish to request per-message forensic reports when | problems they wish to request per-message failure reports when | |||
authentication failures occur. | authentication failures occur. | |||
Not all Receivers will honor such a request, but the Domain Owner | Not all Receivers will honor such a request, but the Domain Owner | |||
feels that any reports it does receive will be helpful enough to | feels that any reports it does receive will be helpful enough to | |||
justify publishing this record. The default per-message report | justify publishing this record. The default per-message report | |||
format ([AFRF]) meets the Domain Owner's needs in this scenario. | format ([AFRF]) meets the Domain Owner's needs in this scenario. | |||
The Domain Owner accomplishes this by adding the following to its | The Domain Owner accomplishes this by adding the following to its | |||
policy record from Appendix B.2): | policy record from Appendix B.2): | |||
o Per-message forensic reports should be sent via email to the | o Per-message failure reports should be sent via email to the | |||
address "auth-reports@example.com" | address "auth-reports@example.com" | |||
("ruf=mailto:auth-reports@example.com") | ("ruf=mailto:auth-reports@example.com") | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool (the output shown would appear on a single | common command-line tool (the output shown would appear on a single | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT _dmarc.example.com. | % dig +short TXT _dmarc.example.com. | |||
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com\; | "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; | |||
ruf=mailto:auth-reports@example.com" | ruf=mailto:auth-reports@example.com" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
might create an entry like the following in the appropriate zone file | might create an entry like the following in the appropriate zone file | |||
(following the conventional zone file format): | (following the conventional zone file format): | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=none; " | _dmarc IN TXT ( "v=DMARC1; p=none; " | |||
"rua=mailto:dmarc-feedback@example.com; " | "rua=mailto:dmarc-feedback@example.com; " | |||
"ruf=mailto:auth-reports@example.com" ) | "ruf=mailto:auth-reports@example.com" ) | |||
B.2.3. Per-Message Forensic Reports Directed to Third Party | B.2.3. Per-Message Failure Reports Directed to Third Party | |||
The Domain Owner from the previous example is maintaining the same | The Domain Owner from the previous example is maintaining the same | |||
policy, but now wishes to have a third party receive and process the | policy, but now wishes to have a third party receive and process the | |||
per-message forensic reports. Again, not all Receivers will honor | per-message failure reports. Again, not all Receivers will honor | |||
this request, but those that do may implement additional checks to | this request, but those that do may implement additional checks to | |||
validate that the third party wishes to receive the forensic reports | validate that the third party wishes to receive the failure reports | |||
for this domain. | for this domain. | |||
The Domain Owner needs to alter its policy record from Appendix B.2.2 | The Domain Owner needs to alter its policy record from Appendix B.2.2 | |||
as follows: | as follows: | |||
o Per message forensic reports should be send via email to the | o Per message failure reports should be send via email to the | |||
address "auth-reports@thirdparty.example.net" | address "auth-reports@thirdparty.example.net" | |||
("ruf=mailto:auth-reports@thirdparty.example.net") | ("ruf=mailto:auth-reports@thirdparty.example.net") | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool (the output shown would appear on a single | common command-line tool (the output shown would appear on a single | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT _dmarc.example.com. | % dig +short TXT _dmarc.example.com. | |||
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com\; | "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; | |||
ruf=mailto:auth-reports@thirdparty.example.net" | ruf=mailto:auth-reports@thirdparty.example.net" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
might create an entry like the following in the appropriate zone file | might create an entry like the following in the appropriate zone file | |||
(following the conventional zone file format): | (following the conventional zone file format): | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=none; " | _dmarc IN TXT ( "v=DMARC1; p=none; " | |||
"rua=mailto:dmarc-feedback@example.com; " | "rua=mailto:dmarc-feedback@example.com; " | |||
"ruf=mailto:auth-reports@thirdparty.example.net" ) | "ruf=mailto:auth-reports@thirdparty.example.net" ) | |||
Because the address used in the "ruf" tag is outside the | Because the address used in the "ruf" tag is outside the | |||
Organizational Domain in whichthat this record is published, | Organizational Domain in which this record is published, conforming | |||
conforming Receivers will implement additional checks as described in | Receivers will implement additional checks as described in | |||
Section 8.2 of this document. In order to pass these additional | Section 8.2 of this document. In order to pass these additional | |||
checks, the third party will need to publish an additional DNS record | checks, the third party will need to publish an additional DNS record | |||
as follows: | as follows: | |||
o Given the DMARC record published by the Domain Owner at | o Given the DMARC record published by the Domain Owner at | |||
"_dmarc.example.com", the DNS administrator for the third party | "_dmarc.example.com", the DNS administrator for the third party | |||
will need to publish a TXT resource record at | will need to publish a TXT resource record at | |||
"example.com._report._dmarc.thirdparty.example.net" with the value | "example.com._report._dmarc.thirdparty.example.net" with the value | |||
"v=DMARC1". | "v=DMARC1". | |||
skipping to change at page 56, line 40 | skipping to change at page 64, line 15 | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT example.com._report._dmarc.thirdparty.example.net | % dig +short TXT example.com._report._dmarc.thirdparty.example.net | |||
"v=DMARC1" | "v=DMARC1" | |||
To publish such a record, the DNS administrator for example.net might | To publish such a record, the DNS administrator for example.net might | |||
create an entry like the following in the appropriate zone file | create an entry like the following in the appropriate zone file | |||
(following the conventional zone file format): | (following the conventional zone file format): | |||
; zone file for thirdparty.example.net | ; zone file for thirdparty.example.net | |||
; Accept DMARC forensic reports on behalf of example.com | ; Accept DMARC failure reports on behalf of example.com | |||
example.com._report._dmarc IN TXT "v=DMARC1" | example.com._report._dmarc IN TXT "v=DMARC1" | |||
Intermediaries and other third parties should refer to Section 8.2 | Intermediaries and other third parties should refer to Section 8.2 | |||
for the full details of this mechanism. | for the full details of this mechanism. | |||
B.2.4. Sub-Domain, Sampling, and Multiple Aggregate Report URIs | B.2.4. Sub-Domain, Sampling, and Multiple Aggregate Report URIs | |||
The Domain Owner has implemented SPF and DKIM in a sub-domain used | The Domain Owner has implemented SPF and DKIM in a sub-domain used | |||
for pre-production testing of messaging services. It now wishes to | for pre-production testing of messaging services. It now wishes to | |||
request that participating receivers act to reject messages from this | request that participating receivers act to reject messages from this | |||
sub-domain that fail to authenticate. | sub-domain that fail to authenticate. | |||
As a first step it will ask that a portion (1/4 in this example) of | As a first step it will ask that a portion (1/4 in this example) of | |||
failing messages be quarantined, enabling examination of messages | failing messages be quarantined, enabling examination of messages | |||
sent to mailboxes hosted by participating receivers. Aggregate | sent to mailboxes hosted by participating receivers. Aggregate | |||
feedback reports will be sent to a mailbox within the Organizational | feedback reports will be sent to a mailbox within the Organizational | |||
Domain, and to a mailbox at a third party selected and authorized to | Domain, and to a mailbox at a third party selected and authorized to | |||
receive same by the Domain Owner. | receive same by the Domain Owner. Aggregate reports sent to the | |||
third party are limited to a maximum size of ten megabytes. | ||||
The Domain Owner will accomplish this by constructing a policy record | The Domain Owner will accomplish this by constructing a policy record | |||
indicating that: | indicating that: | |||
o The version of DMARC being used is "DMARC1" ("v=DMARC1") | o The version of DMARC being used is "DMARC1" ("v=DMARC1") | |||
o It is applied only to this sub-domain (record is published at | o It is applied only to this sub-domain (record is published at | |||
"_dmarc.test.example.com" and not "_dmarc.example.com") | "_dmarc.test.example.com" and not "_dmarc.example.com") | |||
o Receivers should quarantine messages from this organizational | o Receivers should quarantine messages from this organizational | |||
domain that fail to authenticate ("p=quarantine") | domain that fail to authenticate ("p=quarantine") | |||
o Aggregate feedback reports should be sent via email to the | o Aggregate feedback reports should be sent via email to the | |||
addresses "dmarc-feedback@example.com" and | addresses "dmarc-feedback@example.com" and | |||
"example-tld-test@thirdparty.example.net" ("rua=mailto:dmarc- | "example-tld-test@thirdparty.example.net", with the latter | |||
feedback@example.com,mailto:tld-test@thirdparty.example.net") | subjected to a maximum size limit ("rua=mailto:dmarc-feedback@ | |||
example.com,mailto:tld-test@thirdparty.example.net!10m") | ||||
o 25% of messages from this Organizational Domain are subject to | o 25% of messages from this Organizational Domain are subject to | |||
action based on this policy ("pct=25") | action based on this policy ("pct=25") | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool (the output shown would appear on a single | common command-line tool (the output shown would appear on a single | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT _dmarc.test.example.com | % dig +short TXT _dmarc.test.example.com | |||
"v=DMARC1\; p=quarantine\; rua=mailto:dmarc-feedback@example.com, | "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com, | |||
mailto:tld-test@thirdparty.example.net\; pct=25" | mailto:tld-test@thirdparty.example.net!10m; pct=25" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
might create an entry like the following in the appropriate zone | might create an entry like the following in the appropriate zone | |||
file: | file: | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=quarantine; " | _dmarc IN TXT ( "v=DMARC1; p=quarantine; " | |||
"rua=mailto:dmarc-feedback@example.com," | "rua=mailto:dmarc-feedback@example.com," | |||
"mailto:tld-test@thirdparty.example.net; " | "mailto:tld-test@thirdparty.example.net!10m; " | |||
"pct=25" ) | "pct=25" ) | |||
B.2.5. Third Party Sender and Identifier Alignment | B.2.5. Third Party Sender and Identifier Alignment | |||
The Domain Owner only uses the top-level domain for email, and uses a | The Domain Owner only uses the top-level domain for email, and uses a | |||
third-party sender for some marketing message traffic. It has | third-party sender for some marketing message traffic. It has | |||
implemented SPF and DKIM across its in-house infrastructure and | implemented SPF and DKIM across its in-house infrastructure and | |||
required the third-party to do the same. A monitoring period has | required the third-party to do the same. A monitoring period has | |||
shown that the Domain Owner and the third-party sender are both | shown that the Domain Owner and the third-party sender are both | |||
executing well with respect to email authentication measures. | executing well with respect to email authentication measures. | |||
skipping to change at page 58, line 50 | skipping to change at page 66, line 25 | |||
o Aggregate feedback reports should be sent via email to the address | o Aggregate feedback reports should be sent via email to the address | |||
"dmarc-feedback@example.com" | "dmarc-feedback@example.com" | |||
("rua=mailto:dmarc-feedback@example.com") | ("rua=mailto:dmarc-feedback@example.com") | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool (the output shown would appear on a single | common command-line tool (the output shown would appear on a single | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT _dmarc.example.com | % dig +short TXT _dmarc.example.com | |||
"v=DMARC1\; p=reject\; adkim=s\; aspf=r\; | "v=DMARC1; p=reject; adkim=s; aspf=r; | |||
rua=mailto:dmarc-feedback@example.com" | rua=mailto:dmarc-feedback@example.com" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
might create an entry like the following in the appropriate zone | might create an entry like the following in the appropriate zone | |||
file: | file: | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=reject; adkim=s; aspf=r; " | _dmarc IN TXT ( "v=DMARC1; p=reject; adkim=s; aspf=r; " | |||
"rua=mailto:dmarc-feedback@example.com" ) | "rua=mailto:dmarc-feedback@example.com" ) | |||
skipping to change at page 60, line 8 | skipping to change at page 67, line 31 | |||
o Aggregate reports should be sent via email to the addresses | o Aggregate reports should be sent via email to the addresses | |||
"dmarc-feedback@example.com" and | "dmarc-feedback@example.com" and | |||
"customer-analysis@thirdparty.example.net" ("rua=mailto:dmarc- | "customer-analysis@thirdparty.example.net" ("rua=mailto:dmarc- | |||
feedback@example.com,mailto:customer-data@thirdparty.example.net") | feedback@example.com,mailto:customer-data@thirdparty.example.net") | |||
The DMARC policy record might look like this when retrieved using a | The DMARC policy record might look like this when retrieved using a | |||
common command-line tool (the output shown would appear on a single | common command-line tool (the output shown would appear on a single | |||
line, but is wrapped here for publication): | line, but is wrapped here for publication): | |||
% dig +short TXT _dmarc.example.com | % dig +short TXT _dmarc.example.com | |||
"v=DMARC1\; p=quarantine\; sp=reject\; ri=14400\; | "v=DMARC1; p=quarantine; sp=reject; ri=14400; | |||
rua=mailto:dmarc-feedback@example.com, | rua=mailto:dmarc-feedback@example.com, | |||
mailto:customer-data@thirdparty.example.net" | mailto:customer-data@thirdparty.example.net" | |||
To publish such a record, the DNS administrator for the Domain Owner | To publish such a record, the DNS administrator for the Domain Owner | |||
might create an entry like the following in the appropriate zone | might create an entry like the following in the appropriate zone | |||
file: | file: | |||
; DMARC record for the domain example.com | ; DMARC record for the domain example.com | |||
_dmarc IN TXT ( "v=DMARC1; p=quarantine; sp=reject; " | _dmarc IN TXT ( "v=DMARC1; p=quarantine; sp=reject; " | |||
"rua=mailto:dmarc-feedback@example.com," | "rua=mailto:dmarc-feedback@example.com," | |||
skipping to change at page 61, line 32 | skipping to change at page 69, line 7 | |||
the Mail Receiver applies the DMARC-record-specified policy. | the Mail Receiver applies the DMARC-record-specified policy. | |||
However, before this action is taken, the Mail Receiver can consult | However, before this action is taken, the Mail Receiver can consult | |||
external information to override the Domain Owner's policy. For | external information to override the Domain Owner's policy. For | |||
example, if the Mail Receiver knows that this particular email came | example, if the Mail Receiver knows that this particular email came | |||
from a known and trusted forwarder (that happens to break both SPF | from a known and trusted forwarder (that happens to break both SPF | |||
and DKIM), then the Mail Receiver may choose to ignore the Domain | and DKIM), then the Mail Receiver may choose to ignore the Domain | |||
Owner's policy. | Owner's policy. | |||
The Mail Receiver is now ready to reply to the DATA command. If the | The Mail Receiver is now ready to reply to the DATA command. If the | |||
DMARC check yields that the message is to be rejected, then the Mail | DMARC check yields that the message is to be rejected, then the Mail | |||
Receiver replies with a 550 code to inform the sender of failure. If | Receiver replies with a 5xy code to inform the sender of failure. If | |||
the DMARC check cannot be resolved due to transient network errors, | the DMARC check cannot be resolved due to transient network errors, | |||
then the Mail Receiver replies with a 450 code to inform the sender | then the Mail Receiver replies with a 4xy code to inform the sender | |||
as to the need to reattempt delivery later. If the DMARC check | as to the need to reattempt delivery later. If the DMARC check | |||
yields a passing message, then the Mail Receiver continues on with | yields a passing message, then the Mail Receiver continues on with | |||
email processing, perhaps using the result of the DMARC check as an | email processing, perhaps using the result of the DMARC check as an | |||
input to additional processing modules such as a domain reputation | input to additional processing modules such as a domain reputation | |||
query. | query. | |||
Before exiting DMARC-specific processing, the Mail Receiver checks to | Before exiting DMARC-specific processing, the Mail Receiver checks to | |||
see if the Author Domain DMARC record requests AFRF-based reporting. | see if the Author Domain DMARC record requests AFRF-based reporting. | |||
If so, then the Mail Receiver can emit an AFRF to the reporting | If so, then the Mail Receiver can emit an AFRF to the reporting | |||
address supplied in the DMARC record. | address supplied in the DMARC record. | |||
At the exit of DMARC-specific processing, the Mail Receiver captures | At the exit of DMARC-specific processing, the Mail Receiver captures | |||
(through logging or direct insertion into a data store) the result of | (through logging or direct insertion into a data store) the result of | |||
DMARC processing. Captured information is used to build feedback for | DMARC processing. Captured information is used to build feedback for | |||
Domain Owner consumption. | Domain Owner consumption. This is not necessary if the Domain Owner | |||
has not requested aggregate reports, i.e., no "rua" tag was found in | ||||
the policy record. | ||||
B.3.2. Real-time Feedback Processing | B.3.2. Real-time Feedback Processing | |||
If the DMARC record for the Author Domain of the message under | If the DMARC record for the Author Domain of the message under | |||
processing requests [AFRF]-based reporting, then the Mail Receiver | processing requests [AFRF]-based reporting, then the Mail Receiver | |||
can supply an AFRF report for a message that does not pass all | can supply an AFRF report for a message that does not pass all | |||
underlying DMARC authentication checks. In other words, if any | underlying DMARC authentication checks. In other words, if any | |||
DMARC-supporting authentication checks fail, an AFRF report should be | DMARC-supporting authentication checks fail, an AFRF report should be | |||
generated and sent to the reporting address found in the Author | generated and sent to the reporting address found in the Author | |||
Domain's DMARC record. | Domain's DMARC record. | |||
skipping to change at page 63, line 26 | skipping to change at page 71, line 26 | |||
This is a multipart message in MIME format. | This is a multipart message in MIME format. | |||
------=_NextPart_000_024E_01CC9B0A.AFE54C00 | ------=_NextPart_000_024E_01CC9B0A.AFE54C00 | |||
Content-Type: text/plain; charset="us-ascii" | Content-Type: text/plain; charset="us-ascii" | |||
Content-Transfer-Encoding: 7bit | Content-Transfer-Encoding: 7bit | |||
This is an aggregate report from mail.receiver.example. | This is an aggregate report from mail.receiver.example. | |||
------=_NextPart_000_024E_01CC9B0A.AFE54C00 | ------=_NextPart_000_024E_01CC9B0A.AFE54C00 | |||
Content-Type: application/zip | Content-Type: application/gzip | |||
Content-Transfer-Encoding: base64 | Content-Transfer-Encoding: base64 | |||
Content-Disposition: attachment; | Content-Disposition: attachment; | |||
filename="mail.receiver.example!example.com! | filename="mail.receiver.example!example.com! | |||
1013662812!1013749130.zip" | 1013662812!1013749130.gz" | |||
<zipped content of report> | <gzipped content of report> | |||
------=_NextPart_000_024E_01CC9B0A.AFE54C00-- | ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- | |||
Not shown in the above example is that the Mail Receiver's feedback | Not shown in the above example is that the Mail Receiver's feedback | |||
should be authenticated using SPF. Also, the value of the "filename" | should be authenticated using SPF. Also, the value of the "filename" | |||
MIME parameter is wrapped for printing in this specification but | MIME parameter is wrapped for printing in this specification but | |||
would normally appear as one continuous string. | would normally appear as one continuous string. | |||
B.6. https Transport example | B.6. https Transport example | |||
A DMARC record can contain an "https" reporting address, such as: | A DMARC record can contain an "https" reporting address, such as: | |||
https:feedback.example.com/dmarc-feedback-submissions | https://feedback.example.com/dmarc-feedback-submissions | |||
A sample aggregate report from the Mail Receiver at | A sample aggregate report from the Mail Receiver at | |||
mail.receiver.example, being posted per the above URL via an | mail.receiver.example, being posted per the above URL via an | |||
established secure HTTP (https) connection, might look like this: | established secure HTTP (https) connection, might look like this: | |||
POST /dmarc-feedback-submissions HTTP/1.1 | POST /dmarc-feedback-submissions HTTP/1.1 | |||
Host: feedback.example.com | Host: feedback.example.com | |||
Subject: Report Domain: example.com | Subject: Report Domain: example.com | |||
Submitter: mail.receiver.example | Submitter: mail.receiver.example | |||
Report-ID: <2002.02.15.1> | Report-ID: <2002.02.15.1> | |||
Content-Type: application/zip | Content-Type: application/gzip | |||
Content-Length: 19191 | Content-Length: 19191 | |||
<zipped content of report here> | <gzipped content of report here> | |||
Appendix C. DMARC XML Schema | Appendix C. DMARC XML Schema | |||
The following is the proposed initial schema for producing XML | The following is the proposed initial schema for producing XML | |||
formatted aggregate reports as described in this memo: | formatted aggregate reports as described in this memo. | |||
NOTE: Per the definition of XML, unless otherwise specified in the | ||||
schema below, the minOccurs and maxOccurs values for each element is | ||||
set to 1. | ||||
<?xml version="1.0"?> | <?xml version="1.0"?> | |||
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | |||
targetNamespace="http://dmarc.org/dmarc-xml/0.1"> | targetNamespace="http://dmarc.org/dmarc-xml/0.1"> | |||
<!-- The time range in UTC covered by messages in this report, | <!-- The time range in UTC covered by messages in this report, | |||
specified in seconds since epoch. --> | specified in seconds since epoch. --> | |||
<xs:complexType name="DateRangeType"> | <xs:complexType name="DateRangeType"> | |||
<xs:all> | <xs:all> | |||
<xs:element name="begin" type="xs:integer"/> | <xs:element name="begin" type="xs:integer"/> | |||
skipping to change at page 67, line 18 | skipping to change at page 75, line 22 | |||
type="PolicyEvaluatedType" | type="PolicyEvaluatedType" | |||
minOccurs="0"/> | minOccurs="0"/> | |||
</xs:all> | </xs:all> | |||
</xs:complexType> | </xs:complexType> | |||
<xs:complexType name="IdentifierType"> | <xs:complexType name="IdentifierType"> | |||
<xs:all> | <xs:all> | |||
<!-- The envelope recipient domain. --> | <!-- The envelope recipient domain. --> | |||
<xs:element name="envelope_to" type="xs:string" | <xs:element name="envelope_to" type="xs:string" | |||
minOccurs="0"/> | minOccurs="0"/> | |||
<!-- The envelope from domain. --> | ||||
<xs:element name="envelope_from" type="xs:string" | ||||
minOccurs="1"/> | ||||
<!-- The payload From domain. --> | <!-- The payload From domain. --> | |||
<xs:element name="header_from" type="xs:string" | <xs:element name="header_from" type="xs:string" | |||
minOccurs="1"/> | minOccurs="1"/> | |||
</xs:all> | </xs:all> | |||
</xs:complexType> | </xs:complexType> | |||
<!-- DKIM verification result, according to RFC 5451 | <!-- DKIM verification result, according to RFC 5451 | |||
Section 2.4.1. --> | Section 2.4.1. --> | |||
<xs:simpleType name="DKIMResultType"> | <xs:simpleType name="DKIMResultType"> | |||
<xs:restriction base="xs:string"> | <xs:restriction base="xs:string"> | |||
skipping to change at page 67, line 43 | skipping to change at page 75, line 50 | |||
<xs:enumeration value="temperror"/> | <xs:enumeration value="temperror"/> | |||
<xs:enumeration value="permerror"/> | <xs:enumeration value="permerror"/> | |||
</xs:restriction> | </xs:restriction> | |||
</xs:simpleType> | </xs:simpleType> | |||
<xs:complexType name="DKIMAuthResultType"> | <xs:complexType name="DKIMAuthResultType"> | |||
<xs:all> | <xs:all> | |||
<!-- The d= parameter in the signature --> | <!-- The d= parameter in the signature --> | |||
<xs:element name="domain" type="xs:string" | <xs:element name="domain" type="xs:string" | |||
minOccurs="1"/> | minOccurs="1"/> | |||
<!-- The s= parameter in the signature --> | ||||
<xs:element name="selector" type="xs:string" | ||||
minOccurs="0"/> | ||||
<!-- The DKIM verification result --> | <!-- The DKIM verification result --> | |||
<xs:element name="result" type="DKIMResultType" | <xs:element name="result" type="DKIMResultType" | |||
minOccurs="1"/> | minOccurs="1"/> | |||
<!-- Any extra information (e.g., from | <!-- Any extra information (e.g., from | |||
Authentication-Results --> | Authentication-Results --> | |||
<xs:element name="human_result" type="xs:string" | <xs:element name="human_result" type="xs:string" | |||
minOccurs="0"/> | minOccurs="0"/> | |||
</xs:all> | </xs:all> | |||
</xs:complexType> | </xs:complexType> | |||
<!-- SPF domain scope --> | ||||
<xs:simpleType name="SPFDomainScope"> | ||||
<xs:restriction base="xs:string"> | ||||
<xs:enumeration value="helo"/> | ||||
<xs:enumeration value="mfrom"/> | ||||
</xs:restriction> | ||||
</xs:simpleType> | ||||
<!-- SPF result --> | <!-- SPF result --> | |||
<xs:simpleType name="SPFResultType"> | <xs:simpleType name="SPFResultType"> | |||
<xs:restriction base="xs:string"> | <xs:restriction base="xs:string"> | |||
<xs:enumeration value="none"/> | <xs:enumeration value="none"/> | |||
<xs:enumeration value="neutral"/> | <xs:enumeration value="neutral"/> | |||
<xs:enumeration value="pass"/> | <xs:enumeration value="pass"/> | |||
<xs:enumeration value="fail"/> | <xs:enumeration value="fail"/> | |||
<xs:enumeration value="softfail"/> | <xs:enumeration value="softfail"/> | |||
<!-- "TempError" commonly implemented as "unknown" --> | <!-- "TempError" commonly implemented as "unknown" --> | |||
<xs:enumeration value="temperror"/> | <xs:enumeration value="temperror"/> | |||
<!-- "PermError" commonly implemented as "error" --> | <!-- "PermError" commonly implemented as "error" --> | |||
<xs:enumeration value="permerror"/> | <xs:enumeration value="permerror"/> | |||
</xs:restriction> | </xs:restriction> | |||
</xs:simpleType> | </xs:simpleType> | |||
<xs:complexType name="SPFAuthResultType"> | <xs:complexType name="SPFAuthResultType"> | |||
<xs:all> | <xs:all> | |||
<!-- The envelope From domain. --> | <!-- The checked domain. --> | |||
<xs:element name="domain" type="xs:string" minOccurs="1"/> | <xs:element name="domain" type="xs:string" minOccurs="1"/> | |||
<!-- The scope of the checked domain. --> | ||||
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/> | ||||
<!-- The SPF verification result --> | <!-- The SPF verification result --> | |||
<xs:element name="result" type="SPFResultType" | <xs:element name="result" type="SPFResultType" | |||
minOccurs="1"/> | minOccurs="1"/> | |||
</xs:all> | </xs:all> | |||
</xs:complexType> | </xs:complexType> | |||
<!-- This element contains DKIM and SPF results, uninterpreted | <!-- This element contains DKIM and SPF results, uninterpreted | |||
with respect to DMARC. --> | with respect to DMARC. --> | |||
<xs:complexType name="AuthResultType"> | <xs:complexType name="AuthResultType"> | |||
<xs:sequence> | <xs:sequence> | |||
<!-- There may be no DKIM signatures, or multiple DKIM | <!-- There may be no DKIM signatures, or multiple DKIM | |||
signatures. --> | signatures. --> | |||
<xs:element name="dkim" type="DKIMAuthResultType" | <xs:element name="dkim" type="DKIMAuthResultType" | |||
minOccurs="0" maxOccurs="unbounded"/> | minOccurs="0" maxOccurs="unbounded"/> | |||
<!-- There will always be at least one SPF result. --> | <!-- There will always be at least one SPF result. --> | |||
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1" | <xs:element name="spf" type="SPFAuthResultType" minOccurs="1" | |||
maxOccurs="unbounded"/> | maxOccurs="unbounded"/> | |||
</xs:sequence> | </xs:sequence> | |||
skipping to change at page 69, line 4 | skipping to change at page 77, line 26 | |||
<!-- This element contains all the authentication results used | <!-- This element contains all the authentication results used | |||
to evaluate the DMARC disposition for the given set of | to evaluate the DMARC disposition for the given set of | |||
messages. --> | messages. --> | |||
<xs:complexType name="RecordType"> | <xs:complexType name="RecordType"> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="row" type="RowType"/> | <xs:element name="row" type="RowType"/> | |||
<xs:element name="identifiers" type="IdentifierType"/> | <xs:element name="identifiers" type="IdentifierType"/> | |||
<xs:element name="auth_results" type="AuthResultType"/> | <xs:element name="auth_results" type="AuthResultType"/> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
<!-- Parent --> | <!-- Parent --> | |||
<xs:element name="feedback"> | <xs:element name="feedback"> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="version" | ||||
type="xs:decimal"/> | ||||
<xs:element name="report_metadata" | <xs:element name="report_metadata" | |||
type="ReportMetadataType"/> | type="ReportMetadataType"/> | |||
<xs:element name="policy_published" | <xs:element name="policy_published" | |||
type="PolicyPublishedType"/> | type="PolicyPublishedType"/> | |||
<xs:element name="record" type="RecordType" | <xs:element name="record" type="RecordType" | |||
maxOccurs="unbounded"/> | maxOccurs="unbounded"/> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
</xs:schema> | </xs:schema> | |||
skipping to change at page 69, line 47 | skipping to change at page 78, line 24 | |||
this list occurred. Additional detail can be found in the | this list occurred. Additional detail can be found in the | |||
PolicyOverrideReason's "comment" field. | PolicyOverrideReason's "comment" field. | |||
sampled_out: Message was exempted from application of policy by the | sampled_out: Message was exempted from application of policy by the | |||
"pct" setting in the DMARC policy record. | "pct" setting in the DMARC policy record. | |||
trusted_forwarder: Message authentication failure was anticipated by | trusted_forwarder: Message authentication failure was anticipated by | |||
other evidence linking the message to a locally-maintained list of | other evidence linking the message to a locally-maintained list of | |||
known and trusted forwarders. | known and trusted forwarders. | |||
The "version" for reports generated per this specification MUST be | ||||
the value 1.0. | ||||
Appendix D. Public Discussion | Appendix D. Public Discussion | |||
Public discussion of the DMARC proposal documents is taking place on | Public discussion of the DMARC proposal documents is taking place on | |||
the dmarc-discuss@dmarc.org mailing list. Subscription is available | the dmarc-discuss@dmarc.org mailing list. Subscription is available | |||
at http://www.dmarc.org/mailman/listinfo/dmarc-discuss. | at http://www.dmarc.org/mailman/listinfo/dmarc-discuss. | |||
Appendix E. Acknowledgements | ||||
DMARC and the version of this document submitted to the IETF were the | ||||
result of lengthy efforts by an informal industry consortium: | ||||
DMARC.org [1]. Participating companies included: Agari, American | ||||
Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, | ||||
Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, | ||||
Microsoft, Netease, Paypal, ReturnPath, Trusted Domain Project, and | ||||
Yahoo!. Although the number of contributors and supporters are too | ||||
numerous to mention, notable individual contributions were made by J. | ||||
Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, | ||||
Murray Kucherawy, Steve Jones, Franck Martin, Brett McDowell, and | ||||
Paul Midgen. The contributors would also like to recognize the | ||||
invaluable input and guidance that was provided by J.D. Falk. | ||||
Author's Address | Author's Address | |||
Murray S. Kucherawy (editor) | Murray S. Kucherawy (editor) | |||
Cloudmark | ||||
128 King St., 2nd Floor | ||||
San Francisco, CA 94107 | ||||
USA | ||||
Phone: +1 415 946 3800 | Email: superuser@gmail.com | |||
Email: msk@cloudmark.com | ||||
End of changes. 144 change blocks. | ||||
309 lines changed or deleted | 671 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/ |