tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7489

 
 
 

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Part 3 of 4, p. 28 to 49
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 28 
7.  DMARC Feedback

   Providing Domain Owners with visibility into how Mail Receivers
   implement and enforce the DMARC mechanism in the form of feedback is
   critical to establishing and maintaining accurate authentication
   deployments.  When Domain Owners can see what effect their policies
   and practices are having, they are better willing and able to use
   quarantine and reject policies.

7.1.  Verifying External Destinations

   It is possible to specify destinations for the different reports that
   are outside the authority of the Domain Owner making the request.
   This allows domains that do not operate mail servers to request
   reports and have them go someplace that is able to receive and
   process them.

   Without checks, this would allow a bad actor to publish a DMARC
   policy record that requests that reports be sent to a victim address,
   and then send a large volume of mail that will fail both DKIM and SPF
   checks to a wide variety of destinations; the victim will in turn be
   flooded with unwanted reports.  Therefore, a verification mechanism
   is included.

   When a Mail Receiver discovers a DMARC policy in the DNS, and the
   Organizational Domain at which that record was discovered is not
   identical to the Organizational Domain of the host part of the
   authority component of a [URI] specified in the "rua" or "ruf" tag,
   the following verification steps are to be taken:

   1.  Extract the host portion of the authority component of the URI.
       Call this the "destination host", as it refers to a Report
       Receiver.

   2.  Prepend the string "_report._dmarc".

Top      Up      ToC       Page 29 
   3.  Prepend the domain name from which the policy was retrieved,
       after conversion to an A-label if needed.

   4.  Query the DNS for a TXT record at the constructed name.  If the
       result of this request is a temporary DNS error of some kind
       (e.g., a timeout), the Mail Receiver MAY elect to temporarily
       fail the delivery so the verification test can be repeated later.

   5.  For each record returned, parse the result as a series of
       "tag=value" pairs, i.e., the same overall format as the policy
       record (see Section 6.4).  In particular, the "v=DMARC1" tag is
       mandatory and MUST appear first in the list.  Discard any that do
       not pass this test.

   6.  If the result includes no TXT resource records that pass basic
       parsing, a positive determination of the external reporting
       relationship cannot be made; stop.

   7.  If at least one TXT resource record remains in the set after
       parsing, then the external reporting arrangement was authorized
       by the Report Receiver.

   8.  If a "rua" or "ruf" tag is thus discovered, replace the
       corresponding value extracted from the domain's DMARC policy
       record with the one found in this record.  This permits the
       Report Receiver to override the report destination.  However, to
       prevent loops or indirect abuse, the overriding URI MUST use the
       same destination host from the first step.

   For example, if a DMARC policy query for "blue.example.com" contained
   "rua=mailto:reports@red.example.net", the host extracted from the
   latter ("red.example.net") does not match "blue.example.com", so this
   procedure is enacted.  A TXT query for
   "blue.example.com._report._dmarc.red.example.net" is issued.  If a
   single reply comes back containing a tag of "v=DMARC1", then the
   relationship between the two is confirmed.  Moreover,
   "red.example.net" has the opportunity to override the report
   destination requested by "blue.example.com" if needed.

   Where the above algorithm fails to confirm that the external
   reporting was authorized by the Report Receiver, the URI MUST be
   ignored by the Mail Receiver generating the report.  Further, if the
   confirming record includes a URI whose host is again different than
   the domain publishing that override, the Mail Receiver generating the
   report MUST NOT generate a report to either the original or the
   override URI.

Top      Up      ToC       Page 30 
   A Report Receiver publishes such a record in its DNS if it wishes to
   receive reports for other domains.

   A Report Receiver that is willing to receive reports for any domain
   can use a wildcard DNS record.  For example, a TXT resource record at
   "*._report._dmarc.example.com" containing at least "v=DMARC1"
   confirms that example.com is willing to receive DMARC reports for any
   domain.

   If the Report Receiver is overcome by volume, it can simply remove
   the confirming DNS record.  However, due to positive caching, the
   change could take as long as the time-to-live (TTL) on the record to
   go into effect.

   A Mail Receiver might decide not to enact this procedure if, for
   example, it relies on a local list of domains for which external
   reporting addresses are permitted.

