[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03

Network Working Group                                    D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Intended status: Best Current Practice                 November 05, 2013
Expires: May 09, 2014

                              Using DMARC


   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 May 09, 2014.

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 May 09, 2014                  [Page 1]

Internet-Draft                  dmarcops                   November 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Development {T. Draegen}  . . . . . . . . . . . . . . . . . .   4
     2.1.  Developing DMARC Components . . . . . . . . . . . . . . .   4
     2.2.  Developing DMARC-compliant Systems  . . . . . . . . . . .   5
     2.3.  Sending DMARC-compliant Email . . . . . . . . . . . . . .   6
     2.4.  Original bullets: . . . . . . . . . . . . . . . . . . . .   6
   3.  Barriers to Adoption (or, How I Learned          to Stop
       Worrying and Love DMARC) {A. Popowycz}  . . . . . . . . . . .   6
   4.  Planning for DMARC adoption {E. Zwicky} . . . . . . . . . . .   8
     4.1.  Decide what you need to do  . . . . . . . . . . . . . . .   8
     4.2.  Picking Alignment and SP Parameter Values . . . . . . . .  10
     4.3.  Incremental Roll-Out, Sending . . . . . . . . . . . . . .  10
     4.4.  Incremental Roll-Out, Receiving . . . . . . . . . . . . .  11
     4.5.  [Original bullets]  . . . . . . . . . . . . . . . . . . .  11
   5.  DNS Configuration {M. Hammer} . . . . . . . . . . . . . . . .  11
   6.  Receiver Processing {S.Solanki} . . . . . . . . . . . . . . .  12
     6.1.  Preparing for DMARC processing  . . . . . . . . . . . . .  12
     6.2.  Implementing DMARC at receiver  . . . . . . . . . . . . .  13
     6.3.  Rolling out DMARC . . . . . . . . . . . . . . . . . . . .  13
     6.4.  Post roll-out . . . . . . . . . . . . . . . . . . . . . .  14
     6.5.  Original Bullets  . . . . . . . . . . . . . . . . . . . .  14
   7.  Report Generation {M. Jones}  . . . . . . . . . . . . . . . .  15
     7.1.  DMARC aggregate XML report naming and report metadata . .  15
     7.2.  Minimum requirements for DMARC XML aggregate
           report records  . . . . . . . . . . . . . . . . . . . . .  17
     7.3.  Use and Reporting of Local Policy Overrides . . . . . . .  21
     7.4.  Minimum requirements for DMARC failure reports  . . . . .  24
     7.5.  Additional concerns . . . . . . . . . . . . . . . . . . .  25
   8.  Report Receipt and Analysis {M. Jones}  . . . . . . . . . . .  25
     8.1.  Report Receipt  . . . . . . . . . . . . . . . . . . . . .  25
     8.2.  Report Analysis . . . . . . . . . . . . . . . . . . . . .  27
     8.3.  Report Processing and Analysis             Services . . .  29
     8.4.  Additional concerns . . . . . . . . . . . . . . . . . . .  29
   9.  Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . .  29
   10. Interaction Issues  . . . . . . . . . . . . . . . . . . . . .  29
   11. DMARC Commentary -- What were they thinking of...?  . . . . .  30
   12. Privacy Considerations. {T. Adams}  . . . . . . . . . . . . .  32
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  33

Crocker                   Expires May 09, 2014                  [Page 2]

Internet-Draft                  dmarcops                   November 2013

   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
     14.1.  References - Normative . . . . . . . . . . . . . . . . .  34
     14.2.  References - Informative . . . . . . . . . . . . . . . .  34
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  35
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

      v-03 submission:    This version is merely meant to kee the draft
            alive. /d

      *** EDITOR'S NOTE ***    The current version incorporates new
            sections of relatively raw text from the original DMARC.org
            team and has been edited merely to convert to xml2rfc
            format.  This version has not yet received editing for
            content, or any of the wider, public review, discussion and
            revision that is intended.  This version is being issued as
            an Internet Draft in order to create an archived snapshot,
            including noting the authors of specific sub-sections.  It
            is also hoped this version whets more appetites for adding
            content... /Dave

   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

      *  Report Generation

      *  Receiver Processing

Crocker                   Expires May 09, 2014                  [Page 3]

Internet-Draft                  dmarcops                   November 2013

   An IETF mailing list for discussing DMARC issues has been
   established: dmarc@ietf.org.

2.  Development {T. Draegen}

   This section addresses issues that can occur when developing systems
   related to DMARC.  Additional resources for developing DMARC can be
   found at DMARC.ORG.

2.1.  Developing DMARC Components

   DMARC builds on a number of existing technologies, and introduces new
   components only when necessary.  This section helps to identify which
   components are readily available and where new development may be
   necessary.  Combined, the components discussed here form an end-to-
   end DMARC solution.

2.1.1.  Runtime DMARC processing - Sender side

   DMARC requires very little new functionality for senders of email.
   SPF and DKIM are well developed technologies that can be implemented
   and deployed in isolation, and are supported by existing communities.
   DMARC uses TXT-based DNS records that are common.  Support for
   underscores in DNS labels is important to consider while developing
   DNS tools that support DMARC, as DMARC records are located by
   prepending "_dmarc." to a domain and performing a TXT query.

   The ability to configure the domain used for rfc5322.MailFrom
   addresses and for DKIM d= tags is important from a development
   perspective.  Users of DMARC often require flexibility in specifying
   the domains used in both, as DMARC introduces the concept of
   Identifier Alignment to tie existing authentication technologies to
   email's rfc5322.From header domain.

2.1.2.  Runtime DMARC processing - Receiver side

   Because DMARC leverages existing authentication technology,
   developers can often integrate this functionality into existing
   systems without needing to develop entirely new modules.  Developers
   need to take note that DMARC introduces a linkage between email's
   rfc5322.From header domain and the domains authenticated by SPF and
   DKIM, and so Authenticated Domains must be made available from SPF
   and DKIM processing.

   Receiver side processing of DMARC results can also be performed
   during the SMTP conversation, which may cause developers to re-factor
   SPF and DKIM processing code that otherwise might occur after a
   message has been accepted.  Performing the DMARC check during the

Crocker                   Expires May 09, 2014                  [Page 4]

Internet-Draft                  dmarcops                   November 2013

   SMTP conversation allows receivers to enforce "reject" policies

   Receiver side DMARC development also introduces the concept of
   Organization Domain, which should be developed in a modular way so
   that future enhancements/development in the area of Organization
   Domain discovery can be easily integrated.

   The use of Authentication-Results headers is highly recommended to
   ease down-stream processing by receivers.

   The collection of feedback statistics for use in generating DMARC
   aggregate likely presents the most opportunity for new development.
   Collection, harvesting, and storage of such statistics should be
   properly assessed and scoped.  The size of collected datasets can
   become quite large or high-volume email sites.

2.1.3.  Feedback processing - Generator

   Receivers that generate DMARC feedback should be aware of several
   facets of DMARC-related development.

   For feedback that is generated once a day, feedback should span an
   entire 24 hour UTC-based cycle.

   Monitoring and controls around the generation of DMARC feedback
   should be constructed to allow operators the ability to discover
   abuse of report generating code.  Abusers will construct DMARC
   records for large numbers of domains that send unwanted email.
   Consider developing hooks so that intelligence decisions can be made
   as to when DMARC data collection occurs to limit wasted data
   collection and storage resources.

   See Section 7.  "Report Generation" for additional details.

2.1.4.  Feedback processing - Consumer

   Report consumers should be able to control the flow of incoming data
   to disallow abuse of reporting addresses.

   See Section 8.  "Report Receipt and Analysis" for additional details.

2.2.  Developing DMARC-compliant Systems

   Developers of DMARC-compliant systems should consider DMARC
   functionality from the perspective of the day to day operator, and
   ensure their ease of use and deployment scenarios are addressed.  The
   configuration of domains, the maintenance of SPF records and DKIM

Crocker                   Expires May 09, 2014                  [Page 5]

Internet-Draft                  dmarcops                   November 2013

   signing keys, and the ability to quickly diagnose and correct
   problems are essential when creating robust DMARC-compliant systems.

   Integration of existing functionality to build a DMARC-compliant
   system can be helped by leveraging interoperability tests for various
   integrated components.

2.3.  Sending DMARC-compliant Email

   Large portions of this document are relevant to sending DMARC-
   compliant email.

2.4.  Original bullets:

   o  Core Functionality

   o  Tools Support

3.  Barriers to Adoption (or, How I Learned to Stop Worrying and Love
    DMARC) {A. Popowycz}

   Within this section are discussed various hurdles, either real or
   feared, that might need to be overcome to incorporate DMARC into
   successful operational service.  This includes issues that are
   applicable from either a sending perspective, as a receiver, or both.
   When considering DMARC, one must consider the operational and
   technical maturity that would support a successful implementation

   o  I don't know where all my email is sent from!

         One of the first questions that is often raised pertains to
         having an accurate inventory of all sources that may send email
         for a given domain as well as having processes to keep such an
         inventory up-to-date.  This is critical as any policy expressed
         may have implications to mail delivery on that base domain.

         In addition, it is all too easy to have any source send email
         on your domain (which is the underlying problem leading to
         phishing and other similar email threats).

         Such an inventory must consider sources that include organic or
         on-site mail capabilities as well as outsourced mail delivery.
         Also on this list are special purpose emails that are often
         sent as part broader capability, usually in an outsourcing or
         'cloud' capacity

         In actuality, the deployment of DMARC as a sender can actually
         help allay such concerns.  Through both aggregate and message

Crocker                   Expires May 09, 2014                  [Page 6]

Internet-Draft                  dmarcops                   November 2013

         level feedback, DMARC provides a more regular and reliable
         reporting capability which can augment an established inventory
         effort or serve as a core capability in setting such an
         inventory management regime.  Starting with a 'none' policy
         (p=none) expressed in a published policy, one can achieve that
         visibility without having any other implications to mail
         handling behavior.

   o  If I publish a DMARC policy, I lose flexibility in email delivery.

         While DMARC is an important new technology to help address
         phishing, it is not a strategy of itself.  Part of the
         deployment of DMARC is the consideration of segmentation of
         various email sources, usually through the use of subdomains.
         Whereas it is common to send email using a second-level domain
         (e.g. blah.com), segmenting different email sources and
         providers (e.g. source1.blah.com, source2.blah.com) can enhance
         email visibility and diagnostic capability while providing a
         way out of the 'one-size-fits-all' concern.  Furthermore, this
         allows for a more manageable and incremental approach to
         deploying DMARC allowing more aggressive policies to be
         deployed in areas where there is higher confidence in email
         authentication practices.

   o  I use third-party senders for my emails.

         While the use of third party vendors for email delivery
         requires some additional consideration, it is not a major
         hurdle for adoption.  Having good Service Level Agreements
         (SLAs) with your providers that touch upon any changes that
         might impact email authentication should be explicit if at all
         possible to include such items as changes to email hosts and
         addresses (usually impacting SPF) or DKIM key rotations.
         Providing visibility to vendors of their results via regular
         aggregate or message level reporting can help tremendously if
         mail rejection due to 'false-negatives'.[*] Applying subdomain
         segregation as noted previously can also be helpful for
         reporting purposes when more than one email provider is used.

            [*]In this context, a false positive is the identification
            of a valid email failing authentication and having a DMARC
            policy applied when it should not have.

   o  Some of my email is auto-forwarded.

         The email auto-forwarding scenario has been considered in the
         deployment of DMARC.  It is for that reason that a DMARC policy
         is only applied if both SPF and DMARC authentication fails.  In

Crocker                   Expires May 09, 2014                  [Page 7]

Internet-Draft                  dmarcops                   November 2013

         the auto-forwarding scenario, one can expect SPF to fail at the
         final destination, while DKIM is more resilient in that regard.
         But there are those circumstances that in the process of auto-
         forwarding emails are modified (including changes to message
         contents through automatic footer insertion such as Anti-Virus

         Any time an email is handled, the chance for non-delivery
         increases.  From a sender's point of view though, the email did
         reach the mailbox as expressed by the individual who supplied
         the address in the first place.

   Additional concerns:

      Reasons for not publishing a DMARC record (yet).

      Concern for incremental deployment.

      Going through mailing lists.

      Variability in receiver processing; creates unpredictability

4.  Planning for DMARC adoption {E. Zwicky}

   Distinct from lower-level issues in the specific steps for deploying
   and using DMARC is the approach taken in overall planning for its
   integration and use within the operational email service.

4.1.  Decide what you need to do

   DMARC provides protection against some forms of email domain name
   abuse.  Its restricted policy form (p=quarantine or p=reject) is not
   intended for all use cases, and is beneficial only in the presence of
   an actual spoofing problem.  You may, however, want to protect
   mailboxes by checking inbound mail, and you may want information
   about how your domains are showing up at recipients by publishing a
   p=none record.

   So, first you need to determine what domains you own, and sort them
   into piles.

   Sending domains:

   1.  Domains that do not send mail.  These should be protected with
       p=reject, and you can do this quite rapidly -- you might want to
       set them to p=none briefly to verify that you really don't send
       mail from them, but otherwise you can move directly to p=reject.

Crocker                   Expires May 09, 2014                  [Page 8]

Internet-Draft                  dmarcops                   November 2013

   2.  Domains that send only transactional mail.  These should also be
       protected at p=reject, but you will need to follow normal roll-
       out procedures.

   3.  Domains that send mail, but never send transactional mail.  (For
       instance, if you are a mailbox provider, the customer domains do
       not send transactional mail.)  These can be set to p=none if you
       want reporting, or left without records.

   4.  Domains that send both transactional mail and mail for
       individuals -- for many companies, their main corporate domains
       are in this situation.  They both send transactional mail and
       contain users who do things like send mail to mailing lists.

   If you have mixed domains that contain both transactional mail and
   mail from individuals that join mailing lists, you have four main
   choices, in order from best protection of your brand to least:

   1.  Make a declaration that these domains officially represent your
       brand and you do not, as a matter of policy, support forwarding
       mail from them or joining mailing lists from them.  When you have
       enforced this to the extent appropriate to your environment, roll
       out p=reject.

   2.  Move the individuals to another domain, ideally an entirely
       separate one (so if your original domain is example.com, you
       might move the individuals to example-employees.com, letting you
       protect all of example.com at p=reject).

   3.  Move the transactional mail to another domain, usually a
       subdomain of the original domain (official.example.com, for

   4.  Decide not to protect the mail with DMARC directly and use a
       p=none record to get reporting.

   Receiving domains:

   1.  Domains that receive transactional mail (for instance, domains
       where you handle customer inquiries).  If you think forged mail
       from official transactional domains will be a problem here, then
       you should implement inbound DMARC; in most cases, however, you
       derive no large benefit from having it on, and may lose mail from
       misconfigured domains, and might as well leave it off.

   2.  Domains that receive mail for individuals.  These domains should
       implement inbound DMARC to mitigate phishing problems.

Crocker                   Expires May 09, 2014                  [Page 9]

Internet-Draft                  dmarcops                   November 2013

4.2.  Picking Alignment and SP Parameter Values

   Once you know what domains you are trying to protect, you can pick
   values for alignment and for sp.

   If you have a large pile of sending domains like
   shipping.example.com, ordering.example.com, todays-
   promotions.example.com, you probably want to make a single, relaxed
   alignment record for example.com.  The same is true for any domain in
   which you know people frequently create new sending domains with
   little coordination.

   If you have a small number of sending domains, you probably want to
   make an entry for each with strict alignment and sp=reject.  You will
   also want a sp=reject entry on the parent domain.  So, for instance,
   if example.com sends transactional mail only from
   important.example.com and marketing mail from marketing.example.com,
   while the employees hang out on example.com, all three domains should
   be set to strict alignment and sp=reject.  In theory you could in
   omit the records for important.example.com and marketing.example.com
   in this situation.  In practice, you will almost certainly work your
   way up to p=reject on different schedules for them, so at least
   during roll-out you will need separate records.

4.3.  Incremental Roll-Out, Sending

   The procedure for incrementally rolling out DMARC on an individual
   Sending domain is discussed elsewhere.

   Most senders have multiple domains, however, and will have to pick
   which ones to work on first.  Start with some combination of

   1.  Your most attacked domains.

   2.  The easiest domains to secure.

   If you can't easily identify domains in either of these categories,
   turn on DMARC with p=none for a wide assortment of domains, and see
   if that clarifies matters.  (Often it reveals domains that are in
   both categories at once; domains used for sending some particular
   piece of signed, transactional mail, where much more forged mail than
   good mail is sent.)  You can use the p=none reporting on a lower
   domain to substitute for turning on p=none on a subdomain (so, for
   instance, if you have example.com at p=none and notice that
   alerts.example.com sends out only DKIM-signed mail, you can move
   alerts.example.com directly to p=quarantine, and senders who are
   familiar with DMARC and their sending environment may choose to move
   it directly to p=reject)

Crocker                   Expires May 09, 2014                 [Page 10]

Internet-Draft                  dmarcops                   November 2013

4.4.  Incremental Roll-Out, Receiving

   In order to have fully implemented DMARC on the receiving side, you
   must both act on mail and report on mail.  In general, you will have
   to pick one of these to do first; do you turn on reporting, and
   report all mail as exempted for local reasons, or do you turn on
   actions first?  Both of these are acceptable compromises, as long as
   you are rejecting rather than silently discarding mail when p=reject.
   However, you should not spend very long in either state.

4.5.  [Original bullets]

      How to implement DMARC on a corporate email domain.

      Choosing the domain name for alignment.

      Choosing Strict vs. Relaxed.

      Incremental Roll-Out.

5.  DNS Configuration {M. Hammer}

   Malformed Policies:    DMARC policies published in DNS which are
      malformed should be ignored by validators with regard to policy

   Reporting malformed policies:    If a malformed record is identified
      by a validating/reporting entity and that entity wishes to attempt
      reporting a problem with the record, a report may be sent to the
      address(s) indicated in the RUA field.  As an alternative, a
      report may be sent to the technical contact indicated in the WHOIS
      record for the domain.

   Managing DMARC records:    Implementers publishing quarantine or
      reject policies should take care to ensure the integrity of their
      mail streams when rotating DKIM keys.  For owners/administrators
      that manage large numbers of domains, it is recommended to
      automate management and configuration of DMARC records as well as
      underlying DKIM and SPF records to ensure consistency and correct
      deployment of records.

   Publishing DMARC reject policies for non mailing domains:    For
      domains which never send mail, it is appropriate to publish a
      DMARC reject policy as a way to prevent abuse.

   [Original listing of issues]

   o  Malformed DMARC policy TXT records in DNS.

Crocker                   Expires May 09, 2014                 [Page 11]

Internet-Draft                  dmarcops                   November 2013

         Can these be used for anything?

         Should a policy that does not conform to the spec be ignored?

         Should a receiver try to infer meaning in the case where the
         syntax of a DMARC TXT record isn't correct?  For example, if
         "p=monitor" (or p="non", etc.) should the receiver assume the
         domain owner wants to only "monitor" the domain (requesting no
         action other than reports) and apply processing as if it was
         "p=none"?  What if there are what appear to be obvious spelling
         mistakes (e.g. "p=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

   o  DMARC records for many domain names.

6.  Receiver Processing {S.Solanki}

6.1.  Preparing for DMARC processing

   DMARC is a policy enforcement and reporting standard that builds on
   SPF and DKIM to provide more deterministic outcomes of
   authentication-failed messages.  DMARC implementation helps receivers
   to more easily identify email from senders as legitimate, and helps
   keep spam and phishing messages from reaching the inbox.

   The receiver could use the following data points to better understand
   their incoming email traffic:

   o  Total # of phishing messages and campaigns

   o  # of highly phished domains

   o  Total # of senders publishing DMARC records

   o  Total # of messages likely to be processed for DMARC evaluation

   The next step is to scope the engineering work to implement DMARC
   processing.  This includes but not limited to

   o  Support for DKIM and SPF evaluation

   o  Processing DMARC record policy

Crocker                   Expires May 09, 2014                 [Page 12]

Internet-Draft                  dmarcops                   November 2013

   o  Aggregate and message level reporting

   o  Evaluating for Privacy and performance implications

   o  Integration with existing authentication mechanisms from
      processing to user interface

   It is recommended to participate in open DMARC forums, for pursuing
   general questions or learning from experience of receivers who have
   already previously implemented DMARC

6.2.  Implementing DMARC at receiver

   During implementation the goal is to be compliant with the
   specification.  In particular the "must have" attributes have to be
   implemented to be considered compliant.  The optional attributes are
   left to receiver to determine implementation.

   While implementing the specification consider leveraging or building
   the following technologies

   o  DNS service to do real-time lookup

   o  Cache to store recently obtained DMARC records

   o  Dedicated reporting infrastructure to send regular aggregate and
      message level reporting

   o  Instrumentation to track the flow of messages through DMARC
      processing pipeline

   o  Configuration knobs to tune sampling rate and DMARC authentication

   o  Trusted sender visual identification in the emails that pass DMARC

6.3.  Rolling out DMARC

   A phased approach is best recommended for DMARC roll-out at receiver
   side.  Start with a small percentage of your email traffic being
   subject to DMARC processing.

   Reach out to a select group of trusted senders who you know have
   already published DMARC records.  Work closely with them over a
   period of weeks to determine if the implementation is working as

Crocker                   Expires May 09, 2014                 [Page 13]

Internet-Draft                  dmarcops                   November 2013

   Things to observe include but not limited to

      Messages not getting DMARC verdict as expected (either false
      positives or false negatives)

      Reports not being sent in expected format or with missing

   Once any potential issues are fixed, consider ramping up the traffic
   to a larger portion of the incoming traffic.  This will identify
   issues normally caught at scale such as excessing reporting queues or
   caching performance.  This is also a good time to monitor feedback on
   dmarc-dev forums where senders usually post observations or
   complaints about DMARC issues.

   Once satisfied with the feedback you are ready to roll it out full
   scale to the site and announce to the world.

6.4.  Post roll-out

   Post roll-out give sufficient time to evaluate if the processing
   pipeline is working as expected.

   These include monitoring the generated reports in your
   instrumentation infrastructure.  Specifically the "reject" and
   "quarantine" verdicts will give a direct idea of how many phishing
   messages were filtered

   This is a good time to share a summary of your experience
   implementing DMARC and its benefits to you as the receiver over time.
   Feedback regarding quality of documentation and any items missing or
   incorrect should be informed to the community via dmarc-dev for
   future versions of the document.

6.5.  Original Bullets

   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 failure) providing the
         spammers insight that they did not already have?

Crocker                   Expires May 09, 2014                 [Page 14]

Internet-Draft                  dmarcops                   November 2013

         send reports to domains that I trust?

7.  Report Generation {M. Jones}

7.1.  DMARC aggregate XML report naming and report metadata

   The first step most recipients of DMARC aggregate XML reports will
   take, after accepting the compressed files via email, will be to
   uncompress the file and run a script or program to parse and store
   the data contained within the reports.  In order for this to work
   properly, the filenames and report metadata must work in a standard
   way from all DMARC compliant report generators.

   The correct compression mechanism and filename convention is
   described in section 12.2.1 [DMARC] for emailed reports.  It is
   important to ensure that the uncompressed filename still adheres to
   the specified naming convention.  Cases have been noted were upon
   uncompressing a file, the new filename is something entirely
   different than what is specified in section 12.2.1.

   In the report metadata there are several fields that contain
   important information for a report recipient.  Here is a brief
   description of each field and some notes on usage and/or problems
   encountered with each.


            <org_name>  This is generally the domain responsible for
                     producing the data in the report (i.e. the report
                     generator).  In the example below it is
                     'google.com'.  The report itself contains data
                     about messages addressed to users at gmail.com and
                     many other domains hosted by Google.

            <email>  The email address where a report recipient can
                     alert the report generator to problems related to
                     the DMARC aggregate report.  This can be a mailing
                     list address or contain multiple email addresses.

            <extra_contact_info>  A place to point out additional
                     information or resources provided by the report
                     generator.  This could be the URL of a website with
                     additional help, a phone number, etc.

Crocker                   Expires May 09, 2014                 [Page 15]

Internet-Draft                  dmarcops                   November 2013

            <report_id>  A unique report identifier.  This should be
                     unique across all reports by the report generator
                     over time, including reports generated in parallel
                     across multiple MTA's.

            <date_range>  Date range of messages included in the report.
                     The specification says "specified in seconds since
                     epoch".  Note that the begin timestamp for your
                     first report should not be the value 0, but should
                     instead be the begin date/time for the interval.

                     <begin>     UNIX timestamp in UTC.

                     <end>       UNIX timestamp in UTC.

   Below is a sample of report metadata and policy discovery sections of
   DMARC XML report with a the file name:

   <?xml version="1.0" encoding="UTF-8" ?>

Crocker                   Expires May 09, 2014                 [Page 16]

Internet-Draft                  dmarcops                   November 2013

7.2.  Minimum requirements for DMARC XML aggregate report records

   The data contained in a DMARC aggregate report, at minimum, allows a
   report recipient to:

   1.  Identify sources sending email purporting to be "From" its domain
       and sub-domains.

   2.  Determine the aligned DMARC results of SPF and DKIM checks.

   3.  Determine the DMARC disposition of the message.

   4.  Determine the identities used to check the underlying
       authentication mechanisms.

   5.  Determine the results of the underlying authentication mechanism

   To make this possible, each record in a DMARC report must contain a
   minimum set of data.  The fields below are defined in Appendix C.
   DMARC XML Schema and are critical to producing a complete aggregate
   report.  Some notes on usage of these fields are included to help
   guide you in your deployment.

      <source_ip>  IP address (IPv4 or IPv6) of the connecting SMTP

      <count>  The aggregated count of messages represented by this
            record.  The values of all fields contained within the
            <record> must be identical to be part of the aggregate count
            in this record.


            <disposition>  The <disposition> field in DMARC aggregate
                     data is intended to convey the final DMARC
                     disposition of the message.  This is the result of
                     the domain's policy combined with the DKIM and SPF
                     aligned policy results.  The <disposition> field is
                     NOT intended to convey the ultimate placement of
                     the message by the receiving MTA, if for example
                     the report generator decides not to take the DMARC
                     action based on a local policy (Section 7.3).  The
                     allowable results are "none", "quarantine", or

Crocker                   Expires May 09, 2014                 [Page 17]

Internet-Draft                  dmarcops                   November 2013

            <spf>    The DMARC aligned result for SPF.  This must be
                     either "pass" or "fail".

            <dkim>   The DMARC aligned result for DKIM.  This must be
                     either "pass" or "fail".


            <header_from>  This is the rfc5322.From domain in the
                     message(s) for this record.  Note that this is the
                     domain following the @ in the original address,
                     stripped of all surrounding non-domain commentary.



                     <domain>    This is the DKIM signing domain (d=) in
                                 the DKIM signature that the receiver
                                 chose to validate and report.

                     <result>    This is the result of the DKIM
                                 authentication check.  This is NOT the
                                 DMARC aligned result.  The allowable
                                 results are specified in the DMARC XML
                                 Schema and refer to RFC 5451.  Note
                                 that the correct value to report when
                                 no signature is present is "none" as
                                 opposed to "neutral" or NULL.


                     <domain>    This is the domain used for the SPF
                                 check.  Usually it will be the
                                 rfc5321.MailFrom domain.  In cases of a
                                 NULL MAILFROM it may be the EHLO
                                 domain, depending on receiver
                                 implementation of SPF.

                     <result>    This is the result of the SPF
                                 authentication check.  This is NOT the
                                 DMARC aligned result.  The allowable
                                 results are specified in the DMARC XML
                                 Schema.  Note that the correct way to
                                 report that no record exists is "none"
                                 as opposed to a NULL value.

Crocker                   Expires May 09, 2014                 [Page 18]

Internet-Draft                  dmarcops                   November 2013

   Below are three examples of real DMARC XML records for a domain with
   a DMARC reject policy in place.

   This record indicates a single message matching this set of data
   points.  The DMARC disposition for this message was "reject" based on
   DMARC aligned results for SPF and DKIM of "fail" and the domain's
   reject policy.  The empty DKIM domain field and DKIM authentication
   result of "none" indicates that there was no DKIM signature.  The
   result of the SPF authentication check was "neutral".


                  Example - 1 Msg / Disp Reject / No DKIM

   This record indicates that 3 messages were represented by this set of
   data points.  The disposition for these messages was "none" because
   the DMARC aligned result for DKIM was "pass".  The DMARC aligned
   result for SPF was "fail".  The messages passed the DKIM
   authentication check and failed the SPF authentication check.

Crocker                   Expires May 09, 2014                 [Page 19]

Internet-Draft                  dmarcops                   November 2013


                Example - 3 Msgs / Disp None / DKIM-SPF Mix

   This record indicates a single message matching this set of data
   points.  The DMARC disposition for this message was "reject" based on
   DMARC aligned results for SPF and DKIM of "fail" and the domain's
   reject policy.  There was no DKIM signature on this message, as in
   Example 1.  The SPF authentication result was "pass" with a MAILFROM
   domain of "classifiedads.com".  The SPF domain is not aligned with
   the header From domain, causing the DMARC aligned SPF result to be

Crocker                   Expires May 09, 2014                 [Page 20]

Internet-Draft                  dmarcops                   November 2013


                  Example - 1 msg / Disp Reject / No DKIM

7.3.  Use and Reporting of Local Policy Overrides

   The DMARC specification allows for a DMARC compliant receiver to take
   an action that is different than the DMARC disposition for the
   message (see Section B.3.1, SMTP-time Processing [DMARC]).  Reasons
   that a receiver may choose to do so include overriding a reject
   policy if the message source is a known forwarder or mailing list
   that breaks DKIM and SPF.  If a message source has a high reputation
   the receiver may choose to accept and/or analyze a message with local
   rules despite a DMARC disposition of "reject".  While ultimately an
   email receiver's local policy and the final placement of a message
   cannot be standardized by DMARC, the DMARC related reporting of such

   The reporting of a "PolicyOverrideReason" is specified in Appendix C
   [DMARC].  A <reason> tag is included in the <policy_evaluated>
   section of the <record> with two sub-fields, <type> and <comment>.
   Below are the DMARC XML tags and fields involved with a brief
   explanation of each and two real examples of DMARC records with a

Crocker                   Expires May 09, 2014                 [Page 21]

Internet-Draft                  dmarcops                   November 2013


            <disposition>  See Section 7.2.

            <spf>    See Section 7.2.

            <dkim>   See Section 7.2.

            <reason> Present ONLY if the report generator means to tell
                     the report recipient that they did not follow the
                     DMARC disposition.

                     <type>      If a <reason> is included in the record
                                 the <type> must be present.  The
                                 purpose of this field is to explain why
                                 the DMARC policy was overridden.
                                 Allowable values are "forwarded",
                                 "sampled_out", "trusted_forwarder",
                                 "mailing_list", "local_policy", and
                                 "other".  DMARC does NOT attempt to
                                 standardize the meaning of each of
                                 these types nor the methodology by
                                 which a report generator determines the
                                 <type> to report.

                     <comment>   Optional.  A report generator may
                                 include extra explanatory text here.

   Example 1.  In this example the DMARC disposition is reject, based on
   the domain's DMARC reject policy and DMARC aligned SPF and DKIM
   results of "fail".  But a <reason><type> of "mailing_list" is
   reported by the report generator.  The report recipient can interpret
   this to mean that the domain's reject policy was correctly applied,
   but the receiver chose to override the reject action because the
   message source is a known mailing list which cause SPF and DKIM to


Crocker                   Expires May 09, 2014                 [Page 22]

Internet-Draft                  dmarcops                   November 2013


   Example 2.  In this example the DMARC disposition is "none" because
   the DMARC aligned DKIM result is "pass", thus the domain's DMARC
   reject policy is not applicable.  Yet the report generator still
   chose to report a policy override <reason><type> of "forwarded" in
   the record.  This is perfectly acceptable, even though the policy
   override reason did not impact the treatment of the message as far as
   DMARC is concerned.


Crocker                   Expires May 09, 2014                 [Page 23]

Internet-Draft                  dmarcops                   November 2013


7.4.  Minimum requirements for DMARC failure reports

   DMARC failure reports serve two primary purposes.  First is to allow
   a domain owner to investigate in more detail, legitimate sources of
   their email that are failing one or both modes of authentication.
   For example, from aggregate data one might know that a domain's 3rd
   party email is failing DKIM some percentage of the time yet not know
   which messages are affected.  Failure reports could show a consistent
   From address and Subject from the source that are unsigned,
   indicating a specific campaign not being signed by DKIM.  Second is
   to allow a domain owner to understand and mitigate specific threat
   campaigns abusing their domain.  Examples include early
   identification of phishing URLs in current campaigns for quick
   takedown or identification of Subjects used in current campaigns
   which can be used by customer service call center personnel to handle
   customer calls.

   The data contained in a DMARC failure report, at minimum, allows a
   report recipient to:

   1.  Identify the source sending each failed message purporting to be
       "From" its domain or sub-domain.

   2.  Determine the aligned DMARC result of the SPF and DKIM checks.

   3.  Identify the domain used to check SPF.  If this is different than
       the MailFrom domain or the MailFrom domain is NULL and the
       receiver checks EHLO, that identifier must be indicated in the
       failure report.

   4.  Identify the full DKIM signature checked (if the message was DKIM

   5.  Identify the results of the SPF and DKIM authentication checks.

Crocker                   Expires May 09, 2014                 [Page 24]

Internet-Draft                  dmarcops                   November 2013

   6.  Identify the URLs in the body of the message.

   7.  Identify the full rfc5322.From email address in the message.
       This should include the display name portion of the From.

   8.  Identify the Subject of the message.

   Details on the format of failure reports are found in sections 8.4.
   and 8.4.1 [DMARC].

7.5.  Additional concerns

   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 failure reports (soft-fail reports).

         What is the bare minimum required to produce a failure report.

         Whether to request Failure Reports (ruf=)

   o  Utility of Local Policy Overrides.

8.  Report Receipt and Analysis {M. Jones}

8.1.  Report Receipt

8.1.1.  Your first DMARC aggregate reports

   Upon successful publication of a DMARC record for your domain you
   will soon begin to receive DMARC data.  Current report generator
   practice is to aggregate DMARC data daily.  Therefore you should
   expect to receive your first aggregate data in the range of 12 - 48
   hours after you first publish the record.  This can vary depending on
   the time of day your record was published.  DMARC aggregate reports
   should use UTC day boundaries for the reporting intervals.  There is
   also some time lag while your record propagates through DNS is
   discoverable by DMARC compliant receivers.

Crocker                   Expires May 09, 2014                 [Page 25]

Internet-Draft                  dmarcops                   November 2013

   The aggregate data files will arrive as gzipped email attachments.
   While the DMARC specification allows for multiple types of URIs to
   indicate your preference for aggregate data delivery, current report
   generator practice is to deliver reports via email using the mailto:
   URI specified in the rua tag.  Note that if you list multiple email
   addresses in your rua tag, you should list them in the order of the
   highest priority address first, as there have been report generators
   who do not send to all addresses.  In these cases the report
   generator does send reports to at least the first address listed.
   Upon receipt of these files you will need to uncompress them for
   further processing or manual inspection.

8.1.2.  Your first DMARC failure reports

   Upon successful publication of a DMARC record for your domain you
   will also begin to receive DMARC failure data for individual message
   failures at the email address specified in your DMARC record's ruf
   tag.  You will likely receive your first reports within the first 24
   hours of your record being published.  There are several factors that
   will affect the timing and source of your first failure reports.
   First, the current practice is that only a small number of DMARC
   receivers are providing failure reports, as it is optional for a
   DMARC receiver to provide this data.  Therefore you should not expect
   failure reports from all of the same report generators that send you
   aggregate reports.  Next, failure reports are not aggregated and the
   current practice among report generators is to generate a report near
   real time when they receive the failed message.

   The failure reports you will receive are specified in section 8.4.
   and 8.4.1 [DMARC].. These reports are intended to be machine readable
   and it is recommended that you automate the process of parsing and
   storing the data contained in the reports.  The volume of these
   reports you will receive can be highly variable and it is not limited
   by the amount of email that you send.  Attacks using your domain can
   happen at any time and their nature is largely outside of your
   control.  Therefore it is also recommended that your report
   processing infrastructure be able to rate limit or sample the inbound
   reports in a way that does not negatively impact the sending
   infrastructure of report generators.

8.1.3.  What if I do not receive any DMARC reports?

   If you have published DMARC records and waited 24 to 48 hours yet
   still received no data you should check the following:

   1.  Check the rua and ruf addresses in your DMARC record.

          Are they correct without typographical errors?

Crocker                   Expires May 09, 2014                 [Page 26]

Internet-Draft                  dmarcops                   November 2013

          Did you include the "mailto:" prefix?

   2.  Is the domain in your rua and ruf address the same as the domain
       of your DMARC record?

          If not, did you follow the process to verify external
          destinations for data?  See section 6.2 [DMARC]. for details.

   3.  Check your email receiving infrastructure and mail logs for
       indications of problems receiving email.

          Are you accepting email with potentially large attachments?

          Do you need to whitelist any IP addresses?  Or are you
          checking DMARC on the incoming messages which may be failing?

8.2.  Report Analysis

8.2.1.  Data contained in DMARC reports

   For detailed descriptions on the meaning of different data fields in
   DMARC aggregate XML files please see the descriptions in subsections
   .1-.3 of Section 7.  For a description of the data contained in a
   failure report (see Section 7.4).  In order to move on to the
   analysis of DMARC data, it is important to understand what the report
   generator is telling you in each field.

8.2.2.  What should I look for first?

   There are many ways you can approach the analysis of DMARC data for
   your domain.  The approach you take will likely depend on what you
   already know about your domain's email sending and abuse of your
   domain.  It is recommended that in general you start with aggregate
   data.  Here are some suggestions on initial things to look for.

   o  Identify the number of sources (i.e. IP addresses) sending email
      using your From domain.  How many are there and how does that
      compare to your knowledge of your organization's email sending

   o  What is the daily volume of email messages (i.e. sum of all
      counts) sent using your From domain?  What is the volume from your
      known sources vs. those you did not know about?

   o  What is the daily volume that passed DMARC aligned SPF and DKIM?
      Passed only one but not the other?

Crocker                   Expires May 09, 2014                 [Page 27]

Internet-Draft                  dmarcops                   November 2013

   o  What is the daily volume of unauthenticated messages, those that
      failed both DMARC aligned SPF and DKIM?

   o  Are any previously unknown sources of email passing either or both
      of DMARC aligned SPF or DKIM?  If so why?

   o  What are all of these previously unknown sources of email using
      your From domain?

   As you analyze data and answer some of these questions, it will lead
   to deeper investigation.  At some point you will reach a limit to
   what you can learn from the aggregate data and likely need to look
   further using failure reports if they are available.  You may want to
   search for examples of failures coming from a particular IP address
   to understand what kind of messages are being sent.  With the From,
   Subject, and URLs in failure reports you may be able to identify
   specific phishing or spam campaigns using your domain.

   Once you have a good understanding of the current state of your
   domain's email you can use DMARC data to begin remediating problems
   and tracking the ongoing progress of your changes.  Depending on your
   domain's email characteristics your ultimate goal may be to publish
   DMARC reject policies or to simply continue collecting intelligence
   about your email.

8.2.3.  Investigating Anomalies in DMARC data

   When analyzing DMARC data you will likely come across results that
   you want to verify or understand better.  In some cases this is
   possible via further analysis of additional DMARC aggregate data
   fields.  In other cases it is helpful if you have failure reports to
   analyze.  A few examples of common things to explore are noted below.

   o  Some number of records will indicate that the authentication check
      (either SPF or DKIM) passed, yet the DMARC aligned value is a
      failure.  If you want to verify that these are all in fact due to
      misaligned identifiers you can query your data store to show a
      count of all such cases where the <spf><domain> or <dkim><domain>
      does not match or have a sub-domain match to the <header_from>.

   o  If your domain has a reject policy, you may want to check how many
      records have a <dkim> and <spf> value of "fail" in the
      <policy_evaluated> section, but do not have a <disposition> of
      "reject".  If that occurs it indicates a problem with the
      evaluation of your DMARC record.

   o  If a message that failed both DKIM and SPF is still delivered and
      your domain has a reject policy (you may know this if it is

Crocker                   Expires May 09, 2014                 [Page 28]

Internet-Draft                  dmarcops                   November 2013

      reported to you via customer complaint or from your own testing),
      before assuming receiver error you should check for local policy
      overrides (Section 7.3).  Try to identify records in DMARC data
      where the <disposition> is correctly designated as "reject", but a
      <reason><type> is indicated for the policy override.  This is not
      an error on the part of the receiver, but is allowable per the
      DMARC specification.

8.3.  Report Processing and Analysis Services

   Is it appropriate to point out here that there are vendor and 3rd
   party resources that can help with report receipt, processing, and
   analysis?  Of course specifics would not be mentioned here, but the
   document could point to the dmarc.org/resources page.  This could aid
   in making build vs. buy decisions.

8.4.  Additional concerns

      When can I expect to receive my first aggregate report?

      DMARC failure reports are not being received.

      Distinguishing mis-processing of DMARC versus local policy

9.  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}

10.  Interaction Issues

Crocker                   Expires May 09, 2014                 [Page 29]

Internet-Draft                  dmarcops                   November 2013

   Some issues come into play when DMARC is used in conjunction with one
   or more other services.

   o  Sender using both DMARC and ADSP.

11.  DMARC Commentary -- What were they thinking of...?

   This section explains a number of choices made for DMARC.

   Rationale for choosing ZIP for the aggregate reports:  {P. Midgen}
      primary consideration was increasing the amount of data that could
      be presented in a single message and avoiding report truncation
      (e.g. many folks limit inbound message size to 25MB). text
      compresses well in general, so we thought compression would make
      sense. // rather than compress at the transport layer (e.g. send a
      chunked/compressed stream over http) we thought email attachments
      were kinda braindead given the existing message-based feedback
      infrastructure (e.g. ndr, arf, etc.). // zip is everywhere, we
      needed to make no special consideration using it, and (i believe,
      but this needs checking) it is also a registered content-type
      (golden arrow of rationale leads back to "zip is everywhere").

   Why doesn't DMARC solve its problem with mailing lists/gatewats?  {P.
      This question typically refers to a set of well-known issues where
      messages transiting mailing list managers (MLMs), relays, or
      forwarders fail DKIM or SPF checks.

         As a first principle, solving common operational issues in
         underlying authentication mechanisms is out of scope for DMARC.

      The recommendation is for senders to use both SPF and DKIM, since
      we know from research conducted during draft development that the
      likelihood of simultaneous SPF & DKIM failure, while possible, is
      far less common than individual failures.

      Senders are encouraged to use both SPF & DKIM to ensure robust
      operation of DMARC and to pave the way for future technologies
      that will benefit from broad adoption of email authentication,
      such as domain reputation.

      This question also refers to the issue of expanding the set of
      alignable authenticated identities under DMARC.  At the moment
      DMARC looks at the rfc5321.MailFrom (a/k/a envelope sender or
      return-path) for SPF, and the d= field in the message's DKIM-
      Signature block(s), and attempts to align them with the
      rfc5322.From domain since this in the majority of cases is
      displayed to the message recipient by the MUA.

Crocker                   Expires May 09, 2014                 [Page 30]

Internet-Draft                  dmarcops                   November 2013

      The import of that consideration can be argued, but we universally
      felt it was important because it is such a common practice and
      because we are able in majority of cases representing a high
      volume of mail to authenticate and align identities with

         There is no standardized practice for authenticating against
         the Sender or other identity sources, it is out of scope for
         DMARC to do so and until there exists a reliable and reasonably
         well-adopted mechanism that does so, DMARC will rely on the
         envelope and body From identities.

      As a final statement on this issue, it is worth reiterating the
      role of local policy in the determination of message disposition.
      In a sense SPF and DKIM serve to inform local policy mechanisms on
      the disposition of authenticated mail.  DMARC carries that
      tradition forward, but at the end of the day it is a matter of
      local policy whether to act on the suggestions of authentication
      and policy mechanisms or simply mark the message and move it
      further down the delivery pipeline.

   Who is the target audience for the DMARC specification?  {P. Midgen}

      DMARC is intended for submission to become an IETF standard; in a
      sense this means the intended audience is the entire internet and
      email community.  That said, it isn't for everyone.  We believe
      DMARC does four important things:

      1.  Provides a method for uniform evaluation of the authentication
          results generated by standard and well-deployed email
          authentication mechanisms against a common set of identities.

      2.  Provides a reporting mechanism allowing senders to understand
          the performance of their email authentication practices, and
          get an idea of the IPs sending email on behalf of their

      3.  Provides a deterministic policy mechanism allowing the sender
          to tell the receiver how to dispose of their email in the
          event the policy conditions aren't met.

      4.  It achieves this sender/receiver communication via DNS, at
          Internet scale.

      We figured most folks would find 1, 2 and 4 appealing; everyone
      likes information and even more so if it is obtained easily and at
      low risk.  Number 3 is more tricky: under what circumstances
      should a sender publish anything other than p=none?  This depends

Crocker                   Expires May 09, 2014                 [Page 31]

Internet-Draft                  dmarcops                   November 2013

      on a huge number of variables and there is no if-then-else type of
      guideline.  Here are some of the things to consider:

      1.  Are your domains used fraudulently?  DMARC will help curb
          fraudulent use of your organizational domain and subdomains.
          It will not stop homograph/cousin domain abuse (e.g.
          fac3book.com), and it will not stop domain-padding (e.g.
          facebook.superbaddudes.junkyjunkjunkorama1234.com) abuse.

      2.  Are you an ISP, MBP, or EDU?  Your users tend to move around,
          have multiple accounts, forward messages and do other things
          that increase the possibility for a DMARC false positive.
          You, even more so than everyone else, will want to start with
          a monitor-only policy so you can model the what-ifs.

      3.  Do you send mostly transactional, point-to-point mail (e.g.
          account statements, password resets, etc.)?  These are good
          candidates for DMARC since our observation has been that these
          tend to be low risk of failure.

12.  Privacy Considerations. {T. Adams}

   NOTE:    Capitalized terms related to privacy used in this section
      are consistent with the "Guidelines on the Protection of Privacy
      and Transborder Flows of Personal Data" published in 1980 (and
      subsequently reviewed in 2011) by the Organisation for Economic
      Co-operation and Development (OECD).

   Each of the two DMARC feedback reports have different characteristics
   related to privacy based on their design.  Aggregate Reports (RUA)
   are sent by a receiver at periodic intervals (e.g. daily) and contain
   summary data regarding the number and type of email messages that are
   processed in relation to the domain owner's DMARC policy.  As such,
   they do not contain Personal Data and are considered to have no
   impact on privacy.

   The one identified exception to this is when an individual (a.k.a. "a
   Natural Person with legal rights") is operating his or her own email
   server.  In this case, the IP address of the sending server reported
   in the RUA may identify the individual and thus be classified as
   Personal Data in some jurisdictions.

Crocker                   Expires May 09, 2014                 [Page 32]

Internet-Draft                  dmarcops                   November 2013

   Failure Reports (RUF), on the other hand, are sent by an email
   receiver each time an email message being processed fails the DMARC
   authentication checks.  The RUF may include Personal Data as well as
   Sensitive Data, depending on the applicable regulatory jurisdiction.
   When supporting RUF reports, an email receiver should consider
   whether or not to include the full content of the unauthenticated
   email, as well as what email header fields to redact.

   As part of this consideration, the email receiver will need to
   understand its roll in the flow of Personal Data.  For example, the
   domain owner can be viewed as the Data Controller for email sent
   under its aegis as is the case for email sent from the servers of a
   company by its employees or transactional systems.  In this case, the
   email receiver is the Data Processor acting on behalf of the Data
   Controller, and as such the legal responsibility for protection of
   the data rests with the domain owner.  Thus, legitimate mail that
   inadvertently fails the DMARC authorization checks (e.g. if the email
   was handled by mailing list management software acting as an
   Intermediary Processor) is clearly handled by this case.

   The primary area of debate about privacy and RUF reporting revolves
   around the protections offered to the individual (i.e. the "bad
   actor") who sends fraudulent email purporting to be from another
   domain.  Specifically, should the bad actor be protected by privacy
   regulations within the applicable jurisdiction?  Within the context
   of current regulatory guidance, it is possible to view the email
   receiver as the Data Processor on behalf of the bad actor, who is
   filling the role of Data Controller.  It is an open question only
   insofar as what to do about this bad actor who is clearly not
   participating in the data flow in good faith.

   Given that there is significant value in quickly identifying bad
   actors, and taking appropriate enforcement action, it is worth
   exploring how to clarify that existing data sharing regulations allow
   RUF reports.  In any case, both the email receiver (as the report
   generator) and the domain owner (as the report recipient) should
   ensure that the appropriate operational policies are in place to
   protect the Personal Data being handled as dictated by their part of
   the data flow.

      IP Addresses in reports

13.  Security Considerations

   In this section we describe several security considerations related
   to the implementation of the DMARC protocol.

Crocker                   Expires May 09, 2014                 [Page 33]

Internet-Draft                  dmarcops                   November 2013

   1.  The authors see DNS as a potential abuse target.  According to
       the DMARC specification, mail receivers read the DMARC policy
       from the corresponding DNS txt record.  Theoretically a wrong or
       malicious implementation might result in multiple DNS queries per
       message, resulting in a DoS attack on DNS.  Such an attack is
       unlikely to happen; not only is it expensive, the same result can
       be achieved by simpler means.  To avoid causing accidental DNS
       DoS attacks, implementers consider using a DNS cache. {O.

   2.  The authors see the volume of aggregated reports generated by
       other hosts as potential for abuse.  Sending a large volume of
       reports could constitute a DoS attack on the sender domain.  Such
       an attack is also expensive and more theoretical than practical.
       Nevertheless, to protect against this type of abuse, one should
       publish a _reports._dmarc DNS txt record to restrict malicious
       domains from redirecting their aggregate reports to an abuse
       target.  Another related potential risk is excessively large
       aggregate reports that could be damaging to the recipient, though
       the same abuse affect can be achieved without the DMARC protocol.
       The majority of mail recipients enforce message size limits. {O.

   [Original listing of issues]

   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

         If Org Domain policy lookups are required, you may get two
         lookups every time there is a single lookup

14.  References

14.1.  References - Normative

   [DMARC]    Kucherawy, M., Ed., "Domain-based Message Authentication,
              Reporting and Conformance (DMARC)", URL https://
              March 2013.

14.2.  References - Informative

Crocker                   Expires May 09, 2014                 [Page 34]

Internet-Draft                  dmarcops                   November 2013

   [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

Appendix A.  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

   Dave Crocker (editor)
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086

   Phone: +1.408.246.8253
   Email: dcrocker@bbiw.net

Crocker                   Expires May 09, 2014                 [Page 35]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/