DMARC Working Group                                          K. Andersen
Internet-Draft                                                  LinkedIn
Intended status: Standards Track                            B. Long, Ed.
Expires: January 19, 22, 2018                                         Google
                                                           S. Jones, Ed.
                                                       M. Kucherawy, Ed.
                                                                     TDP
                                                           July 18, 21, 2017

              Authenticated Received Chain (ARC) Protocol
                    draft-ietf-dmarc-arc-protocol-06
                    draft-ietf-dmarc-arc-protocol-07

Abstract

   The Authenticated Received Chain (ARC) permits an organization which is
   creating or handling email to indicate its involvement with the
   handling process.  It defines protocol creates a set of cryptographically signed
   header fields in mechanism
   whereby a manner analagous to that series of handlers of DKIM.  Assertion a message can conduct authentication
   of
   responsibility is validated through a cryptographic signature and by
   querying message as it passes among them on the Signer's domain directly way to retrieve the appropriate
   public key.  Changes in its destination,
   and record the message status of that might break DKIM can be
   identified through authentication at each step along the ARC set
   handling path, for use by the final recipient in making choices about
   the disposition of header fields. the message.

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 January 19, 22, 2018.

Copyright Notice

   Copyright (c) 2017 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Primary Design Criteria
   3.  Terminology . . . . . . . . . . . . . . . . .   4
     2.2.  Out of Scope . . . . . . . .   5
   4.  Instance ('i=') Tags  . . . . . . . . . . . . . .   4
     2.3.  Utility . . . . . .   5
     4.1.  Valid Range for Instance Tags . . . . . . . . . . . . . .   6
   5.  The ARC Header Fields . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . .   6
     5.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . .   5
   4.  Overview . .   6
     5.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . . . .   7
     5.3.  ARC-Seal (AS) . . . . . . . . .   5
   5.  Definition . . . . . . . . . . . . .   7
       5.3.1.  The 'cv' Tag  . . . . . . . . . . . .   5
     5.1.  Description of the New Header Fields . . . . . . . .   8
       5.3.2.  Selected Header Fields  . .   6
       5.1.1.  ARC-Seal . . . . . . . . . . . . .   8
   6.  Verifier Actions  . . . . . . . . .   6
       5.1.2.  ARC-Message-Signature . . . . . . . . . . . . .   9
   7.  Signer Actions  . . .  10
       5.1.3.  ARC-Authentication-Results . . . . . . . . . . . . .  11
     5.2.  Constructing the ARC-Seal Set . . . . . . .  10
   8.  Key Management  . . . . . . .  12
       5.2.1.  Handling Minor Violations in the ARC Sets . . . . . .  13
       5.2.2.  Handling Major Violations in the ARC Sets . . . . . .  13
     5.3.  Key Management and Binding . . . .  11
   9.  Usage of Chain Validity . . . . . . . . . . .  14
       5.3.1.  Namespace . . . . . . . .  11
     9.1.  Assessing Chain Validity Violations . . . . . . . . . . .  11
     9.2.  Marking and Sealing Invalid Chains  . . .  14
     5.4.  Supporting Alternate Signing Algorithms . . . . . . . .  11
     9.3.  Handling DNS Problems While Validating ARC  .  14
       5.4.1.  Introductory Period . . . . . .  12
     9.4.  Responding to ARC Validity Violations . . . . . . . . . .  12
     9.5.  Recording the Results of ARC Evaluation .  14
       5.4.2.  Co-Existence Period . . . . . . . .  12
       9.5.1.  Output Information from an ARC Evaluation . . . . . .  12
       9.5.2.  Reporting ARC Effects for DMARC Local Policy -
               Interim . . .  14
       5.4.3.  Deprecation Period . . . . . . . . . . . . . . . . .  14
       5.4.4.  Obsolescence Period . . .  13
   10. Supporting Alternate Signing Algorithms . . . . . . . . . . . . . .  15
   6.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Participation . . . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Relationship between DKIM Signatures and ARC Headers  . .  15
     6.3.  Validating the ARC Set of Header Fields . . . . . . . . .  15
     6.4.  ARC Set Validity  . . . . . . . . . . . . .  13
     10.1.  Introductory Period  . . . . . . .  15
       6.4.1.  Assessing Chain Validity Violations . . . . . . . . .  15
       6.4.2.  Marking and Sealing Invalid Chains  . . . . . . . . .  16
       6.4.3.  Responding to ARC Validity Violations . . . . . . . .  16
       6.4.4.  Recording the Results of ARC Evaluation  14
     10.2.  Co-Existence Period  . . . . . . .  16
       6.4.5.  Output Data Points from ARC Evaluation . . . . . . .  16
       6.4.6.  Reporting ARC Effects for DMARC Local Policy -
               Interim . . . .  14
     10.3.  Deprecation Period . . . . . . . . . . . . . . . . . . .  16
   7.  14
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   8.  14
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  14
     12.1.  Authentication-Results Method Registry Update  . . . . . .  17
     8.2.  14
     12.2.  Definitions of the ARC header fields . . . . . . . . . .  18
   9.  15
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
     9.1.  15
     13.1.  GMail test reflector and incoming validation . . . . . .  19
     9.2.  16
     13.2.  AOL test reflector and internal tagging  . . . . . . . . .  20
     9.3.  16
     13.3.  dkimpy . . . . . . . . . . . . . . . . . . . . . . . . .  20
     9.4.  17
     13.4.  OpenARC  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     9.5.  17
     13.5.  Mailman addition . . . . . . . . . . . . . . . . . . . .  21
     9.6.  18
     13.6.  Copernica/MailerQ web-based validation . . . . . . . . .  22
     9.7.  18
     13.7.  Rspamd . . . . . . . . . . . . . . . . . . . . . . . . .  22
   10.  19
     13.8.  PERL Mail::Milter::Authentication module . . . . . . . .  19

   14. Security Considerations . . . . . . . . . . . . . . . . . . .  22
     10.1.  20
     14.1.  Message Content Suspicion  . . . . . . . . . . . . . . .  23
   11.  20
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     11.1.  20
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     11.2.  20
     15.2.  Informative References . . . . . . . . . . . . . . . . .  25
     11.3.  22
     15.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  26  23
   Appendix A.  Appendix A - Example Usage (Obsolete but retained
                for illustrative purposes) . . . . . . . . . . . . .  26  23
     A.1.  Example 1: Simple mailing list  . . . . . . . . . . . . .  26  23
       A.1.1.  Here's the message as it exits the Origin:  . . . . .  26  23
       A.1.2.  Message is then received at example.org . . . . . . .  27  24
       A.1.3.  Example 1: Message received by Recipient  . . . . . .  29  26
     A.2.  Example 2: Mailing list to forwarded mailbox  . . . . . .  30  27
       A.2.1.  Here's the message as it exits the Origin:  . . . . .  30  27
       A.2.2.  Message is then received at example.org . . . . . . .  31  28
       A.2.3.  Example 2: Message received by Recipient  . . . . . .  35  32
     A.3.  Example 3: Mailing list to forwarded mailbox with source   37   34
       A.3.1.  Here's the message as it exits the Origin:  . . . . .  37  34
       A.3.2.  Message is then received at example.org . . . . . . .  38  35
       A.3.3.  Example 3: Message received by Recipient  . . . . . .  43  40
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  45  42
   Appendix C.  Comments and Feedback  . . . . . . . . . . . . . . .  46  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46  43