7.2.  Aggregate Reports

   The DMARC aggregate feedback report is designed to provide Domain
   Owners with precise insight into:

   o  authentication results,

   o  corrective action that needs to be taken by Domain Owners, and

   o  the effect of Domain Owner DMARC policy on email streams processed
      by Mail Receivers.

   Aggregate DMARC feedback provides visibility into real-world email
   streams that Domain Owners need to make informed decisions regarding
   the publication of DMARC policy.  When Domain Owners know what
   legitimate mail they are sending, what the authentication results are
   on that mail, and what forged mail receivers are getting, they can
   make better decisions about the policies they need and the steps they
   need to take to enable those policies.  When Domain Owners set
   policies appropriately and understand their effects, Mail Receivers
   can act on them confidently.

   Visibility comes in the form of daily (or more frequent) Mail
   Receiver-originated feedback reports that contain aggregate data on
   message streams relevant to the Domain Owner.  This information
   includes data about messages that passed DMARC authentication as well
   as those that did not.

   The format for these reports is defined in Appendix C.

Top      Up      ToC       Page 31 
   The report SHOULD include the following data:

   o  The DMARC policy discovered and applied, if any

   o  The selected message disposition

   o  The identifier evaluated by SPF and the SPF result, if any

   o  The identifier evaluated by DKIM and the DKIM result, if any

   o  For both DKIM and SPF, an indication of whether the identifier was
      in alignment

   o  Data for each Domain Owner's subdomain separately from mail from
      the sender's Organizational Domain, even if there is no explicit
      subdomain policy

   o  Sending and receiving domains

   o  The policy requested by the Domain Owner and the policy actually
      applied (if different)

   o  The number of successful authentications

   o  The counts of messages based on all messages received, even if
      their delivery is ultimately blocked by other filtering agents

   Note that Domain Owners or their agents may change the published
   DMARC policy for a domain or subdomain at any time.  From a Mail
   Receiver's perspective, this will occur during a reporting period and
   may be noticed during that period, at the end of that period when
   reports are generated, or during a subsequent reporting period, all
   depending on the Mail Receiver's implementation.  Under these
   conditions, it is possible that a Mail Receiver could do any of the
   following:

   o  generate for such a reporting period a single aggregate report
      that includes message dispositions based on the old policy, or a
      mix of the two policies, even though the report only contains a
      single "policy_published" element;

   o  generate multiple reports for the same period, one for each
      published policy occurring during the reporting period;

   o  generate a report whose end time occurs when the updated policy
      was detected, regardless of any requested report interval.

Top      Up      ToC       Page 32 
   Such policy changes are expected to be infrequent for any given
   domain, whereas more stringent policy monitoring requirements on the
   Mail Receiver would produce a very large burden at Internet scale.
   Therefore, it is the responsibility of report consumers and Domain
   Owners to be aware of this situation and allow for such mixed reports
   during the propagation of the new policy to Mail Receivers.

   Aggregate reports are most useful when they all cover a common time
   period.  By contrast, correlation of these reports from multiple
   generators when they cover incongruent time periods is difficult or
   impossible.  Report generators SHOULD, wherever possible, adhere to
   hour boundaries for the reporting period they are using.  For
   example, starting a per-day report at 00:00; starting per-hour
   reports at 00:00, 01:00, 02:00; etc.  Report generators using a
   24-hour report period are strongly encouraged to begin that period at
   00:00 UTC, regardless of local timezone or time of report production,
   in order to facilitate correlation.

   A Mail Receiver discovers reporting requests when it looks up a DMARC
   policy record that corresponds to an RFC5322.From domain on received
   mail.  The presence of the "rua" tag specifies where to send
   feedback.

7.2.1.  Transport

   Where the URI specified in a "rua" tag does not specify otherwise, a
   Mail Receiver generating a feedback report SHOULD employ a secure
   transport mechanism.

   The Mail Receiver, after preparing a report, MUST evaluate the
   provided reporting URIs in the order given.  Any reporting URI that
   includes a size limitation exceeded by the generated report (after
   compression and after any encoding required by the particular
   transport mechanism) MUST NOT be used.  An attempt MUST be made to
   deliver an aggregate report to every remaining URI, up to the
   Receiver's limits on supported URIs.

   If transport is not possible because the services advertised by the
   published URIs are not able to accept reports (e.g., the URI refers
   to a service that is unreachable, or all provided URIs specify size
   limits exceeded by the generated record), the Mail Receiver SHOULD
   send a short report (see Section 7.2.2) indicating that a report is
   available but could not be sent.  The Mail Receiver MAY cache that
   data and try again later, or MAY discard data that could not be sent.

