DMARC Working Group                                          K. Andersen
Internet-Draft                                                  LinkedIn
Intended status: Experimental                               B. Long, Ed.
Expires: October 25, December 26, 2018                                        Google
                                                           S. Jones, Ed.
                                                                     TDP
                                                           S. Blank, Ed.
                                                                Valimail
                                                       M. Kucherawy, Ed.
                                                                     TDP
                                                          April 23,
                                                         T. Draegon, Ed.
                                                                dmarcian
                                                           June 24, 2018

              Authenticated Received Chain (ARC) Protocol
                    draft-ietf-dmarc-arc-protocol-14
                    draft-ietf-dmarc-arc-protocol-15

Abstract

   The Authenticated Received Chain (ARC) protocol creates a mechanism
   whereby a series of handlers allows Internet Mail
   Handlers to attach assertions of an email message can conduct authentication of the email message as it passes among them on the
   way state to its destination, and create an attached, authenticated record
   individual messages.  As messages traverse ARC-enabled Internet Mail
   Handlers, additional ARC assertions can be attached to messages to
   form ordered sets of the status at ARC assertions that represent authentication
   state along each step along the of message handling path, for use by the
   final recipient in making choices about the disposition paths.

   ARC-enabled Internet Mail Handlers can process sets of the
   message.  Changes in the ARC assertions
   to inform message disposition decisions, to identify Internet Mail
   Handlers that might break existing authentication mechanisms can be identified through the ARC Set of
   header fields. mechanisms, and to
   convey original authentication state across trust boundaries.

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 https://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 October 25, December 26, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  General Concepts  .  Note to Reviewers in the DMARC WG . . . . . . . . . . . .   4
   2.  General Concepts  . . . . . . .   5
     1.2.  Differences Between ARC and DKIM . . . . . . . . . . . .   5
     1.3.  Definitions and Terminology . . .   5
     2.1.  Evidence  . . . . . . . . . . . .   6
       1.3.1.  Terms defined and used in this document . . . . . . .   6
       1.3.2.  Referenced Definitions . . . . .   5
     2.2.  Custody . . . . . . . . . .   7
   2.  Protocol Elements and Features . . . . . . . . . . . . . . .   7
     2.1.  The "ARC Set"   5
     2.3.  Chain of Header Fields  . Custody  . . . . . . . . . . . .   8
       2.1.1.  Instance Tags . . . . . . . .   5
     2.4.  Validation of Chain of Custody  . . . . . . . . . . . .   9
     2.2.  Chain Validation Status .   5
   3.  Terminology and Definitions . . . . . . . . . . . . . . . .   9
     2.3.  Trace Information .   6
     3.1.  ARC Set . . . . . . . . . . . . . . . . . . .   9
     2.4.  Key Management . . . . . .   6
     3.2.  Authenticated Received Chain (ARC)  . . . . . . . . . . .   7
     3.3.  Sealer  . . . .   9
     2.5.  All Failures are Permanent . . . . . . . . . . . . . . .  10
     2.6.  Chain of Custody . . . . . .   7
     3.4.  Validator . . . . . . . . . . . . . .  10
     2.7.  Optional Participation . . . . . . . . . .   7
     3.5.  Imported ABNF Tokens  . . . . . . .  10
     2.8.  Broad Responsibility to Seal . . . . . . . . . . .   7
     3.6.  Common ABNF Tokens  . . .  10
     2.9.  One Chain to Rule Them All . . . . . . . . . . . . . . .  11
     2.10. Sealing is Always Safe .   7
   4.  Protocol Elements . . . . . . . . . . . . . . . .  11
   3.  The ARC Header Fields . . . . . .   8
     4.1.  ARC Headers . . . . . . . . . . . . . .  11
     3.1.  Instance ('i=') Tag . . . . . . . . . . . . . . . . . . .  11
     3.2.   8
       4.1.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . . . .  12
     3.3.   8
       4.1.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . . . .  12
     3.4.   8
       4.1.3.  ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . .  13
       3.4.1.  Covered Header Fields .   9
     4.2.  ARC Set . . . . . . . . . . . . . . .  13
       3.4.2.  The 'cv' Tag . . . . . . . . . .  10
       4.2.1.  Instance Tags . . . . . . . . . .  14
   4.  Verifier Actions . . . . . . . . . .  11
     4.3.  Authenticated Received Chain  . . . . . . . . . . . .  14
     4.1.  Authentication-Results Information . .  11
     4.4.  Chain Validation Status . . . . . . . . .  15
     4.2.  Handling DNS Problems While Validating ARC . . . . . . .  16
     4.3.  Responding to ARC Validity Violations During the SMTP
           Transaction .  11
   5.  Protocol Actions  . . . . . . . . . . . . . . . . . . . . . .  16
   5.  12
     5.1.  Sealer Actions  . . . . . . . . . . . . . . . . . . . . .  12
       5.1.1.  Header Fields To Include In ARC-Seal Signatures . . .  16
     5.1.  13
       5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains  . . .  13
       5.1.3.  Only One Authenticated Received Chain Per Message . .  17
   6.  Recording and Reporting the Results of ARC Evaluation  14
       5.1.4.  Broad Ability to Seal . . . .  17
     6.1.  Information from an ARC Evaluation . . . . . . . . . . .  17
     6.2.  Recording (local) ARC Evaluation Results .  14
       5.1.5.  Sealing is Always Safe  . . . . . . .  17
     6.3.  DMARC Reporting of ARC Findings - Interim . . . . . . . .  18
   7.  Privacy Considerations  14
       5.1.6.  Signing vs Sealing  . . . . . . . . . . . . . . . . .  14

     5.2.  Validator Actions . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . .  14
       5.2.1.  All Failures Are Permanent  . . .  18
     8.1.  Authentication-Results Method Registry Update . . . . . .  19
     8.2.  Email Authentication Result Names Registry Update . . . .  19
     8.3.  Definitions of the  16
       5.2.2.  Responding to ARC header fields Validation Failures During the SMTP
               Transaction . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . .  16
     5.3.  Result of Validation  . . . . . . . .  20
     9.1.  Header Size . . . . . . . . . .  16
   6.  Communication of Validation Results . . . . . . . . . . . . .  20
     9.2.  DNS Operations  17
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . .  20
     9.3.  Message Content Suspicion . . . . .  17
     7.1.  Communicate Authentication Results Across Trust
           Boundaries  . . . . . . . . . . .  21
   10. Evaluating the Efficacy of the ARC Protocol (Experimental
       Considerations) . . . . . . . . . . . .  17
       7.1.1.  Message Scanning Services . . . . . . . . . . .  21
     10.1.  Success Consideration . . .  18
       7.1.2.  Multi-tier MTA Processing . . . . . . . . . . . . . .  21
     10.2.  Failure Considerations  18
       7.1.3.  Mailing Lists . . . . . . . . . . . . . . . . .  22
     10.3.  Open Questions . . .  18
     7.2.  Inform Message Disposition Decisions  . . . . . . . . . .  19
       7.2.1.  DMARC Local Policy Overrides  . . . . . . . .  22
       10.3.1.  Value of the ARC-Seal (AS) Header . . . .  19
       7.2.2.  DMARC Reporting . . . . .  22
       10.3.2.  DNS Overhead . . . . . . . . . . . . . .  19
   8.  Privacy Considerations  . . . . . .  22
       10.3.3.  Distinguishing Valuable from Worthless Trace
                Information . . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . .  22
   11. Implementation Status . . . . . . . . . . . .  20
     9.1.  Increased Header Size . . . . . . . .  23
     11.1.  GMail test reflector and incoming validation . . . . . .  24
     11.2.  AOL test reflector and internal tagging . . . .  21
     9.2.  DNS Operations  . . . .  24
     11.3.  dkimpy . . . . . . . . . . . . . . . . .  21
     9.3.  Message Content Suspicion . . . . . . . .  24
     11.4.  OpenARC . . . . . . . .  21
     9.4.  Message Sealer Suspicion  . . . . . . . . . . . . . . . .  25
     11.5.  Mailman 3.2 patch  22
     9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . .  25
     11.6.  Copernica/MailerQ web-based validation . .  22
   10. IANA Considerations . . . . . . .  25
     11.7.  Rspamd . . . . . . . . . . . . . .  22
     10.1.  Email Authentication Results Names Registry Update . . .  22
     10.2.  Email Authentication Methods Registry Update . . . . . .  22
     10.3.  Definitions of the ARC header fields . .  26
     11.8.  PERL MAIL::DKIM module . . . . . . . .  23
   11. Experimental Considerations . . . . . . . . .  26
     11.9.  PERL Mail::Milter::Authentication module . . . . . . . .  27
     11.10. Sympa List Manager  23
     11.1.  Success Consideration  . . . . . . . . . . . . . . . . .  23
     11.2.  Failure Considerations . .  27
     11.11. Oracle Messaging Server . . . . . . . . . . . . . . .  24
     11.3.  Open Questions .  27
     11.12. MessageSystems Momentum and PowerMTA platforms . . . . .  28
   12. References . . . . . . . . . . . . . . .  24
       11.3.1.  Value of the ARC-Seal (AS) Header  . . . . . . . . .  24
       11.3.2.  DNS Overhead .  28
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     12.2.  Informative References .  24
       11.3.3.  What Trace Information is Valuable . . . . . . . . .  24
   12. Implementation Status . . . . . . .  29
     12.3.  URIs . . . . . . . . . . . . .  25
     12.1.  GMail test reflector and incoming validation . . . . . .  26
     12.2.  AOL test reflector and internal tagging  . . . . . . .  30
   Appendix A.  Appendix A - Design Requirements .  26
     12.3.  dkimpy . . . . . . . . .  31
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . .  26
     12.4.  OpenARC  .  31
     A.2.  Out of Scope . . . . . . . . . . . . . . . . . . . . . .  31
   Appendix B.  Appendix B - Example Usage .  27
     12.5.  Mailman 3.x patch  . . . . . . . . . . . .  31
     B.1.  Example 1: Simple mailing list . . . . . . .  27
     12.6.  Copernica/MailerQ web-based validation . . . . . .  31
       B.1.1.  Here's the message as it exits the Origin: . . .  27
     12.7.  Rspamd . .  31
       B.1.2.  Message is then received at example.org . . . . . . .  32
       B.1.3.  Example 1: Message received by Recipient . . . . . .  34

     B.2.  Example 2: Mailing list to forwarded mailbox . . . . . .  35
       B.2.1.  Here's the message as it exits the Origin: . . . .  28
     12.8.  PERL MAIL::DKIM module .  35
       B.2.2.  Message is then received at example.org . . . . . . .  36
       B.2.3.  Example 2: Message received by Recipient . . . . . .  40
     B.3.  Example 3: Mailing list to forwarded mailbox with source   42
       B.3.1.  Here's the message as it exits the Origin: . . .  28
     12.9.  PERL Mail::Milter::Authentication module . .  42
       B.3.2.  Message is then received at example.org . . . . . .  28
     12.10. Sympa List Manager . . .  43
       B.3.3.  Example 3: Message received by Recipient . . . . . .  48
   Appendix C.  Acknowledgements . . . . . . . . . .  29
     12.11. Oracle Messaging Server  . . . . . . . .  50
   Appendix D.  Comments . . . . . . . .  29
     12.12. MessageSystems Momentum and Feedback PowerMTA platforms . . . . .  29
     12.13. Exim . . . . . . . . . .  51
   Authors' Addresses . . . . . . . . . . . . . . . .  29
   13. References  . . . . . . .  51