1.  Introduction

   The development of strong domain

   Modern email authentication through techniques such as the Sender Policy
   Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
   [RFC6376] has led to the implementation have become ubiquitious.  However, they are stymied by a
   small number of the DMARC framework
   [RFC7489] which extends the authentication 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 [RFC6377].

   In an effort to reduce the author's "From:"
   (RFC5322.From) field success of fraudulent email campaigns,
   there has been an effort to develop and permits publishing policies for non-
   compliant messages.  Implicit within the DMARC framework is a
   requirement deploy technologies that any intermediaries between the source system use
   SPF and
   ultimate receiver system need DKIM to preserve assure legitimate use of the validity identity of the DKIM
   signature; however, there apparent
   message author, i.e., the visible "From:" field in a message.  To
   this end, Domain-based Mail Authentication, Reporting and Compliance
   (DMARC) [RFC7489] has been developed and deployed.  However, its
   deployment in environments where mailing lists are common legitimate email practices which
   break used has had the DKIM validation ([RFC7960]).  This specification defines
   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).  ARC addresses the problems with
   the untrustworthiness (ARC), described here, provides a superset of the standard Received header field sequence.
   Through the information tracked in the ARC series functionality
   of headers,
   receivers can develop a more nuanced interpretation DKIM in order to guide any
   local policies related provide to messages that arrive with broken domain
   authentication (DMARC).

   Forgery of the Received header fields is final message recipient a common tactic used by bad
   actors.  One of more
   complete view into the goals handling chain of this specification defines a comparable
   set message and the points in
   that chain where alterations of trace header fields which the content may have occurred.
   Equipped with this more compelte information, the final recipient can be relied upon by receivers,
   assuming all ADministrative Management Domain (ADMD) ([RFC5598],
   section 2.2) intermediary handlers of
   make a message participate in ARC.

   The Authentication-Results (A-R) mechanism [RFC7601] permits more informed handling choice, reducing or eliminating the
   output
   false postives inherent in use of an email authentication evaluation process to be
   transmitted from the evaluating DKIM and/or SPF themselves.

2.  Overview

   In DKIM, every participating signing agent to attaches a consuming agent signature that uses
   the information.  On its own, A-R
   is believable only within a trust
   domain.  ARC provides a protection mechanism for based on the data, permiting content of the message, local policy, and the communication to cross trust domain boundaries.

2.  Requirements

   The specification
   name of the ARC framework is driven participating Administrative Management Domain (ADMD).
   Any verifier can process such a signature; a verified signature means
   the message content that was "covered" by the following
   high-level goals, security considerations, and practical operational
   requirements.

2.1.  Primary Design Criteria

   o  Provide a verifiable "chain of custody" for email messages;

   o  Not require changes for originators signature has not been
   altered since the signature was applied.  The signatures themselves
   are generally independent of email;

   o  Support one another.

   By contrast, this protocol seeks to have each signature be able to
   convey the verification following pieces of information:

   1.  As with DKIM, an assertion that, for a passing signature, the ARC header field set by each hop
       domain name in the signature takes some responsibility for
       handling chain;

   o  Work at Internet scale; of the message and

   o  Provide a trustable mechanism for that the communication of
      Authentication-Results across trust boundaries.

2.2.  Out of Scope

   ARC message is unchanged since
       that signature was applied;

   2.  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 a trust framework.  Users of valid;

   3.  A further assertion that combines and protects the ARC header fields are
   cautioned above against making unsubstantiated conclusions when
   encountering a "broken" ARC sequence.

2.3.  Utility

   The ARC-related set
       alteration by later handlers.

   This protocol accomplishes each of these by adding a new header fields can be used (when validated) field
   to
   determine the path that an email message has taken between the
   originating system and receiver.  Subject for each of them, as follows:

   o  ARC-Authentication-Results: (referred to the cautions mentioned
   in Section 10, this information can assist below as "AAR") virtually
      identical in determining any local
   policy overrides syntax to for violations an Authentication-Results field [RFC7601],
      this field records the results of origination domain all message authentication policies.

3.  Terminology

   This section defines terms used in
      checks done by the rest of recording ADMD at the document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are time the message arrived;

   o  ARC-Message-Signature: (referred to be interpreted below as described "AMS") virtually
      identical in [RFC2119].

   Readers are encouraged 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

   o  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 Section 4, 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.

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

   A single group of the header fields introduced in Section 2 is called
   an email message "ARC Set", and the complete sequence of these groups is received without a properly validated
   originating domain, called an
   "Authenticated Received Chain" or merely an "ARC chain".  Although
   the inability to believe "Received" header field is typically not included in the accuracy of signed
   content, the name is based on the notion that this is in essence a
   cryptographically signed series of Received header fields prevents receiving systems from having a
   way that attest to infer anything about the
   handling chain of the a message much as Received fields always have.

4.  Instance ('i=') Tags

   The header fields comprising a single ARC set are identified by looking at
   the ADMDs through which the message has traveled.

   With ARC, participating ADMDs are able to securely register their
   handling
   presence of an email message.  If all mediators ([RFC5598])
   participate a string in the ARC process, receivers will be able to rely upon
   the chain and make local policy decisions informed by that
   information.

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

