Skip to main content

Using DMARC
draft-crocker-dmarc-bcp-00

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]