Authenticated Received Chain (ARC)
draft-andersen-arc-00

Abstract

Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate their involvement with the handling process by adding a cryptographicly signed header (or headers) in a manner analagous to that of DomainKeys Identified Mail (DKIM). Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. Changes in the message which may break DKIM, may be tracked through the ARC set of headers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 18, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.

Table of Contents

• 1. Introduction
• 2. Requirements
• 2.1. Primary Design Criteria
• 2.2. Out of Scope
• 2.3. Utility
• 3. Terminology
• 4. Overview
• 5. Definition
• 5.1. Description of the new headers
• 5.1.1. ARC-Seal
• 5.1.2. ARC-Message-Signature
• 5.1.3. ARC-Authentication-Results
• 5.2. Constructing the ARC-Seal Header Set
• 5.2.1. Handling Violations in the ARC Header Set
• 5.3. Constructing the ARC-Message-Signature header
• 5.4. Key Management and Binding
• 5.4.1. Namespace
• 6. Usage
• 6.1. Participation
• 6.2. Relationship between DKIM Signatures and ARC Headers
• 6.3. Relationship of ARC-Message-Signatures and ARC-Seals
• 6.4. Validating the ARC set of headers
• 6.5. Assessing violations of ARC set validity
• 6.6. Reporting violations of ARC set validity
• 6.7. Recording results of ARC evaluation
• 7. Privacy Considerations
• 8. IANA Considerations
• 9. Security Considerations
• 9.1. Preventing Repurposing of ARC Headers
• 9.2. Messages Which Transit the Same ADMD More Than Once
• 10. References
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Appendix A. Appendix A - Example Usage
• A.1. Example 1: Simple mailing list
• A.1.1. Here’s the message as it exits the Origin:
• A.1.2. Message is then received at example.org
• A.1.3. Example 1: Message received by Recipient
• A.2. Example 2: Mailing list to forwarded mailbox
• A.2.1. Here’s the message as it exits the Origin:
• A.2.2. Message is then received at example.org
• A.2.3. Example 2: Message received by Recipient
• A.3. Example 3: Mailing list to forwarded mailbox with source
• A.3.1. Here’s the message as it exits the Origin:
• A.3.2. Message is then received at example.org
• A.3.3. Example 3: Message received by Recipient
• Appendix B. Acknowledgements
• Appendix C. Comments and Feedback
• Appendix D. Historical Note
• Authors' Addresses

1. Introduction

The development of strong domain authentication through SPF and DKIM has led to the implementation of the DMARC framework [RFC7489]. Implicit within the DMARC framework is a requirement that any intermediaries between the source system and ultimate receiver system must preserve the validity of the DKIM signature; however, there are common email practices which break the DKIM validation ([DMARC-INTEROP]). This proposal is intended to define an Authenticated Received Chain (ARC) to address the problems with the untrustworthiness of the standard Received header sequence so that receivers can develop a more nuanced interpretation to guide any local policies related to messages which arrive with broken domain authentication.

Forgery of the Received headers is a common tactic for bad actors. One of the goals of this proposal is to define a comparable set of trace headers which can be relied upon by receivers in so far as all ADMD (ADministrative Management Domain) handlers of a message participate in the ARC chain.

2. Requirements

The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.

2.1. Primary Design Criteria

• Provide a method by which a “chain of custody” can be documented for email messages
• Not require changes for senders of email
• Support the complete verification of the ARC header set by each hop in the handling chain
• Work at internet scale

2.2. Out of Scope

ARC is not a trust framework. Users of the ARC headers are cautioned against making unsubstantiated conclusions when encountering a “broken” ARC sequence.

2.3. Utility

The ARC-related set of headers can be used (when validated) to determine the path that an email message has taken between the sending system and receiver. Subject to the cautions mentioned below under Section 9, this information can assist in determining any local policy overrides to for violations of sender domain authentication policies.

3. Terminology

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 [RFC2119].

Readers are encouraged to be familiar with the contents of [RFC5598], and in particular, the potential roles of intermediaries in the delivery of email.

Syntax descriptions use Augmented BNF (ABNF) [RFC5234].

4. Overview

When an email is received without a properly valildated domain author, the inability to believe the accuracy of a series of Received headers prevents receiving systems from having a way to infer anything about the handling of the message by looking at the ADMD’s through which the message has traveled.

With the implementation of this proposal, participating ADMDs would be able to securely register their handling of an email message. If all intermediaries participate in the ARC process, then receivers will be able to rely upon the chain and make local policy decisions informed by that information.

The ARC set of headers provides a method by which participating intermediaries can indicate the hand-offs for email messages.

5. Definition