5.  Definition

   This specification defines three new header fields:

   o  Header field name: ARC-Seal (abbreviated below as AS)

   o  Header field name: ARC-Message-Signature (abbreviated below as
      AMS)

   o  Header field name: ARC-Authentication-Results (abbreviated below
      as AAR)

   Collectively, these header fields form a connected set of attribution
   information by which receivers can identify that
   complies with the handling path for a
   message.  As described below, a distinct set of these fields share a
   common sequence number, identified "tag-spec" ABNF found in an "i=" tag.  Such a correlated
   group Section 3.2 of header fields [RFC6376].
   The tag-name is referred to as an "ARC set".

   Specific references to individual header fields use always the header field
   names to distinguish such references.

   The ARC sets SHOULD be added at single character "i" and the value is the top
   text representation of a message header as it
   transits MTAs that do authentication checks, so some idea of how far
   away positive integer, indicating the checks were done can be inferred.  They are therefore
   considered to be a trace field as defined position in [RFC5321], and all of
   the related definitions in that document apply.

   Relative ordering of different trace header fields (the ARC sets,
   DKIM, Received, etc.) is unimportant for sequence this specification.  In
   general, trace header fields, such as ARC, SHOULD be added at set occupies, where the top first ARC set is
   numbered 1.  In ABNF terms:

      instance = [FWS] %x69 [FWS] "=" [FWS] 1*DIGIT [FWS] ";"

   At any delivery stage, it is an error if any ARC set is invalid
   (i.e., does not contain exactly one of the email three header fields, but receivers MUST be able to process fields
   defined by this protocol).

   Note that because the AMS and AS header fields from wherever they field values are found in made up of
   tag-spec constructs, the message header.
   Ordering amongst i= tag may be found anywhere within the individual ARC
   header fields and sets field value, but is
   specified below and MUST be followed represented throughout this spec in the
   initial position for proper canonicalized signing
   and evaluation.

5.1.  Description convenience.  Implementers SHOULD seek to start
   with the i= tag to facilitate human inspection of the New Header Fields

5.1.1.  ARC-Seal

   ARC-Seal headers.

4.1.  Valid Range for Instance Tags

   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 a Structured considered extremely unlikely
   so ARC chains with more than fifty intermediaries may be marked with
   "cv=fail".

5.  The ARC Header Field as defined in Internet Message
   Format ([RFC5322]).  All Fields

   The three header fields that are part of this specification borrow
   heavily from existing specifications.  Rather than repeating all of
   the related formal definitions in that are being recycled in ARC, this document
   apply.

   The ARC-Seal makes use of Tag=Value Lists as defined
   instead only describes and specifies changes in [RFC6376],
   Section 3.2. syntax and semantics.

5.1.  ARC-Authentication-Results (AAR)

   The value of the ARC-Authentication-Results header field consists of an authentication sequence
   identifier, and a series of statements is defined.  It is
   syntactically and supporting data. semantically identical to an Authentication-Results
   header field [RFC7601] (A-R), as is the mechanism by which it is
   constructed, with the following exception:

   o  There is an "i" tag, as described in Section 4.

   The
   statements indicate relevant data about instance identifier MUST be separated from the signing rest of the
   Authentication-Results value contents with a semi-colon (';', 0x3b).

   An ARC set.
   The header signer generates this field can appear more than once in the same way that a single message, but
   each instance MUST have a unique "i=" value.

   The ARC-Seal header
   conventional A-R field includes would be generated.  Because the AAR is
   designed for machine-based consumption over the course of a digital signature message's
   transit through a series of all
   preceding ARC message header mediators and to facilitate
   troubleshooting of problematic sources by sending organizations, two
   additional fields on of data SHOULD be added to the message.

5.1.1.1.  Tags in normal A-R content,
   if available to the ARC-Seal Header Field Value A-R generating system:

   o  source.ip - The following tags are connecting client IP address from which the only supported tags for an ARC-Seal field.
   All of them MUST be present.  Unknown tags MUST be ignored
      message is received; and do not
   affect

   o  header.s - The selector value associated with each dkim signature
      (added to the validity dkim or arc data sections of the header.

   o  a = hash algorithm; syntax A-R/AAR record

   The purpose of this header field is to incorporate into the same as record
   the "a=" tag defined in
      Section 3.5 success or failure of [RFC6376];

   o  b = digital signature; syntax is 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 as authserv-id.  In such cases, the "b=" tag defined
      in Section 3.5 resinfo value from each
   of [RFC6376];

   o  cv = chain validation status: valid values:

      *  'none' = no pre-existing chain;

      *  'fail' = the chain A-R records should be concatenated into a single record just
   as received does not or can not validate; or

      *  'pass' = valid chain received.

   o  d = domain for key; syntax they would have been if they were generated in a single A-R
   record.

5.2.  ARC-Message-Signature (AMS)

   The ARC-Message-Signature header field is the same defined.  It is
   syntactically and semantically identical to a DKIM-Signature header
   field [RFC6376], as is the "d=" tag defined in
      Section 3.5 of [RFC6376];

   o  i = "instance" or sequence number; monotonically increasing at
      each "sealing" entity, beginning mechanism by which it is constructed, with '1', see Section 5.1.1.1.1
      regarding
   the valid range following exceptions:

   o  s = selector for key; syntax  There is the same an "i" tag, as the "s=" tag defined described in Section 3.5 of [RFC6376]; 4.

   o  t = timestamp; syntax  There is no "v" tag.

   o  ARC-Seal header fields MUST never be included in the same as content
      covered by the "t=" tag defined signature in
      Section 3.5 of [RFC6376].

5.1.1.1.1.  Valid Range for "Instance" 'i' Tag Value

5.1.1.1.1.1.  Minimum 'i' Tag Value this header field.

   The minimum valid 'i' tag value is one (1).

5.1.1.1.1.2.  Maximum 'i' Tag Value

   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 maximum valid 'i' tag value is 1024, but values more that the
   supported number of intermediaries are meaningless.

5.1.1.2.  Differences between AMS SHOULD include any DKIM-Signature and ARC-Seal

   No 'bh' value is defined for ARC-Seal, since only message header fields are ever signed by already
   present on the ARC-Seal.

   ARC-Seal does not use message in the 'h' tag (the list of signed header fields)
   that is defined for DKIM-Signatures because the list of applicable fields covered by this
   signature.

   Authentication-Results header fields is fully determined SHOULD NOT be included since
   they are likely to be deleted by downstream ADMDs, thereby breaking
   the construction rules (see
   Section 5.1.1.3).

   ARC-Seal does not use AMS signature.

   As with a DKIM-Signature, the 'c' (canonicalization) tag because only
   'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal purpose of this header field canonicalization.

5.1.1.3.  Deterministic (Implicit) 'h' Tag Value for ARC-Seal

   In this section, the term "scope" is used to indicate those header
   fields signed by an ARC-Seal header field.  A number in parentheses
   indicates
   allow the instance of that field, starting at 1. ADMD generating it to take some responsibility for handling
   this message as it progresses toward delivery.

5.3.  ARC-Seal (AS)

   The suffix "-
   no-b" is used with an ARC-Seal field to indicate that its "b" header field is empty at the time defined.  It is syntactically and
   semantically similar to a DKIM-Signature field, with the signature following
   exceptions:

   o  There is computed, an "i" tag, as described in Section 3.5 of [RFC6376].  "AAR" refers to ARC-Authentication-
   Results, "AMS" to ARC-Message-Signature, "AS" to ARC-Seal, and "ASB"
   to an 4.

   o  The ARC-Seal with an empty "b" tag.

   Generally, the scope covers none of an ARC set for a message containing "n" ARC
   sets is the concatenation body content of the following, for x (instance number)
   from 1 to n:

   o  AAR(x);

   o  AMS(x);

   o  ASB(x) if x = n, else AS(x)

   Thus for message.  It
      only covers specific header fields.  (See below: Section 5.3.2.)
      As a message with result, no seals (i.e., upon injection), the scope of
   the first ARC set body canonicalization is AAR(1):AMS(1):ASB(1).  The ARC set thus
   generated would produce a first ARC-Seal with a "b" value.  The next
   ARC set would include in its signed content the prior scope, so it
   would have a scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2).

   Note: Typically header field sets appear within the done.  Further, only
      "relaxed" header in
   descending instance order.