1.  Introduction

   Modern email authentication techniques such as the Sender Policy
   Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
   [RFC6376] have become common.  However, their end-to-end utility is
   limited by the effects of intermediaries along the transmission path,
   which either are not listed (for SPF) or which break digital
   signatures (for DKIM).  These issues are described in substantial
   detail in those protocols' defining documents as well as in [RFC6377]
   and [RFC7960].

   Technologies that build upon the use . . . . . . . . . . . . . . . . . .  30
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  30
     13.2.  Informative References . . . . . . . . . . . . . . . . .  31
     13.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  32
   Appendix A.  Appendix A - Design Requirements . . . . . . . . . .  32
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  33
     A.2.  Out of SPF and DKIM can reduce the
   success of fraudulent email campaigns.  To this end, Domain-based
   Mail Authentication, Reporting Scope  . . . . . . . . . . . . . . . . . . . . . .  33
   Appendix B.  Appendix B - Example Usage . . . . . . . . . . . . .  33
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  33
   Appendix D.  Comments and Conformance (DMARC) [RFC7489],
   validates the domain Feedback  . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

1.  Introduction

   The utility of the RFC5322.From header field.  However its
   use along widely deployed email transmission paths that have independent
   intermediaries, authentication technologies such
   as some forwarders Sender Policy Framework (SPF) [RFC7208] and essentially all mailing
   list services, produces false positive rejections that are
   problematic, both for the message authors, DomainKeys Identified
   Mail (DKIM) [RFC6376] is impacted by the intermediary
   service(s), and for those they are interacting with.

   [RFC7960] processing of Internet Mail
   by intermediate handlers.  This impact is thoroughly documented in
   the need defining documents for a mechanism which would survive
   legitimate alteration of a message, SPF and DKIM and further discussed in spite
   [RFC6377] and [RFC7960].

   The utility of breaking the
   associated technologies that build upon SPF and DKIM information so that the end receiver
   system(s) (such as
   DMARC [RFC7489]) is similarly impacted by intermediate handlers.  The
   disruption of authentication mechanisms for legitimate messages by
   intermediate handlers can avoid those false positive rejections on delivery. impact all aspects of Internet Mail -
   message authors, message recipients, and even the intermediary
   handler itself.

   Authenticated Received Chain (ARC) builds upon DKIM mechanisms to
   provide creates a sequence of signatures that provide a view of the handling
   sequence mechanism for individual
   Internet Mail Handlers to add their authentication processing results
   to a message, especially the points where alterations message's ordered set of
   the content might have occurred.  Equipped with this more complete
   information, the recipient system(s) can make processing results.  ARC encapsulates
   processing results in a more informed
   handling choice, reducing or eliminating DKIM signature derivative to grant other
   handlers the rejections that would
   occur with ability to verify the use of DKIM and/or SPF alone.

1.1.  General Concepts

   ARC provides a "chain authenticity of custody" for a message, allowing each entity
   that handles individual
   processing results as well as the message to see what entities handled it before, aggregate set and
   to see what the authentication status sequence of the
   results.

   Ordered sets of processing results can be used by ARC-enabled
   Internet Mail Handlers to inform message was at each step
   in the handling.  The handling entity can then put its own entry into
   the chain disposition, to
   identify where alteration of custody and then relay the message content might have occurred, and
   to the next handler.

   When the provide additional trace information for use in understanding
   message reaches final delivery, the decision handling paths.

1.1.  Note to accept and
   deliver Reviewers in the message, or, alternatively, DMARC WG

   [[ Note: This section is editorial to reject, discard, or
   quarantine it, can take the chain WG.  Will be removed for
   final version. ]]
   This version of custody into account, applying
   local policy in addition to policies advertised by the (purported)
   sending domain.  Consider, draft has been extensively reorganized for example, this scenario:

   1.  A sender from mysender.example posts a message to a mailing list
       hosted at listmania.example;

   2.  The mailing list modifies the message by prepending the list name
   readability.  No changes to the subject line, then sends it wire protocol or specification are
   intended from [ARC-DRAFT-14].

2.  General Concepts

   ARC is loosely based on concepts from evidence collection.  Evidence
   is usually collected, labeled, stored, and transported in specific
   ways to preserve the subscribers;

   3.  One state of evidence and to document all processing
   steps.

2.1.  Evidence

   In ARC's situation, the subscribers "evidence" is alice@mail.service.example, which
       receives a message's authentication
   state at any point along the message from listmania.example.

   Assuming the original message was DKIM-signed delivery path between origination and mysender.example
   published
   final delivery.  Authentication state can change when intermediate
   handlers modify message content, route messages through unforeseen
   paths, or change envelope information.

2.2.  Custody

   "Custody" refers to when an SPF record, the handling by the mailing list will break
   the DKIM signature because ARC-enabled Internet Mail Handler
   processes a message.  When a handler takes custody of a message, the message modification,
   handler becomes a Custodian and the
   forwarding will cause the SPF check attaches their own evidence
   (authentication state upon receipt) to fail in the next step.  But
   listmania.example message.  Evidence is
   added in such a way so that future handlers can add ARC headers to the message to add itself to verify the document's chain
   authenticity of both evidence and custody.  When mail.service.example sees

2.3.  Chain of Custody

   The "chain of custody" of ARC is the
   message, it can see that SPF entire set of evidence and DKIM validation fail, but it can
   also see
   custody that both travels with a message.

2.4.  Validation of these succeeded when they were checked by
   listmania.example, and Chain of Custody

   Any ARC-enabled Internet Mail Handler can verify listmania's assertion.

   As part validate the entire set of its evaluation
   evidence and custody to yield a valid Chain of Custody.  If the message for delivery,
   mail.service.example
   evidence-supplying Custodians can see that mysender.example publishes a DMARC
   policy asking that unauthenticated messages be rejected.  But is can
   also see the assertion by listmania.example that trusted, then the message was
   correctly authenticated when validated
   Chain of Custody describes the message arrived there, and if it
   accepts that assertion, it can accept (possibly changing) authentication
   state as the message for further
   processing, rather than reject it, based on the additional
   information that ARC has provided.

1.2.  Differences Between ARC and DKIM

   In DKIM, every participating signing agent attaches traveled through various Custodians.

   Even though a signature that
   is based on some of message's authentication state might have changed, the content
   validated chain of custody can be used to determine if the message, local policy, and changes
   (and the
   domain name of Custodians responsible for the signing agent's Administrative Management Domain
   (ADMD).  Any verifier changes) can process such a signature; a verified
   signature means that the domain referenced be tolerated.

3.  Terminology and Definitions

   This section defines terms used in the signature's "d="
   parameter has some responsibility for handling the message.  An
   artifact of using digital signature technology for this means that
   verification also ensures that the portion of the message that was
   "covered" by the signature has not been altered since the signature
   was applied.  The signatures themselves are generally independent of
   one another.

   In contrast, a validated ARC Set conveys the following pieces rest of
   information:

   1.  An assertion that, at the time that the intermediary ADMD
       processed the message, the various assertions (such as SPF, DKIM-
       Signature(s) and/or ARC Chain) already attached document.

   Readers should to the message by
       other ADMDs were or were not valid;

   2.  As be familiar with DKIM, an assertion that, for a validated ARC signature, the domain name contents, core concepts, and
   definitions found in the signature takes some responsibility for
       handling [RFC5598].  The potential roles of
   intermediaries in the message and that the covered content delivery of the
       message email is unchanged since that signature was applied;

   3.  A further assertion that binds the ARC evaluation results into
       the ARC Chain sequence.

1.3.  Definitions directly relevant.

   Language, syntax (including some ABNF constructs), and Terminology

   This section defines concepts are
   imported from DKIM [RFC6376].  Specific references to DKIM are made
   throughout this document.  The following terms used in the rest of are imported from
   [RFC5598]:

   o  ADministrative Management Domain (ADMD), Section 2.3

   o  Message Transfer Agents (MTA), Section 4.3.2

   o  Message Submission Agent (MSA), Section 4.3.1

   o  Message Delivery Agent (MDA), Section 4.3.3

   Internet Mail Handlers process and deliver messages across the document.
   Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists.

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP14 ([RFC2119][RFC8174]).

   Because many of the core concepts
   BCP 14 [RFC2119] [RFC8174] when, and definitions are found only when, they appear in
   [RFC5598], readers should 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].

1.3.1.  Terms defined and used all
   capitals, as shown here.  These words may also appear in this
   document

   o  "ARC-Authentication-Results" (AAR) - an ARC header field described in Section 3.2.

   o  "ARC-Message-Signature" (AMS) - an lower case as plain English words, absent their normative
   meanings.

3.1.  ARC header field described in Set

   Section 3.3.

   o  "ARC-Seal" (AS) - an Section 4.1 introduces three (3) ARC header field described in Section 3.4.

   o  "ARC Set" - A single group of fields.
   Together, the 3 header fields introduced in
      Section 2.1 is called an compose a single "ARC Set".

   o  "ARC Chain" -  An ARC Set
   provides the means for an Internet Mail Handler to attach
   authentication state to a message in a manner that can be verified by
   future handlers.  A single message can contain multiple ARC Sets.

   In General Concept terms, an ARC Set represents Evidence and Custody.

3.2.  Authenticated Received Chain (ARC)

   The complete sequence of ARC Sets for attached to a message.
      The ARC message is called the
   Authenticated Received Chain.  An Authenticated Received Chain represents is a "chain of custody" for the message,
   recording its of individual authentication status at each ARC-participating ADMD
      that handled the message.

1.3.2.  Referenced Definitions

   The following terms are defined in other RFCs.  Those definitions can
   be found states as follows:

   o  ADMD - [RFC5598], Section 2.3

   o  MTA - [RFC5598], Section 4.3.2

   o  MSA - [RFC5598], Section 4.3.1

   o  MDA - [RFC5598], Section 4.3.3 a message traverses
   through ARC-participating ADMDs.

   The three header fields that are part first attachment of this specification borrow
   heavily from existing specifications.  Rather than repeating all an ARC Set to a message causes an
   Authenticated Received Chain to be created.  Additional attachments
   of ARC Sets cause the formal definitions that are being reused in ARC, this document
   only describes and specifies changes in syntax and semantics.

   Language, syntax, and other details are imported from DKIM [RFC6376].
   Specific references can Authenticated Received Chain to be found below.

2.  Protocol Elements and Features

   As with other domain authentication technologies (such as SPF, DKIM,
   and DMARC), ARC makes no claims about the contents extended.

   In General Concept terms, an Authenticated Received Chain represents
   Chain of the email
   message it has sealed.  However, for a valid and passing ARC Chain, a
   Final Receiver Custody.

3.3.  Sealer

   A Sealer is able to ascertain:

   o  all (participating) domains an Internet Mail Handler that claim responsibility for handling
      (and possibly modifying) the email message in transit;

   o  trace information, including:

      *  the [RFC7601] Authentication-Results each participating ADMD
         saw; attaches a complete and

      *  additional data needed
   valid ARC Set to compile a DMARC report for the
         sending domain.

   Given this information, each receiver is able to make message.

   In General Concept terms, a more informed
   local policy decision regarding message processing and, ultimately,
   delivery to the end user in spite of authentication failure(s) Sealer adds Evidence and proof of Custody
   to
   inform the message orgination system(s) through the DMARC report(s).

   Every participant in an ARC Chain, except for the originating sender
   and Final Receiver, is both an ARC Chain of Custody.

3.4.  Validator

   A Validator (when receiving) and
   then an ARC Sealer (when sending a message onward).

   _INFORMATIONAL_: It is important to understand an ARC-enabled Internet Mail Handler that validating and
   then immediately sealing a message leaves no room evaluates an
   Authenticated Received Chain for message
   modification, validity and many early implementations content.  The process
   of evaluation of the individual ARC did not initially
   work because both operations were performed Sets that compose an
   Authenticated Received Chain is described in Section Section 5.2.

   In General Concept terms, a single pass over Validator inspects the
   message. Chain of Custody
   to determine the content and validity of individual Evidence supplied
   by Custodians.

3.5.  Imported ABNF Tokens

   The following protocol features are functional parts and design
   decisions related the protocol that ABNF tokens are not specific to either
   Validators or Sealers, but ensure that the ARC Chain conveys this
   information to a Final Receiver.