This proposal 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: OAR-Dev Group
  
  Specification document(s): [I-D.ARC]
  
  Related information: [RFC6376]
• Header field name: ARC-Message-Signature
  
  Applicable protocol: mail
  
  Status: draft
  
  Author/Change controller: OAR-Dev Group
  
  Specification document(s): [I-D.ARC]
  
  Related information: [RFC6376]
• Header field name: ARC-Authentication-Results
  
  Applicable protocol: mail
  
  Status: standard
  
  Author/Change controller: IETF
  
  Specification document(s): [I-D.ARC]
  
  Related information: [RFC7601] [OAR]

5.1. Description of the new headers

5.1.1. ARC-Seal

ARC-Seal is a Structured Header Field as defined in Internet Message Format ([RFC5321]), and thus all of the related definitions in that document apply.

This header field is added at the top of the message as it transits MTAs that do authentication checks, so some idea of how far away the checks were done can be inferred. It is therefore considered to be a trace field as defined in [RFC5321], and thus all of the related definitions in that document apply.

The ARC-Seal makes use of the same “tag=value” construction as defined in [RFC6376], section 3.2.

The value of the header field consists of an authentication identifier, and a series of statements and supporting data. The statements are of the form “tag=value” and indicate relevant data about the signing of the ARC set of headers. The header field can appear more than once in a single message.

5.1.1.1. Tags in the ARC-Seal header

5.1.1.1.1. Mandatory

• i = instance or sequence number; monotonically increasing at each “sealing” entity beginning with ‘1’
• a = hash algorithm (SHA256 as example) (as per [RFC6376] “a” tag)
• t = timestamp (seconds since Unix epoch) (as per [RFC6376] “t” tag)
• s = Selector for key (“s=seal2015”) (as per [RFC6376] “s” tag)
• d = domain for key (“d=example.com”) (as per [RFC6376] “d” tag)
• k = selector key path (specifies which ARC-Message-Signature is being asserted)
• b = signature of the header hash (as per [RFC6376] “b” tag)
• cv = chain validation status: values = ** ‘V’ = valid chain received; ** ‘N’ = no pre-existing chain; ** ‘P’ = permanent error, the chain as received does not validate; ** ‘T’ = temporary error, such as a DNS lookup error

5.1.1.2. Differences between DKIM-Signature and ARC-Seal

No ‘bh’ value is defined for ARC-Seal.

ARC-Seal does not use the ‘h’ list of headers that is defined for DKIM-Signatures because the list of applicable headers is fully determined by the construction rules (see Section 5.2).

ARC-Seal does not use the ‘c’ (canonicalization) tag because only ‘relaxed’ canonicalization [RFC6376] is allowed for ARC-Seal headers.

5.1.2. ARC-Message-Signature

The ARC-Message-Signature header is a special variant of a DKIM-Signature [RFC6376], using the relaxed header canonicalization rules specified in [RFC6376] but with a different rules for the header (h=) list to prevent mis-appropriation as a DKIM-Signature.

5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature

5.1.2.1.1. ‘h’ value

When constructing the ‘h’ list for the ARC-Message-Signature, the following headers must be implicitly signed, but not listed within the list: 1. Message-ID 2. Date 3. From 4. To 5. Subject

This provides a unique h list which prevents re-use or misappropriation of the ARC-Message-Signature as if it was a DKIM-Signature.

5.1.2.1.2. ‘i’ value

For the ARC-Message-Signature, the ‘i’ value is the corresponding instance which matches the ‘i’ value of the related ARC-Seal (see Section 5.1.1.1.1).

5.1.2.1.3. ‘v’

‘v’ is not defined for an ARC-Message-Signature and is not allowed.

5.1.3. ARC-Authentication-Results

ARC-Authentication-Results is a direct copy of the Authentication-Results header [RFC7601] created for archival purposes by the first MTA outside of the trust boundary of the originating system. (See also [OAR] for a similar usage.)

The value of the header field (after removing comments) consists of an authentication identifier, and then a series of statements and supporting data. The statements are of the form “method=result” and indicate which authentication method(s) were applied and their respective results. For each such statement, the supporting data can include a “reason” string and one or more “property=value” statements indicating which message properties were evaluated to reach that conclusion. The header field can appear only once in a single message.

5.2. Constructing the ARC-Seal Header Set

The ARC-Seal is built in the same fashion as the analogous DKIM-Signature [RFC6376], using the relaxed header canonicalization rules specified in [RFC6376] but with a strict ordering component for the headers which are covered by the cryptographic signature:

1. The ARC-Seal headers MUST be ordered in descending instance (i=) order.
2. The referenced ARC-Message-Signatures (via k= tags) MUST immediately follow the ARC-Seal instance which included the reference.
3. The ARC-Authentication-Results header MUST be the last item in the list.