5.1.1.4.  Computing the 'b' Tag Value for ARC-Seal canonicalization (Section 3.4.2 of [RFC6376]) is
      used.

   o  The ARC-Seal generation process mirrors only supported tags are "i" (Section 4 supercedes the procedure used for DKIM-
   Signature fields described in Section
      [RFC6376] definition), and "a", "b", "d, "s", "t".  The latter 5
      tag definitions are copied from Section 3.5 of [RFC6376] in that it [RFC6376].

   o  An additional tag, "cv" is at
   first generated with empty "b" field for the defined.  (See below: Section 5.3.1)

   The purpose of signature
   generation, and then the "b" value is added just prior to adding the
   ARC-Seal this field is to assure the message.

   In particular, signing calculation MUST be done in bottom-up order as
   specified in Section 5.4.2 of [RFC6376] and as illustrated above
   Section 5.1.1.3.

5.1.1.5.  Determining the 'cv' Tag Value for ARC-Seal

   In order for a series integrity of ARC sets to be considered valid, the
   following statements MUST be satisfied:

   1.  The chain of ARC sets must have structural integrity (no sets or set component header fields missing, no duplicates, excessive
       hops (cf.  Section 5.1.1.1.1), etc.);

   2.  All ARC-Seal header fields MUST validate;

   3.  All ARC-Seal header fields MUST have a chain value (cv=) status
       of "pass" (except
   being added by the first which MUST be "none"); and

   4.  The newest (highest instance number (i=)) AMS ADMD generating this header field MUST
       validate.

5.1.1.5.1.  Pseudocode field, and moreover to Determine Chain Value Status:

   In the algorith below, a "hop" is represented by
   ensure no tampering with the ARC set bearing
   a particular instance number. overall.

5.3.1.  The number of hops 'cv' Tag

   A new tag "cv" (chain validation) is defined, which indicates the same as the
   highest instance number found in
   state of the ARC sets, or 0 (zero) if there
   are no ARC sets found within the header.

   "Success" means that the signature found in the referenced header
   validates chain as evaluated when checked against it arrived at the specified content.

   if (lastest_hop.AS.cv == "fail") {
     terminate analysis - ADMD
   adding this header field.  It includes one of three possible values:

   o  none: There was no further ARC processing
   }

   if (chain not structurally valid) {
     return "fail"
   } else if (num_hops == 0) {
     return "none"
   } else {
     if (validate(latest_hop.AMS) != success) {
       return "fail"
     } else {
       // note that instance is always >= 1 by definition chain on the message when it arrived for each hop (from highest instance to lowest) {
         if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or
             (hop_num == 1 and hop.ARC-Seal.cv == "none")) {
           if (validate(hop.ARC-Seal) != success) {
             return "fail"
           }
         } else {
           return "fail"
         }
       }
     }

     return "pass"
   }

5.1.2.  ARC-Message-Signature

   The ARC-Message-Signature header field is
      validation; typically occurs when the message arrives at a special variant of Message
      Transfer Agent (MTA) from a
   DKIM-Signature [RFC6376].

   The ARC-Message-Signature header field can appear multiple times Message Submission Agent (MSA) or when
      any upstream MTAs may not be participating in ARC handling;

   o  fail: The message has a
   single chain whose validation failed;

   o  pass: The message but each instance MUST have has a unique "i=" value.

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

5.1.2.1.1. chain whose validation succeeded.

   In ABNF terms:

    seal-cv-tag = %x63.76 [FWS] "=" [FWS]
                  ("none" / "fail" / "pass")

5.3.2.  Selected Header Fields Eligible For ARC-Message-Signature Inclusion

   Participants may include any other header fields within the scope of
   the ARC-Message-Signature signature except that they MUST NOT include
   ARC-Seal headers fields.  In particular, including all DKIM-Signature
   header fields and all ARC-Authentication-Results header fields is
   RECOMMENDED.

   The advice regarding headers to include or avoid for
   ARC-Message-Signature ARC-Seal signature is otherwise identical to that specified in
   section 5.4 an encryption of [RFC6376].

5.1.2.1.2.  "Canonicalization" 'c' Tag Value

   The ARC-Message-Signature header field MUST be created using the
   header and body canonicalization rules mechanisms in Section 3.4 hash of
   [RFC6376].  The corresponding "c=" tag value MUST be specified in the
   AMS header field value.

5.1.2.1.3.  "Instance" 'i' Tag Value

   Contrary to DKIM, the 'i' tag for ARC-Message-Signature identifies the sequential instance
   concatenation of the field, thus indicating that it is part canonicalized form of a particular the ARC set.  That is, an ARC-Message-Signature, ARC-
   Seal, and ARC-Authentication-Results all bearing an "i=" tag with sets present on
   the
   same value are part message at the time of sealing, in increasing instance order,
   starting at 1, including the same ARC set (see Section 5.1.1.1).

5.1.2.1.4.  'v' Tag Value

   There is no "v" tag for ARC-Message-Signature.