2.1. imported:

   o  tag-list ([RFC6376] section 3.2)

   o  authres-payload ([I-D-7601bis] section 2.2)

   o  cfws ([RFC5322] section 3.2.2)

3.6.  Common ABNF Tokens

   The "ARC Set" of Header Fields

   Each "ARC Set" consists of the following ABNF tokens are used elsewhere in this document:

   position = 1*2DIGIT ; 1 - 50
   instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";"
   chain-status = ("none" / "fail" / "pass")
   seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status

4.  Protocol Elements

4.1.  ARC Headers

   ARC introduces three new header fields:

   1.  ARC-Authentication-Results (referred to below as "AAR"):
       virtually identical fields.  Syntax for new header fields
   borrows heavily from existing specifications.  This document only
   describes where ARC-specific changes in syntax to an Authentication-Results field
       [RFC7601], this and semantics differ
   from existing specifications.

4.1.1.  ARC-Authentication-Results (AAR)

   The ARC-Authentication-Results (AAR) header field records the results of all message
   authentication checks done state as processed by the recording an ARC-participating ADMD at the time the
   message arrived.  Additional information is placed in this arrival time.

   In General Concept terms, the AAR header field
       compared to is where Evidence is
   recorded by a standard Authentication-Results Custodian.

   The AAR header field in order to
       support a more complete DMARC report;

   2.  ARC-Message-Signature (referred to below as "AMS"): virtually
       identical is similar in syntax and semantics to DKIM-Signature, this an
   Authentication-Results field contains [I-D-7601bis], with two (2) differences:

   o  the
       signature about name of the message header and body as they existed at field itself;

   o  the time presence of handling by the ADMD adding it (including any
       modifications made by "instance tag".  Additional information on the sealing ADMD); and

   3.  ARC-Seal (referred to below as "AS"): highly similar
      "instance tag" can be found in structure
       and format to a DKIM-Signature, this Section Section 4.2.1.

   The formal ABNF for the AAR header field applies a digital
       signature that protects is:

   arc-info = instance [CFWS] ";" authres-payload
   arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info

   Because there is only one AAR allowed per ARC set, the integrity of AAR MUST
   contain all three of these new
       fields when they are added by an authentication results from within the participating
   ADMD, plus all instances of
       these fields added by prior ADMDs.

   An ARC participant always adds all regardless of these header fields before
   relaying a message how many Authentication-Results headers are
   attached to the next handling agent _en route_ to its
   destination.  Moreover, they each have message.

4.1.2.  ARC-Message-Signature (AMS)

   The ARC-Message-Signature (AMS) header field allows an "instance number" that
   increases with each ARC Set in the handling chain so that their
   original order can be preserved ARC-
   participating ADMD to convey some responsibility (custodianship) for
   a message and possible message modifications to future ARC-
   participating Custodians.

   In General Concept terms, the three related AMS header fields
   can be processed as field identifies a set.

2.1.1.  Instance Tags

   ARC includes an indicator in its
   Custodian.

   The AMS header fields to show the order field is similar in
   which the header fields comprising an ARC Chain were added, syntax and semantics to a DKIM-
   Signature field [RFC6376], with three (3) differences:

   o  the
   specific members name of each ARC Set.  This is known as the "instance",
   and the indicator header field itself;

   o  no version tag ("v") is an "i=" tag/value.  That is, defined for the AMS header.  As required
      for undefined tags (in [RFC6376]), if seen, a version tag MUST be
      ignored;

   o  the members presence of the
   first ARC Set affixed to a message will all include "i=1".  This is
   described in detail "instance tag".  Additional information on the
      "instance tag" can be found in section Section 3.1.

2.2.  Chain Validation Status

   ARC includes a mechanism which denotes the state of Section 4.2.1.  The
      instance tag replaces the DKIM "AUID" tag.

   ARC Chain at
   each step.  The "chain validation status" ("cv" tag/value) is used to
   communicate places no requirements on the current chain status within selectors and/or domains used for
   the ARC Chain and also
   through Authentication-Results and ARC-Authentication-Results stamps
   as well as DMARC reporting. AMS header field signatures.

   The chain validation status has one of three possible values:

   o  none: There was no chain on the message when it arrived formal ABNF for
      validation; typically occurs when the message arrives at a Message
      Transfer Agent (MTA) or mediator from a Message Submission Agent
      (MSA) or when any upstream handlers may not be participating in
      ARC handling;

   o  fail: The message has a chain whose validation failed; AMS header field is:

   arc-ams-info = instance [CFWS] ";" tag-list
   arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info

   To avoid unwanted invalidation of AMS signatures:

   o  pass: The message has a chain whose validation succeeded.

2.3.  Trace Information

   ARC includes trace information encoded in the AAR.  While section
   Section 3.2 defines what information must be provided, sealing  AMS header fields are added by ARC-participating ADMDs
   may provide additional information, and validating receivers may use
   this trace information as they find it useful.

2.4.  Key Management

   The public keys for ARC messages
      exit the ADMD.  AMS header fields follow should be attached so that any
      modifications made by the same requirements,
   syntax and semantics as those for DKIM signatures, described ADMD are included in
   Section 3.6 of [RFC6376].  ARC places no requirements on the
   selectors and/or domains used for signature of
      the ARC AMS header field signatures.

2.5.  All Failures are Permanent

   Because ARC Chains are transmitted across multiple intermediaries,
   all errors, even temporary ones, become unrecoverable and are
   considered permanent.

   Any error validating or sealing a chain, for whatever reason, field.

   o  Authentication-Results header fields MUST
   result NOT be included in a "cv=fail" verdict AMS
      signatures as documented in they are likely to be deleted by downstream ADMDs
      (per Section 3.4.2.

2.6.  Chain 5 of Custody

   At a high level, an ARC Chain represents a chain [I-D-7601bis]).

   o  ARC-related header fields (ARC-Authentication-Results, ARC-
      Message-Signature, ARC-Seal) MUST NOT be included in the list of custody of
   authentication and other trace information (AAR) related to a
   message, signed by each handler
      header fields covered by the signature of the message.  Each link in AMS header field.

   To preserve the
   chain (AMS) is designed ability to be brittle, insofar as it survives only
   until verify the next modification integrity of a message, the message.  However, the sequence
   signature of
   intermediaries the AMS header field SHOULD include any DKIM-Signature
   header fields already present in the handling chain message.

4.1.3.  ARC-Seal (AS)

   The ARC-Seal (AS) header field is designed to remain
   intact over the entirety mechanism by which ARC-
   participating ADMDs can verify the integrity of AAR header fields and
   corresponding AMS header fields.

   In General Concept terms, the chain.

   The ARC AS header field is how Custodians bind
   Evidence into a Chain can be conceptualized through an analogy with the chain of custody for legal evidence. Custody so that Validators can inspect
   individual Evidence and Custodians.

   The material evidence itself AS header field is
   sealed within an tamper-proof bag (AMS) each time.  When handed similar in syntax and semantics to a
   new party, that party both vouches for DKIM-
   Signatures [RFC6376], with the state of following differences:

   o  the received
   evidence container (AAR) and signs for presence of the evidence "instance tag".  Additional information on a chain of
   custody report form (AS).  As with all analogies, this one should not
   be taken to interpretive extremes, but primarily used as a conceptual
   framework.

   An ARC Chain that is valid and passing has the attributes listed
   above
      "instance tag" can be found in Section 2.

2.7.  Optional Participation

   Validating an existing chain and then adding your own ARC Set to a
   message allows you to claim responsibility for handling Section 4.2.1.

   o  the signature of the AS header field does not cover the body of
      the message and modifications, if any, done by your ADMD to benefit message
   delivery downstream.  However, therefore there is no ADMD 'bh' tag.  The signature of
      the AS header field only covers specific header fields as defined
      in Section Section 5.1.1.

   o  no body canonicalization is obligated to perform these
   actions.

2.8.  Broad Responsibility to Seal

   Any mediator ([RFC5598], performed as the AS signature does not
      cover the body of a message.

   o  only "relaxed" header canonicalization ([RFC6376] section 5) 3.4.2)
      is used.

   o  the only supported tags are "i" (from Section Section 4.2.1 of
      this document), and "a", "b", "d, "s", "t" from Section 3.5 of
      [RFC6376].  Note especially that modifies the DKIM "h" header is NOT
      allowed and if found, MUST result in a message may seal
   its own changes.  ARC cv status of "fail" (for
      more information see Section 5.1.1;

   o  an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
      definition) is not solely intended for perimeter MTAs.

2.9.  One used to communicate Chain Validation Status to Rule Them All

   A message can have only one
      subsequent ADMDs.

   ARC Chain places no requirements on it at a time (see
   Section 3.1).  Once broken, the chain cannot be continued, as selectors and/or domains used for
   the
   chain of custody is no longer valid and responsibility AS header field signatures.

   The formal ABNF for the
   message has been lost.  For further discussion AS header field is:

   arc-as-info = instance [CFWS] ";" tag-list
   arc-seal = "ARC-Seal:" [CFWS] arc-as-info

4.2.  ARC Set

   An "ARC Set" is a single collection of this topic three ARC Headers (AAR, AMS,
   and the
   designed restriction which prevents chain continuation or re-
   establishment, see [ARC-USAGE].

2.10.  Sealing is Always Safe

   Even when AS).  ARC Headers of an ARC Chain is valid and passes, its value is limited to
   very specific cases.  An Set share the same "instance" value.

   By adding all ARC Chain is specifically designed Headers to
   provide additional information a message, an ARC Sealer adds an ARC Set
   to a receiver evaluating message
   delivery in the context message.  A description of an authentication failure and otherwise be
   benign.  Specifically:

   o  properly adding how Sealers add an ARC Set to a
   message does not damage or
      invalidate an existing chain,

   o  sealing a chain when you did not modify a message does not
      negatively affect the chain, and

   o  validating a message exposes no new threat vectors (see
      Section 9).

   _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
   and/or modifying a message, it may elect to seal all inbound mail.
   For complex or nested ADMD relationships such as found in some hosted
   mail solutions, this "inbound seal" can be used to facilitate
   traversal of internal boundaries as well as properly conveying
   incoming state to any egress MTAs that may need to assert a seal upon
   exit from the ADMD.  Since these internal relationships are highly
   implementation dependent, this protocol definition can not usefully
   explore such usage except Section Section 5.1.

4.2.1.  Instance Tags

   Instance tags describe which ARC Headers belong to note that it is intentionally allowed
   within the scope of this specification.

3.  The an ARC Set. Each
   ARC Header Fields

3.1.  Instance ('i=') Tag

   The header fields comprising a single of an ARC Set are identified by a
   common "instance" shares the same instance tag value.  The instance

   Instance tag is a string in each
   header field value values are integers that complies with the "tag-spec" ABNF found in
   Section 3.2 of [RFC6376].  The tag-name is "i" begin at 1 and the value is the
   text representation are incremented
   by each addition of a positive integer, indicating the position in an ARC Set. Through the incremental values of
   instance tags, an ARC sequence this set occupies, where Validator can determine the first order in which ARC Set is
   numbered 1.  In ABNF terms:

      position = 1*2DIGIT ; 1 - 50
      instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
   Sets were added to a message.

   Instance tag values can range from 1-50 (inclusive).

   Valid ARC Sets MUST have exactly one instance of each header ARC Header
   field
   (of three) (AAR, AMS, and AS) for a given instance value and signing
   algorithm.

   (_INFORMATIONAL:_

   _INFORMATIONAL:_ Initial development of ARC is only being done with a
   single allowed signing algorithm, but parallel work in the DCRUP
   working group [1] is expanding that.  For handling multiple signing
   algorithms, see [ARC-MULTI].)

   The 'i' tag value can range from 1-50 (inclusive).

   ARC Chains longer than the defined maximum count MUST be marked as
   failed.

   _INFORMATIONAL_: Because the AMS and AS header field values [ARC-MULTI].