Top      Up      ToC       Page 33 
7.2.1.1.  Email

   The message generated by the Mail Receiver MUST be a [MAIL] message
   formatted per [MIME].  The aggregate report itself MUST be included
   in one of the parts of the message.  A human-readable portion MAY be
   included as a MIME part (such as a text/plain part).

   The aggregate data MUST be an XML file that SHOULD be subjected to
   GZIP compression.  Declining to apply compression can cause the
   report to be too large for a receiver to process (a commonly observed
   receiver limit is ten megabytes); doing the compression increases the
   chances of acceptance of the report at some compute cost.  The
   aggregate data SHOULD be present using the media type "application/
   gzip" if compressed (see [GZIP]), and "text/xml" otherwise.  The
   filename is typically constructed using the following ABNF:

     filename = receiver "!" policy-domain "!" begin-timestamp
                "!" end-timestamp [ "!" unique-id ] "." extension

     unique-id = 1*(ALPHA / DIGIT)

     receiver = domain
                ; imported from [MAIL]

     policy-domain   = domain

     begin-timestamp = 1*DIGIT
                       ; seconds since 00:00:00 UTC January 1, 1970
                       ; indicating start of the time range contained
                       ; in the report

     end-timestamp = 1*DIGIT
                     ; seconds since 00:00:00 UTC January 1, 1970
                     ; indicating end of the time range contained
                     ; in the report

     extension = "xml" / "xml.gz"

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

Top      Up      ToC       Page 34 
   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

     mail.receiver.example!example.com!1013662812!1013749130.gz

   No specific MIME message structure is required.  It is presumed that
   the aggregate reporting address will be equipped to extract MIME
   parts with the prescribed media type and filename and ignore the
   rest.

   Email streams carrying DMARC feedback data MUST conform to the DMARC
   mechanism, thereby resulting in an aligned "pass" (see Section 3.1).
   This practice minimizes the risk of report consumers processing
   fraudulent reports.

   The RFC5322.Subject field for individual report submissions SHOULD
   conform to the following ABNF:

     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     msg-id                          ; from RFC 5322

   The first domain-name indicates the DNS domain name about which the
   report was generated.  The second domain-name indicates the DNS
   domain name representing the Mail Receiver generating the report.
   The purpose of the Report-ID: portion of the field is to enable the
   Domain Owner to identify and ignore duplicate reports that might be
   sent by a Mail Receiver.

   For instance, this is a possible Subject field for a report to the
   Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example".  It is line-wrapped as allowed by [MAIL]:

     Subject: Report Domain: example.com
         Submitter: mail.receiver.example
         Report-ID: <2002.02.15.1>

   This transport mechanism potentially encounters a problem when
   feedback data size exceeds maximum allowable attachment sizes for
   either the generator or the consumer.  See Section 7.2.2 for further
   discussion.

Top      Up      ToC       Page 35 
7.2.1.2.  Other Methods

   The specification as written allows for the addition of other
   registered URI schemes to be supported in later versions.

7.2.2.  Error Reports

   When a Mail Receiver is unable to complete delivery of a report via
   any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD
   generate an error message.  An attempt MUST be made to send this
   report to all listed "mailto" URIs, and it MAY also be sent to any or
   all other listed URIs.

   The error report MUST be formatted per [MIME].  A text/plain part
   MUST be included that contains field-value pairs such as those found
   in Section 2 of [DSN].  The fields required, which may appear in any
   order, are as follows:

   Report-Date:  A [MAIL]-formatted date expression indicating when the
      transport failure occurred.

   Report-Domain:  The domain-name about which the failed report was
      generated.

   Report-ID:  The Report-ID: that the report tried to use.

   Report-Size:  The size, in bytes, of the report that was unable to be
      sent.  This MUST represent the number of bytes that the Mail
      Receiver attempted to send.  Where more than one transport system
      was attempted, the sizes may be different; in such cases, separate
      error reports MUST be generated so that this value matches the
      actual attempt that was made.

   Submitter:  The domain-name representing the Mail Receiver that
      generated, but was unable to submit, the report.

   Submitting-URI:  The URI(s) to which the Mail Receiver tried, but
      failed, to submit the report.

   An additional text/plain part MAY be included that gives a human-
   readable explanation of the above and MAY also include a URI that can
   be used to seek assistance.