5.1.2.2.  Computing the 'b' Tag Value for ARC-Message-Signature

   As with DKIM-Signature and ARC-Seal header fields, one being added at the "b" tag time of sealing
   the message.

   Within a set, the header fields are presented in the following order:

   1.  ARC-Authentication-Results
   2.  ARC-Message-Signature is empty until

   3.  ARC-Seal

   Where the signature is actually
   computed, and only then ARC-Seal is the one being generated, it added is presented to the header field, before
   affixing
   hash function in its final form except with an empty "b=" value, in
   the ARC-Message-Signature same manner by which a DKIM-Signature signs itself.

6.  Verifier Actions

   The verifier takes the following steps to determine the current state
   of the ARC on the message:

   1.  Collect all ARC sets currently on the message.

   As with ARC-Seal  If there were
       none, the ARC state is "none" and DKIM-Signature header fields, the order algorithm stops here.

   2.  If any ARC set is invalid (e.g., does not contain exactly one of
   header fields signed MUST be done in bottom-up order.

5.1.3.  ARC-Authentication-Results

   [[ Note: The intent
       each of the AAR header is to provide the necessary
   information for meaningful DMARC reporting back to the originating
   ADMD.  As such, it needs to include additional information than the
   user-focused Authentication-Results three ARC-specific header [RFC7601] but fields), then the details
   of that incremental information have not yet been fully determined.
   ]]

   ARC-Authentication-Results chain
       state is a copy "fail" and the algorithm stops here.

   3.  Conduct verification of the Authentication-Results ARC-Message-Signature header field [RFC7601] value with
       bearing the corresponding ARC-set highest instance
   ("i=") tag value prefixed to the Authentication-Results value string.
   Since Authentication-Results headers are frequently deleted from a
   message's header list, number.  If this verification fails,
       then the AAR chain state is created for archival purposes by
   each ARC-participating ADMD outside of "fail" and the trust boundary of algorithm stops here.

   4.  For each ARC-Seal from the
   originating system.

   The "N"th instance identifier MUST be separated from to the rest of first, apply the
       following logic:

       1.  If the
   Authentication-Results value contents with a semi-colon (';', 0x3b).

   The value of the header field (after removing comments) consists of
   an instance identifier, an authentication identifier, "cv" tag on that seal is "fail", the
           chain state is "fail" and then a
   series the algorithm stops here.

       2.  If the instance number being processed is greater than 1 and
           the value of statements the "cv" tag is "none", the chain state is
           "fail" and supporting data, as described in [RFC7601].
   The header field can appear multiple times in a single message but
   each the algorithm stops here.

       3.  If the instance MUST have a unique "i=" value.

5.1.3.1.  'i' Tag Value

   ARC-Authentication-Results requires inclusion number being processed is 1 and the value of an "i="
           the "cv" tag before is not "none", the "authserv-id" which indicates chain state is "fail" and the ARC set
           algorithm stops here.

       4.  Prepare a hash function corresponding to which it belongs as
   described in the previous section (see Section 5.1.1.1).

   The "i=" "a" tag MUST be separated from the rest of the Authentication-
   Results value contents with a semi-colon (';', 0x3b).

5.2.  Constructing
           ARC-Seal.

       5.  Compute the ARC-Seal Set

   The ARC-Seal is built in canonicalized form of the same fashion as ARC header fields, in
           the analogous DKIM-
   Signature [RFC6376], order described in Section 5.3.2, using the relaxed "relaxed"
           header canonicalization rules
   specified defined in that document but with a strict ordering component for (Section 3.4.2 of
           [RFC6376].  Pass them to the header fields covered by hash function.

       6.  Retrieve the cryptographic signature:

   1.  The ARC sets MUST be ordered in descending instance (i=) order.

   2.  The referenced ARC-Message-Signatures (matching i= value) MUST
       immediately follow final digest from the ARC-Seal instance which included hash function.

       7.  Retrieve the
       reference.

   3.  The associated ARC-Authentication-Results header field (matching
       i= value) MUST be public key identified by the last item "s" and "d" tags in
           the list for each set ARC-Seal, as described in Section 8.

       8.  Determine whether the signature portion ("b" tag) of ARC
       header fields.

   Thus, when prefixing ARC header fields the ARC-
           Seal and the digest computed above are valid according to the existing header,

   1.
           public key.

       9.  If the AAR header would be prefixed first; then

   2. signature is not valid, the AMS would be calculated chain state is "fail" and prefixed (above
           the AAR);

   3.  lastly algorithm stops here.

   5.  If all seals pass validation, then the AS would be calculated chain state is "pass", and prefixed (above
       the AMS). algorithm is complete.

   The ARC-Message-Signature field(s) MUST not include verifier should record the cv state for subsequent use by any of
   sealing which may be done later (potentially after message
   modification) within the ARC-
   Seal header field(s) (from prior ARC sets) in their signing scope in
   order maintain a separation same trust boundary.  The cv state may be
   recorded by sealing at the time of responsibilities.  When adding verification in an ARC-
   Authentication-Results header field, it MUST additional ARC
   set or may be added before
   computing recorded out of band depending on the ARC-Message-Signature.  When "sealing" architecture of
   the message, an
   operator MUST create and attach ADMD.

7.  Signer Actions

   This section includes a walk-through of the ARC-Message-Signature before actions an ARC signing
   implementation takes when presented with a message.

   The signing agent should undertake the
   ARC-Seal in order to reference it and embed following steps:

   1.  Do any authentication steps that the ARC-Message-Signature ADMD normally does:

       1.  If a message is traveling within the ARC-Seal signature scope.

   Each ARC-Seal is connected to its respective ARC-Message-Signature
   and ARC-Authentication-Results through same trust boundary,
           this would include any transitive trust conveyance with the common value of
           message;

       2.  If a message is coming from outside the "i="
   tag.

5.2.1.  Handling Minor Violations in same trust boundary,
           this would include any SPF / DKIM / DMARC / other
           authentication evaluation steps.

   2.  Do any DKIM signing or authentication assertion steps that the ARC Sets

   When ordering
       ADMD normally does.

   3.  Generate and optionally attach to the ARC message an Authentication-
       Results header field sets, misordering of header fields
   MUST be resolved as follows:

   o  Within each set, header fields are sorted as specified in using the ADMD's authserv-id (see
       Section 5.2; then

   o  Any remaining order dependencies between sets (e.g., such as
      different hash algorithms) MUST be ordered as follows:

   1.  (First) By descending order of i=; then

   2.  (Second) By descending order 2.5 of t= (from [RFC7601]) indicating whatever authentication
       might have been done by the ARC-Seal header
       field within MTA, or possibly indicate that none
       was done.

       1.  If an ARC chain exists on the set); message, then

   3.  (Finally) By ascending US-ASCII [RFC1345] sort order for the
       entire canonicalized header field set

   The intent of specifying this ordering is to allow downstream message
   handlers "N" equal to add their own ARC sets in a deterministic manner and to
   provide some resiliance against downstream MTAs which may reorder
   header fields.