4.3.  Authenticated Received Chain

   An Authenticated Received Chain is an ordered collection of ARC Sets.
   As ARC Sets are made
   up enumerated sets of ARC Headers, an Authenticated
   Received Chain represents the output of tag-spec constructs, message authentication state
   along the i= tag may be found anywhere within handling path of ARC-enabled processors.

   Results of message authentication processing along each step of the header field value, but
   ARC-enabled handling path is represented throughout this spec present in an Authenticated Received
   Chain in the initial position for convenience.  Implementers are encouraged form of AAR header fields.  The ability to
   place verify the i= tag at
   identity of message handlers and the beginning integrity of message content is
   provided by AMS header fields.  AS header fields allow messages
   handlers to validate the assertions, order and sequence of the field value
   Authenticated Received Chain itself.

   In General Concept terms, an Authenticated Received Chain represents
   a message's Chain of Custody.  Validators can consult a message's
   Chain of Custody to facilitate
   human inspection gain insight regarding each Custodian of a
   message and the headers.

3.2.  ARC-Authentication-Results (AAR) Evidence collected by each Custodian.

4.4.  Chain Validation Status

   The ARC-Authentication-Results header field state of the Authenticated Received Chain at a specific
   processing step is syntactically and
   semantically identical, except for called the header field name itself and
   its instance tag, to an Authentication-Results header field (defined "Chain Validation Status".  Chain
   Validation Status information is communicated in Section 2.2 of [I-D-7601bis]).

   Formally, several ways:

   o  the AS header field is specified as follows using ABNF
   [RFC5234]:

   arc-info = instance [CFWS] ";" authres-payload
   arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info

   The AAR MUST contain all Authentication-Results from within in the
   participating ADMD, regardless "cv" tag, and
   o  as part of how many Authentication-Results
   headers are on the message.

3.3.  ARC-Message-Signature (AMS)

   The ARC-Message-Signature header field is simplified version and AAR headers.

   Chain Validation Status has one of a
   DKIM-Signature header field [RFC6376], with the following
   modifications: three possible values:

   o  none: There was no Authenticated Received Chain on the message
      when it arrived for validation.  Typically this occurs when a
      message is received directly from a message's original Message
      Transfer Agent (MTA) or Message Submission Agent (MSA), or from an "i" tag, as described
      upstream Internet Mail Handler that is not participating in Section 3.1. ARC
      handling.

   o  There is no "v"  fail: The message contains an Authenticated Received Chain whose
      validation failed.

   o  pass: The message contains an Authenticated Received Chain whose
      validation succeeded.

5.  Protocol Actions

   ARC-enabled Internet Mail Handlers generally act as both ARC Sealers
   (when sending messages) and ARC Validators (when receiving messages).

5.1.  Sealer Actions

   To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
   header fields AAR, AMS, and AS) to a message.  All ARC header fields
   in an ARC Set share the same instance tag defined for value.

   To perform Sealing (aka to build and attach a new ARC Set), the AMS header.  As required for
      undefined tags (in [RFC6376]), if seen, it MUST
   following actions must be ignored.

   ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC-
   Authentication-Results) taken by an ARC Sealer when presented with
   a message:

   1.  All message modifications (including adding DKIM-Signatures) MUST NOT
       be included in performed before Sealing.

   2.  Calculate the content covered
   by instance value: if the signature in message contains an
       Authenticated Received Chain, the signature instance value is 1 more than
       the highest instance number found in this header field.

   The AMS SHOULD include any DKIM-Signature header fields already
   present on the Authenticated Received
       Chain.  If no Authenticated Received Chain exists, the instance
       value is 1.

   3.  Using the calculated instance value, generate and attach to the
       message in the following order:

   4.  An ARC-Authentication-Results header fields covered by this
   signature.

   Authentication-Results field as defined in
       Section Section 4.1.1.

   5.  An ARC-Message-Signature header fields MUST NOT be included since they
   are likely to be deleted by downstream ADMDs (per field as defined in
       Section 5 of
   [RFC7601]), thereby breaking the AMS signature.

3.4.  ARC-Seal (AS)

   The Section 4.1.2.

   6.  An ARC-Seal header field is syntactically and semantically similar
   to a DKIM-Signature field, with using the following exceptions:

   o  There is an "i" tag, as described AS definition found in
       Section 3.1.

   o  The ARC-Seal covers none of the body content of Section 4.1.3, the message.  It
      only covers specific header fields as defined below: method described in
       Section 3.4.1.  No body canonicalization is done.

   o  Only "relaxed" header canonicalization (Section 3.4.2 of
      [RFC6376]) is used.

   o  The only supported tags are "i" (from Section 3.1 of this
      document), 5.1.1, and "a", "b", "d, "s", "t" from Section 3.5 of
      [RFC6376].

   o  An additional tag, "cv" is defined in Section 3.4.2

3.4.1.  Covered the Chain Validation Status as
       determined during ARC validation.

5.1.1.  Header Fields

   The To Include In ARC-Seal Signatures

   The signature of an AS header field signs a specific canonicalized
   form of the ARC Set header values.  The ARC set header values are compiled
   supplied to the hash function in increasing instance order, starting
   at 1, and include the set ARC Set being added at the time of sealing Sealing the
   message.

   Within a set, the an ARC Set, header fields are listed supplied to the hash function in
   the following order:

   1.  ARC-Authentication-Results

   2.  ARC-Message-Signature

   3.  ARC-Seal

   Where the

   The ARC-Seal is the one being generated, it is input to the
   hash function in its final form except with an empty "b=" value, generated in
   the same manner by which a DKIM-Signature signs itself manner similar to when DKIM-Signatures
   are added to messages ([RFC6376], section 3.7).

   Note that when an Authenticated Received Chain has failed validation,
   the signing scope for the ARC-Seal is modified in (see
   Section Section 5.1.2).

5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains

   In the
   situation where case of a chain has failed validation (see Section 5.1).

3.4.2.  The 'cv' Tag

   A new tag "cv" (chain validation) indicates Authenticated Received Chain, the header
   fields included in the outcome signature scope of evaluating the existing AS header field b=
   value MUST only include the ARC Chain upon arrival at Set headers created by the ADMD that is adding this
   header field.  The values are defined per Section Section 2.2.

   In ABNF terms:

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

4.  Verifier Actions

   A verifier takes the following steps to validate MTA which
   detected the malformed chain, as if this newest ARC Chain.
   Canonicalization, hash functions, and signature validation methods
   are imported from Section 5 of [RFC6376].

   1.  Collect all ARC Sets currently on the message.  If there were
       none, Set was the ARC state only
   set present.

   _INFORMATIONAL_: This approach is "none" and the algorithm stops here.

   2.  Check mandated to handle the morphology case of the ARC a
   malformed or otherwise invalid Authenticated Received Chain.  If any of these
       conditions are not met, the chain state  There
   is "fail" and the
       algorithm stops here:

       1.  Each ARC Set must be complete (e.g., contains exactly one of
           each no way to generate a deterministic set of the three ARC-specific AS header fields);

       2.  The instance values must form fields
   (Section 5.1.1) in most cases of invalid chains.

5.1.3.  Only One Authenticated Received Chain Per Message

   A message can have only one Authenticated Received Chain on it at a continuous sequence from 1..N
           with no gaps or repeats;

       3.  The cv value for all ARC-Seal(s) must be non-failing:

           1.  For i > 1, the value must be "pass";

           2.  For i = 1,
   time.  Once broken, the value must chain cannot be "none".

   3.  For each ARC-Message-Signature from the "N"th instance to the
       first, validate the AMS:

       1.  If the "N"th instance (most recent) signature fails, then continued, as the chain state of
   custody is "fail" no longer valid and responsibility for the algorithm stops here.

       2.  If one message has
   been lost.  For further discussion of this topic and the prior AMS signatures fails to validate (for
           instance "M"), then set the oldest-pass value to the lowest
           AMS instance number designed
   restriction which passed (M+1) and go onto the next
           step (there is no need to check any other (older) AMS
           signatures).  This does not affect the validity of the chain.

       3.  If all AMS signatures verify, set the oldest-pass value to
           zero (0).

   4.  For each ARC-Seal from the "N"th instance prevents chain continuation or re-establishment,
   see [ARC-USAGE].

5.1.4.  Broad Ability to the first, validate
       the seal.

       1.  If any seal Seal

   ARC is not valid, the chain state is "fail" and the
           algorithm stops here.

       2.  If all seals pass validation, then the chain state is "pass",
           and the algorithm solely intended for perimeter MTAs.  Any mediator
   ([RFC5598], section 5) that modifies a message may Seal its own
   changes.  For additional information, see Section Section 7.1.

5.1.5.  Sealing is complete. Always Safe

   The end result of the verifier's checks via this algorithm MUST be
   added into the Authentication-Results header(s) for the ADMD.

   _INFORMATIONAL_: Recipients utility of an ARC Authenticated Received Chain that is invalid or does
   not pass SHOULD NOT draw negative conclusions without a good
   understanding of the wider handling context.  Until ARC usage is
   widespread, intermediaries will continue limited to modify very
   specific cases.  Authenticated Received Chains are designed to
   provide additional information to an Internet Mail Handler when
   evaluating messages without for delivery in the context of authentication
   failures.  Specifically:

   o  Properly adding an ARC seals.

   As with a failing DKIM signature ([RFC6376] Section-6.3), Set to a message
   with a failing ARC does not damage or
      invalidate an existing Authenticated Received Chain.

   o  Sealing an Authenticated Received Chain MUST be treated when a message has not
      been modified does not negatively affect the same as chain.

   o  Validating a message with exposes no ARC Chain.

4.1.  Authentication-Results Information

   Certain information pertinent new threat vectors (see
      Section Section 9).

   o  An ADMD may choose to ascertaining message disposition can
   be lost in transit when messages are handled by intermediaries.  For
   example, failing DKIM signatures are sometimes removed by MTAs, and
   most DKIM signatures on Seal all inbound messages whether or not a
      message has been modified by intermediaries or will
   fail.  Recording the following information in be retransmitted.

5.1.6.  Signing vs Sealing

   Signing is the Authentication-
   Results stamped as part process of the ARC evaluation provides affixing a mechanism
   for this information digital signature to survive transit through a particular ADMD.

   Stamped ARC evaluation results message
   as a header, such as when a DKIM-Signature (as in [RFC6376] section
   2.1), or an AMS or AS is limited added.  Sealing is when an ADMD affixes a
   complete and valid ARC Set to a message creating or continuing an
   Authenticated Received Chain.

5.2.  Validator Actions

   A validator performs the Chain Validation
   status (cv) from Section 2.2.

   The ptypes and properties defined following steps, in this sequence, to process an
   Authenticated Received Chain.  Canonicalization, hash functions, and
   signature validation methods are imported from [RFC6376] section SHOULD be recorded
   in 5.

   1.  Collect all ARC Sets currently attached to the Authentication-Results:

   o  smtp.client-ip - The connecting client IP address from which message.  If there
       are none, the
      message Chain Validation Status is received;

   o  header.oldest-pass - "none" and the algorithm
       stops here.  The instance maximum number of the oldest AMS that
      still validates, or 0 if all pass.

4.2.  Handling DNS Problems While Validating ARC

   DNS-based failures Sets that can be attached
       to verify a chain are treated no differently message is 50.  If more than
   any other ARC violation.  They result in a "cv=fail" verdict.

4.3.  Responding to ARC Validity Violations During the SMTP Transaction

   If a receiver determines that maximum number exist 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] Validation Status is "fail" and
   corresponding SMTP response code.

