]> LinkedIn

1000 West Maude Ave Sunnyvale California 94085 USA kurta@linkedin.com

Google

blong@google.com

TDP

smj@crash.com

TDP

superuser@gmail.com

art DMARC Working Group Internet-Draft The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of a message can conduct authentication of a message as it passes among them on the way to its destination, and record the status of that authentication at each step along the handling path, for use by the final recipient in making choices about the disposition of the message.

Modern email authentication techniques such as the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) have become ubiquitious. However, they are stymied by a small number of common applications, most notably mailing list managers, as these applications have handling properties that prevent these authentication schemes from universal effectiveness. These issues are described in substantial detail in those protocols’ defining documents as well as in . In an effort to reduce the success of fraudulent email campaigns, there has been an effort to develop and deploy technologies that use SPF and DKIM to assure legitimate use of the identity of the apparent message author, i.e., the visible “From:” field in a message. To this end, Domain-based Mail Authentication, Reporting and Compliance (DMARC) has been developed and deployed. However, its deployment in environments where mailing lists are used has had the negative impacts predicted in the documents listed above. What is needed is a mechanism by which legitimate alteration of a message, invalidating SPF and DKIM, does not ultimately result in a rejection of an email message on delivery. An Authenticated Received Chain (ARC), described here, provides a superset of the functionality of DKIM in order to provide to the final message recipient a more complete view into the handling chain of a message and the points in that chain where alterations of the content may have occurred. Equipped with this more compelte information, the final recipient can make a more informed handling choice, reducing or eliminating the false postives inherent in use of DKIM and/or SPF themselves.

In DKIM, every participating signing agent attaches a signature that is based on the content of the message, local policy, and the domain name of the participating Administrative Management Domain (ADMD). Any verifier can process such a signature; a verified signature means the message content that was “covered” by the signature has not been altered since the signature was applied. The signatures themselves are generally independent of one another. By contrast, this protocol seeks to have each signature be able to convey the following pieces of information: As with DKIM, an assertion that, for a passing signature, the domain name in the signature takes some responsibility for handling of the message and that the message is unchanged since that signature was applied; A further assertion that, at the time that same ADMD processed the message, the various assertions already attached to the message by other ADMDs were or were not valid; A further assertion that combines and protects the above against alteration by later handlers. This protocol accomplishes each of these by adding a new header field to the message for each of them, as follows: ARC-Authentication-Results: (referred to below as “AAR”) virtually identical in syntax to an Authentication-Results field , this field records the results of all message authentication checks done by the recording ADMD at the time the message arrived; ARC-Message-Signature: (referred to below as “AMS”) virtually identical in syntax to DKIM-Signature, this field contains the assertions about the message header and body as they existed at the time of handling by the ADMD adding it; and ARC-Seal: (referred to below as “AS”) highly similar in structure and format to a DKIM-Signature, this field applies a digital signature that protects the integrity of all three of these new fields when they are added by an ADMD, plus all instances of these fields added by prior ADMDs. A distinguishing feature of all of these is that an ARC participant always adds all of them before relaying a message to the next handling agent en route to its destination. Moreover, as described in , they each have an “instance” number that increases with each ADMD in the handling chain so that their original order can be preserved and the three of them can be processed as a group.

This section defines terms used in the rest of the document. 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 . Readers are encouraged to be familiar with the contents of , and in particular, the potential roles of intermediaries in the delivery of email. Syntax descriptions use Augmented BNF (ABNF) . A single group of the header fields introduced in is called an “ARC Set”, and the complete sequence of these groups is called an “Authenticated Received Chain” or merely an “ARC chain”. Although the “Received” header field is typically not included in the signed content, the name is based on the notion that this is in essence a cryptographically signed series of header fields that attest to the handling chain of a message much as Received fields always have.

The header fields comprising a single ARC set are identified by the presence of a string in the value portion of the header field that complies with the “tag-spec” ABNF found in Section 3.2 of . The tag-name is always the single character “i” and the value is the text representation of a positive integer, indicating the position in the ARC sequence this set occupies, where the first ARC set is numbered 1. In ABNF terms:

At any delivery stage, it is an error if any ARC set is invalid (i.e., does not contain exactly one of the three header fields defined by this protocol). Note that because the AMS and AS header field values are made up of tag-spec constructs, the i= tag may be found anywhere within the header field value, but is represented throughout this spec in the initial position for convenience. Implementers SHOULD seek to start with the i= tag to facilitate human inspection of the headers.

