Using DMARC
draft-crocker-dmarc-bcp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Dave Crocker | ||
Last updated | 2013-02-17 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-crocker-dmarc-bcp-00
Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Intended status: Best Current Practice February 17, 2013 Expires: August 21, 2013 Using DMARC draft-crocker-dmarc-bcp-00 Abstract Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. 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 August 21, 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 Crocker Expires August 21, 2013 [Page 1] Internet-Draft dmarcops February 2013 (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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNS Configuration . . . . . . . . . . . . . . . . . . . . . . 3 4. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 3 5. Report Generation . . . . . . . . . . . . . . . . . . . . . . 4 6. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. References - Normative . . . . . . . . . . . . . . . . . 5 8.2. References - Informative . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF [RFC4408] and DKIM [RFC6376] provide basic domain name authentication methods for email. A recent industry effort [DMARC.ORG] built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance. [DMARC] allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. Discussion is divided along basic lines of activity: o Development o DNS Configuration o Receiver Processing o Report Generation Crocker Expires August 21, 2013 [Page 2] Internet-Draft dmarcops February 2013 This initial version of the document is primarily meant to seed discussion, rather than offer complete consideration of the topic... Besides obviously soliciting more content and discussion, a review of the document's organization is strongly requested. An IETF mailing list for discussing DMARC issues has been requested: dmarc@ietf.org. 2. Development {This section is meant for any software development practices, relevant to the use of DMARC. -ed} 3. DNS Configuration o Malformed DMARC policy TXT records in DNS. Can these be used for anything? Should a policy that does not conform to the spec be ignored? Is there any benefit in attempting to infer meaning (monitor = none, non = ??, rejec = ??) How lenient can one safely be as regards spacing, quotes, separators and slashes? Is there anyway I can report the malformation to the domain owner? 4. Receiver Processing o Rapid adoption of DMARC by apparent spammers Thousands upon thousands of DMARC records published by abusive domains -- probably wildcarding, but it works out the same Using data that is several weeks old, we have a handful of domains that are accepting aggregate reports for over 20 thousand subdomains each Are the reports (either aggregate or forensic) providing the spammers insight that they did not already have? ***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should I only send reports to domains that I trust? Crocker Expires August 21, 2013 [Page 3] Internet-Draft dmarcops February 2013 5. Report Generation o Minimum requirements for aggregate report XML documents What is the bare minimum (in terms of data gleaned from a given email) I need to produce a valid report? What sections of the XML need to be repeated when there is a new aggregation point (email from a different IP, for example) Essentially this could be considered "XML for people who thought they could figure out how to read an XSD but reality crashed that party." o Minimum requirements for forensic reports (soft-fail reports) What is the bare minimum required to produce a forensic report. 6. Miscellaneous This section is meant as a catch-all, for items that haven't yet been assigned to their appropriate section. o Performing remote destination checking What happens if I don't? o Identifier alignment {This has been cited, but not yet explained, as a potential BCP issue. -ed} o Owner vs. Operator {It is possible that there are distinctive practices for domain name owners, versus agents that operate DNS or email services on behalf of the name owner. -ed} 7. Security Considerations o DNS Abuse Most probably don't see this, but adding potentially multiple new DNS lookups per email multiplies rapidly DNS Cache can only help for so long Agg reports are (probably) created from some other host Crocker Expires August 21, 2013 [Page 4] Internet-Draft dmarcops February 2013 If Org Domain policy lookups are required, you may get two lookups every time there is a single lookup 8. References 8.1. References - Normative [DMARC] Kucherawy, M., Ed., "Domain-based Message Authentication, Reporting and Conformance (DMARC)", URL http://http://www.dmarc.org/draft-dmarc-base-00-02.txt, March 2013. 8.2. References - Informative [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. Appendix A. Acknowledgements DMARC and this draft are the result of lengthy efforts by an informal industry consortium: dmarc.org. Author's Address Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 Email: dcrocker@bbiw.net Crocker Expires August 21, 2013 [Page 5]