5.  Sealer Actions

   An ARC sealer MUST take the algorithm stops here.
       In the following actions when presented with a
   message:

   1.  Before creating an ARC signature, perform any other, normal
       authentication and/or signing, so that algorithm, the maximum ARC signature can
       cover those results. instance value is
       referred to as "N".

   2.  Build and attach the new ARC Set:

       1.  If an ARC Chain exists on the message, then set "N" equal to Chain Validation Status of the highest instance number found on the chain (i=);
           otherwise set "N" equal to zero for the following steps.

       2.  Generate and attach to value ARC
       Set is "fail", then the message an ARC-Authentication-
           Results header field as defined in Section Section 3.2, using
           instance number N+1 Chain Validation status is "fail" and the same content from the previous
           step.
       algorithm stops here.

   3.  Generate and attach to  Validate the message an ARC-Message-Signature
           header field as defined in Section 3.3 above, using instance
           number N+1.

       4.  Generate and attach to structure of the message an ARC-Seal header field
           using Authenticated Received Chain.  A
       valid ARC has the general algorithm described in Section 3.4 above, following conditions:

       1.  Each ARC Set MUST contain exactly one each of the chain validation status as determined in Section 4, three ARC
           header fields (AAR, AMS, and AS).

       2.  The instance number N+1.