5.2.2.  Handling Major Violations in the ARC Sets

   Gross violations of
           the ARC protocol definition (e.g., such as
   duplicated highest instance numbers or missing header fields or header field
   sets) MUST be terminated by the detecting system setting 'cv=fail' in number found on the ARC-Seal header.  The status of chain (i=);
           otherwise set "N" equal to zero for the ARC evaluation reported in following steps.

   4.  Generate and attach to the corresponding AAR message an ARC-Authentication-Results
       header field MUST be 'unknown'.

   Because using instance number N+1 and the violations can not be readily enumerated, same content from
       the header
   fields signed by previous step.

   5.  Generate and attach to the AS message an ARC-Message-Signature
       header field in using the case general algorithm described in Section 5
       of a major violation
   MUST be only the matching 'i=' instance headers created by the MTA
   which detected the malformed chain, [RFC6376] and as if this newest ARC set was modified in Section 5.1 above, using instance
       number N+1.

   6.  Generate and attach to the
   only set present.

   Downstream MTAs SHOULD NOT attempt any analysis on message an ARC ARC-Seal header field using
       the general algorithm described in Section 5.3 above, using a
       chain that
   has been marked 'fail'.

5.3. validation status as determined in Section 6 and instance
       number N+1.

8.  Key Management and Binding

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

5.3.1.  Namespace

   All ARC-related keys

9.  Usage of Chain Validity

9.1.  Assessing Chain Validity Violations

   There are stored in the same namespace as DKIM keys
   [RFC6376]: "_domainkey" specifically by adding the "._domainkey"
   suffix to the name a wide variety of ways in which the key (the "selector").  For example, given
   an ARC-Seal (or ARC-Message-Signature) field ARC set of a "d=" tag value header
   fields can be broken.  Receivers need to be wary of
   "example.com" and an "s=" value of "foo.bar", the DNS query seeking
   the public key will a query at the name
   "foo.bar._domainkey.example.com".

5.4.  Supporting Alternate Signing Algorithms

   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.

5.4.1.  Introductory Period

   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.

5.4.2.  Co-Existence Period

   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.

5.4.3.  Deprecation Period

   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.

5.4.4.  Obsolescence Period

   ARC sets which are created with obsolete algorithms must be ignored.

6.  Usage

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

6.1.  Participation

   The inclusion of additional ARC sets is to be done whenever a trust
   boundary is crossed, and especially when prior DKIM-Signatures might
   not survive the handling being performed such as some mailing lists
   that modify the content of messages or some gateway transformations.
   Note that trust boundaries might or might not exactly correspond with
   ADMD boundaries.  Some organizations may have internal trust
   boundaries within a single ADMD or have trust boundaries which span
   more than one ADMD.

   Each participating ADMD MUST validate the preceding ARC set as a part
   of asserting their own seal.  Until the chain is determined to be
   failed, and marked with an ARC set bearing the "cv=fail" indication,
   each participating ADMD SHOULD apply their own seal.

6.2.  Relationship between DKIM Signatures and ARC Headers

   ARC-aware DKIM signers do not DKIM-sign any ARC header fields.

6.3.  Validating the ARC Set of Header Fields

   Determining the validity of a chain of ARC sets is defined above in
   Section 5.1.1.5.  Validation failures MUST be indicated with a "cv="
   tag value of 'fail' when attaching a subsequent ARC-Seal header
   field.

6.4.  ARC Set Validity

6.4.1.  Assessing Chain Validity Violations

   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 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 messages bearing a valid chain of ARC
   header sets.

9.2.  Marking and Sealing Invalid Chains

   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.)

9.3.  Handling DNS Problems While Validating ARC

   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.

9.4.  Responding to ARC Validity Violations

   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
   [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
   corresponding SMTP response code.

9.5.  Recording the Results of ARC Evaluation

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

9.5.1.  Output Information from an ARC Evaluation

   The evaluation of a valid chain series of ARC sets results in the following data
   which MAY be used to inform local-policy decisions:

   o  A list of the "d=" domains found in the validated (== all) ARC-
      Seal header sets.

6.4.2.  Marking and Sealing Invalid Chains fields;

   o  The header fields signed by "d=" domain found in the AS most recent (highest instance number)
      AMS header field b= value in (since that is the only one necessarily
      validated)

   In the case of a major violation MUST be failed chain, only the matching 'i=' instance headers
   created terminal ARC set is covered
   by the MTA which detected ARC-Seal so the malformed chain, as if this
   newest reporting is limited to the findings in that
   terminal ARC set was set.

9.5.2.  Reporting ARC Effects for DMARC Local Policy - Interim

   [[ Note: Discussion on the only set present.  (This 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 same procedure
   required for handling major/structural validity problems.)

6.4.3.  Responding to note at
   Section 5.1) ]]

   Receivers SHOULD indicate situations in which ARC Validity Violations

   If evaluation
   influenced the results of their local policy determination.  DMARC
   reporting of ARC-informed decisions is augmented by adding a receiver determines that
   local_policy comment explanation containing the list of data
   discovered in the ARC chain has failed, evaluation (Section 9.5.1):

   <policy_evaluated>
     <disposition>delivered</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass ams=d2.example d=d2.example,d1.example</comment>
     </reason>
   </policy_evaluated>

   In the suggested sample, d2.example is the receiver
   MAY signal sealing domain for ARC[2]
   and d1.example is the breakage through 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 extended SMTP response code 5.7.7
   [RFC3463] "message integrity failure" [ENHANCED-STATUS] series of handlers.  DMARC report consumers should be
   aware of this behaviour and
   corresponding SMTP response code.

6.4.4.  Recording make the Results necessary accommodations.

10.  Supporting Alternate Signing Algorithms

   [[ Note: Some additional development of ARC Evaluation

   Receivers MAY add this section is needed. ]]

   In the following branch diagrams, each algorithm is represented by an "arc=pass"
   'A' or "arc=fail" method annotation into
   a locally-affixed Authentication-Results [RFC7601] header field.

6.4.5.  Output Data Points from 'B' at each hop to depict the ARC Evaluation

   The evaluation of chain that develops over a series
   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 ARC sets results in the following data statements in this spec which MAY be used refer to inform local-policy decisions:

   o  A list "exactly
   one set of the "d=" domains found in the validated (all) ARC-Seal
      header fields;

   o  The "d=" domain found in the most recent (highest ARC headers per instance" need to be understood as "at
   least one set per instance number)
      AMS header field (since that is the only and no more than one necessarily
      validated)