The ‘i’ tag value can range from 1-1024 (inclusive). ARC implementations MUST support at least ten (10) intermediary steps. More than fifty (50) intermediaries is considered extremely unlikely so ARC chains with more than fifty intermediaries may be marked with “cv=fail”.

The three header fields that are part of this specification borrow heavily from existing specifications. Rather than repeating all of the formal definitions that are being recycled in ARC, this document instead only describes and specifies changes in syntax and semantics.

The ARC-Authentication-Results header field is defined. It is syntactically and semantically identical to an Authentication-Results header field (A-R), as is the mechanism by which it is constructed, with the following exception: There is an “i” tag, as described in . The instance identifier MUST be separated from the rest of the Authentication-Results value contents with a semi-colon (‘;’, 0x3b). An ARC signer generates this field in the same way that a conventional A-R field would be generated. Because the AAR is designed for machine-based consumption over the course of a message’s transit through a series of mediators and to facilitate troubleshooting of problematic sources by sending organizations, two additional fields of data SHOULD be added to the normal A-R content, if available to the A-R generating system: source.ip - The connecting client IP address from which the message is received; and header.s - The selector value associated with each dkim signature (added to the dkim or arc data sections of the A-R/AAR record The purpose of this header field is to incorporate into the record the success or failure of any authentication done on the message upstream of the participating ADMD, to validate and continue the authentication chain. In processing, some architectures will generate multiple A-R records for the same authserv-id. In such cases, the resinfo value from each of the A-R records should be concatenated into a single record just as they would have been if they were generated in a single A-R record.

The ARC-Message-Signature header field is defined. It is syntactically and semantically identical to a DKIM-Signature header field , as is the mechanism by which it is constructed, with the following exceptions: There is an “i” tag, as described in . There is no “v” tag. ARC-Seal header fields MUST never be included in the content covered by the signature in this header field. The AMS SHOULD include any DKIM-Signature header fields already present on the message in the header fields covered by this signature. Authentication-Results header fields SHOULD NOT be included since they are likely to be deleted by downstream ADMDs, thereby breaking the AMS signature. As with a DKIM-Signature, the purpose of this header field is to allow the ADMD generating it to take some responsibility for handling this message as it progresses toward delivery.

The ARC-Seal header field is defined. It is syntactically and semantically similar to a DKIM-Signature field, with the following exceptions: There is an “i” tag, as described in . The ARC-Seal covers none of the body content of the message. It only covers specific header fields. (See below: .) As a result, no body canonicalization is done. Further, only “relaxed” header canonicalization (Section 3.4.2 of ) is used. The only supported tags are “i” ( supercedes the definition), and “a”, “b”, “d, “s”, “t”. The latter 5 tag definitions are copied from Section 3.5 of . An additional tag, “cv” is defined. (See below: ) The purpose of this field is to assure the integrity of the ARC set being added by the ADMD generating this header field, and moreover to ensure no tampering with the ARC overall.

A new tag “cv” (chain validation) is defined, which indicates the state of the ARC chain as evaluated when it arrived at the ADMD adding this header field. It includes one of three possible values: none: There was no chain on the message when it arrived for validation; typically occurs when the message arrives at a Message Transfer Agent (MTA) from a Message Submission Agent (MSA) or when any upstream MTAs may not be participating in ARC handling; fail: The message has a chain whose validation failed; pass: The message has a chain whose validation succeeded. In ABNF terms:

The ARC-Seal signature is an encryption of the hash of the concatenation of the canonicalized form of the ARC sets present on the message at the time of sealing, in increasing instance order, starting at 1, including the one being added at the time of sealing the message. Within a set, the header fields are presented in the following order: ARC-Authentication-Results ARC-Message-Signature ARC-Seal Where the ARC-Seal is the one being generated, it is presented to the hash function in its final form except with an empty “b=” value, in the same manner by which a DKIM-Signature signs itself.

The verifier takes the following steps to determine the current state of the ARC on the message: Collect all ARC sets currently on the message. If there were none, the ARC state is “none” and the algorithm stops here. If any ARC set is invalid (e.g., does not contain exactly one of each of the three ARC-specific header fields), then the chain state is “fail” and the algorithm stops here. Conduct verification of the ARC-Message-Signature header field bearing the highest instance number. If this verification fails, then the chain state is “fail” and the algorithm stops here. For each ARC-Seal from the “N”th instance to the first, apply the following logic: If the value of the “cv” tag on that seal is “fail”, the chain state is “fail” and the algorithm stops here. If the instance number being processed is greater than 1 and the value of the “cv” tag is “none”, the chain state is “fail” and the algorithm stops here. If the instance number being processed is 1 and the value of the “cv” tag is not “none”, the chain state is “fail” and the algorithm stops here. Prepare a hash function corresponding to the “a” tag of the ARC-Seal. Compute the canonicalized form of the ARC header fields, in the order described in , using the “relaxed” header canonicalization defined in (Section 3.4.2 of . Pass them to the hash function. Retrieve the final digest from the hash function. Retrieve the public key identified by the “s” and “d” tags in the ARC-Seal, as described in . Determine whether the signature portion (“b” tag) of the ARC-Seal and the digest computed above are valid according to the public key. If the signature is not valid, the chain state is “fail” and the algorithm stops here. If all seals pass validation, then the chain state is “pass”, and the algorithm is complete. The verifier should record the cv state for subsequent use by any sealing which may be done later (potentially after message modification) within the same trust boundary. The cv state may be recorded by sealing at the time of verification in an additional ARC set or may be recorded out of band depending on the architecture of the ADMD.

This section includes a walk-through of the actions an ARC signing implementation takes when presented with a message. The signing agent should undertake the following steps: Do any authentication steps that the ADMD normally does: If a message is traveling within the same trust boundary, this would include any transitive trust conveyance with the message; If a message is coming from outside the same trust boundary, this would include any SPF / DKIM / DMARC / other authentication evaluation steps. Do any DKIM signing or authentication assertion steps that the ADMD normally does. Generate and optionally attach to the message an Authentication-Results header field using the ADMD’s authserv-id (see Section 2.5 of ) indicating whatever authentication might have been done by the MTA, or possibly indicate that none was done. If an ARC chain exists on the message, then set “N” equal to the highest instance number found on the chain (i=); otherwise set “N” equal to zero for the following steps. Generate and attach to the message an ARC-Authentication-Results header field using instance number N+1 and the same content from the previous step. Generate and attach to the message an ARC-Message-Signature header field using the general algorithm described in Section 5 of and as modified in above, using instance number N+1. Generate and attach to the message an ARC-Seal header field using the general algorithm described in above, using a chain validation status as determined in and instance number N+1.

The public keys for ARC header fields follow the same requirements, syntax and semantics as those for DKIM signatures, described in Section 3.6 of . Operators may use distinct selectors and/or domains for the ARC header fields at their own discretion.

There are a wide variety of ways in which the ARC set of header fields can be broken. Receivers need to be wary of ascribing motive to such breakage although patterns of common behaviour may provide some basis for adjusting local policy decisions. This specification is exclusively focused on well-behaved, participating intermediaries that result in a valid chain of ARC-related header fields. The value of such a well-formed, valid chain needs to be interpreted with care since malicious content can be easily introduced by otherwise well-intended senders through machine or account compromises. All normal content-based analysis still needs to be performed on any messages bearing a valid chain of ARC header sets.

The header fields signed by the AS header field b= value in the case of a major violation MUST be only the matching ‘i=’ instance headers created by the MTA which detected the malformed chain, as if this newest ARC set was the only set present. (This is the same procedure required for handling major/structural validity problems.)

DNS failures to resolve or return data which is needed for ARC validation SHOULD result in a 421 tempfail during the SMTP conversation with the sending system. Temporary or intermittent DNS problems will generally not be sufficiently transitory to allow a mediator to obtain a different result during the ordinary transit duration so it is better to have the source system queue the problematic message(s) than to generate (potential) backscatter. DNS-based failures to verify a chain are treated no differently than any other ARC violation. They result in a cv=fail verdict.

If a receiver determines that the ARC chain has failed, the receiver MAY signal the breakage through the extended SMTP response code 5.7.7 “message integrity failure” and corresponding SMTP response code.

Receivers MAY add an “arc=[pass|fail|policy]” method annotation into a locally-affixed Authentication-Results header field along with any salient comment(s).

The evaluation of a series of ARC sets results in the following data which MAY be used to inform local-policy decisions: A list of the “d=” domains found in the validated (== all) ARC-Seal header fields; The “d=” domain found in the most recent (highest instance number) AMS header field (since that is the only one necessarily validated) In the case of a failed chain, only the terminal ARC set is covered by the ARC-Seal so the reporting is limited to the findings in that terminal ARC set.

[[ Note: Discussion on the IETF DMARC-WG list has indicated some interest in more substantial reporting for analytic purposes. To support that effort, the following guidance is provided only as an interim, minimal data set. A more complete reporting construct will be specified in a related spec - TBD. (see also the note at ) ]] Receivers SHOULD indicate situations in which ARC evaluation influenced the results of their local policy determination. DMARC reporting of ARC-informed decisions is augmented by adding a local_policy comment explanation containing the list of data discovered in the ARC evaluation ():

delivered fail fail local_policy arc=pass ams=d2.example d=d2.example,d1.example ]]>