5.1.  Marking and Sealing "cv=fail" (Invalid) Chains values of the ARC Sets MUST form a continuous
           sequence from 1..N with no gaps or repetition.

       3.  The "cv" value for all ARC-Seal header fields signed by must be non-
           failing.  For instance values > 1, the AS header field b= value in the case
   of a chain failure MUST must be only the matching "pass".
           For instance headers created
   by the MTA which detected the malformed chain, as if this newest ARC
   Set was the only set present.

   _INFORMATIONAL:_ In value = 1, the case of a malformed or otherwise invalid
   chain there is no way to generate a deterministic set value must be "none".

       *  If any of AS header
   fields ({#implicit_as_h}) so this approach these conditions are not met, the Chain Validation
          Status is mandated.

6.  Recording "fail" and Reporting the Results of ARC Evaluation

   The evaluation of an ARC Chain provides information which will be
   useful to both algorithm stops here.

   4.  Validate the receiver (or intermediary) and to AMS with the initial
   sender of greatest instance value (most recent).
       If validation fails, then the message.  This information should be preserved Chain Validation Status is "fail"
       and
   reported as follows.

6.1.  Information the algorithm stops here.

   5.  _OPTIONAL:_ Determine the "oldest-pass" value from an ARC Evaluation

   The evaluation of an ARC Chain produces a list of domain names for
   participating intermediaries which handled the message, to wit:

   o  A list of ARC Set by
       validating each prior AMS beginning with the "d=" domains found N-1 and proceeding
       in decreasing order to the validated ARC-Seal header
      fields

   o  The "d=" domain found in AMS with the most recent (highest instance number) value of 1:

   6.  If an AMS header field (since that is fails to validate (for instance value "M"), then set
       the only one necessarily
      validated)

   In oldest-pass value to the case of a failed chain, only lowest AMS instance value which
       passed (M+1) and go to the terminal ARC Set next step (there is covered
   by no need to check
       any other (older) AMS headers).  This does not affect the ARC-Seal so
       validity of the reporting is limited Authenticated Received Chain.

   7.  If all AMS headers verify, set the oldest-pass value to zero (0).

   8.  Validate each AS beginning with the findings in that
   terminal ARC Set.

6.2.  Recording (local) ARC Evaluation Results

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

   Details of the ARC Chain which was evaluated should be included in
   the Authentication-Results greatest instance value and AAR headers per Section Section 4.1.

6.3.  DMARC Reporting of ARC Findings - Interim

   Receivers SHOULD indicate situations
       proceeding in which ARC evaluation
   influenced decreasing order to the results of their local policy determination.  DMARC
   reporting of ARC-informed decisions can be accomplished by adding a
   local_policy comment explanation containing AS with the list instance value
       of data
   discovered in the ARC evaluation, which at a minimum SHOULD include:
   * 1.  If any AS fails to validate, the Chain Validation status, * the domain Status
       is "fail" and selector for each AS,
   * the IP addresses of algorithm stops here.

   9.  If the mail originating ADMD:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
   <type>local_policy</type>
   <comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
     as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13</comment>
  </reason>
</policy_evaluated>

   In algorithm reaches this step, then the sample above, d2.example Chain Validation
       Status is the sealing domain for ARC[2] "pass", and
   d1.example is the sealing domain for ARC[1].

   Intermediary message handlers SHOULD generate DMARC reports on
   messages which transit their system just like any other message which
   they receive.  This will algorithm is complete.

   The end result in multiple reports for each mediated
   message as they transit the series of handlers.  DMARC report
   consumers should be aware of this behaviour and make the necessary
   accommodations.

7.  Privacy Considerations

   The ARC Chain provides a verifiable record of Validation algorithm is added into the handlers
   Authentication-Results header for the ADMD.

   As with a
   message.  Anonymous remailers will probably not find this compatible failing DKIM signature ([RFC6376] section 6.3), a message
   with their operating goals.

8.  IANA Considerations

   [[ Note to a failing Authenticated Received Chain MUST be treated the RFC Editors: Some of these fields are defined both
   here and in [I-D-7601bis].  Please delete the overlap from whichever
   document goes through the publication process after the other. ]]

   This specification adds three new header fields same
   as defined below.

8.1.  Authentication-Results Method Registry Update

   This draft adds one item a message with no Authenticated Received Chain.

   _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
   Received Chain can use that information as part of a wider handling
   context.  ARC adoption cannot be assumed by intermediaries; many
   intermediaries will continue to modify messages without adding ARC
   Seals.

5.2.1.  All Failures Are Permanent

   Authenticated Received Chains represent 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 3.4)
      Status: active

8.2.  Email Authentication Result Names Registry Update

   This draft updates the Email Authentication Results registry, most
   recently defined in [I-D-7601bis], with traversal of messages
   through one new authentication method or more intermediaries.  All errors, including DNS
   failures, become unrecoverable and several status codes, all defined by this document:

   o  Auth Method : arc
      Code: "none", "pass", "fail"
      Specification: [I-D.ARC] Section 3.4.2 Status: active

   o  Method : spf
      Defined: [I-D.ARC]
      ptype: smtp
      Property: client-ip
      Value: the connecting client IP address from which the message is
      received
      Status: active

   o  Method : arc
      Defined: [I-D.ARC]
      ptype: header
      Property: oldest-pass
      Value: the oldest instance with are considered permanent.

   Any error Validating an Authenticated Received Chain results in a still validating AMS signature
      Status: active

8.3.  Definitions
   failed Chain Validation Status.  For further discussion of this topic
   and the ARC header fields

   This specification adds three new header fields design restriction which prevents chain continuation or re-
   establishment, see [ARC-USAGE].

5.2.2.  Responding to ARC Validation Failures During the "Permanent
   Message Header Field Registry", as follows:

   o  Header field name: ARC-Seal
      Applicable protocol: mail
      Status: draft
      Author/Change controller: 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: 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.  Security Considerations

   The Security Considerations of [RFC6376] and [RFC7601] apply directly
   to this specification.

9.1.  Header Size

   Inclusion of SMTP
        Transaction

   If an ARC Sets in the header of emails may cause problems for
   some older or more constrained MTAs if they are unable to accept Validator determines that the
   greater size of Authenticated Received Chain
   has failed, the header.

9.2.  DNS Operations

   Operators who receive a message bearing N ARC Sets have to complete
   up to N+1 DNS queries to evaluate Validator MAY signal the chain (barring DNS redirection
   mechanisms which can increase breakage through the lookups for a given target value).
   This has at least two effects:

   1.
   extended SMTP response code 5.7.7 [RFC3463] "message integrity
   failure" [ENHANCED-STATUS] and corresponding SMTP response code.

5.3.  Result of Validation

   An attacker can send a message to an ARC participant Authenticated Received Chain with a
       concocted sequence of ARC Sets bearing the domains Chain Validation Status of intended
       victims, and
   "pass" allows Internet Mail Handlers to ascertain:

   o  all of them will be queried by the participant until
       a failure is discovered.  The difficulty of forging ARC-participating ADMDs that claim responsibility for handling
      (and possibly modifying) the signature
       values should limit message in transit;

   o  the extent of this load to domains under
       control authentication state of the attacker.

   2.  DKIM only does one DNS check per signature, while message as perceived by each ADMD
      (from Authentication-Results header fields).

   Given this one can do
       many (per chain).  Absent caching, slow DNS responses information, handlers can cause
       SMTP timeouts; and backlogged delivery queues on mediating
       systems.  This could be exploited as a DoS attack.

9.3.  Message Content Suspicion

   Recipients are cautioned to treat inform local policy decisions
   regarding disposition of messages bearing ARC Sets with the
   same suspicion that they apply experience authentication
   failure due to all other email messages. intermediate processing.

6.  Communication of Validation Results

   Chain Validation Status (described in Section Section 4.4) is
   communicated via Authentication-Results (and AAR) headers using the
   auth method "arc".  This
   includes appropriate content scanning and other checks for
   potentially malicious content.  The handlers which are identified
   within auth method is described in
   Section Section 10.1.

   If necessary data is available, the ARC Chain may ptypes and properties defined in
   Section Section 10.2 SHOULD be used to provide input to local policy
   engines recorded in cases where DMARC validation fails (due to mediation
   impacting SPF attribution, DKIM validity or alignment).

   Note that a passing ARC Chain may not adequately mean that an Authentication-Results
   header field:

   o  smtp.client-ip - The connecting client IP address from which the
      message is safe because:

   1.  You have to trust all signatories; and

   2.  Even trusted systems may have become compromised or may not
       properly authenticate messages, so even with a chain received.

   o  header.oldest-pass - The instance number of trusted
       participants, the message might oldest AMS that
      still never have authenticated in validates, or 0 if all pass.

   Upon Sealing of a message, this Authentication-Results information
   along with all other Authentications-Results added by the first place (which is why you have ADMD will
   be recorded into the AAR to inspect) or
       could have been subject to unintended modifications.

10.  Evaluating as defined in section Section 4.1.1.

   In General Concept terms, the Efficacy of information recorded in the ARC Protocol (Experimental
     Considerations)

   The ARC protocol ARC-
   Authentication-Results header field is designed to mitigate some of the most common
   failure conditions for email which transits Evidence that gets
   attached to a message.

7.  Use Cases

   This section explores several messaging handling use cases that are
   addressed by ARC.

7.1.  Communicate Authentication Results Across Trust Boundaries

   When an intermediary handlers en
   route ADMD adds an ARC Set to a message's
   Authenticated Received Chain (or creates the final recipient.  Some of these problems have happened
   due to initial ARC Set), the adoption of
   ADMD communicates authentication state to the DMARC protocol [RFC7489] and are listed next ADMD in
   [RFC6377] and [RFC7960].

   As the ARC protocol becomes standardized and implemented amongst
   intermediary handlers, the following aspects should
   message handling path.

   If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
   be evaluated used to bridge administrative boundaries.

7.1.1.  Message Scanning Services

   Message services are available to perform anti-spam, anti-malware,
   and anti-phishing scanning.  Such services typically remove malicious
   content, replace HTTP links in
   order messages with sanitized links, and/or
   attach footers to determine messages advertising the success abilities of the protocol in accomplishing message
   scanning service.  These modifications almost always break signature-
   based authentication (such as DKIM).

   Scanning services typically require clients to point MX records of an
   Internet domain to the
   intended benefits.

   NOTE: Terminology within this section does NOT follow [RFC2119]
   interpretation.  This section represents scanning service.  Messages destined for the current thoughts of
   Internet domain are initially delivered to the
   working group regarding unanswered questions related scanning service.
   Once scanning is performed, messages are then routed to the protocol.
   Wider deployment will inform these topics and probably expand them.

10.1.  Success Consideration

   Currently, many receivers have heuristically determined overrides client's
   own mail handling infrastructure.  Re-routing messages in
   order this way
   almost always breaks path-based authentication (such as SPF).

   Message scanning services can attach Authenticated Received Chains to rescue mail from intermediary-caused failures.  Many of
   those overrides rely on inferrence rather than direct evidence.

   ARC will be a success if, for ARC sealed messages, receivers are able
   messages to implment ARC-based algorithmic decisions based on communicate authentication results into client ADMDs.
   Clients can then benefit from the direct
   evidence found within message scanning service while
   processing messages as if the ARC Chain.  This is especially relevant for
   DMARC processing when the DKIM d= value is aligned with client's infrastructure were the
   rfc5322.From author domain.

10.2.  Failure Considerations

   The intent
   original destination of ARC the Internet domain's MX record.

7.1.2.  Multi-tier MTA Processing

   Large message processing infrastructure is often divided into several
   processing tiers that can break authentication information between
   tiers.  For example, a large site may maintain a cluster of MTAs
   dedicated to be at most value-add connection handling and at worst benign.  If
   ARC opens up significant new vectors for abuse (see Section 9) then
   this protocol will enforcement of IP-based
   reputation filtering.  A secondary cluster of MTAs may be a failure.  Note that weaknesses inherent in
   the mail protocols ARC is built upon (such as DKIM replay attacks dedicated
   and
   other known issues) are not new vectors which optimized for content-based processing of messages.

   Authenticated Received Chains can be attributed used to
   this specification.

10.3.  Open Questions

   The following open questions are academic and have no clear answer at
   the time of the development communicated
   authentication state between processing tiers.

7.1.3.  Mailing Lists

   Mailing lists resend posted messages to subscribers.  A full
   description of the protocol.  However, wide-spread
   deployment should authentication-related mailing list issues can be able
   found in [RFC7960] Section 3.2.3.

   Mailing list services can implement ARC to gather convey the necessary data to answer some
   or all original
   authentication state of them.

10.3.1.  Value posted messages sent to the list's subscriber
   base.  The ADMDs of the ARC-Seal (AS) Header

   Data should be collected mailing list subscribers can then use the
   Authenticated Received Chain to show if determine the ARC-Seal (AS) provides value
   beyond authentication state of
   the ARC original message before mailing list handling.

7.2.  Inform Message Signature (AMS) for either making delivery
   decisions or catching malicious actors trying to craft or replay
   malicious chains.

10.3.2.  DNS Overhead

   Longer Disposition Decisions

   ARC Chains will require more queries functionality allows Internet Mail Handlers to retrieve the keys reliably identify
   intermediary ADMDs and for
   validating the chain.  While this is not believed ADMDs to be a security
   issue (see Section 9.2), it is unclear how much overhead will truly
   be added.  This is similar to some of the initial processing and
   query load concerns which were debated at the time of the DKIM
   specification development.

   Data should be collected to better understand usable length expose authentication state that
   can survive additional intermediary handling.

   Intermediaries often break authentication through content
   modification, interfere with path-based authentication (such as SPF),
   and
   distribution of lengths found in valid ARC strip authentication results (if an MTA removes Authentication-
   Results headers).

   Authenticated Received Chains along with allow ARC Validators to:

   1.  identify ARC-enabled ADMDs that break authentication while
       processing messages;

   2.  gain extended visibility into the authentication-preserving
       abilities of ADMDs that relay messages into ARC-enabled ADMDs.

   Through the
   DNS impact collection of processing ARC Chains.

   An effective operational maximum will ARC-related data, an ADMD can identify
   handling paths that have broken authentication.

   An Authenticated Received Chain allows an Internet Mail Handler to be developed through
   deployment experience in the field.

10.3.3.  Distinguishing Valuable from Worthless Trace Information

   There are several edge cases
   potentially base decisions of message disposition on authentication
   state provided by different ADMDs.

7.2.1.  DMARC Local Policy Overrides

   DMARC introduces a policy model where the information in the AAR Domain Owners can
   make the difference between message delivery request email
   receivers to reject or rejection.  For
   example, if there is a well known mailing list quarantine messages that ARC seals but
   doesn't do its own initial fail DMARC enforcement, alignment.
   Interoperability issues between DMARC and indirect email flows are
   documented in [RFC7960].

   Authenticated Received Chains allow DMARC processors to consider
   authentication states provided by other ADMDs.  As a Final Receiver with
   this knowledge could make matter of local
   policy, a delivery decision based upon DMARC processor may choose to accept the authentication information it sees in the corresponding AAR header.

   Certain trace information in the AAR is useful/necessary in the
   construction of
   state provided by an Authenticated Received Chain when determining if
   a message is DMARC reports.  It would be beneficial compliant.

   When an Authenticated Received Chain is used to identify
   the value-add of having intermediary-handled mail flow information
   added into determine message
   disposition, the DMARC reports going back processor can communicate this local policy
   decision to senders.

   Certain Domain Owners as described in Section Section 7.2.2.

7.2.2.  DMARC Reporting

   DMARC-enabled receivers believe the entire set indicate when ARC Validation influences
   DMARC-related local policy decisions.  DMARC reporting of trace information would
   be valuable to feed into machine learning systems to identify fraud
   and/or provide other signals related to message delivery.

   It ARC-
   influenced decisions is unclear what trace information will be valuable for all
   receivers, regardless accomplished by adding a local_policy comment
   containing a list of size.

   Data should be collected on what trace information receivers are
   using that provides useful signals that affect deliverability, data discovered during ARC Validation, which at
   a minimum includes:

   o  the Chain Validation Status,

   o  the domain and
   what portions of selector for each AS,

   o  the trace originating IP address from the first ARC Set:

   EXAMPLE:

   <policy_evaluated>
     <disposition>none</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass ams[2].d=d2.example ams[2].s=s1
        as[2].d=d2.example as[2].s=s2 as[1].d=d1.example
        as[1].s=s3 client-ip[1]=10.10.10.13</comment>
     </reason>
   </policy_evaluated>

   In the above example DMARC XML reporting fragment, data are left untouched or provide no
   useful information.

   Since many such systems are intentionally proprietary or confidential
   to prevent gaming by abusers, it may not be viable relating to reliably answer
   this particular question.  The evolving nature
   specific validated ARC Sets are enumerated using array syntax (eg,
   "ams[2]" means AMS header field with instance value of attacks can also
   shift 2). d2.example
   is the landscape of "useful" information over time.

11.  Implementation Status

   [[ Note to Sealing domain for ARC Set #2 (i=2) and d1.example is the RFC Editor: Please remove this section before
   publication along with the reference to [RFC6982]. ]]

   This section records
   Sealing domain for ARC Set #1 (i=1).

   Depending on the status reporting practices of known implementations intermediate message
   handlers, Domain Owners may receive multiple DMARC reports for a
   single message.  DMARC report processors should be aware of the
   protocol defined by this specification at
   behaviour and make the time of posting necessary accommodations.

8.  Privacy Considerations

   The Authenticated Received Chain provides a verifiable record of this
   Internet-Draft, the
   handlers for a message.  This record may include Personally
   Identifiable Information such as IP address and domain names.  Such
   information is based on a proposal described also including in [RFC6982]. existing header fields such as the
   "Received" header field.

9.  Security Considerations

   The description Security Considerations of implementations in this section is intended [RFC6376] and [I-D-7601bis] apply
   directly to
   assist this specification.

   As with other domain authentication technologies (such as SPF, DKIM,
   and DMARC), ARC makes no claims about the IETF in its decision processes in progressing drafts semantic content of
   messages.

9.1.  Increased Header Size

   Inclusion of Authenticated Received Chains into messages may cause
   issues for older or constrained MTAs due to
   RFCs.  Please note that the listing increased total header
   size.

9.2.  DNS Operations

   The validation of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent an Authenticated Received Chain composed of N ARC
   Sets can require up to verify 2*N DNS queries (not including any DNS
   redirection mechanisms which can increase the information presented here that was
   supplied by IETF contributors. total number of
   queries).  This is not intended as, and must not
   be construed leads to be, two considerations:

   1.  An attacker can send a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   This information is known message to be correct as an ARC participant with a
       concocted sequence of ARC Sets bearing the seventh
   interoperability test event which was held on 2017-07-15 & 16 at
   IETF99.

   For domains of intended
       victims, and all of them will be queried by the participant until
       a few failure is discovered.  The difficulty of forging the implementations, later status information was
   available as signature
       values should limit the extent of December 2017.

11.1.  GMail test reflector and incoming validation

   Organization: Google
   Description: Internal production implementation with both debug this load to domains under
       control of the attacker.  Query traffic pattern analysis and may
       expose information about downstream validating + sealing pass-through function
   Status of Operation: Production - Incoming Validation
   Coverage: Full spec implemented as of [ARC-DRAFT-06]
   Licensing: Proprietary - Internal ADMD
       infrastructure.

   2.  DKIM only
   Implementation Notes:

   o  Full functionality was demonstrated during the interop testing on
      2017-07-15.

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

11.2.  AOL test reflector performs one DNS query per signature, while ARC can
       introduce many (per chain).  Absent caching, slow DNS responses
       can cause SMTP timeouts; and internal tagging

   Organization: AOL
   Description: Internal prototype implementation backlogged delivery queues on
       Validating systems.  This could be exploited as a DoS attack.

9.3.  Message Content Suspicion

   Recipients are cautioned to treat messages bearing Authenticated
   Received Chains with both debug
   analysis the same suspicion applied to all other
   messages.  This includes appropriate content scanning and validating + sealing pass-through function
   Status other
   checks for potentially malicious content.

   Just as passing message authentication is not an indication of
   message safety, forwarding that information through the mechanism of Operation: Beta
   Coverage:
   ARC Chain validity status checking is operational, but only
   applied to email addresses enrolled in the test program.
   This system conforms also not an indication of message safety.  Even if all ARC-
   enabled ADMDs are trusted, ADMDs may have become compromised, may
   miss unsafe content, or may not properly authenticate messages.

9.4.  Message Sealer Suspicion

   Recipients are cautioned to [ARC-DRAFT-06]
   Licensing: Proprietary - Internal only
   Implementation Notes:

   o  2017-07-15: Full functionality verified during treat every Sealer of the interop
      testing.

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

11.3.  dkimpy

   Organization: dkimpy developers/Scott Kitterman
   Description: Python ARC Chain with
   suspicion.  Just as with a validated DKIM package
   Status of Operation: Production
   Coverage:

   o  2017-07-15: The internal test suite signature, responsibility
   for message handling is incomplete, attributed to the signing domain, but whether
   or not that signer is a malicious actor is out of scope of the command
      line developmental version
   authentication mechanism.  Since ARC aids message delivery in the
   event of validator was demonstrated to
      interoperate an authentication failure, ARC Sealers should be treated
   with suspicion, so that a malicious actor cannot Seal spam or other
   fraudulent messages to aid their delivery, too.

9.5.  Replay Attacks

   Since ARC inherits heavily from DKIM, it has similar attack vectors.
   In particular, the Google Replay Attack described in [RFC6376] section 8.6
   is potentially amplified by ARC's chained statuses.  In an ARC replay
   attack, a malicious actor would take an intact and AOL implementations during passing ARC Chain,
   and then resend it to many recipients without making any
   modifications that invalidate the
      interop on 2017-07-15 latest AMS or AS.  The impact to a
   receiver would be more DNS lookups and signature evaluations.  This
   scope of this attack can be limited by caching DNS queries and
   following the released version passes same signing scope guidance from [RFC6376] section
   5.4.1.

10.  IANA Considerations

   [[ *Note to the tests in
      [ARC-TEST] arc_test_suite [4] with RFC Editors:* dkim header.s is defined both python here and python3.

   Licensing: Open/Other (same as dkimpy package = BCD version 2)
   Contact Info: https://launchpad.net/dkimpy

11.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-10]
   Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
   Implementation Notes:

   o  The build is FreeBSD oriented but some packages have been built
      for easier deployment on RedHat-based Linux platforms.

   o  Some issues still exist when deploying
   in a chained milter
      arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
      with coordination between [I-D-7601bis].  Please delete the stages.  When deployed in a
      "sandwich" configuration around an MLM, there is no effective
      mechanism to convey trust overlap from whichever document
   goes through the ingress (validator) to egress
      (signer) instances.  (_NOTE_: this is expected to resolved publication process after the other. ]]

   This draft introduces three new headers fields and updates the Email
   Authentication Parameters registry with a one new release of OpenDMARC expected in January 2018.)

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

