]> Google, Inc.

weihaw@google.com

Independent Stream DKIM2 DMARC This document updates DMARC RFC9989 for DKIM2. In particular DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, so this updates DMARC to support those scenarios as well. While DMARC defines a RFC5322 From alignment constraint with an enforcement policy if validation fails, this generalizes and separates enforcement policy from constraint validation policies. This provides a mechanism for MTAs to declare support for DKIM2 through the DMARC DNS policy record that helps secure DKIM2 from downgrade attacks.

Introduction DKIM2 draft-ietf-dkim-dkim2-spec defines a new way to authenticate email with a focus to support SMTP MTA relay forwarding and message mutation. It records the relay mutation as "recipes" and envelope identities as part of its digital signature, and those "recipes" can be reversed to recover prior signatures. Signature header fields may carry flags "donotmodify" and "donotexplode" which are sender defined constraints requested of forwarders. DMARC combines a domain owner's enforcement policy published via DNS plus the concept of what is to be validated which is around From alignment. To authenticate the email, DMARC uses DKIM and SPF but not DKIM2. This document updates DMARC to permit the use of DKIM2. DMARC focussed on originating senders but really didn't consider intermediary relaying forwarders to the Mail Receiver. As DKIM2 explicitly supports relaying forwarders with mutations, this document updates DMARC to support those scenarios as well. In addition, this calls for distinguishing domain owner's constraint policies from the enforcement policy, and defining an explicit separation of specification behavior to make consistent where to read policies. DMARC will be defined to manage and publish domain level sender policies in its DNS policy. This includes enforcement and authentication policies. DKIM2 will define per message constraints by publishing signature flags. These are declarations by the DKIM2 signer of their sender policies. Certain constraints can be validated by the Mail Receiver, and when they fail, the Mail Receiver can use the published enforcement behavior to determine the disposition of the email message. This document updates these sender constraint policies and defines the interactions between each other, taking into account the sender domain level enforcement policies. Besides consistency, this normative explicit specification of DKIM2 and DMARC behavior will help improve the security of email authentication. As not all behavior need be normative, this also describes updates to the DKIM2 best current practices draft-ietf-dkim-dkim2-bcp document with recommendations that follow this document especially in regards to DKIM2 and DMARC interactions. As such this provides illustrative and non-normative example scenarios.

Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Email message transport and message format are defined in SMTP and Internet Message Format . The parties to email transport are defined in Email Architecture . That document notes that SMTP MTAs are SMTP relays that take on different roles when serving as the mail handling service agent. The first mail handling service that introduces the message is message "Originator" while the last mail handling service that no longer relays the message onwards is the "Final Receiver". There are intermediary relays that are neither Originator nor final receiver. While that document never uses the term "forwarder", this document adopts the commonly used "forwarding relay" to describe those MTA intermediaries that are neither Originator nor Final Receiver. DMARC defines the role of a "Mail Receiver" that is a "entity or organization that receives and processes email" which document uses for processing DMARC policy. As such, this document also acknowledges that SMTP MTAs may perform the dual role of sending and receiving email i.e. SMTP delivery of an outbound message or perform delivery of an inbound message. Unfortunately receiver and receiving have overlapping but different meanings. This document clarifies by using "Final Receiver" to describe mail handling service that takes the final delivery of the message i.e. without further relaying as well as a "Mail Receiver" that evaluates DMARC policy. DKIM2 draft-ietf-dkim-dkim2-spec defines a chain of custody to indicate DKIM2 signatures in a relayed message. Email Architecture observed that SMTP MTA relays are coupled to ADministrative Management Domains (ADMDs) where each ADMD is defined by a different set of policies. ADMDs can choose to publish a DMARC sender policy. Each ADMD can have one or more relay and add one or more DKIM2 signature along with sender constraints and validations.

Modification to DMARC This document updates DMARC to support DKIM2 draft-ietf-dkim-dkim2-spec with the following considerations for compatibility and security. Specifically, this modifies DMARC Section 4.3 to add DKIM2 as an authentication for determining authenticated identifiers. As noted earlier, this document separates domain owner's constraint and validation policies from the enforcement and authentication policies. This Section specifies the latter domain level policies through DNS to act as a side-channel outside of the message such that it cannot be downgraded.