6.4.6.  Reporting instance-set per
   algorithm".

10.1.  Introductory Period

   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.

10.2.  Co-Existence Period

   Intermediaries MUST be able to validate ARC Effects chains build with either
   algorithm and MUST create ARC sets with both algorithms.  Chains
   ending with either algorithm may be used for DMARC Local Policy - Interim

   [[ Note: Discussion on the IETF DMARC-WG list has indicated some
   interest in more substantial reporting for analytic purposes.  To
   support result.

10.3.  Deprecation Period

   ARC sets built with algorithms that effort, the following guidance is provided only as an
   interim, minimal data set.  A more complete reporting construct will are being deprecated MAY be specified in a related spec - TBD. (see also the note at
   Section 5.1.3) ]]
   Receivers SHOULD indicate situations in which
   considered valid within an ARC evaluation
   influenced chain, however, intermediaries MUST
   not create additional sets with the results of their local policy determination.  DMARC
   reporting of ARC-informed decisions is augmented by adding a
   local_policy comment explanation as follows:

   <policy_evaluated>
     <disposition>delivered</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass ams=d1.example d=d1.example,d2.example</comment>
     </reason>
   </policy_evaluated>

7. deprecated algorithm.

   The deprecation period should be at least two (2) years.

11.  Privacy Considerations

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

8.

12.  IANA Considerations

   This specification adds three new header fields as defined below.

8.1.

12.1.  Authentication-Results Method Registry Update

   This draft adds one item to the IANA "Email Authentication Methods"
   registry:

   o  Method : arc

      Defined: [I-D.ARC]

      ptype: header

      Property: chain evaluation result

      Value: chain evaluation result status (see Section 5.1.1.1) 5.3)

      Status: active
      Version: 1

8.2.

12.2.  Definitions of the ARC header fields

   This specification adds three new header fields to the "Permanent
   Message Header Field Registry", as follows:

   o  Header field name: ARC-Seal

      Applicable protocol: mail

      Status: draft

      Author/Change controller: OAR-Dev Group IETF

      Specification document(s): [I-D.ARC]

      Related information: [RFC6376]

   o  Header field name: ARC-Message-Signature

      Applicable protocol: mail

      Status: draft

      Author/Change controller: OAR-Dev Group IETF

      Specification document(s): [I-D.ARC]

      Related information: [RFC6376]

   o  Header field name: ARC-Authentication-Results

      Applicable protocol: mail

      Status: standard

      Author/Change controller: IETF

      Specification document(s): [I-D.ARC]

      Related information: [RFC7601]

9.

13.  Implementation Status

   [[ Note to the RFC Editor: Please remove this section before
   publication along with the reference to [RFC6982]. ]]
   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 [RFC6982].
   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.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   This information is known to be correct as of the third seventh
   interoperability test event which was held on 2016-06-17.

9.1. 2017-07-15 & 16 at
   IETF99.

13.1.  GMail test reflector and incoming validation

   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 [ARC-DRAFT] [ARC-DRAFT-03]

   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 [1]

9.2.

13.2.  AOL test reflector and internal tagging

   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 [ARC-DRAFT] [ARC-DRAFT-03]

   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 [2]

9.3.

13.3.  dkimpy

   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 [ARC-TEST]
   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

9.4.

13.4.  OpenARC

   Organization: TDP/Murray Kucherawy

   Description: Implemention of milter functionality related to the
   OpenDKIM and OpenDMARC packages

   Status of Operation: Beta

   Coverage: Built to support [ARC-DRAFT] [ARC-DRAFT-03]
   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.

 Initial testing during the
 interop event on 2016-06-17 showed that it can be operational, but the
 documentation regarding configuration settings is unclear and the
 generated signature values do not validate when compared to the Google,
 AOL or dkimpy implementations.

 Testing during the 2017-02-24 interop event showed that some of the
 problems have been fixed, but there are still interoperability problems
 when trying to use OpenARC in a "sandwich" configuration around a MLM.

   Contact Info: arc-discuss@dmarc.org [3]

9.5.

13.5.  Mailman addition

   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]

9.6. https://www.gnu.org/software/mailman/contact.html

13.6.  Copernica/MailerQ web-based validation

   Organization: Copernica

   Description: Web-based validation of ARC-signed messages

   Status of Operation: Beta

   Coverage: Built to support [ARC-DRAFT] [ARC-DRAFT-03]

   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/]
   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/]

9.7.

13.7.  Rspamd

   Organization: Rspamd community

   Description: ARC signing and verification module

   Status of Operation: Production, though deployment usage is unknown

   Coverage: Built to support [ARC-DRAFT] [ARC-DRAFT-03]

   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]

10.

13.8.  PERL Mail::Milter::Authentication module

   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 [I-D.ARC]

   Licensing: Open Source

   Implementation Notes:

   Contact Info: https://github.com/fastmail/authentication_milter

14.  Security Considerations

   The Security Considerations of [RFC6376] and [RFC7601] 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:

   1.  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.

   2.  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.

10.1.

14.1.  Message Content Suspicion

   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.

11.

15.  References

11.1.