In the suggested sample, d2.example is the sealing domain for ARC[2] and d1.example is the sealing domain for ARC[1]. Mediators SHOULD generate DMARC reports on messages which transit their system just like any other message which they receive. This will result in multiple reports for each mediated message as they transit the series of handlers. DMARC report consumers should be aware of this behaviour and make the necessary accommodations.

[[ Note: Some additional development of this section is needed. ]] In the following branch diagrams, each algorithm is represented by an ‘A’ or ‘B’ at each hop to depict the ARC chain that develops over a five hop scenario. ‘x’ represents a hop that does not support that algorithm. Note that during a transitional period where multiple algorithms are allowed, all of the statements in this spec which refer to “exactly one set of ARC headers per instance” need to be understood as “at least one set per instance and no more than one instance-set per algorithm”.

Intermediaries MUST be able to validate ARC chains build with either algorithm but MAY create ARC sets with either (or both) algorithm. The introductory period should be at least six (6) months.

Intermediaries MUST be able to validate ARC chains build with either algorithm and MUST create ARC sets with both algorithms. Chains ending with either algorithm may be used for the result.

ARC sets built with algorithms that are being deprecated MAY be considered valid within an ARC chain, however, intermediaries MUST not create additional sets with the deprecated algorithm. The deprecation period should be at least two (2) years.