Top      Up      ToC       Page 36 
7.3.  Failure Reports

   Failure reports are normally generated and sent almost immediately
   after the Mail Receiver detects a DMARC failure.  Rather than waiting
   for an aggregate report, these reports are useful for quickly
   notifying the Domain Owners when there is an authentication failure.
   Whether the failure is due to an infrastructure problem or the
   message is inauthentic, failure reports also provide more information
   about the failed message than is available in an aggregate report.

   These reports SHOULD include any URI(s) from the message that failed
   authentication.  These reports SHOULD include as much of the message
   and message header as is reasonable to support the Domain Owner's
   investigation into what caused the message to fail authentication and
   track down the sender.

   When a Domain Owner requests failure reports for the purpose of
   forensic analysis, and the Mail Receiver is willing to provide such
   reports, the Mail Receiver generates and sends a message using the
   format described in [AFRF]; this document updates that reporting
   format, as described in Section 7.3.1.

   The destination(s) and nature of the reports are defined by the "ruf"
   and "fo" tags as defined in Section 6.3.

   Where multiple URIs are selected to receive failure reports, the
   report generator MUST make an attempt to deliver to each of them.

   An obvious consideration is the denial-of-service attack that can be
   perpetrated by an attacker who sends numerous messages purporting to
   be from the intended victim Domain Owner but that fail both SPF and
   DKIM; this would cause participating Mail Receivers to send failure
   reports to the Domain Owner or its delegate in potentially huge
   volumes.  Accordingly, participating Mail Receivers are encouraged to
   aggregate these reports as much as is practical, using the Incidents
   field of the Abuse Reporting Format ([ARF]).  Various aggregation
   techniques are possible, including the following:

   o  only send a report to the first recipient of multi-recipient
      messages;

   o  store reports for a period of time before sending them, allowing
      detection, collection, and reporting of like incidents;

   o  apply rate limiting, such as a maximum number of reports per
      minute that will be generated (and the remainder discarded).