DMARC Domain Owner Policy DMARC Section 5.3.1 defines the RFC5322 From header address as supplying the apparent author domain. That domain is then used to lookup the domain owner's DMARC policy record. Because DKIM2 supports one or more intermediate relay forwarders that can modify messages including the RFC5322 From header field, potentially there may be multiple addresses that can supply the author domains. author differs from the DMARC author in that it is the agent that introduces the message to be SMTP relayed starting at the Originator's MTA relay. Because From header fields can be rewritten, the DMARC apparent author domain potentially does not represent the author and instead represent identities of relay forwarders that presumably work in service of the author. When possible, the author's sender policy SHOULD be used instead, using the RFC5322 From header field that was recovered at DKIM2 signature i=1 using the description in draft-ietf-dkim-dkim2-spec in Section 10.2. If so, the entire chain of custody SHOULD be successfully validated for the DMARC evaluation of DKIM2. Once the author domain is found, the domain owner's DMARC policy record is fetched and interpreted using the procedures in Section 4.10 of DMARC including DMARC reporting. The domain owner's policy comes from DNS policy because it acts as a side-channel outside of the content of the message (besides the identity of the RFC5322.From). DMARC defines a domain owner's enforcement policy to be used when RFC5322.From alignment fails. These come from the DMARC policy record DNS policy tags "p" and "sp" with the value and behavior as defined by :

• reject
• quarantine
• none

This document generalizes DMARC enforcement sender policies to be used for any failing domain owner's constraint/validation subject to local policy, and not just for alignment. Other RFC9989 DNS policy record tags are specified for DKIM2 without further interpretation.

DMARC Authentication with DKIM2

DMARC Policy Auth Tag This modifies DMARC to allow SMTP MTA to declare which authentication method it supports to prevent authentication downgrade or spoofing attacks. Threat actors can become Man-In-The-Middle (MitM) relays that maliciously modify emails and strip the DKIM2 or DKIM signatures. Alternatively the threat actor can take advantage of receivers that support alternate vulnerable authentication methods and spoof victim senders. To prevent downgrade or spoofing attacks, this defines a method for MTAs to publish what authentication methods it supports as a DMARC Section 4.7 DNS policy record tag "auth=". This flag provides a declaration of authentication methods supported as both a SMTP MTA sender and receiver, meaning what authentication methods potentially present in the messages when sent, and what authentication methods it will process as a receiver. "auth=" takes a comma separated list of supported authentication methods:

dkim:

DomainKeys Identified Mail .

dkim2:

DomainKeys Identified Mail v2 draft-ietf-dkim-dkim2-spec.

spf:

Sender Policy Framework .

Usage of "auth=" tag is completely optional. If not specified, relying parties MAY assume that both DKIM and SPF are supported. Because this declaration is optional, MTAs may choose not to use this tag but still support an authentication method such as DKIM2 during the bring-up period. Notably by default DKIM2 is not specified by default. DKIM2 is meant to be explicitly declared so that it can be used as a capability declaration mechanism. Senders may declare with the "auth=" tag a set of specified authentication methods. If a message purportedly from the sender arrives using the methods in , the mail receiver can evaluate that the expected authentication methods are present. If the expected authentication is missing, the mail receiver SHOULD apply the sender's enforcement policy. Relaying may in the course of normal operation, hide evidence of authentication, so the following should be taken into account.

dkim:

DKIM signature is present. Because a given signature may be rewritten (i.e. deleted and replaced by another) by intermediate relays, the signature may contain a different domain than expected.

dkim2:

DKIM2 signatures are present and the chain of custody verifies. The expected domain should be present.

spf:

Cannot be verified unless the immediate sender is the expected domain. The message does not contain independently verifiable evidence of SPF authentication.

An explicit "auth=" tag can also declare that a MTA does not support some authentication method, and a mail receiver SHOULD NOT evaluate the expected authentication method when the authentication method is not present nor use that method for other applications.

DKIM2 Alignment DMARC alignment non-normatively implies "ownership" of the message though this becomes potentially muddled with DKIM2. Relay forwarding intermediaries may rewrite the RFC5322 From header field. DKIM2 draft-ietf-dkim-dkim2-spec chain of custody evaluation can recover prior versions of the From header all the way back to the Originator (i=1). The motivation for using the From header and the DKIM2 signature d= domain at the Originator and not other versions, is described earlier in . Mail Receivers that evaluate DKIM2 for DMARC validates the DKIM2 signatures that form the chain of custody as described in draft-ietf-dkim-dkim2-spec Section 11 to protect any policy evaluation or enforcement from being spoofed. If the chain of custody validates, then this is considered a DKIM2 authentication "pass" as input to the alignment test in the next paragraph. Otherwise if chain of custody does not validate, and if DKIM2 header fields are present, the result is "fail", otherwise without header fields, the result is "neutral". Next Mail Receivers checks the Identifier Alignment as described in Section 3.2.10 between the RFC5322 From header field Author domain and the DKIM2 signature d= domain at the Originator (i=1). For Identifier Alignment, this document uses relaxed domain matching between the DKIM2 signature d= and Author domain as described in draft-ietf-dkim-dkim2-spec Section 9.4 and Section 3.2.10.1 and Section 4.4. Policy evaluation MUST proceed only after this alignment check. There may be multiple DKIM2 signatures per ADMD as described in draft-ietf-dkim-dkim2-spec Section 9.3, and alignment check is meant to be processed on the SMTP transaction boundary. More specifically the alignment check SHOULD only be performed on signatures with the "rt=" and "mf=" tags, and exclude signatures with "nd=" tag.