The ARC chain provides a verifiable record of the handlers for a message. Anonymous remailers will probably not find this to match their operating goals.

This specification adds three new header fields as defined below.

This draft adds one item to the IANA “Email Authentication Methods” registry: Method : arc Defined: &SELF; ptype: header Property: chain evaluation result Value: chain evaluation result status (see ) Status: active Version: 1

This specification adds three new header fields to the “Permanent Message Header Field Registry”, as follows: Header field name: ARC-Seal Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): &SELF; Related information: Header field name: ARC-Message-Signature Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): &SELF; Related information: Header field name: ARC-Authentication-Results Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): &SELF; Related information:

[[ Note to the RFC Editor: Please remove this section before publication along with the reference to . ]] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. This information is known to be correct as of the seventh interoperability test event which was held on 2017-07-15 & 16 at IETF99.

Organization: Google Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Production - Incoming Validation Coverage: Full spec implemented as of Licensing: Proprietary - Internal only Implementation Notes: Full functionality was demonstrated during the interop testing on 2016-06-17 In place for reporting usage only as of 2016-11-21 on all GMail flows. Rechecked general incoming validation as of 2017-02-24 interop event. Contact Info: arc-discuss@dmarc.org

Organization: AOL Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function Status of Operation: Beta Coverage: ARC chain validity status checking is not operational, but otherwise this system conforms to Licensing: Proprietary - Internal only Implementation Notes: Full functionality with the exception of chain validity checking was demonstrated during the interop testing on 2016-06-17 Available for production mail via selected account whitelisting for test validation only. Intermittent stability problems discovered at the interop event on 2017-02-24. Remediation underway as of the publication of this draft. Contact Info: arc-discuss@dmarc.org

Organization: dkimpy developers Description: Python DKIM package Status of Operation: Production Coverage: The internal test suite is incomplete, but the command line developmental version of validator was demonstrated to interoperate with the Google and AOL implementations during the interop on 2016-06-17 and the released version passes the tests in https://github.com/ValiMail/arc_test_suite with both python and python3. Licensing: Open/Other (same as dkimpy package) Contact Info: https://launchpad.net/dkimpy