Top      Up      ToC       Page 37 
7.3.1.  Reporting Format Update

   Operators implementing this specification also implement an augmented
   version of [AFRF] as follows:

   1.  A DMARC failure report includes the following ARF header fields,
       with the indicated normative requirement levels:

       *  Identity-Alignment (REQUIRED; defined below)

       *  Delivery-Result (OPTIONAL)

       *  DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the
          message was signed by DKIM)

       *  DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL
          if the message was signed by DKIM)

       *  SPF-DNS (REQUIRED)

   2.  The "Identity-Alignment" field is defined to contain a comma-
       separated list of authentication mechanism names that produced an
       aligned identity, or the keyword "none" if none did.  ABNF:

     id-align     = "Identity-Alignment:" [CFWS]
                    ( "none" /
                      dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
                    [CFWS]

     dmarc-method = ( "dkim" / "spf" )
                    ; each may appear at most once in an id-align

   3.  Authentication Failure Type "dmarc" is defined, which is to be
       used when a failure report is generated because some or all of
       the authentication mechanisms failed to produce aligned
       identifiers.  Note that a failure report generator MAY also
       independently produce an AFRF message for any or all of the
       underlying authentication methods.

8.  Minimum Implementations

   A minimum implementation of DMARC has the following characteristics:

   o  Is able to send and/or receive reports at least daily;

   o  Is able to send and/or receive reports using "mailto" URIs;

Top      Up      ToC       Page 38 
   o  Other than in exceptional circumstances such as resource
      exhaustion, can generate or accept a report up to ten megabytes in
      size;

   o  If acting as a Mail Receiver, fully implements the provisions of
      Section 6.6.

9.  Privacy Considerations

   This section discusses security issues specific to private data that
   may be included in the interactions that are part of DMARC.

9.1.  Data Exposure Considerations

   Aggregate reports are limited in scope to DMARC policy and
   disposition results, to information pertaining to the underlying
   authentication mechanisms, and to the identifiers involved in DMARC
   validation.

   Failed-message reporting provides message-specific details pertaining
   to authentication failures.  Individual reports can contain message
   content as well as trace header fields.  Domain Owners are able to
   analyze individual reports and attempt to determine root causes of
   authentication mechanism failures, gain insight into
   misconfigurations or other problems with email and network
   infrastructure, or inspect messages for insight into abusive
   practices.

   Both report types may expose sender and recipient identifiers (e.g.,
   RFC5322.From addresses), and although the [AFRF] format used for
   failed-message reporting supports redaction, failed-message reporting
   is capable of exposing the entire message to the report recipient.

   Domain Owners requesting reports will receive information about mail
   claiming to be from them, which includes mail that was not, in fact,
   from them.  Information about the final destination of mail where it
   might otherwise be obscured by intermediate systems will therefore be
   exposed.

   When message-forwarding arrangements exist, Domain Owners requesting
   reports will also receive information about mail forwarded to domains
   that were not originally part of their messages' recipient lists.
   This means that destination domains previously unknown to the Domain
   Owner may now become visible.

   Disclosure of information about the messages is being requested by
   the entity generating the email in the first place, i.e., the Domain
   Owner and not the Mail Receiver, so this may not fit squarely within

Top      Up      ToC       Page 39 
   existing privacy policy provisions.  For some providers, aggregate
   reporting and failed-message reporting are viewed as a function
   similar to complaint reporting about spamming or phishing and are
   treated similarly under the privacy policy.  Report generators (i.e.,
   Mail Receivers) are encouraged to review their reporting limitations
   under such policies before enabling DMARC reporting.

9.2.  Report Recipients

   A DMARC record can specify that reports should be sent to an
   intermediary operating on behalf of the Domain Owner.  This is done
   when the Domain Owner contracts with an entity to monitor mail
   streams for abuse and performance issues.  Receipt by third parties
   of such data may or may not be permitted by the Mail Receiver's
   privacy policy, terms of use, or other similar governing document.
   Domain Owners and Mail Receivers should both review and understand if
   their own internal policies constrain the use and transmission of
   DMARC reporting.

   Some potential exists for report recipients to perform traffic
   analysis, making it possible to obtain metadata about the Receiver's
   traffic.  In addition to verifying compliance with policies,
   Receivers need to consider that before sending reports to a third
   party.

10.  Other Topics

   This section discusses some topics regarding choices made in the
   development of DMARC, largely to commit the history to record.

10.1.  Issues Specific to SPF

   Though DMARC does not inherently change the semantics of an SPF
   policy record, historically lax enforcement of such policies has led
   many to publish extremely broad records containing many large network
   ranges.  Domain Owners are strongly encouraged to carefully review
   their SPF records to understand which networks are authorized to send
   on behalf of the Domain Owner before publishing a DMARC record.

   Some receiver architectures might implement SPF in advance of any
   DMARC operations.  This means that a "-" prefix on a sender's SPF
   mechanism, such as "-all", could cause that rejection to go into
   effect early in handling, causing message rejection before any DMARC
   processing takes place.  Operators choosing to use "-all" should be
   aware of this.

Top      Up      ToC       Page 40 
10.2.  DNS Load and Caching

   DMARC policies are communicated using the DNS and therefore inherit a
   number of considerations related to DNS caching.  The inherent
   conflict between freshness and the impact of caching on the reduction
   of DNS-lookup overhead should be considered from the Mail Receiver's
   point of view.  Should Domain Owners publish a DNS record with a very
   short TTL, Mail Receivers can be provoked through the injection of
   large volumes of messages to overwhelm the Domain Owner's DNS.
   Although this is not a concern specific to DMARC, the implications of
   a very short TTL should be considered when publishing DMARC policies.

   Conversely, long TTLs will cause records to be cached for long
   periods of time.  This can cause a critical change to DMARC
   parameters advertised by a Domain Owner to go unnoticed for the
   length of the TTL (while waiting for DNS caches to expire).  Avoiding
   this problem can mean shorter TTLs, with the potential problems
   described above.  A balance should be sought to maintain
   responsiveness of DMARC preference changes while preserving the
   benefits of DNS caching.

10.3.  Rejecting Messages

   This proposal calls for rejection of a message during the SMTP
   session under certain circumstances.  This is preferable to
   generation of a Delivery Status Notification ([DSN]), since
   fraudulent messages caught and rejected using DMARC would then result
   in annoying generation of such failure reports that go back to the
   RFC5321.MailFrom address.

   This synchronous rejection is typically done in one of two ways:

   o  Full rejection, wherein the SMTP server issues a 5xy reply code as
      an indication to the SMTP client that the transaction failed; the
      SMTP client is then responsible for generating notification that
      delivery failed (see Section 4.2.5 of [SMTP]).

   o  A "silent discard", wherein the SMTP server returns a 2xy reply
      code implying to the client that delivery (or, at least, relay)
      was successfully completed, but then simply discarding the message
      with no further action.

   Each of these has a cost.  For instance, a silent discard can help to
   prevent backscatter, but it also effectively means that the SMTP
   server has to be programmed to give a false result, which can
   confound external debugging efforts.

Top      Up      ToC       Page 41 
   Similarly, the text portion of the SMTP reply may be important to
   consider.  For example, when rejecting a message, revealing the
   reason for the rejection might give an attacker enough information to
   bypass those efforts on a later attempt, though it might also assist
   a legitimate client to determine the source of some local issue that
   caused the rejection.

   In the latter case, when doing an SMTP rejection, providing a clear
   hint can be useful in resolving issues.  A receiver might indicate in
   plain text the reason for the rejection by using the word "DMARC"
   somewhere in the reply text.  Many systems are able to scan the SMTP
   reply text to determine the nature of the rejection.  Thus, providing
   a machine-detectable reason for rejection allows the problems causing
   rejections to be properly addressed by automated systems.  For
   example:

       550 5.7.1 Email rejected per DMARC policy for example.com

   If a Mail Receiver elects to defer delivery due to inability to
   retrieve or apply DMARC policy, this is best done with a 4xy SMTP
   reply code.

10.4.  Identifier Alignment Considerations

   The DMARC mechanism allows both DKIM and SPF-authenticated
   identifiers to authenticate email on behalf of a Domain Owner and,
   possibly, on behalf of different subdomains.  If malicious or unaware
   users can gain control of the SPF record or DKIM selector records for
   a subdomain, the subdomain can be used to generate DMARC-passing
   email on behalf of the Organizational Domain.

   For example, an attacker who controls the SPF record for
   "evil.example.com" can send mail with an RFC5322.From field
   containing "foo@example.com" that can pass both authentication and
   the DMARC check against "example.com".

   The Organizational Domain administrator should be careful not to
   delegate control of subdomains if this is an issue, and to consider
   using the "strict" Identifier Alignment option if appropriate.

10.5.  Interoperability Issues

   DMARC limits which end-to-end scenarios can achieve a "pass" result.

   Because DMARC relies on [SPF] and/or [DKIM] to achieve a "pass",
   their limitations also apply.

Top      Up      ToC       Page 42 
   Additional DMARC constraints occur when a message is processed by
   some Mediators, such as mailing lists.  Transiting a Mediator often
   causes either the authentication to fail or Identifier Alignment to
   be lost.  These transformations may conform to standards but will
   still prevent a DMARC "pass".

   In addition to Mediators, mail that is sent by authorized,
   independent third parties might not be sent with Identifier
   Alignment, also preventing a "pass" result.

   Issues specific to the use of policy mechanisms alongside DKIM are
   further discussed in [DKIM-LISTS], particularly Section 5.2.

11.  IANA Considerations

   This section describes actions completed by IANA.

11.1.  Authentication-Results Method Registry Update

   IANA has added the following to the "Email Authentication Methods"
   registry:

   Method:  dmarc

   Defined:  RFC 7489

   ptype:  header

   Property:  from

   Value:  the domain portion of the RFC5322.From field

   Status:  active

   Version:  1

11.2.  Authentication-Results Result Registry Update

   IANA has added the following in the "Email Authentication Result
   Names" registry:

   Code:  none

   Existing/New Code:  existing

   Defined:  [AUTH-RESULTS]

   Auth Method:  dmarc (added)

Top      Up      ToC       Page 43 
   Meaning:  No DMARC policy record was published for the aligned
      identifier, or no aligned identifier could be extracted.

   Status:  active


   Code:  pass

   Existing/New Code:  existing

   Defined:  [AUTH-RESULTS]

   Auth Method:  dmarc (added)

   Meaning:  A DMARC policy record was published for the aligned
      identifier, and at least one of the authentication mechanisms
      passed.

   Status:  active


   Code:  fail

   Existing/New Code:  existing

   Defined:  [AUTH-RESULTS]

   Auth Method:  dmarc (added)

   Meaning:  A DMARC policy record was published for the aligned
      identifier, and none of the authentication mechanisms passed.

   Status:  active


   Code:  temperror

   Existing/New Code:  existing

   Defined:  [AUTH-RESULTS]

   Auth Method:  dmarc (added)

   Meaning:  A temporary error occurred during DMARC evaluation.  A
      later attempt might produce a final result.

   Status:  active

Top      Up      ToC       Page 44 
   Code:  permerror

   Existing/New Code:  existing

   Defined:  [AUTH-RESULTS]

   Auth Method:  dmarc (added)

   Meaning:  A permanent error occurred during DMARC evaluation, such as
      encountering a syntactically incorrect DMARC record.  A later
      attempt is unlikely to produce a final result.

   Status:  active

11.3.  Feedback Report Header Fields Registry Update

   The following has been added to the "Feedback Report Header Fields"
   registry:

   Field Name:  Identity-Alignment

   Description:  indicates whether the message about which a report is
      being generated had any identifiers in alignment as defined in
      RFC 7489

   Multiple Appearances:  No

   Related "Feedback-Type":  auth-failure

   Reference:  RFC 7489

   Status:  current

11.4.  DMARC Tag Registry

   A new registry tree called "Domain-based Message Authentication,
   Reporting, and Conformance (DMARC) Parameters" has been created.
   Within it, a new sub-registry called the "DMARC Tag Registry" has
   been created.

   Names of DMARC tags must be registered with IANA in this new
   sub-registry.  New entries are assigned only for values that have
   been documented in a manner that satisfies the terms of Specification
   Required, per [IANA-CONSIDERATIONS].  Each registration must include
   the tag name; the specification that defines it; a brief description;
   and its status, which must be one of "current", "experimental", or
   "historic".  The Designated Expert needs to confirm that the provided

Top      Up      ToC       Page 45 
   specification adequately describes the new tag and clearly presents
   how it would be used within the DMARC context by Domain Owners and
   Mail Receivers.

   To avoid version compatibility issues, tags added to the DMARC
   specification are to avoid changing the semantics of existing records
   when processed by implementations conforming to prior specifications.

   The initial set of entries in this registry is as follows:

    +----------+-------------+---------+------------------------------+
    | Tag Name | Reference   | Status  | Description                  |
    +----------+-------------+---------+------------------------------+
    |  adkim   |  RFC 7489   | current | DKIM alignment mode          |
    +----------+-------------+---------+------------------------------+
    |   aspf   |  RFC 7489   | current | SPF alignment mode           |
    +----------+-------------+---------+------------------------------+
    |    fo    |  RFC 7489   | current | Failure reporting options    |
    +----------+-------------+---------+------------------------------+
    |     p    |  RFC 7489   | current | Requested handling policy    |
    +----------+-------------+---------+------------------------------+
    |    pct   |  RFC 7489   | current | Sampling rate                |
    +----------+-------------+---------+------------------------------+
    |    rf    |  RFC 7489   | current | Failure reporting format(s)  |
    +----------+-------------+---------+------------------------------+
    |    ri    |  RFC 7489   | current | Aggregate Reporting interval |
    +----------+-------------+---------+------------------------------+
    |    rua   |  RFC 7489   | current | Reporting URI(s) for         |
    |          |             |         | aggregate data               |
    +----------+-------------+---------+------------------------------+
    |    ruf   |  RFC 7489   | current | Reporting URI(s) for         |
    |          |             |         | failure data                 |
    +----------+-------------+---------+------------------------------+
    |    sp    |  RFC 7489   | current | Requested handling policy    |
    |          |             |         | for subdomains               |
    +----------+-------------+---------+------------------------------+
    |     v    |  RFC 7489   | current | Specification version        |
    +----------+-------------+---------+------------------------------+

11.5.  DMARC Report Format Registry

   Also within "Domain-based Message Authentication, Reporting, and
   Conformance (DMARC) Parameters", a new sub-registry called "DMARC
   Report Format Registry" has been created.

   Names of DMARC failure reporting formats must be registered with IANA
   in this registry.  New entries are assigned only for values that
   satisfy the definition of Specification Required, per

Top      Up      ToC       Page 46 
   [IANA-CONSIDERATIONS].  In addition to a reference to a permanent
   specification, each registration must include the format name; a
   brief description; and its status, which must be one of "current",
   "experimental", or "historic".  The Designated Expert needs to
   confirm that the provided specification adequately describes the
   report format and clearly presents how it would be used within the
   DMARC context by Domain Owners and Mail Receivers.

   The initial entry in this registry is as follows:

    +--------+-------------+---------+-----------------------------+
    | Format | Reference   | Status  | Description                 |
    |  Name  |             |         |                             |
    +--------+-------------+---------+-----------------------------+
    | afrf   |  RFC 7489   | current | Authentication Failure      |
    |        |             |         | Reporting Format (see       |
    |        |             |         | [AFRF])                     |
    +--------+-------------+---------+-----------------------------+

12.  Security Considerations

   This section discusses security issues and possible remediations
   (where available) for DMARC.

12.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.

12.2.  Attacks on Reporting URIs

   URIs published in DNS TXT records are well-understood possible
   targets for attack.  Specifications such as [DNS] and [ROLES] either
   expose or cause the exposure of email addresses that could be flooded
   by an attacker, for example; MX, NS, and other records found in the
   DNS advertise potential attack destinations; common DNS names such as
   "www" plainly identify the locations at which particular services can
   be found, providing destinations for targeted denial-of-service or
   penetration attacks.

   Thus, Domain Owners will need to harden these addresses against
   various attacks, including but not limited to:

   o  high-volume denial-of-service attacks;

   o  deliberate construction of malformed reports intended to identify
      or exploit parsing or processing vulnerabilities;

Top      Up      ToC       Page 47 
   o  deliberate construction of reports containing false claims for the
      Submitter or Reported-Domain fields, including the possibility of
      false data from compromised but known Mail Receivers.

12.3.  DNS Security

   The DMARC mechanism and its underlying technologies (SPF, DKIM)
   depend on the security of the DNS.  To reduce the risk of subversion
   of the DMARC mechanism due to DNS-based exploits, serious
   consideration should be given to the deployment of DNSSEC in parallel
   with the deployment of DMARC by both Domain Owners and Mail
   Receivers.

   Publication of data using DNSSEC is relevant to Domain Owners and
   third-party Report Receivers.  DNSSEC-aware resolution is relevant to
   Mail Receivers and Report Receivers.

12.4.  Display Name Attacks

   A common attack in messaging abuse is the presentation of false
   information in the display-name portion of the RFC5322.From field.
   For example, it is possible for the email address in that field to be
   an arbitrary address or domain name, while containing a well-known
   name (a person, brand, role, etc.) in the display name, intending to
   fool the end user into believing that the name is used legitimately.
   The attack is predicated on the notion that most common MUAs will
   show the display name and not the email address when both are
   available.

   Generally, display name attacks are out of scope for DMARC, as
   further exploration of possible defenses against these attacks needs
   to be undertaken.

   There are a few possible mechanisms that attempt mitigation of these
   attacks, such as the following:

   o  If the display name is found to include an email address (as
      specified in [MAIL]), execute the DMARC mechanism on the domain
      name found there rather than the domain name discovered
      originally.  However, this addresses only a very specific attack
      space, and spoofers can easily circumvent it by simply not using
      an email address in the display name.  There are also known cases
      of legitimate uses of an email address in the display name with a
      domain different from the one in the address portion, e.g.,

        From: "user@example.org via Bug Tracker" <support@example.com>

Top      Up      ToC       Page 48 
   o  In the MUA, only show the display name if the DMARC mechanism
      succeeds.  This too is easily defeated, as an attacker could
      arrange to pass the DMARC tests while fraudulently using another
      domain name in the display name.

   o  In the MUA, only show the display name if the DMARC mechanism
      passes and the email address thus validated matches one found in
      the receiving user's list of known addresses.

12.5.  External Reporting Addresses

   To avoid abuse by bad actors, reporting addresses generally have to
   be inside the domains about which reports are requested.  In order to
   accommodate special cases such as a need to get reports about domains
   that cannot actually receive mail, Section 7.1 describes a DNS-based
   mechanism for verifying approved external reporting.

   The obvious consideration here is an increased DNS load against
   domains that are claimed as external recipients.  Negative caching
   will mitigate this problem, but only to a limited extent, mostly
   dependent on the default TTL in the domain's SOA record.

   Where possible, external reporting is best achieved by having the
   report be directed to domains that can receive mail and simply having
   it automatically forwarded to the desired external destination.

   Note that the addresses shown in the "ruf" tag receive more
   information that might be considered private data, since it is
   possible for actual email content to appear in the failure reports.
   The URIs identified there are thus more attractive targets for
   intrusion attempts than those found in the "rua" tag.  Moreover,
   attacking the DNS of the subject domain to cause failure data to be
   routed fraudulently to an attacker's systems may be an attractive
   prospect.  Deployment of [DNSSEC] is advisable if this is a concern.

   The verification mechanism presented in Section 7.1 is currently not
   mandatory ("MUST") but strongly recommended ("SHOULD").  It is
   possible that it would be elevated to a "MUST" by later security
   review.

12.6.  Secure Protocols

   This document encourages use of secure transport mechanisms to
   prevent loss of private data to third parties that may be able to
   monitor such transmissions.  Unencrypted mechanisms should be
   avoided.

Top      Up      ToC       Page 49 
   In particular, a message that was originally encrypted or otherwise
   secured might appear in a report that is not sent securely, which
   could reveal private information.



(page 49 continued on part 4)

Next RFC Part