Modification to DKIM2 This document proposes that all domain owner's constraint and validation policies be controllable by DKIM2 signature flags. This permits per message control which is useful in a number of different contexts such as policy rollout or for differentiating message applications such between transactional emails from promotional. With this flexibility comes extra coordination between different sender constraint and validation policies and between different signers in a DKIM2 chain. To reduce that burden, this provides sensible defaults when the DKIM2 signature flag is not present.

Unaligned Flag This introduces a DKIM2 signature flag "unaligned" to control the DMARC RFC9989 Author Domain alignment behavior with the Authenticated Identifier. By default the Mail Receiver expects relaxed alignment between the Author Domain and the DKIM2 signature d= domain at the Originator (i=1) as noted earlier in . When "unaligned" is set on the i=1 DKIM2 signature, this MAY be used to indicate that a message originated elsewhere, and the i=1 signer declines to take "ownership" of that message. This MUST only be done when the original message entering DKIM2 relay is already DMARC aligned with passing DKIM signature. No DMARC alignment validation is expected at DKIM2 signature at i=1 and such DMARC DKIM2 alignment validation for that signature will indicate "pass". The Mail Receiver MAY fetch the DMARC DNS policy from RFC5322 From provided by the Originator associated with the DKIM signature, and otherwise perform DMARC authentication checks with DKIM. Other DKIM2 Mail Receivers can validate the authenticity of such messages, as the DKIM2 chain of custody algorithm can recover the original DKIM authenticated message.

DKIM2 Flag Evaluation Besides the "unaligned" flag described earlier, DKIM2 supports the flags described in draft-ietf-dkim-dkim2-spec Section 8.10. This Section describes the policy behavior of these flags, its interactions with other flags, and across prior and successive flags. The presence of a flag on a signature can indicate that the signer MTA relay makes a "constraint" request to subsequent Mail Receivers. Mail Receivers SHOULD respect the "constraint". If it does not due to local policy, that Mail Receiver MUST NOT relay the message outside of its control meaning it's ADMD. Presence of a flag on a signature can also indicate that the Mail Receivers SHOULD perform "validation" to see if prior relaying MTAs respected the requested "constraint". If the validation fails, then the Mail Receiver SHOULD apply the enforcement policy described in subject to local policy.

exploded This flag reports that this message is being sent to more than one email address.

constraint:

Mail Receivers MAY use this report to suppress replay as the message has been sent to multiple email addresses.

validation:

N/A

flag interaction:

donotexplode

donotexplode This flag requests that this message not be sent to more than one recipient.

constraint:

Requests that MTA relays not the message to more than one recipient.

validation:

Mail Receivers SHOULD validate whether the message was sent to more than one recipient, and examine signatures to see if the "exploded" flag was set after the "donotexplode" flag. If so, then validation has failed.

flag interaction:

exploded

donotmodify This flag requests that this message not be modified. More specifically this requests no body changes or header fields be modified with the exception of RFC5322 From to support maintaining DMARC alignment.

constraint:

Requests that MTA relays not modify the message.

validation:

Mail Receivers SHOULD check if the message was modified after the "donotexplode". This MAY be done by checking if the corresponding Message-Instance recipes indicating any body changes or unexplained header field changes. If so, then validation has failed.

flag interaction:

N/A

feedback This flag requests that the signature signer get a DMARC report. The details of this flag are TBD.

feedhere This flag requests feedback about how this message is handled during delivery and thereafter is relayed via this hop. The details of this flag are TBD.

unaligned This flag reports that the corresponding RFC5322 From header field is unaligned.

constraint:

Mail Receivers MAY use this report to suppress DMARC alignment check for this signature subject to the description in .

validation:

N/A