Organization: TDP/Murray Kucherawy Description: Implemention of milter functionality related to the OpenDKIM and OpenDMARC packages Status of Operation: Beta Coverage: Built to support Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Implementation Notes: The build is FreeBSD oriented and takes some tweaks to build on RedHat-based Linux platforms.

Contact Info: arc-discuss@dmarc.org

Organization: Mailman development team Description: Integrated ARC capabilities within the Mailman package Status of Operation: Patch submitted Coverage: Unknown Licensing: Same as mailman package - GPL Implementation Notes: Incomplete at this time Contact Info: https://www.gnu.org/software/mailman/contact.html

Organization: Copernica Description: Web-based validation of ARC-signed messages Status of Operation: Beta Coverage: Built to support Licensing: On-line usage only Implementation Notes: Released 2016-10-24 Requires full message content to be pasted into a web form found at http://arc.mailerq.com/ (warning - https is not supported). An additional instance of an ARC signature can be added if one is willing to paste a private key into an unsecured web form. Initial testing shows that results match the other implementations listed in this section. Contact Info: [https://www.copernica.com/]

Organization: Rspamd community Description: ARC signing and verification module Status of Operation: Production, though deployment usage is unknown Coverage: Built to support Licensing: Open source Implementation Notes: Released with version 1.6.0 on 2017-06-12 Contact Info: [https://rspamd.com/doc/modules/arc.html] and [https://github.com/vstakhov/rspamd]

Organization: FastMail Description: Email domain authentication milter, previously included SPF / DKIM / DMARC, now has ARC added Status of Operation: Intial validation completed during IETF99 hackathon with some follow-on work during the week Coverage: Built to support &SELF; Licensing: Open Source Implementation Notes: Contact Info: https://github.com/fastmail/authentication_milter

The Security Considerations of and apply directly to this specification. Inclusion of ARC sets in the header of emails may cause problems for some older or more constrained MTAs if they are unable to accept the greater size of the header. Operators who receive a message bearing N ARC sets has to complete N+1 DNS queries to evaluate the chain (barring DNS redirection mechanisms which can increase the lookups for a given target value). This has at least two effects: An attacker can send a message to an ARC partipant with a concocted sequence of ARC sets bearing the domains of intended victims, and all of them will be queried by the participant until a failure is discovered. DKIM only does one DNS check per signature, while this one can do many. Absent caching, slow DNS responses can cause SMTP timeouts; this could be exploited as a DoS attack.

Recipients are cautioned to treat messages bearing ARC sets with the same suspicion that they apply to all other email messages. This includes appropriate content scanning and other checks for potentially malicious content. The handlers which are identified within the ARC-Seal chain may be used to provide input to local policy engines in cases where the sending system’s DKIM-Signature does not validate.

&RFC1345; &RFC5234; &RFC5321; &RFC5322; &RFC3463; &RFC7601; &RFC7208; &RFC6651; &RFC5863; &RFC6377; &RFC5585; &RFC6376; &RFC4686; &RFC5598; &RFC5226; &RFC2142; &RFC2606; &RFC2119; &RFC6982; &RFC7489; &RFC7960;

[[ Note: The following examples were mocked up early in the definition process for the spec. They no longer reflect the current definition and need various updates which will be included in draft -08. ]]

Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@dmarc.org Subject: Example 1 Hey gang, This is a test message. --J. ]]>

Processing at example.org: example.org performs authentication checks No previous Auth-Results or ARC-Seal headers are present example.org adds ARC-Auth-Results header example.org adds Received: header example.org adds a ARC-Seal header Here’s the message as it exits example.org:

ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5 vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

Let’s say that the Recipient is example.com Processing at example.com: example.com performs usual authentication checks example.com adds Auth-Results: header, Received header Determines that message fails DMARC Checks for ARC-Seal: header; finds one Validates the signature in the ARC-Seal: header, which covers the ARC-Authentication-Results: header example.com can use the ARC-Authentication-Results values or verify the DKIM-Signature from lists.example.org Here’s what the message looks like at this point:

Received: from example.org (example.org [208.69.40.157]) by clothilde.example.com with ESMTP id d200mr22663000ykb.93.1421363207 for ; Thu, 14 Jan 2015 15:02:40 -0800 (PST) Authentication-Results: clothilde.example.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@example.org; dmarc=fail; arc=pass ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: Example 1 Hey gang, This is a test message. --J. ]]>