11.5.  Mailman 3.2 patch

   Organization: Mailman development team
   Description: Integrated ARC capabilities within authentication method
   and several status codes.

10.1.  Email Authentication Results Names Registry Update

   This draft adds one Auth Method with three Codes to the Mailman 3.2
   package
   Status of Operation: Patch submitted
   Coverage: Based on OpenARC
   Licensing: Same as mailman package - GPL
   Implementation Notes: IANA "Email
   Authentication Result Names" registry:

   o  Appears  Auth Method : arc Code: "none", "pass", "fail" Specification:
      [I-D.ARC] Section 2.2 Status: active

10.2.  Email Authentication Methods Registry Update

   This draft adds several new items to work properly in at least one beta deployment, but
      waiting on acceptance of the pull request into the mainline of
      mailman development

   Contact Info: https://www.gnu.org/software/mailman/contact.html

11.6.  Copernica/MailerQ web-based validation

   Organization: Copernica
   Description: Web-based validation Email Authentication Methods
   registry, most recently defined in [I-D-7601bis]:

   o  Method: arc Definition: [I-D.ARC] ptype: smtp Property: client-ip
      Value: IP address of ARC-signed messages
   Status originating SMTP connection Status: active
      Version: 1

   o  Method: arc Definition: [I-D.ARC] ptype: header Property: oldest-
      pass Value: The instance id of Operation: Beta
   Coverage: Built the oldest validating AMS, or 0 if
      they all pass (see Sectionn 4) Status: active Version: 1

   o  Method: dkim Definition: [RFC6376] ptype: header Property: s
      Value: value of signature "s" tag Status: active Version: 1

10.3.  Definitions of the ARC header fields

   This specification adds three new header fields to support [ARC-DRAFT-05]
   Licensing: On-line usage only
   Implementation Notes: the "Permanent
   Message Header Field Registry", as follows:

   o  Released 2016-10-24  Header field name: ARC-Seal Applicable protocol: mail Status:
      draft Author/Change controller: IETF Specification document(s):
      [I-D.ARC] Related information: [RFC6376]

   o  Requires full message content to be pasted into a web form found
      at http://arc.mailerq.com/ (warning - https is not supported).  Header field name: ARC-Message-Signature Applicable protocol: mail
      Status: draft Author/Change controller: IETF Specification
      document(s): [I-D.ARC] Related information: [RFC6376]

   o  An additional instance of an  Header field name: ARC-Authentication-Results Applicable protocol:
      mail Status: standard Author/Change controller: IETF Specification
      document(s): [I-D.ARC] Related information: [I-D-7601bis]

11.  Experimental Considerations

   The ARC signature can be added if one protocol is
      willing designed to paste a private key into an unsecured web form.

   o  2017-07-15: Testing shows that results match the other
      implementations listed address common interoperability
   issues introduced by intermediate message handlers.  Interoperability
   issues are described in this section.

   Contact Info: https://www.copernica.com/

11.7.  Rspamd

   Organization: Rspamd community
   Description: ARC signing [RFC6377] and verification module
   Status of Operation: Production, though deployment usage [RFC7960].

   As the ARC protocol is unknown
   Coverage: Built implemented by intermediary handlers over
   time, the following should be evaluated in order to support [ARC-DRAFT-06]
   Licensing: Open source
   Implementation Notes:

   o  2017-06-12: Released with version 1.6.0

   o  2017-07-15: Testing during determine the interop showed that
   success of the validation
      functionality interoperated with protocol in accomplishing the Google, AOL, dkimpy and
      MailerQ implementations

   Contact Info: https://rspamd.com/doc/modules/arc.html and
   https://github.com/vstakhov/rspamd

11.8.  PERL MAIL::DKIM module

   Organization: FastMail
   Description: Email domain authentication (sign and/or verify) module,
   previously included SPF / DKIM / DMARC, now has intended benefits.

11.1.  Success Consideration

   In an attempt to deliver legitimate messages that users desire, many
   receivers use heuristic-based methods to identify messages that
   arrive via indirect delivery paths.

   ARC added
   Status will be a success if the presence of Operation: Production, deployment usage unknown
   Coverage: Built to support [ARC-DRAFT-10]
   Licensing: Open Source
   Implementation Notes:

   o  2017-12-15: v0.50 released with full test set passing Authenticated Received
   Chains allows for improved decision making when processing legitimate
   messages.

11.2.  Failure Considerations

   ARC

   Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/

11.9.  PERL Mail::Milter::Authentication module

   Organization: FastMail
   Description: Email domain authentication milter, uses MAIL::DKIM should function without introducing significant new vectors for
   abuse (see
   above)
   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:

   o  2017-07-15: Validation functionality which interoperates with
      Gmail, AOL, dkimpy was demonstrated; later Section Section 9).  If unforseen vectors are enabled by
   ARC, then this protocol will be a failure.  Note that weaknesses
   inherent in the week of IETF99,
      the signing functionality was reported to be working

   o  2017-07-20: mail protocols ARC functionality has is built upon (such as DKIM replay
   attacks and other known issues) are not yet been pushed back new vectors which can be
   attributed to this specification.

11.3.  Open Questions

   The following open questions are academic and have no clear answer at
   the
      github repo but time of the development of the protocol.  However, additional
   deployment should be showing up soon

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

11.10.  Sympa List Manager

   Organization: Sympa Dev Community
   Description: Work in progress
   Status able to gather the necessary data to answer some
   or all of Operation: Work in progress
   Coverage: unknown
   Licensing: open source
   Implementation Notes:

   o  2018-01-05: Tracked as https://github.com/sympa-community/sympa/
      issues/153

   Contact Info: https://github.com/sympa-community

11.11.  Oracle Messaging Server

   Organization: Oracle
   Description:
   Status them.

11.3.1.  Value of Operation: Intial development work during IETF99 hackathon.
   Status since then unknown.
   Coverage: Work in progress
   Licensing: Unknown
   Implementation Notes:

   o  2018-03: Protocol handling components are completed, but crypto the ARC-Seal (AS) Header

   Data should be collected to show if the ARC-Seal (AS) provides value
   beyond the ARC Message Signature (AMS) for either making delivery
   decisions or catching malicious actors trying to craft or replay
   malicious chains.

11.3.2.  DNS Overhead

   Longer Authenticated Received Chains will require more queries to
   retrieve the keys for validating the chain.  While this is not yet functional.

   Contact Info: Chris Newman

11.12.  MessageSystems Momentum and PowerMTA platforms

   Organization: MessageSystems/SparkPost
   Description: OpenARC integration into
   believed to be a security issue (see Section Section 9.2), it is
   unclear how much overhead will truly be added.  This is similar to
   some of the LUA-enabled Momentum initial processing space
   Status and query load concerns which were
   debated at the time of Operation: Beta
   Coverage: Built the DKIM specification development.

   Data should be collected to support [ARC-DRAFT-10]
   Licensing: Unknown
   Implementation Notes:

   o  Initial deployments for validation expected in mid-2018.

   Contact Info:

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use better understand usable length and
   distribution of lengths found in RFCs valid Authenticated Received Chains
   along with the the DNS impact of processing Authenticated Received
   Chains.

   An effective operational maximum will have to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3463]  Vaudreuil, G., "Enhanced be developed through
   deployment experience in the field.

11.3.3.  What Trace Information is Valuable

   There are several edge cases where the information in the AAR can
   make the difference between message delivery or rejection.  For
   example, if there is a well known mailing list that seals with ARC
   but doesn't do its own initial DMARC enforcement, an Internet Mail System
   Handler with this knowledge could make a delivery decision based upon
   the authentication information it sees in the corresponding AAR
   header.

   Certain trace information in the AAR is useful/necessary in the
   construction of DMARC reports.

   Certain receivers believe the entire set of trace information would
   be valuable to feed into machine learning systems to identify fraud
   and/or provide other signals related to message delivery.

   It is unclear what trace information will be valuable for all
   receivers, regardless of size.

   Data should be collected on what trace information receivers are
   using that provides useful signals that affect deliverability, and
   what portions of the trace data are left untouched or provide no
   useful information.

   Since many such systems are intentionally proprietary or confidential
   to prevent gaming by abusers, it may not be viable to reliably answer
   this particular question.  The evolving nature of attacks can also
   shift the landscape of "useful" information over time.