Support for DKIM2 Unaware Relays Because the DMARC RFC9989 "auth=" tag can serve as a DKIM2 capabilities mechanism, a DKIM2 aware SMTP relay sender can check if the receiver supports DKIM2. If the receiver does not, the sender can choose to bounce the message, or continue to relay onwards. If relaying, the relay sender MAY choose to delete all DKIM2 signature header fields, or terminate the DKIM2 chain of custody by declaring DKIM2 signature header field "rt=" tag without envelope recipient addresses. Subsequent DKIM2 receivers can see that a message was intentionally sent to a non DKIM2 domain via the terminated chain of custody, and that address membership comparison between "rt=" against RCPT TO is unnecessary. Participants of this approach essentially allows all DKIM2 receivers to more deterministically apply anti-replay enforcements without solely relying on local policy to suppress flagging benign DKIM2 to DKIM traffic. Moreover preserving the DKIM2 signature header fields propagate DKIM2 policy to subsequent DKIM2 relays even after traversing a DKIM-only relay, such as "donotmodify", "donotexplode" and "feedback" policies. The DKIM2 signature header fields also provide delivery forensics value to Mail Receivers.

Modification to Best Current Practices This document calls for the update to the DKIM2 best current practices draft-ietf-dkim-dkim2-bcp document in the following way. The BCPs are non-normative recommendations.

DKIM2 Interop with DKIM DKIM2 participants should be very careful about using these features that enable interop between DKIM-only participants due to the potential of introduced replay risks. This is particularly true when a DKIM2 participant accepts DKIM traffic and signs as a DKIM2 message. It is incumbent on the DKIM2 relay that introduces DKIM traffic that the traffic is free of replay because downstream receivers cannot use DKIM2 (i.e. validation of the signed "rt=" recipient against envelope recipient) to prevent replay. These DKIM interop features should be limited to DKIM2 bring up and when the DKIM-only participant is well understood such as legacy enterprise services. Relays should restrain from extending the DKIM2 signature chain of custody if it was terminated. Such a message has left DKIM2, traversed a DKIM-only relay and is returning to a DKIM2 relay. If a DKIM-DKIM2 forwarder fails to protect against replay, they are well identified by their DKIM2 signature. At the introduction of a DKIM message to DKIM2, the DKIM2 relay can validate and provide "unaligned" flag on the DKIM2 i=1 signature as described in . Alternatively a DKIM2 relay may instead rewrite RFC5322 From with alignment. The relay however takes "ownership" of the message, and any prior authentication will be ignored by subsequent DKIM2 Mail Receivers.

Examples The following are non-normative examples meant to illustrate this specification.

DKIM2 → DKIM2 This represents a directly relayed message i.e. without an intermediates. The Originator MTA can lookup the DMARC DNS policy at _dmarc.destination.example to see that it supports DKIM2. The destination MTA can lookup the DMARC policy using the Author Domain of originator.example. DMARC DNS policy: Header fields before destination.example:

DKIM2 → DKIM2 → DKIM2 This represents a message an intermediate relay forwarder. That forwarder requests reporting via DKIM2 signature flag. The Mail Receiver destination.example follows the recommendation in this document, and uses the recovered RFC5322 From associated with the signature i=1 with the Author Domain Originator.example. It fetches p=quarantine policy and finds a request for DMARC aggregate reporting to be sent to report@originator.example. It also fetches the policy at forwarder.example, and finds a request for DMARC aggregate reporting to be sent to report@forwarder.example DMARC DNS policy: Header fields before destination.example:

DKIM → DKIM2 → DKIM2 This represents a message originating with DKIM only. The intermediate relay forwarder is DKIM2 aware and it indicates that it is not the Originator by a "unaligned" DKIM2 signature flag. The intermediate relay also does not . Also it knows that the Final Receiver supports DKIM2 as it can fetch the policy that indicates support for DKIM2 via the "auth=dkim2,dkim,spf" tag-value. The Mail Receiver destination.example finds the Author Domain Originator.example using the From header associated with the DKIM signature. DMARC DNS policy: Header fields before destination.example:

DKIM2 → DKIM → DKIM2 This represents a message be relayed through a DKIM only intermediate MTA. The Originator knows that the intermediate does not support DKIM2, and so terminates the chain of custody by setting the "rt=" to empty. Note the intermediate does not explicitly set "auth=", so it takes the default spf and dkim. DMARC DNS policy: Header fields:

Normative References This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

Acknowledgement Thanks goes to Todd Herr for clarifying how to update RFC9989. Many thanks goes to Richard Clayton for feedback on the authenticated identifier selection.