Processing at example.org: example.org performs authentication checks example.org applies standard DKIM signature No previous Auth-Results or ARC-Seal headers are present example.org adds ARC-Auth-Results header example.org adds usual Received: header example.org adds a ARC-Seal header Here’s the message as it exits Step A:

ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

The message is delivered to a mailbox at gmail.com Processing at gmail.com: gmail.com performs usual authentication checks gmail.com adds Auth-Results: and Received: header Determines that message fails DMARC Checks for ARC-Seal: header; finds one Validates the signature in the ARC-Seal: header, which covers the ARC-Authentication-Results: header Uses the ARC-Auth-Results: values, but: Instead of delivering message, prepares to forward message per user settings Applies usual DKIM signature gmail.com adds it’s own ARC-Seal: header, contents of which are version sequence number (“i=2”) hash algorithm (SHA256 as example) timestamp (“t=”) selector for key (“s=notary01”) domain for key (“d=gmail.com”) headers included in hash (“h=ARC-Authentication-Results:ARC-Seal”) Note: algorithm requires only ARC-Seals with lower sequence # be included, in ascending order signature of the header hash Here’s what the message looks like at this point:

ARC-Seal: i=2; a=rsa-sha256; t=1421363253; s=notary01; d=gmail.com; cv=pass; b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut txO+RRNr0fCFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120806; h=mime-version:content-type:x-original-sender: x-original-authentication-results:precedence:mailing-list: list-id:list-post:list-help:list-archive:sender:reply-to: list-unsubscribe:DKIM-Signature; bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw bQoZyRtb6X6q0mYaszUB8kw== Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) Authentication-Results: i=2; gmail.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@example.org; dmarc=fail; arc=pass ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=none: b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

 

Let’s say that the Recipient is example.com Processing at example.com: example.com performs usual authentication checks example.com adds Auth-Results: header, Received header Determines that message fails DMARC Checks for ARC-Seal: header; finds two Validates the signature in the highest numbered (“i=2”) ARC-Seal: header, which covers all previous ARC-Seal: and ARC-Authentication-Results: headers Validates the other ARC-Seal header (“i=1”), which covers the ARC-Authentication-Results: header example.com uses the ARC-Authentication-Results: values Here’s what the message looks like at this point:

Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com [208.69.40.157]) by clothilde.example.com with ESMTP id d200mr22663000ykb.93.1421363268 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) Authentication-Results: clothilde.example.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@gmail.com; dmarc=fail; arc=pass ARC-Seal: i=2; a=rsa-sha256; t=1421363253; s=notary01; d=gmail.com; cv=pass; b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut txO+RRNr0fCFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120806; h=mime-version:content-type:x-original-sender: x-original-authentication-results:precedence:mailing-list: list-id:list-post:list-help:list-archive:sender:reply-to: :list-unsubscribe:DKIM-Signature; bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw bQoZyRtb6X6q0mYaszUB8kw== Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) Authentication-Results: i=2; gmail.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@example.org; dmarc=fail; arc=pass ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=origin2015; d=d1.example; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU 8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3 TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: Example 1 Hey gang, This is a test message. --J. ]]>

 

Processing at example.org: example.org performs authentication checks example.org applies standard DKIM signature Checks for ARC-Seal: header; finds one (i=1) Validates the signature in the ARC-Seal (i=1): header, which covers the d1.example ARC-Message-Signature: header example.org adds ARC-Auth-Results header example.org adds usual Received: header example.org adds a DKIM-Signature example.org adds a ARC-Seal header, contents of which are sequence number (“i=2”) hash algorithm (SHA256 as example) timestamp (“t=”) chain validity (“cv=”) selector for key (“s=seal2015”) domain for key (“d=example.org”) signature (“b=”) Here’s the message as it exits Step A:

ARC-Seal: i=2; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=pass; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF 1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3 A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=2; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=origin2015; d=d1.example; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