5.2.1. Handling Violations in the ARC Header Set

When ordering the ARC-Seal headers, if there are gross violations of this protocol, such as duplicated instance numbers, such headers (and any associated headers) shall be ordered as follows:

• Any headers which are complete duplicates shall be deduplicated - leaving only one instance of each unique header; then any remaining order dependencies shall be ordered as follows:

1. (First) By descending order of t=
2. (Second) By ascending order of d=
3. (Third) By ascending order of s=
4. (Fourth) By ascending order of b=
5. (Finally) By ascending UTF-7 sort order for the entire canonicalized header

5.3. Constructing the ARC-Message-Signature header

The ARC-Message-Signature header is built in the same fashion as a DKIM-Signature [RFC6376], using the relaxed header canonicalization rules specified in [RFC6376] but with a different rules for the header (h=) list to prevent mis-appropriation as a DKIM-Signature. ARC-Message-Signatures (via k= tags) MUST immediately follow the ARC-Seal instance which includes the reference.

5.4. Key Management and Binding

The public keys for ARC-Seals follow the same requirements and semantics as those for DKIM-Signatures [RFC6376]. Operators may use distinct selectors for the ARC-Seals at their own discretion.

5.4.1. Namespace

All ARC-Seal keys are stored in the same subdomain as DKIM keys [RFC6376]: “_domainkey”. Given an ARC-Seal field with a “d=” tag of “example.com” and an “s=” tag of “foo.bar”, the DNS query will be for “foo.bar._domainkey.example.com”.

6. Usage

For a more thorough treatment of the recommended usage of the ARC headers for both intermediaries and end receivers, please consult [ARC-USAGE].

6.1. Participation

The inclusion of additional ARC-Seal headers should be done whenever a trust boundary is crossed and especially when prior DKIM-Signatures may not survive the handling which is being performed (such as some mailing lists which modify the content of messages or some gateway transformations). Note that trust boundaries may or may not exactly correspond with ADMD boundaries.

Each participating ADMD MUST validate the preceding ARC set of headers as a part of asserting their own seal. Even if the set is determined to be invalid, a participating ADMD SHOULD apply their own seal because this can help in analysis of breakage points in the chain.

6.2. Relationship between DKIM Signatures and ARC Headers

Any DKIM-Signatures SHOULD not include any of the ARC-Seal, ARC-Message-Signature, or ARC-Authentication-Results headers in the scope of their header list.

ARC-Message-Signatures SHOULD include all DKIM-Signatures within their scope.

6.3. Relationship of ARC-Message-Signatures and ARC-Seals

The ARC-Message-Signature(s) should not include any of the ARC-Seal headers in their coverage scope in order maintain a separation of responsibilities. When adding an ARC-Authentication-Results header, it should be added before computing the ARC-Message-Signature. When “sealing” the message, an operator must create the ARC-Message-Signature before the ARC-Seal in order to reference it and embed the ARC-Message-Signature within the ARC-Seal signature scope.

Each ARC-Seal ties into its respective ARC-Message-Signature through the k= and i= fields.

6.4. Validating the ARC set of headers

Validation of the ARC headers can be performed step-wise by building up the sequence in order as defined in Section 5.2 and evaluating the correctness of the b= signature at each step. If a violation of the construction rules is found, for instance missing or repeated instance numbers or an otherwise invalid ARC-Seal header, validation fails and should be indicated as ‘P’(ermanent error).

6.5. Assessing violations of ARC set validity

There are a wide variety of ways in which the ARC set of headers can be broken. Receivers should be wary of ascribing motive to such breakage although patterns of common behaviour may provide some basis for adjusting local policy decisions.

This proposal is exclusively focused on well-behaved, participating intermediaries that result in a valid chain of ARC-related headers. The presence of such a well-formed valid chain should also not be over-interpreted since malicious content can be easily introduced by otherwise well-intended senders through machine or account compromises. All normal content-based analysis should still be performed on any messages bearing an ARC sequence.

6.6. Reporting violations of ARC set validity

If a receiver determines that the ARC set of headers has a permanent error, the receiver MAY signal the breakage through the extended SMTP response code X.7.7 [RFC3463] “message integrity failure” [ENHANCED-STATUS].

6.7. Recording results of ARC evaluation

Receivers may add an “arc=pass” or “arc=fail” method annotation into their local Authentication-Results [RFC7601] header.

7. Privacy Considerations

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

8. IANA Considerations

This proposal adds three new headers as defined above.

This proposal adds a new method to the [RFC7601] header.

9. Security Considerations

Recipients are cautioned to treat messages bearing ARC-Seal chains 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.

