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 December 25, 2016.

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

• 1. Introduction
• 2. Development
• 3. DNS Configuration
• 4. Receiver Processing
• 5. Report Generation
• 6. Miscellaneous
• 7. Security Considerations
• 8. References
• 8.1. References - Normative
• 8.2. References - Informative
• Appendix A. Acknowledgements
• Author's Address

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:

• Development
• DNS Configuration
• Receiver Processing
• Report Generation

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

• 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

• 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?

5. Report Generation

• 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."
• 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.

• Performing remote destination checking
  • What happens if I don't?

• Identifier alignment
  • {This has been cited, but not yet explained, as a potential BCP issue. -ed}
• 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

• 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
  • 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

8.2. References - Informative

Appendix A. Acknowledgements

DMARC and this draft are the result of lengthy efforts by an informal industry consortium: dmarc.org.

Author's Address