The message is delivered to a mailbox at gmail.com Processing at gmail.com: gmail.com performs usual authentication checks gmail.com adds Auth-Results: and Received: header Determines that message fails DMARC Checks for ARC-Seal: header; finds two Validates the signature in the ARC-Seal (i=2): header, which covers the ARC-Authentication-Results: header Validates the signature in the ARC-Seal (i=1): header, which covers the d1.example ARC-Message-Signature: header Uses the ARC-Auth-Results: values, but: Instead of delivering message, prepares to forward message per user settings Applies usual DKIM signature gmail.com adds it’s own ARC-Seal: header, contents of which are version sequence number (“i=2”) hash algorithm (SHA256 as example) timestamp (“t=”) selector for key (“s=notary01”) domain for key (“d=gmail.com”) Note: algorithm requires only ARC-Seals with lower sequence # be included, in ascending order signature of the chain Here’s what the message looks like at this point:

ARC-Seal: i=3; a=rsa-sha256; t=1421363253; s=notary01; d=gmail.com; cv=pass; b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF /suttxO+RRNr0fCFw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120806; h=mime-version:content-type:x-original-sender :x-original-authentication-results:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender :list-unsubscribe:reply-to; bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD BJtXwbQoZyRtb6X6q0mYaszUB8kw== Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) Authentication-Results: i=3; gmail.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@example.org; dmarc=fail; arc=pass ARC-Seal: i=2; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=pass; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=2; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=origin2015; d=d1.example; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD 4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

Let’s say that the Recipient is example.com Processing at example.com: example.com performs usual authentication checks example.com adds Auth-Results: header, Received header Determines that message fails DMARC Checks for ARC-Seal: header; finds three Validates the signature in the highest numbered (“i=2”) ARC-Seal: header, which covers all previous ARC-Seal: and ARC-Authentication-Results: headers Validates the other ARC-Seal header (“i=2”), which covers the ARC-Authentication-Results: header Validates the other ARC-Seal header (“i=1”), which covers the d1.example ARC-Message-Signature: header example.com uses the ARC-Authentication-Results: values Here’s what the message looks like at this point:

Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com [208.69.40.157]) by clothilde.example.com with ESMTP id d200mr22663000ykb.93.1421363268 for ; Thu, 14 Jan 2015 15:03:15 -0800 (PST) Authentication-Results: clothilde.example.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@gmail.com; dmarc=fail; arc=pass ARC-Seal: i=3; a=rsa-sha256; t=1421363253; s=notary01; d=gmail.com; cv=pass; b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s uttxO+RRNr0fCFw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120806; h=mime-version:content-type:x-original-sender :x-original-authentication-results:precedence :mailing-list:list-id:list-post:list-help:list-archive:sender :list-unsubscribe:reply-to; bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD BJtXwbQoZyRtb6X6q0mYaszUB8kw== Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10 for ; Thu, 14 Jan 2015 15:02:45 -0800 (PST) Authentication-Results: i=3; gmail.com; spf=fail smtp.from=jqd@d1.example; dkim=pass (1024-bit key) header.i=@example.org; dmarc=fail; arc=pass ARC-Seal: i=2; a=rsa-sha256; t=1421363107; s=seal2015; d=example.org; cv=pass; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6 1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L 69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=clochette; t=1421363105; bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=; h=List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Reply-To:DKIM-Signature; b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1 F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+ m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M= Received: from segv.d1.example (segv.d1.example [72.52.75.15]) by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123 for ; Thu, 14 Jan 2015 15:01:30 -0800 (PST) (envelope-from jqd@d1.example) ARC-Authentication-Results: i=2; lists.example.org; spf=pass smtp.mfrom=jqd@d1.example; dkim=pass (1024-bit key) header.i=@d1.example; dmarc=pass Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) (authenticated bits=0) by segv.d1.example with ESMTP id t0FN4a8O084569; Thu, 14 Jan 2015 15:00:01 -0800 (PST) (envelope-from jqd@d1.example) ARC-Seal: i=1; a=rsa-sha256; t=1421363107; s=origin2015; d=d1.example; cv=none; b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61 TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69 EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=d1.example; s=20130426; t=1421363082; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= Message-ID: <54B84785.1060301@d1.example> Date: Thu, 14 Jan 2015 15:00:01 -0800 From: John Q Doe To: arc@example.org Subject: [Lists] Example 1 Hey gang, This is a test message. --J. ]]>

This draft is the work of OAR-Dev Group. The authors thank all of the OAR-Dev group for the ongoing help and though-provoking discussions from all the participants, especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Grateful appreciation is extended to the people who provided feedback through the discuss mailing list.

Please address all comments, discussions, and questions to dmarc@ietf.org. Earlier discussions can be found at arc-discuss@dmarc.org.