15.1.  Normative References

   [RFC1345]  Simonsen, K., "Character Mnemonics and Character Sets",
              RFC 1345, DOI 10.17487/RFC1345, June 1992,
              <http://www.rfc-editor.org/info/rfc1345>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2142]  Crocker, D., "Mailbox Names for Common Services, Roles and
              Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
              <http://www.rfc-editor.org/info/rfc2142>.

   [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
              <http://www.rfc-editor.org/info/rfc2606>.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              RFC 3463, DOI 10.17487/RFC3463, January 2003,
              <http://www.rfc-editor.org/info/rfc3463>.

   [RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
              Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
              September 2006, <http://www.rfc-editor.org/info/rfc4686>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5585]  Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
              Identified Mail (DKIM) Service Overview", RFC 5585,
              DOI 10.17487/RFC5585, July 2009,
              <http://www.rfc-editor.org/info/rfc5585>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

   [RFC5863]  Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development,
              Deployment, and Operations", RFC 5863,
              DOI 10.17487/RFC5863, May 2010,
              <http://www.rfc-editor.org/info/rfc5863>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <http://www.rfc-editor.org/info/rfc6376>.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
              September 2011, <http://www.rfc-editor.org/info/rfc6377>.

   [RFC6651]  Kucherawy, M., "Extensions to DomainKeys Identified Mail
              (DKIM) for Failure Reporting", RFC 6651,
              DOI 10.17487/RFC6651, June 2012,
              <http://www.rfc-editor.org/info/rfc6651>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <http://www.rfc-editor.org/info/rfc7208>.

   [RFC7601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7601,
              DOI 10.17487/RFC7601, August 2015,
              <http://www.rfc-editor.org/info/rfc7601>.

11.2.

15.2.  Informative References

   [ARC-DRAFT]

   [ARC-DRAFT-03]
              Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S.
              Jones, "Authenticated Received Chain (ARC) Protocol
              (I-D-03)", April 2017, <https://tools.ietf.org/html/draft-
              ietf-dmarc-arc-protocol-03>.

   [ARC-TEST]
              Blank, S., "ARC Test Suite", January 2017,
              <https://github.com/ValiMail/arc_test_suite>.

   [ARC-USAGE]
              Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
              "Recommended Usage of the ARC Headers", December 2017,
              <https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-
              01>.

   [ENHANCED-STATUS]
              "IANA SMTP Enhanced Status Codes", n.d.,
              <http://www.iana.org/assignments/smtp-enhanced-status-
              codes/smtp-enhanced-status-codes.xhtml>.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <http://www.rfc-editor.org/info/rfc6982>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <http://www.rfc-editor.org/info/rfc7489>.

   [RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
              E., Ed., and K. Andersen, Ed., "Interoperability Issues
              between Domain-based Message Authentication, Reporting,
              and Conformance (DMARC) and Indirect Email Flows",
              RFC 7960, DOI 10.17487/RFC7960, September 2016,
              <http://www.rfc-editor.org/info/rfc7960>.

11.3.

15.3.  URIs

   [1] mailto:arc-discuss@dmarc.org

   [2] mailto:arc-discuss@dmarc.org

   [3] mailto:arc-discuss@dmarc.org

   [4] mailto:dmarc@ietf.org

   [5] mailto:arc-discuss@dmarc.org

Appendix A.  Appendix A - Example Usage (Obsolete but retained for
             illustrative purposes)

   [[ 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. updates which will be included in draft
   -08. ]]

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:

   o  example.org performs authentication checks

   o  No previous Auth-Results or ARC-Seal headers are present

   o  example.org adds ARC-Auth-Results header

   o  example.org adds Received: header

   o  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=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 <arc@example.org>; 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 <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:

   o  example.com performs usual authentication checks

   o  example.com adds Auth-Results: header, Received header

   o  Determines that message fails DMARC

   o  Checks for ARC-Seal: header; finds one

   o  Validates the signature in the ARC-Seal: header, which covers the
      ARC-Authentication-Results: header

   o  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=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 <arc@example.org>; 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 <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:

   o  example.org performs authentication checks

   o  example.org applies standard DKIM signature

   o  No previous Auth-Results or ARC-Seal headers are present

   o  example.org adds ARC-Auth-Results header

   o  example.org adds usual Received: header

   o  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=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 <arc@example.org>; 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 <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:

   o  gmail.com performs usual authentication checks

   o  gmail.com adds Auth-Results: and Received: header

   o  Determines that message fails DMARC

   o  Checks for ARC-Seal: header; finds one

   o  Validates the signature in the ARC-Seal: header, which covers the
      ARC-Authentication-Results: header

   o  Uses the ARC-Auth-Results: values, but:

   o  Instead of delivering message, prepares to forward message per
      user settings

   o  Applies usual DKIM signature

   o  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=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 <mailbox@gmail.com>; 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 <arc@example.org>; 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 <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:

   o  example.com performs usual authentication checks

   o  example.com adds Auth-Results: header, Received header

   o  Determines that message fails DMARC

   o  Checks for ARC-Seal: header; finds two

   o  Validates the signature in the highest numbered ("i=2") ARC-Seal:
      header, which covers all previous ARC-Seal: and ARC-
      Authentication-Results: headers

   o  Validates the other ARC-Seal header ("i=1"), which covers the ARC-
      Authentication-Results: header

   o  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=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 <mailbox@gmail.com>; 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 <arc@example.org>; 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 <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=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 <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:

   o  example.org performs authentication checks

   o  example.org applies standard DKIM signature

   o  Checks for ARC-Seal: header; finds one (i=1)

   o  Validates the signature in the ARC-Seal (i=1): header, which
      covers the d1.example ARC-Message-Signature: header

   o  example.org adds ARC-Auth-Results header

   o  example.org adds usual Received: header
   o  example.org adds a DKIM-Signature

   o  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:

   Return-Path: <jqd@d1.example>
   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 <arc@example.org>; 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 <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:

   o  gmail.com performs usual authentication checks

   o  gmail.com adds Auth-Results: and Received: header

   o  Determines that message fails DMARC

   o  Checks for ARC-Seal: header; finds two

   o  Validates the signature in the ARC-Seal (i=2): header, which
      covers the ARC-Authentication-Results: header

   o  Validates the signature in the ARC-Seal (i=1): header, which
      covers the d1.example ARC-Message-Signature: header

   o  Uses the ARC-Auth-Results: values, but:

   o  Instead of delivering message, prepares to forward message per
      user settings

   o  Applies usual DKIM signature

   o  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:

   Return-Path: <jqd@d1.example>
   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 <mailbox@gmail.com>; 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 <arc@example.org>; 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 <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:

   o  example.com performs usual authentication checks

   o  example.com adds Auth-Results: header, Received header

   o  Determines that message fails DMARC

   o  Checks for ARC-Seal: header; finds three

   o  Validates the signature in the highest numbered ("i=2") ARC-Seal:
      header, which covers all previous ARC-Seal: and ARC-
      Authentication-Results: headers

   o  Validates the other ARC-Seal header ("i=2"), which covers the ARC-
      Authentication-Results: header

   o  Validates the other ARC-Seal header ("i=1"), which covers the
      d1.example ARC-Message-Signature: header

   o  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=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 <mailbox@gmail.com>; 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 <arc@example.org>; 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 <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.

   Grateful appreciation is extended to the people who provided feedback
   through the discuss mailing list.

Appendix C.  Comments and Feedback

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

Authors' Addresses

   Kurt Andersen
   LinkedIn
   1000 West Maude Ave
   Sunnyvale, California  94043  94085
   USA

   Email: kurta@linkedin.com

   Brandon Long (editor)
   Google

   Email: blong@google.com

   Steven Jones (editor)
   TDP

   Email: smj@crash.com

   Murray Kucherawy (editor)
   TDP

   Email: superuser@gmail.com