]> Google, Inc.

weihaw@google.com

Independent Stream DKIM ARC Email Authentication Forwarded email often becomes unauthenticated because it breaks SPF (RFC7208) authentication and DKIM (RFC6376) authentication. For example mailing-lists distribute email to multiple recipients through a separate server than the original sending server that breaks IP based SPF authentication and potentially may modify the message that breaks the DKIM signature. This document calls for using ARC (RFC8617) to identify and authenticate forwarded emails by further specifying the naming of the two digital signatures present in ARC headers- the message signature and the seal. Because this uses ARC digital signature, the receiver has confidence that a valid signature corresponding to some forwarder only could have been generated by the named domain. This document also specifies that all forwarded mail flows have associated ARC headers and the means to characterize the mail flows.

Introduction

Purpose Forwarding has long complicated email authentication as forwarding email through a 3rd party server breaks SPF IP based authentication and breaks DKIM authentication when the message is modified. The IETF DMARC WG published ARC as a solution to the limitations of SPF and DKIM based authentication caused by forwarding. ARC headers propagate the DKIM and SPF authentication as seen by the forwarder to the receiver. Using those results, the receiver may choose to override their own authentication result to overcome the SPF and DKIM limitations. The key problem with using ARC this way is trusting that the forwarder didn't forge those results, and this trust problem has prevented further adoption of ARC. This document proposes a different, potentially complementary approach in utilizing ARC. This document calls for identifying the forwarder and placing the responsibility on any forwarded spam on the forwarder. This specification calls for using the ARC-Message-Signature d= domain to name the forwarder with the same identity as the DKIM-Signature d= domain. This specification permits both DKIM and ARC headers identities, and provides rules and additional tools to help interpret their results. For example, to assist the human reader in understanding the mail flow, this specification provides a new ARC header tag-value to name all the stages of the mail flow. Notably this approach does not require the original DKIM signature or all forwarded ARC message signatures to pass. Only the most recent forwarded ARC message signatures must pass if the message is forwarded. When no ARC headers are present, then the DKIM signature must pass. Forwarders may still modify the message that breaks the prior signatures but the message must be then ARC message signed afterwards. This document does not attempt to justify why those changes occur, and only broadly attempts to determine who made changes to the message. It does require, as before, that all ARC seals must verify. If they do not, this document calls for following the ARC specification in not trusting the ARC chain. However, unlike that document, this specification calls for the preservation of the invalid ARC chain results for forensics in a clearly distinguishable way. Delivery Status Notifications (DSN ) and auto-reply messages may be used in backscatter attacks. Part of the difficulty in remedying this problem has been the lack of observability mail flow at scale. This specification calls for DSN or auto-reply messages triggered by some other message delivery to be tracked as one mail flow by propagating the ARC headers to DNS or auto-reply messages and continue building the chain. By treating the initial message and subsequent new message as part of the same mail delivery flow, a mail receiver of the DSN or auto-reply will be able to observe the initial forwarding flow potentially to the originator. Incorporating DKIM and ARC headers should make it easier for automated systems to discover spam that attempts to hide behind backscatter attacks. This document uses mail flow descriptions from the Internet-Draft draft-ietf-dkim-replay-problem which in turn is based on . The usage is this document are defined in section .

Existing Authentication Practices This section attempts to generalize the authentication practices of originators and forwarders at the time of writing. Most email originators sign messages with DKIM following on behalf of some responsible party's domain to permit authentication to that domain. That domain is called the DKIM Signing Domain Identifier (SDID). Many originators further specify the DKIM SDID to be the same as the payload From header sender's domain thus identifying the sender in the visible part of the email to be displayed by the email MUA client. DMARC calls this process alignment. Occasionally some forwarders resign DKIM, meaning that a DKIM header is added and possibly the old header is removed, which complicates attribution. In some of those cases, the payload From header may be rewritten as well. Forwarders may also generate ARC headers that follow to report the DKIM and SPF authentication results in the ARC-Authentication-Result header. In many cases the ARC-Seal d= domain and ARC-Message-Signature d= domain are the same. When there is a prior ARC header seal validation failure, forwarders in many cases do not follow ARC , and generate a single ARC set indicating the failure. In some cases, the ARC headers are removed. In other cases, the forwarder stops generating new headers. However, these actions permit a spammer to introduce an ARC header error to prevent valuable forensics information from being sent to the receiver.

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 .

Characterizing Mail Flow

ARC-Message-Signature and ARC-Seal Domains This specification calls for the ARC-Message-Signature d= domain to represent the responsible party that controls the forwarding of the message. DKIM calls this domain the SDID, and this document proposes using the same equivalent DKIM SDID of the controlling forwarder to represent the ARC-Message-Signature SDID. The existing ARC specification leaves that domain unspecified, which permits the refinement. Moreover this specification calls for the ARC-Seal d= domain to represent the responsible party for generating the ARC headers and vouches for the truthfulness of the ARC-Authentication-Results. This too would be a SDID corresponding to the party that generates the ARC headers. In a cloud environment, the party that generates the ARC headers is often a different entity that controls message forwarding. Example:

Interaction Between DKIM and ARC As noted earlier, the more common arrangement between DKIM and ARC today is for the originator to generate DKIM header as specified in and for forwarders to ARC specification . This specification calls for the originator to always DMARC aligns the payload From header domain with the DKIM SDID domain. This alignment permits a subsequent receiver to identify the originator. Some originators may also generate ARC headers, and if so, this specification calls for the ARC-Message-Signature SDID to be the same as the From header to help clarify that the originator generated the ARC headers. This specification also calls for the originator to clear the ARC-Authentication-Result header body as there are no authentication results at origination. The advantage of generating ARC headers at origination is that a receiver may find it convenient to primarily work with one type of headers rather than both ARC and DKIM at the cost of extra headers size overhead. A forwarder may resign the message with DKIM and rewrite with the payload From header. This specification calls the ARC-Message-Signature SDID to be the same as the new SDID that is the From header. This makes it clear that the forwarder claims ownership of the message. DKIM originator and ARC forwarder example: DKIM and ARC originator example: Forwarder claiming ownership example:

Edge and Forwarder Characterization This document specifies the functional purpose of ARC-Message-Signature SDID as description is added as a tag-value to the ARC-Message-Signature with mail flow description tag of "m". This serves two purposes- 1) to help a human reading the ARC headers understand the mail flow 2) let receivers know that this forwarder or originator participates in this specification. Notably these values are not the source of truth about the mail flow characterization, and rather a receiver SHOULD infer them from the DKIM and ARC headers SDID and payload From alignment. The values of the "m" tag are characterized as a subset of the Mail Handling Services defined in and clarified in the internet-draft draft-ietf-dkim-replay-problem. This document reuses that list and description from the latter document. In a few cases, this document extends the description and a later section on discontiguous mail-flow further extends this list. The list of Mail Handling Services are: Edge services:

originator:

Defined in Section 2.2.1. This is the first component of the MHS and works on behalf of the author to ensure the message is valid for transport; it then posts it to the relay (MTA) that provides SMTP store-and-forward transfer. The Originator can DKIM sign the message on behalf of the author, although it is also possible that the author's system, or even the first MTA, does DKIM signing. If specified, the ARC-Authentication-Result SHOULD be empty.

receiver:

Defined in Section 2.2.4 is the last stop in the MHS, and works on behalf of the recipient to deliver the message to their inbox; it also might perform filtering. If specified, this message SHOULD NOT be used subsequently in forwarded traffic and when found, may be processed by spam systems according to local policy.

Forwarder services:

alias:

Defined in Section 5.1. A type of Mediator user, operating in between a delivery and a following posting. The Alias replaces the original RCPT TO envelope recipient address but does not alter the content address field header fields. Often used for Auto-Forwarding.

resender:

Defined in Section 5.2. ReSender is a type of Mediator user, like an Alias; however, the ReSender updates the recipient address, and "splices" the destination header field and possibly other address fields as well.

mailing_list:

Defined in Section 5.3. Mailing list is another Mediator; it receives a message and reposts it to the list's members; it might add list-specific header fields e.g. List-XYZ: might modify other contents, such as revising the Subject: field, or adding content to the body.

esp:

Email Service Provider is often called a Bulk Sender - An originating third-party service, acting as an agent of the author and sending to a list of recipients. They may DKIM sign as themselves and/or sign with the author's domain name.

ofs:

Outbound Filtering Service: Rather than sending directly to recipients' servers, the Originator can route mail through a Filtering Service, to provide spam or data loss protection services. This service may modify the message and can have a different ADMD from the Originator.

ifs:

Inbound Filtering Service: The Receiver can also route mail through a Filtering Service, to provide spam, malware and other anti-abuse protection services. Typically, this is done by listing the service in an DNS MX record. This service may modify the message and have a different ADMD from the Receiver.

Example:

Invalid ARC Headers The ARC specification does not acknowledge the forensics value of invalid ARC headers. Further spammers will intentionally invalidate ARC headers knowing that receivers will typically stop processing and publishing ARC headers. This specification calls for the receiver to continue generating the ARC headers, but obfuscate the invalid ARC headers to be conformant with the ARC specification. When ARC verification finds prior ARC headers to be invalid, this specification calls for the prior ARC headers to be prefixed with X-Invalid-. The ARC signer continues the ARC instance number at the next instance number as if prior ARC headers were valid. It also seals assuming the prior ARC headers lack the prefix. The ARC signer generates a new set of normal ARC headers (without any prefix) with the ARC-Seal's having a tag cv=fail and ARC-Authentication-Result with the result arc=fail. ARC validators unaware of this specification will ignore the prior ARC headers with the X-Invalid- prefix, and see that the new ARC headers seal will intentionally not validate correctly. Aware validators will process the current and prior invalid ARC headers without the X-Invalid- prefix. This specification also calls for supporting invalid headers without the X-Invalid- prefix to keep the very same forensics information if ARC signers don't follow this specification. Humans and automated systems may be able to make use of the invalid headers to determine which participants in the mail flows contributed to observed potentially malicious messages. Example:

Reporting Discontiguous Mail Flow Mail handling systems may automatically respond to messages by sending new messages with status notifications or by sending auto-replies. In some cases, the original message content is copied over such as with Delivery Status Notification (DSN) RFC or the subject as with auto-reply. As a consequence, spammers have used these auto-reply and status notification messages to propagate spam. These attacks are particularly difficult to respond to at scale because of the discontinuity between the original message that triggered the auto-reply and the subsequent message containing spam that is sent to the victim. The discontinuity prevents appropriate attribution by automated systems. This specification proposes that the ARC headers be preserved from the original message and propagated to the new auto-reply message. The receiver that sends the response SHOULD continue the ARC chain as if the messages were simply forwarded between the original and the new response, and the ARC message set number should simply increment after the last ARC set in the original message. To help with human review of such messages, this proposes additional mail flow tag values:

ndr:

Non-Delivery Reports: This describes a mail flow for a special kind of Delivery Status Notification when the message is not delivered, and the originator should be notified. This is commonly called a bounce.

dsn:

Delivery Status Notifications: This describes a mail flow for all other delivery notifications besides Non-Delivery Reports, such as when the originator is informed of delivery of the message.

auto_reply:

For messages generated by a message handler working on behalf of a recipient. Some examples of these are vacation responders, and calendar schedulers.

Example after a bounce, as seen by the original sender that is now handling the bounce:

Additional Examples These examples are informational. These are more complex examples, to show how these various techniques may compose across the different participants in the mail flow.

Originator ⇒ Mailing-List ⇒ Receiver: Bounce This message is sent through a mailing-list to some receiver where the message bounces. The initial sent message from the originator: The inbound DKIM signature pass verification. Next the mailing-list modifies the message by adding a Subject header prefix and message-body footer, then adds an ARC set with the DKIM authentication result. As the mailing-list is hosted on forwarder.example.com, the ARC-Seal SDID is forwarder.example.com, while the ARC-Message-Signature SDID is mailinglist.example.com. It also adds a new DKIM-Signature with a SDID of mailinglist.example.com. When the receiver verifies the message, it finds that the original message DKIM signature fails verification, but the ARC-Message-Signature passes along with the ARC seals and the new DKIM signature. As the ARC-Message-Signature contains a mail flow tag (m=mailinglist), the receiver knows the forwarder is participating in this specification, and can extract the SDID from the ARC-Message-Signature d= domain. From this, the receiver understands that the message was forwarded by mailinglist.example.com and is responsible for this message. At some point during delivery, the receiver sees that the message is being sent to a non-existent user, and bounces the message to the original sender. It removes the original headers, except the ARC headers, and adds new ones indicating the bounce in a NDR. The originator receives the bounce, and verifies the content. The DKIM signature signed by the receiver passes, as does the ARC seals. The originator can see from the ARC headers that this message was originally from it as the ARC-Authentication-Result at i=1 indicates the original DKIM SDID was orig.example.com, and is likely a bounce. This is confirmed by the mail flow tag of m=ndr found in the ARC-Message-Signature at i=2.

Security Considerations A spammer may remove all ARC and DKIM headers to confuse an ARC/DKIM aware receiver, however this specification calls for ARC headers to always be present on forwarded messages and that the message must always have a DKIM signature. The lack of ARC and DKIM headers would indicate that this message cannot be authenticated with the method in this specification. Valid DKIM header indicates that the message has not been tampered with since origination and can be authenticated. If the DKIM header is invalid, then the message must have valid ARC headers with a forwarder that can be identified to be considered authenticated. A spammer may manipulate ARC headers to confuse an ARC aware receiver. Modification of existing ARC headers will result in the seal not verifying, which the receiver will detect and handle using ARC . Manipulated ARC headers will not be used with authenticating the message. A spammer may choose to participate in ARC header generation with valid ARC seals but misleading results e.g. results for a good mail attached to spammy one. This then is forwarded to the receiver. This will be confusing the receiver but it will also identify the spammy forwarder. A spammer may replay messages ARC signed by another party. This document does not attempt to solve that problem and leaves that to subsequent work such as draft-chuang-replay-resistant-arc. `

IANA Considerations There are no requests at this time.

Normative References 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. 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] The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [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. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. 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 defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]

Acknowledgments Thanks goes to Emanuel Schorsch. The mail handler server list and content in section was written by David Crocker.