12.  Implementation Status Codes",

   [[ Note to the RFC 3463, DOI 10.17487/RFC3463, January 2003,
              <https://www.rfc-editor.org/info/rfc3463>.

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

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

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

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., 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.

   This information is known to be correct as of the eighth
   interoperability test event which was held on 2018-03-17 at IETF101.

   For a few of the implementations, later status information was
   available as of June 2018.

12.1.  GMail test reflector and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) incoming validation

   Organization: Google Description: Internal production implementation
   with both debug analysis and
              Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
              September 2011, <https://www.rfc-editor.org/info/rfc6377>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use validating + sealing pass-through
   function Status of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://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,
              <https://www.rfc-editor.org/info/rfc7601>.

   [RFC8174]  Leiba, B., "Ambiguity Operation: Production - Incoming Validation
   Coverage: Full spec implemented as of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>. [ARC-DRAFT-14] Licensing:
   Proprietary - Internal only Implementation Notes:

   o  Full functionality was demonstrated during the interop testing on
      2018-03-17.

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

12.2.  Informative References

   [ARC-DRAFT-05]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-05)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-05>.

   [ARC-DRAFT-06]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-06)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-06>.

   [ARC-DRAFT-10]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-10)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-10>.

   [ARC-MULTI]
              Andersen, K., "Using Multiple Signing Algorithms  AOL test reflector and internal tagging

   Organization: AOL Description: Internal prototype implementation with
              ARC", January 2018, <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-multi-01>.

   [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.,
   both debug analysis and K. Andersen,
              "Recommended Usage validating + sealing pass-through function
   Status of Operation: Beta Coverage: ARC Chain validity status
   checking is operational, but only applied to email addresses enrolled
   in the test program.  This system conforms to [ARC-DRAFT-05]
   Licensing: Proprietary - Internal only Implementation Notes:

   o  2017-07-15: Full functionality verified during the interop
      testing.

   o  2018-06: Partially retired but still accessible by special request
      due to the in process evolution 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>.

   [I-D-7601bis]
              Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", February 2018,
              <https://datatracker.ietf.org/doc/
              draft-ietf-dmarc-rfc7601bis/>.

   [RFC6982]  Sheffer, Y. AOL mail infrastructure to
      the integrated OATH environment.  The implementation was based on
      the Apache James DKIM code base and A. Farrel, "Improving Awareness may be contributed back to
      that project in the future.

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

12.3.  dkimpy

   Organization: dkimpy developers/Scott Kitterman Description: Python
   DKIM package Status of Running
              Code: Operation: Production Coverage:

   o  2017-07-15: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <https://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,
              <https://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, internal test suite is incomplete, but the command
      line developmental version of validator was demonstrated to
      interoperate with the Google and Conformance (DMARC) AOL implementations during the
      interop on 2017-07-15 and Indirect Email Flows",
              RFC 7960, DOI 10.17487/RFC7960, September 2016,
              <https://www.rfc-editor.org/info/rfc7960>.

12.3.  URIs

   [1] https://datatracker.ietf.org/wg/dcrup/about/

   [2] mailto:arc-discuss@dmarc.org the released version passes the tests in
      [ARC-TEST] arc_test_suite [3] mailto:arc-discuss@dmarc.org

   [4] https://github.com/Valimail/arc_test_suite

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

   [6] https://trac.ietf.org/trac/dmarc/ticket/17

   [7] mailto:dmarc@ietf.org

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

Appendix A.  Appendix A - Design Requirements

   (This section is re-inserted for background information from
   [ARC-DRAFT-06] with both python and earlier versions.)

   The specification python3.

   Licensing: Open/Other (same as dkimpy package = BCD version 2)
   Contact Info: https://launchpad.net/dkimpy

12.4.  OpenARC

   Organization: TDP/Murray Kucherawy Description: Implemention of
   milter functionality related to the ARC framework is driven by the following
   high-level goals, security considerations, OpenDKIM and practical operational
   requirements.

A.1.  Primary Design Criteria

   o  Provide a verifiable "chain OpenDMARC packages
   Status of custody" for email messages; Operation: Beta Coverage: Built to support [ARC-DRAFT-14]
   Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
   Implementation Notes:

   o  Not require changes  The build is FreeBSD oriented but some packages have been built
      for originators of email; easier deployment on RedHat-based Linux platforms.

   o  Support the verification of the ARC header field set by each hop  Some issues still exist when deploying in a chained milter
      arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
      with coordination between the handling chain;

   o  Work at Internet scale; and

   o  Provide stages.  When deployed in a trustable
      "sandwich" configuration around an MLM, there is no effective
      mechanism for the communication of
      Authentication-Results across to convey trust boundaries.

A.2.  Out of Scope

   ARC from the ingress (validator) to egress
      (signer) instances.  (_NOTE_: this is not expected to resolved with a trust framework.  Users
      new release of the ARC header fields are
   cautioned against making unsubstantiated conclusions when
   encountering a "broken" ARC sequence.

Appendix B.  Appendix B - Example Usage

   [[ Note: The following examples were mocked up early OpenDMARC expected in mid-2018.)

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

12.5.  Mailman 3.x patch

   Organization: Mailman development team Description: Integrated ARC
   capabilities within the
   definition process for the spec.  They no longer reflect the current
   definition and need various updates which will be included Mailman 3.2 package Status of Operation:
   Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman
   package - GPL Implementation Notes:

   o  Appears to work properly in a
   future draft.  Issue 17 [6] ]]

   (Obsolete at least one beta deployment, but retained for illustrative purposes)

B.1.  Example 1: Simple mailing list

B.1.1.  Here's
      waiting on acceptance of the message as it exits pull request into 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.

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

B.1.2.1.  Example 1, Step A: Message forwarded mainline of
      mailman development

   Contact Info: https://www.gnu.org/software/mailman/contact.html

12.6.  Copernica/MailerQ web-based validation

   Organization: Copernica Description: Web-based validation of ARC-
   signed messages Status of Operation: Beta Coverage: Built to list members

   Processing at example.org:

   o  example.org performs authentication checks

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

   o  example.org adds ARC-Authentication-Results header support
   [ARC-DRAFT-05] Licensing: On-line usage only Implementation Notes:

   o  example.org adds Received: header  Released 2016-10-24

   o  example.org adds a ARC-Seal header

   Here's the  Requires full 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 content to be pasted into a test message.
 --J.

B.1.3.  Example 1: Message received by Recipient

   Let's say that the Recipient is example.com

   Processing web form found
      at example.com:

   o  example.com performs usual authentication checks http://arc.mailerq.com/ (warning - https is not supported).

   o  example.com adds Authentication-Results: header, Received header  An additional instance of an ARC signature can be added if one is
      willing to paste a private key into an unsecured web form.

   o  Determines  2017-07-15: Testing shows that message fails DMARC results match the other
      implementations listed in this section.

   Contact Info: https://www.copernica.com/

12.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-14]
   Licensing: Open source Implementation Notes:

   o  Checks for ARC-Seal: header; finds one  2017-06-12: Released with version 1.6.0

   o  Validates  2017-07-15: Testing during the signature in interop showed that the ARC-Seal: header, which covers validation
      functionality interoperated with the
      ARC-Authentication-Results: header Google, AOL, dkimpy and
      MailerQ implementations

   Contact Info: https://rspamd.com/doc/modules/arc.html and
   https://github.com/vstakhov/rspamd

12.8.  PERL MAIL::DKIM module

   Organization: FastMail Description: Email domain authentication (sign
   and/or verify) module, previously included SPF / DKIM / DMARC, now
   has ARC added Status of Operation: Production, deployment usage
   unknown Coverage: Built to support [ARC-DRAFT-10] Licensing: Open
   Source Implementation Notes:

   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)  2017-12-15: v0.50 released with ESMTP id t0EKaNU9010123 full test set passing 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 ARC

   Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/

12.9.  PERL Mail::Milter::Authentication module

   Organization: FastMail Description: Email domain authentication
   milter, uses MAIL::DKIM (see above) Status of Operation: Intial
   validation completed during IETF99 hackathon 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.

B.2.  Example 2: Mailing list some follow-on work
   during the week Coverage: Built to forwarded mailbox

B.2.1.  Here's support [ARC-DRAFT-14] Licensing:
   Open Source Implementation Notes:

   o  2017-07-15: Validation functionality which interoperates with
      Gmail, AOL, dkimpy was demonstrated; later in the message as it exits week of IETF99,
      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.

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

B.2.2.1.  Example 2, Step A: Message forwarded signing functionality was reported to list members

   Processing at example.org: be working

   o  example.org performs authentication checks  2017-07-20: ARC functionality has not yet been pushed back to the
      github repo but should be showing up soon

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

12.10.  Sympa List Manager

   Organization: Sympa Dev Community Description: Work in progress
   Status of Operation: Work in progress Coverage: unknown Licensing:
   open source Implementation Notes:

   o  example.org applies standard DKIM signature  2018-01-05: Tracked as https://github.com/sympa-community/sympa/
      issues/153

   Contact Info: https://github.com/sympa-community

12.11.  Oracle Messaging Server

   Organization: Oracle Description: Status of Operation: Intial
   development work during IETF99 hackathon.  Framework code is
   complete, crypto functionality requires integration with libsodium
   Coverage: Work in progress Licensing: Unknown Implementation Notes:

   o  No previous Authentication-Results or ARC-Seal headers  2018-03: Protocol handling components are present

   o  example.org adds ARC-Authentication-Results header

   o  example.org adds usual Received: header

   o  example.org adds a ARC-Seal header

   Here's completed, but crypto is
      not yet functional.

   Contact Info: Chris Newman, Oracle

12.12.  MessageSystems Momentum and PowerMTA platforms

   Organization: MessageSystems/SparkPost Description: OpenARC
   integration into the message LUA-enabled Momentum processing space Status of
   Operation: Beta Coverage: Same 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.

B.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: OpenARC Licensing: Unknown
   Implementation Notes:

   o  gmail.com performs usual authentication checks  Initial deployments for validation expected in mid-2018.

   Contact Info: TBD

12.13.  Exim

   Organization: Exim developers Status of Operation: Operational;
   requires specific enabling for compile.  Coverage: Full spec
   implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim-
   users@exim.org Implementation notes:

   o  gmail.com adds Authentication-Results:  Exim 4.91

13.  References

13.1.  Normative References

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

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

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

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

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

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and Received: header

   o  Determines that message fails DMARC

   o  Checks M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://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, <https://www.rfc-editor.org/info/rfc6377>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) 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-Authentication-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
              Authorizing Use of which are

      *  version

      *  sequence number ("i=2")

      *  hash algorithm (SHA256 as example)

      *  timestamp ("t=")

      *  selector for key ("s=notary01")

      *  domain Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
              RFC 7405, DOI 10.17487/RFC7405, December 2014,
              <https://www.rfc-editor.org/info/rfc7405>.

   [RFC7601]  Kucherawy, M., "Message Header Field for key ("d=gmail.com")

      *  headers included Indicating
              Message Authentication Status", RFC 7601,
              DOI 10.17487/RFC7601, August 2015,
              <https://www.rfc-editor.org/info/rfc7601>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in hash ("h=ARC-Authentication-Results:ARC-
         Seal")

      *  Note: algorithm requires only ARC-Seals RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.  Informative References

   [ARC-DRAFT-05]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-05)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-05>.

   [ARC-DRAFT-10]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-10)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-10>.

   [ARC-DRAFT-13]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-13)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-13>.

   [ARC-DRAFT-14]
              Andersen, K., "Authenticated Received Chain (ARC) Protocol
              (I-D-14)", n.d., <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-protocol-14>.

   [ARC-MULTI]
              Andersen, K., "Using Multiple Signing Algorithms with lower sequence #
         be included, in ascending order

      *  signature
              ARC", January 2018, <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-multi-01>.

   [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 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 ARC Headers", April 2018,
              <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-usage-05>.

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

   [I-D-7601bis]
              Kucherawy, M., "Message Header Field 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.

B.2.3.  Example 2: Indicating
              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 Authentication-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: Authentication Status", February 2018,
              <https://datatracker.ietf.org/doc/
              draft-ietf-dmarc-rfc7601bis/>.

   [RFC6982]  Sheffer, Y. 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.

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

B.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, A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <https://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,
              <https://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,
              <https://www.rfc-editor.org/info/rfc7960>.

13.3.  URIs

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

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

   [3] https://github.com/Valimail/arc_test_suite

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

   [5] https://trac.ietf.org/trac/dmarc/ticket/17

   [6] mailto:dmarc@ietf.org

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

   [8] mailto:arc-interop@dmarc.org

   [9] https://arc-spec.org

Appendix A.  Appendix A - Design Requirements

   [[ Note: This section is a test message.
  --J.

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

B.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 re-inserted 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-Authentication-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 background information from
   early versions 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.

B.3.2.2.  Example 3, Step B: Message from list forwarded with source spec. ]]
   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 Authentication-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-Authentication-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 specification 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 ARC framework is a test message.
   --J.

B.3.3.  Example 3: Message received driven 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 Authentication-Results: header, Received header following
   high-level goals, security considerations, and practical operational
   requirements.

A.1.  Primary Design Criteria

   o  Determines that message fails DMARC  Provide a verifiable "chain of custody" for email messages;

   o  Checks  Not require changes for ARC-Seal: header; finds three originators of email;

   o  Validates  Support the signature verification of the ARC header field set by each hop
      in the highest numbered ("i=2") ARC-Seal:
      header, which covers all previous ARC-Seal: handling chain;

   o  Work at Internet scale; and ARC-
      Authentication-Results: headers

   o  Validates  Provide a trustable mechanism for the other ARC-Seal header ("i=2"), which covers communication of
      Authentication-Results across trust boundaries.

A.2.  Out of Scope

   ARC is not a trust framework.  Users of the ARC-
      Authentication-Results: ARC header

   o  Validates fields are
   cautioned against making unsubstantiated conclusions when
   encountering a "broken" ARC sequence.

Appendix B.  Appendix B - Example Usage

   [[ Note: The following examples were mocked up early in the other ARC-Seal header ("i=1"), which covers
   definition process for the
      d1.example ARC-Message-Signature: header

   o  example.com uses spec.  They no longer reflect the ARC-Authentication-Results: values
   Here's what current
   definition and need various updates which will be included in a
   future draft.  Issue 17 [5] ]]

   [[ Note: Need input from the message looks like at WG as to what sort of sequence of
   examples would be considered useful - otherwise we'll just drop 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
   section entirely. ]]

   <removed 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. now to reduce confusion>

Appendix C.  Acknowledgements

   This draft originated with 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 D.  Comments and Feedback

   Please address all comments, discussions, and questions to
   dmarc@ietf.org [7]. [6].  Earlier discussions can be found at arc-
   discuss@dmarc.org [7].  Interop discussions planning can be found at
   arc-interop@dmarc.org [8].

   Some introductory material for less technical people can be found at
   https://arc-spec.org [9].

Authors' Addresses

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

   Email: kurta@linkedin.com

   Brandon Long (editor)
   Google

   Email: blong@google.com

   Steven Jones (editor)
   TDP

   Email: smj@crash.com

   Seth Blank (editor)
   Valimail

   Email: seth@valimail.com

   Murray Kucherawy (editor)
   TDP

   Email: superuser@gmail.com

   Tim Draegon (editor)
   dmarcian

   Email: tim@dmarcian.com