9.1. Preventing Repurposing of ARC Headers

The ARC headers have been designed in such a way that they can not be re-used as standard DKIM-Signatures to prevent mis-use.

9.2. Messages Which Transit the Same ADMD More Than Once

Messages which loop in and out of an ADMD may lead to confusion about the scope of a particular set of ARC headers. The use of coordinated instance (i=) values and the non-confusability of the ARC-Message-Signature vs. a DKIM-Signature are designed to prevent misunderstandings.

10. References

11. References

11.1. Normative References

11.2. Informative References

Appendix A. Appendix A - Example Usage

A.1. Example 1: Simple mailing list

A.1.1. Here’s the message as it exits the Origin:

Return-Path: <jqd@d1.example>
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 <jqd@d1.example>
To: arc@dmarc.org
Subject: Example 1
 
Hey gang,
This is a test message.
--J.

A.1.2. Message is then received at example.org

A.1.2.1. Example 1, Step A: Message forwarded to list members

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:

Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=N; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.1.3. Example 1: Message received by Recipient

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:

Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
    by clothilde.example.com with ESMTP id 
    d200mr22663000ykb.93.1421363207
    for <fmartin@example.com>; 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=N; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.2. Example 2: Mailing list to forwarded mailbox

A.2.1. Here’s the message as it exits the Origin:

Return-Path: <jqd@d1.example>
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 <jqd@d1.example>
To: arc@example.org
Subject: Example 1
 
Hey gang,
This is a test message.
--J.

A.2.2. Message is then received at example.org

A.2.2.1. Example 2, Step A: Message forwarded to list members

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:

Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=N; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.2.2.2. Example 2, Step B: Message from list forwarded

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:

Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
    s=notary01; d=gmail.com; cv=V; k=20120806;
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
     YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
     txO+RRNr0fCFw==
ARC-Message-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=gmail.com; s=20120806;
    h=mime-version:date:message-id:subject:from:to: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/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 <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: gmail.com; spf=fail
    smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 
    header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: v=1; i=1; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=N:
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.2.3. Example 2: Message received by Recipient

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:

Return-Path: <jqd@d1.example>
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 <fmartin@example.com>; 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=V; k=20120806;
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
     YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
     txO+RRNr0fCFw==
ARC-Message-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=gmail.com; s=20120806;
    h=mime-version:date:message-id:subject:from:to: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/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 <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: 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=N; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.3. Example 3: Mailing list to forwarded mailbox with source

A.3.1. Here’s the message as it exits the Origin:

Return-Path: <jqd@d1.example>
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=N; k=20130426;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
     X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
     8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-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/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 <jqd@d1.example>
To: arc@example.org
Subject: Example 1
 
Hey gang,
This is a test message.
--J.

A.3.2. Message is then received at example.org

A.3.2.1. Example 3, Step A: Message forwarded to list members with source

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”) - link to DKIM-Signature (“k=clochette”) - signature (“b=”)

Here’s the message as it exits Step A:

Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=V; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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=N; k=20130426;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.3.2.2. Example 3, Step B: Message from list forwarded with source

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 - link to DKIM-Signature (“k=20120806”) - signature of the chain

Here’s what the message looks like at this point:

Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
    s=notary01; d=gmail.com; cv=V; k=20120806;
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
     WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
     /suttxO+RRNr0fCFw==
ARC-Message-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=gmail.com; s=20120806;
    h=mime-version:date:message-id:subject:from:to: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 <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: 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=V; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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=N; k=20130426;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-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/vpVBRJnD4I2weEIyYij
     rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
     4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

A.3.3. Example 3: Message received by Recipient

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:

Return-Path: <jqd@d1.example>
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 <fmartin@example.com>; 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=V; k=20120806;
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
     RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
     uttxO+RRNr0fCFw==
ARC-Message-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=gmail.com; s=20120806;
    h=mime-version:date:message-id:subject:from:to: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 <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: 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=V; k=clochette;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: v=1; a=rsa-sha256; c=simple/simple; 
    d=example.org; s=clochette; t=1421363105;
    bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
    h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:
     List-Help:List-Subscribe:From:Reply-To;
    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 <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
    (envelope-from jqd@d1.example)
ARC-Authentication-Results: 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=N; k=20130426;
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-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: &lt;54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe &lt;jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.

Appendix B. Acknowledgements

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.

Appendix C. Comments and Feedback

Please address all comments, discussions, and questions to arc-discuss@dmarc.org[mailto:arc-discuss@dmarc.org].

Appendix D. Historical Note

The ARC-Authentication-Results header is a direct copy of the normal Authentication-Results header ([RFC7601]) used in a similar fashion as that proposed in [OAR].

Authors' Addresses