DMARC Working Group
Internet Engineering Task Force (IETF)                       K. Andersen
Internet-Draft
Request for Comments: 8617                                      LinkedIn
Intended status:
Category: Experimental                                      B. Long, Ed.
Expires: June 21, 2019
ISSN: 2070-1721                                                   Google
                                                           S. Blank, Ed.
                                                                Valimail
                                                       M. Kucherawy, Ed.
                                                                     TDP
                                                       December 18, 2018
                                                               June 2019

            The Authenticated Received Chain (ARC) Protocol
                    draft-ietf-dmarc-arc-protocol-23

Abstract

   The Authenticated Received Chain (ARC) protocol provides an
   authenticated "chain of custody" for a message, allowing each entity
   that handles the message to see what entities handled it before, before and
   to see
   what the message's authentication assessment was at each step in the
   handling.

   ARC allows Internet Mail Handlers to attach assertions of message
   authentication assessment to individual messages.  As messages
   traverse ARC-enabled Internet Mail Handlers, additional ARC
   assertions can be attached to messages to form ordered sets of ARC
   assertions that represent the authentication assessment at each step
   of message handling the message-handling paths.

   ARC-enabled Internet Mail Handlers can process sets of ARC assertions
   to inform message disposition decisions, to identify Internet Mail
   Handlers that might break existing authentication mechanisms, and to
   convey original authentication assessments across trust boundaries.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents valid approved by the IESG are candidates for a maximum any level of six months
   Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 June 21, 2019.
   https://www.rfc-editor.org/info/rfc8617.

Copyright Notice

   Copyright (c) 2018 2019 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
   2.  General Concepts  . . . . . . . . . . . . . . . . . . . . . .   5   4
     2.1.  Evidence  . . . . . . . . . . . . . . . . . . . . . . . .   5   4
     2.2.  Custody . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Chain of Custody  . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Validation of Chain of Custody  . . . . . . . . . . . . .   5
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   6   5
     3.1.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Authenticated Received Chain (ARC)  . . . . . . . . . . .   7   6
     3.3.  Internet Mail Handlers / Intermediaries . . . . . . . . .   7
     3.4.  Authentication Assessment . . . . . . . . . . . . . . . .   7
     3.5.  Signing vs vs. Sealing . . . . . . . . . . . . . . . . . . .   7
     3.6.  Sealer  . . . . . . . . . . . . . . . . . . . . . . . . .   8   7
     3.7.  Validator . . . . . . . . . . . . . . . . . . . . . . . .   8   7
     3.8.  Imported ABNF Tokens  . . . . . . . . . . . . . . . . . .   8
     3.9.  Common ABNF Tokens  . . . . . . . . . . . . . . . . . . .   8
   4.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  ARC Header Fields . . . . . . . . . . . . . . . . . . . .   8
       4.1.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . .   9   8
       4.1.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . .   9
       4.1.3.  ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . .  10
       4.1.4.  Internationalized Email (EAI) . . . . . . . . . . . .  11
     4.2.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .  12  11
       4.2.1.  Instance Tags . . . . . . . . . . . . . . . . . . . .  12  11
     4.3.  Authenticated Received Chain  . . . . . . . . . . . . . .  12
     4.4.  Chain Validation Status . . . . . . . . . . . . . . . . .  13  12
   5.  Protocol Actions  . . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Sealer Actions  . . . . . . . . . . . . . . . . . . . . .  14  13
       5.1.1.  Header Fields To to Include In in ARC-Seal Signatures . . .  15  14
       5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains  . . .  15
       5.1.3.  Only One Authenticated Received Chain Per per Message . .  15
       5.1.4.  Broad Ability to Seal . . . . . . . . . . . . . . . .  16  15
       5.1.5.  Sealing is Is Always Safe  . . . . . . . . . . . . . . .  16  15
     5.2.  Validator Actions . . . . . . . . . . . . . . . . . . . .  16
       5.2.1.  All Failures Are Permanent  . . . . . . . . . . . . .  18  17
       5.2.2.  Responding to ARC Validation Failures During during the SMTP
               Transaction . . . . . . . . . . . . . . . . . . . . .  18
   6.  Communication of Validation Results . . . . . . . . . . . . .  18
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  19  18
     7.1.  Communicate Authentication Assessment Across across Trust
           Boundaries  . . . . . . . . . . . . . . . . . . . . . . .  19  18
       7.1.1.  Message Scanning  Message-Scanning Services . . . . . . . . . . . . . .  19
       7.1.2.  Multi-tier MTA Processing . . . . . . . . . . . . . .  19
       7.1.3.  Mailing Lists . . . . . . . . . . . . . . . . . . . .  20  19
     7.2.  Inform Message Disposition Decisions  . . . . . . . . . .  20
       7.2.1.  DMARC Local Policy Overrides  . . . . . . . . . . . .  20
       7.2.2.  DMARC Reporting . . . . . . . . . . . . . . . . . . .  21  20
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22  21
     9.1.  Increased Header Field Size . . . . . . . . . . . . . . .  22
     9.2.  DNS Operations  . . . . . . . . . . . . . . . . . . . . .  22
     9.3.  Message Content Suspicion . . . . . . . . . . . . . . . .  23  22
     9.4.  Message Sealer Suspicion  . . . . . . . . . . . . . . . .  23
     9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  23
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     10.1.  Update to Email Authentication Results Result Names Registry Update . . .  24  23
     10.2.  Update to Email Authentication Methods Registry Update . .  . . . .  24
     10.3.  Definitions of the ARC header fields  New Header Fields in Permanent Message Header Field
            Registry . . . . . . . . . . . . . . . . . . .  24
     10.4.  New Enhanced Status Code - ARC Validation . . . . .  24
     10.4.  New Status Code in Enumerated Status Codes Registry  . .  25
   11. Experimental Considerations . . . . . . . . . . . . . . . . .  25
     11.1.  Success Consideration  . . . . . . . . . . . . . . . . .  25
     11.2.  Failure Considerations . . . . . . . . . . . . . . . . .  26  25
     11.3.  Open Questions . . . . . . . . . . . . . . . . . . . . .  26
       11.3.1.  Value of the ARC-Seal (AS) Header Field  . . . . . .  26
       11.3.2.  Usage and/or signals Signals from multiple selectors Multiple Selectors and/or
                domains
                Domains in ARC sets Sets  . . . . . . . . . . . . . . . .  26
       11.3.3.  DNS Overhead . . . . . . . . . . . . . . . . . . . .  26
       11.3.4.  What Trace Information is Valuable . Is Valuable?  . . . . . . . .  27
   12. Implementation Status . . . . . . . References  . . . . . . . . . . . . .  27
     12.1.  GMail test reflector and incoming validation . . . . . .  28
     12.2.  AOL test reflector and internal tagging . . . . . .  27
     12.1.  Normative References . .  28
     12.3.  dkimpy . . . . . . . . . . . . . . . .  27
     12.2.  Informative References . . . . . . . . .  29
     12.4.  OpenARC . . . . . . . .  28
   Appendix A.  Design Requirements  . . . . . . . . . . . . . . . .  29
     12.5.  Mailman 3.x patch  . .
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  29
     12.6.  Copernica/MailerQ web-based validation . . . . .
     A.2.  Out of Scope  . . . .  30
     12.7.  Rspamd . . . . . . . . . . . . . . . . . .  29
   Appendix B.  Example Usage  . . . . . . .  30
     12.8.  PERL MAIL::DKIM module . . . . . . . . . . . .  29
   Acknowledgments . . . . .  31
     12.9.  PERL Mail::Milter::Authentication module . . . . . . . .  31
     12.10. Sympa List Manager . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . .  32
     12.11. Oracle Messaging Server . . . . . . . . . . . . . . . .  32
     12.12. MessageSystems Momentum and PowerMTA platforms . . . . .  32
     12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . .  33
     12.14. Halon MTA  . . . . . . . . . . . . . . . . . . . . . . .  33
     12.15. IIJ  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     13.2.  Informative References . . . . . . . . . . . . . . . . .  35
     13.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  36
   Appendix A.  Design Requirements  . . . . . . . . . . . . . . . .  36
     A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  36
     A.2.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .  37
   Appendix B.  Example Usage  . . . . . . . . . . . . . . . . . . .  37
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  39
   Appendix D.  Comments and Feedback  . . . . . . . . . . . . . . .  39
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

1.  Introduction

   The utility of widely deployed email authentication technologies such
   as Sender Policy Framework (SPF) [RFC7208]  31

1.  Introduction

   The utility of widely deployed email authentication technologies such
   as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
   Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
   by intermediate handlers.  This impact is thoroughly documented in
   the defining documents for SPF and DKIM and further discussed in
   [RFC6377] and [RFC7960].

   DMARC

   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) [RFC7489] also relies upon SPF and DKIM authentication
   mechanisms.  Failures of authentication caused by the actions of
   intermediate handlers can cause legitimate mail to be incorrectly
   rejected or misdirected.

   Authenticated Received Chain (ARC) creates a mechanism for individual
   Internet Mail Handlers to add their authentication assessment to a
   message's ordered set of handling results.  ARC encapsulates the
   authentication assessment in a DKIM signature derivative to grant
   other handlers the ability to verify the authenticity of the
   individual assessment assertion as well as the aggregate set and
   sequence of results.

   Ordered sets of authentication assessments can be used by ARC-enabled
   Internet Mail Handlers to inform message handling message-handling disposition, to
   identify where alteration of message content might have occurred, and
   to
   provide additional trace information for use in understanding
   message handling
   message-handling paths.

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 state of evidence and to document all processing
   steps.

2.1.  Evidence

   In ARC's situation, the "evidence" is a message's authentication
   assessment at any point along the delivery path between origination
   and final delivery.  Determination of message authentication can be
   affected when intermediate handlers modify message content (header
   fields and/or body content), route messages through unforeseen paths,
   or change envelope information.

   The authentication assessment for a message is determined upon
   receipt of a message and documented in the Authentication-Results
   header field(s).  ARC extends this mechanism to survive transit
   through intermediary ADMDs. Administrative Management Domains (ADMDs).

   Because the first-hand determination of an authentication assessment
   can never be reproduced by other handlers, the assertion of the
   authentication assessment is more akin to testimony by a verifiable
   party than to hard evidence evidence, which can be independently evaluated.

2.2.  Custody

   "Custody" refers to when an Internet Mail Handler processes a
   message.  When a handler takes custody of a message, the handler
   becomes a custodian and attaches their its own evidence (authentication
   assessment upon receipt) to the message if they are ARC-enabled. it is ARC enabled.
   Evidence is added in such a way so that future handlers can verify the
   authenticity of both evidence and custody.

2.3.  Chain of Custody

   The "chain of custody" of ARC is the entire set of evidence and
   custody that travels with a message.

2.4.  Validation of Chain of Custody

   Any ARC-enabled Internet Mail Handler can validate the entire set of
   custody and the authentication assessments asserted by each party to
   yield a valid Chain chain of Custody. custody.  If the evidence-supplying custodians
   can be trusted, then the validated Chain chain of Custody custody describes the
   (possibly changing) authentication assessment as the message traveled
   through various custodians.

   Even though a message's authentication assessment might have changed,
   the validated chain of custody can be used to determine if the
   changes (and the custodians responsible for the changes) can be
   tolerated.

3.  Terminology and Definitions

   This section defines terms used in the rest of the document.

   Readers should to be familiar with the contents, core concepts, and
   definitions found in [RFC5598].  The potential roles of transit
   services in the delivery of email are directly relevant.

   Language, syntax (including some ABNF constructs), and concepts are
   imported from DKIM [RFC6376].  Specific references to DKIM are made
   throughout this document.  The following terms are imported from
   [RFC5598]:

   o  ADministrative  Administrative Management Domain (ADMD), Section 2.3

   o  Message Transfer Agents Agent (MTA), Section 4.3.2

   o  Message Submission Agent (MSA), Section 4.3.1

   o  Message Delivery Agent (MDA), Section 4.3.3

   Syntax descriptions use Augmented BNF (ABNF) 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
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

3.1.  ARC Set

   Section 4.1 introduces three (3) ARC header fields which that are added to
   a message by an ARC-enabled internet mail handler. Internet Mail Handler.  Together, these
   three header fields compose a single "ARC Set".  An ARC Set provides
   the means for an Internet Mail Handler to attach an authentication
   assessment 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 sequence of ARC Sets attached to a message at a given time is
   called the Authenticated "Authenticated Received Chain. Chain" or "ARC".  An Authenticated
   Received Chain is the record of individual authentication assessments
   as a message traverses through ARC-participating ADMDs.

   The first attachment of an ARC Set to a message causes an
   Authenticated Received Chain to be created.  Additional attachments
   of ARC Sets cause the Authenticated Received Chain to be extended.

   In General general concept terms, an Authenticated Received Chain represents
   Chain
   a chain of Custody. custody.

3.3.  Internet Mail Handlers / Intermediaries

   Internet Mail Handlers process and deliver messages across the
   Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
   defined in [RFC5598].

   Throughout this document document, the term "intermediaries" refers to the both
   regular MTAs as well as delivery/reposting agents such as mailing
   lists covered within the scope of [RFC5598]'s transit services. services per [RFC5598].

   "Intermediaries" and "Internet Mail Handlers" are used synonymously
   throughout this document.

3.4.  Authentication Assessment

   The Authentication Assessment which authentication assessment that is affixed to a message as part of
   each ARC Set consists of the "authres-payload" [I-D-7601bis]. [RFC8601].  For the
   integrity of an ARC Set, the Authentication Assessment authentication assessment only needs to
   be properly encapsulated within the ARC Set as defined below in
   Section 4.1.  The accuracy or syntax of the authres-payload field
   does not affect the validity of the ARC chain Chain itself.

3.5.  Signing vs vs. Sealing

   Signing is the process of affixing a digital signature to a message
   as a header field, such as when a DKIM-Signature (as in [RFC6376]
   section [RFC6376],
   Section 2.1), or an AMS AMS, or an AS is added.  Sealing is when an ADMD
   affixes a complete and valid ARC Set to a message creating to create or
   continuing
   continue an Authenticated Received Chain.

3.6.  Sealer

   A Sealer is an Internet Mail Handler that attaches a complete and
   valid ARC Set to a message.

   In general concept terms, a Sealer adds its testimony (assertion of
   authentication assessment) and proof of custody to the Chain chain of
   Custody.
   custody.

3.7.  Validator

   A Validator is an ARC-enabled Internet Mail Handler that evaluates an
   Authenticated Received Chain for validity and content.  The process
   of evaluation of the individual ARC Sets that compose an
   Authenticated Received Chain is described in Section 5.2.

   In general concept terms, a Validator inspects the Chain chain of Custody custody
   to determine the content and validity of individual Evidence evidence supplied
   by custodians.

3.8.  Imported ABNF Tokens

   The following ABNF tokens are imported:

   o  tag-list ([RFC6376] section ([RFC6376], Section 3.2)

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

   o  cfws ([RFC5322] section  CFWS ([RFC5322], Section 3.2.2)

3.9.  Common ABNF Tokens

   The following ABNF tokens are used elsewhere in this document:

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

4.  Protocol Elements

4.1.  ARC Header Fields

   ARC introduces three new header fields.  Syntax  The syntax for new header
   fields adapts existing specifications.  This document only describes
   where ARC-specific changes in syntax and semantics differ from
   existing specifications.

4.1.1.  ARC-Authentication-Results (AAR)

   The ARC-Authentication-Results (AAR) header field records the message
   authentication assessment as processed by an ARC-participating ADMD
   at message arrival time.

   In general concept terms, the AAR header field is where Evidence evidence is
   recorded by a custodian.

   The AAR header field is similar in syntax and semantics to an
   Authentication-Results field [I-D-7601bis], [RFC8601], with two (2) differences:

   o  the name of the header field itself; itself and
   o  the presence of the "instance tag". instance tag.  Additional information on the
      "instance tag"
      instance tag can be found in Section 4.2.1.

   The formal ABNF for the AAR header field 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, Set, the AAR MUST
   contain the combined authres-payload with all of the authentication
   results from within the participating ADMD, regardless of how many
   Authentication-Results header fields are attached to the message.

4.1.2.  ARC-Message-Signature (AMS)

   The ARC-Message-Signature (AMS) header field allows an 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 AMS header field identifies a
   custodian.

   The AMS header field has the same syntax and semantics as the DKIM-
   Signature field [RFC6376], with three (3) differences:

   o  the name of the header field itself;

   o  no version tag ("v") is defined for the AMS header field.  As
      required for undefined tags (in [RFC6376]), if seen, a version tag
      MUST be ignored; and

   o  the "i" (AUID) (Agent or User Identifier (AUID)) tag is not imported from
      DKIM; instead, this tag is replaced by the "instance tag" instance tag as defined
      in Section 4.2.1; 4.2.1.

   ARC places no requirements on the selectors and/or domains used for
   the AMS header field signatures.

   The formal ABNF for the AMS header field is:

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

   To reduce the chances of accidental invalidation of AMS signatures:

   o  AMS header fields are added by ARC-participating ADMDs as messages
      exit the ADMD.  AMS header fields SHOULD be attached so that any
      modifications made by the ADMD are included in the signature of
      the AMS header field.

   o  Authentication-Results header fields MUST NOT be included in AMS
      signatures as they are likely to be deleted by downstream ADMDs
      (per [I-D-7601bis] [RFC8601], Section 5).

   o  ARC-related header fields (ARC-Authentication-Results, ARC-
      Message-Signature, and ARC-Seal) MUST NOT be included in the list
      of header fields covered by the signature of the AMS header field.

   To preserve the ability to verify the integrity of a message, the
   signature of the AMS header field SHOULD include any DKIM-Signature
   header fields already present in the message.

4.1.3.  ARC-Seal (AS)

   The ARC-Seal (AS) AS header field permits ARC-participating ADMDs to verify the
   integrity of AAR header fields and corresponding AMS header fields.

   In general concept terms, the AS header field is how custodians bind
   their authentication assessments (testimonial) (testimonials) into a Chain chain of
   Custody
   custody so that Validators can inspect individual evidence and
   custodians.

   The AS header field is similar in syntax and semantics to DKIM-
   Signatures
   Signature header fields [RFC6376], with the following differences:

   o  the "i" (AUID) tag is not imported from DKIM; instead, this tag is
      replaced by the "instance tag" instance tag as defined in Section 4.2.1;

   o  the signature of the AS header field does not cover the body of
      the message and therefore message; therefore, there is no 'bh' "bh" tag.  The signature of
      the AS header field only covers specific header fields as defined
      in Section 5.1.1;

   o  no body canonicalization is performed as the AS signature does not
      cover the body of a message;

   o  only "relaxed" header field canonicalization ([RFC6376] section ([RFC6376],
      Section 3.4.2) is used;

   o  the only supported tags are "i" (from Section 4.2.1 of this
      document), and "a", "b", "d, "d", "s", and "t" from [RFC6376] [RFC6376],
      Section 3.5.  Note especially that the DKIM "h" tag is NOT allowed and
      and, if found, MUST result in a cv status of "fail" (for more information
      information, see Section 5.1.1); and
   o  an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
      definition)
      definition), is used to communicate the Chain Validation Status to
      subsequent ADMDs.

   ARC places no requirements on the selectors and/or domains used for
   the AS header field signatures.

   The formal ABNF for the AS header field is:

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

4.1.4.  Internationalized Email (EAI)

   In internationalized messages [RFC6532] [RFC6532], many header fields can
   contain UTF-8 as well as ASCII text.  The changes for EAI are all
   inherited from DKIM as updated by [draft-levine-eaiauth] [RFC8616] and
   Authentication-Results Authentication-
   Results (A-R) as updated in [I-D-7601bis], [RFC8601], but they are called out here
   for emphasis.

   In all ARC header fields, the d= and s= tags can contain U-labels.
   In all tags, non-ASCII characters need not be quoted in dkim-quoted-
   printable.

   The AAR header allows UTF-8 in the same places that A-R Authentication-
   Results does, as described in [I-D-7601bis]. [RFC8601].

4.2.  ARC Set

   An "ARC Set" is a single collection of three ARC header fields (AAR,
   AMS, and AS).  ARC header fields of an ARC Set share the same
   "instance" value.

   By adding all ARC header fields to a message, an ARC Sealer adds an
   ARC Set to a message.  A description of how Sealers add an ARC Set to
   a message is found in Section 5.1.

4.2.1.  Instance Tags

   Instance tags describe which ARC header fields belong to an ARC Set.
   Each ARC header field of an ARC Set shares the same instance tag
   value.

   Instance tag values are integers that begin at 1 and are incremented
   by each addition of an ARC Set.  Through the incremental values of
   instance tags, an ARC Validator can determine the order in which ARC
   Sets were added to a message.

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

   _INFORMATIONAL:_

   _INFORMATIONAL_: The upper limit of 50 was picked based on some
   initial observations reported by early working group members.  The
   value was chosen so as to balance the risk of excessive header field growth
   (see Section 9.1 9.1) against expert opinion regarding the probability of long-tail
   long-tail, but non-looping non-looping, multiple-intermediary mail flows.  Longer
   ARC chains Chains will also impose a load on validators Validators and DNS to support
   additional verification steps.  Observed quantities of "Received"
   header fields was were also considered in establishing this as an
   experimental initial value.

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

   For handling multiple signing algorithms, see [ARC-MULTI].

4.3.  Authenticated Received Chain

   An Authenticated Received Chain is an ordered collection of ARC Sets.
   As ARC Sets are enumerated sets of ARC header fields, an
   Authenticated Received Chain represents the output of message
   authentication assessments along the handling path of ARC-enabled
   processors.

   Authentication Assessments assessments determined at each step of the ARC-enabled
   handling path is are present in an Authenticated Received Chain in the
   form of AAR header fields.  The ability to verify the identity of
   message handlers and the integrity of message content is provided by
   AMS header fields.  AS header fields allow messages message handlers to
   validate the assertions, order order, and sequence of the Authenticated
   Received Chain itself.

   In general concept terms, an Authenticated Received Chain represents
   a message's Chain chain of Custody. custody.  Validators can consult a message's
   Chain
   chain of Custody custody to gain insight regarding each custodian of a
   message and the Evidence evidence collected by each custodian.

4.4.  Chain Validation Status

   The state of the Authenticated Received Chain at a specific
   processing step is called the "Chain Validation Status".  Chain
   Validation Status information is communicated in several ways:

   o  as the AS header field in the "cv" tag, tag and

   o  as part of the Authentication-Results and AAR header field(s).

   Chain Validation Status has one of 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
      upstream Internet Mail Handler that is not participating in ARC
      handling.

   o  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
   Validators (when receiving messages) and ARC Sealers (when sending
   messages onward, not originated locally).

   An Authenticated Received Chain with a Chain Validation Status of
   "pass" (or "none") allows Internet Mail Handlers to ascertain:

   o  all ARC-participating ADMDs that claim responsibility for handling
      (and possibly modifying) the message in transit; transit and

   o  the authentication assessments of the message as determined by
      each ADMD (from AAR header fields).

   With this information, Internet Mail Handlers MAY inform local policy
   decisions regarding disposition of messages that experience
   authentication failure due to intermediate processing.

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

   To perform Sealing sealing (aka to build and attach a new ARC Set), the
   following actions must be taken by an ARC Sealer when presented with
   a message:

   1.  All message modifications (including adding a DKIM-Signature
       header field(s)) MUST be performed before Sealing. sealing.

   2.  If the message already contains an Authenticated Received Chain
       with the most recent AS reporting "cv=fail", then there is no need to
       proceed and the algorithm stops here.

   3.  Calculate the instance value: if value.  If the message already contains an
       Authenticated Received Chain, the instance value is 1 more than
       the highest instance number found in the Authenticated Received
       Chain.  If no Authenticated Received Chain exists, the instance
       value is 1.

   4.  Using the calculated instance value, generate and attach a
       complete ARC set Set to the message as follows:

       1.

       A.  Generate and attach an ARC-Authentication-Results header
           field as defined in Section 4.1.1.

       2.

       B.  Generate and attach an ARC-Message-Signature header field as
           defined in Section 4.1.2.

       3.

       C.  Generate and attach an ARC-Seal header field using the AS
           definition found in Section 4.1.3, the prescribed headers
           defined in Section 5.1.1, and the Chain Validation Status as
           determined during ARC Validation. validation.

5.1.1.  Header Fields To to Include In in ARC-Seal Signatures

   The ARC-Seal is generated in a manner similar to how DKIM-Signatures DKIM-Signature
   header fields are added to messages ([RFC6376], section Section 3.7), with
   explicit requirements on the header fields and ordering of those
   fields.

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

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

   1.  ARC-Authentication-Results

   2.  ARC-Message-Signature

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

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

   In the case of a failed Authenticated Received Chain, the header
   fields included in the signature scope of the AS header field b=
   value MUST only include the ARC Set header fields created by the MTA
   which
   that detected the malformed chain, as if this newest ARC Set was the
   only set present.

   _INFORMATIONAL_: This approach is mandated to handle the case of a
   malformed or otherwise invalid Authenticated Received Chain.  There
   is no way to generate a deterministic set of AS header fields
   (Section 5.1.1) in most cases of invalid chains.

5.1.3.  Only One Authenticated Received Chain Per per Message

   A message can have only one Authenticated Received Chain on it at a
   time.  Once broken, the chain cannot be continued, as the chain of
   custody is no longer valid valid, and responsibility for the message has
   been lost.  For further discussion of this topic and the design
   restriction which that prevents chain continuation or re-establishment, see
   [ARC-USAGE].

5.1.4.  Broad Ability to Seal

   ARC is not solely intended for perimeter MTAs.  Any Internet Mail
   Handler MAY seal a message by adding a complete ARC set, Set, whether or
   not they have modified or are aware of having modified the message.
   For additional information, see Section 7.1.

5.1.5.  Sealing is Is Always Safe

   The utility of an Authenticated Received Chain is limited to very
   specific cases.  Authenticated Received Chains are designed to
   provide additional information to an Internet Mail Handler when
   evaluating messages for delivery in the context of authentication
   failures.  Specifically:

   o  Properly adding an ARC Set to a message does not damage or
      invalidate an existing Authenticated Received Chain.

   o  Sealing an Authenticated Received Chain when a message has not
      been modified does not negatively affect the chain.

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

   o  An ADMD may choose to Seal seal all inbound messages whether or not a
      message has been modified or will be retransmitted.

5.2.  Validator Actions

   A validator Validator performs the following steps, in sequence, to process an
   Authenticated Received Chain.  Canonicalization, hash functions, and
   signature validation methods are imported from [RFC6376] section [RFC6376], Section 5.

   1.  Collect all ARC Sets currently attached to the message.

       *  If there are none, the Chain Validation Status is "none" "none", and
          the algorithm stops here.

       *  The maximum number of ARC Sets that can be attached to a
          message is 50.  If more than the maximum number exist exist, the
          Chain Validation Status is "fail" "fail", and the algorithm stops
          here.

       *  In the following algorithm, the maximum discovered ARC
          instance value is referred to as "N".

   2.  If the Chain Validation Status of the highest instance value ARC
       Set is "fail", then the Chain Validation status Status is "fail" "fail", and
       the algorithm stops here.

   3.  Validate the structure of the Authenticated Received Chain.  A
       valid ARC has the following conditions:

       1.

       A.  Each ARC Set MUST contain exactly one each of the three ARC
           header fields (AAR, AMS, and AS).

       2.

       B.  The instance values of the ARC Sets MUST form a continuous
           sequence from 1..N with no gaps or repetition.

       3.

       C.  The "cv" value for all ARC-Seal header fields MUST NOT be
           "fail".  For ARC Sets with instance values > 1, the values
           MUST be "pass".  For the ARC Set with instance value = 1, the
           value MUST be "none".

       *  If any of these conditions are not met, the Chain Validation
          Status is "fail" "fail", and the algorithm stops here.

   4.  Validate the AMS with the greatest instance value (most recent).
       If validation fails, then the Chain Validation Status is "fail" "fail",
       and the algorithm stops here.

   5.  _OPTIONAL:_  _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by
       validating each prior AMS beginning with the N-1 and proceeding in
       decreasing order to the AMS with the instance value of 1:

       1.

       A.  If an AMS fails to validate (for instance value "M"), then
           set the oldest-pass value to the lowest AMS instance value
           which
           that passed (M+1) (M+1), and go to the next step (there is no need
           to check any other (older) AMS header fields).  This does not
           affect the validity of the Authenticated Received Chain.

       2.

       B.  If all AMS header fields verify, set the oldest-pass value to
           zero (0).

   6.  Validate each AS beginning with the greatest instance value and
       proceeding in decreasing order to the AS with the instance value
       of 1.  If any AS fails to validate, the Chain Validation Status
       is "fail" "fail", and the algorithm stops here.

   7.  If the algorithm reaches this step, then the Chain Validation
       Status is "pass", and the algorithm is complete.

   The end result of this Validation validation algorithm SHOULD be included within
   the Authentication-Results header field for the ADMD.

   As with a DKIM signature ([RFC6376] section ([RFC6376], Section 6.3) which that fails
   verification, a message with an Authenticated Received Chain with a
   Chain Validation status Status of "fail" MUST be treated the same as 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.
   seals.

5.2.1.  All Failures Are Permanent

   Authenticated Received Chains represent the traversal of messages
   through one or more intermediaries.  All errors, including DNS
   failures, become unrecoverable and are considered permanent.

   Any error validating an Authenticated Received Chain results in a
   Chain Validation Status of "fail".  For further discussion of this
   topic and the design restriction which that prevents chain continuation or
   re-establishment, see [ARC-USAGE].

5.2.2.  Responding to ARC Validation Failures During during the SMTP
        Transaction

   If an ARC Validator determines that the incoming message fails ARC
   validation, the Validator MAY signal the breakage through the
   extended SMTP response code 5.7.29 "ARC ("ARC validation failure" failure") and the
   corresponding SMTP basic response code.  Because ARC failures are
   likely only to be detected in the context of other underlying
   authentication mechanism failures, validators Validators MAY use the more
   general 5.7.26 "Multiple ("Multiple authentication checks failed" failed") instead of
   the ARC-specific code.

6.  Communication of Validation Results

   Chain Validation Status (described in Section 4.4) is communicated
   via Authentication-Results (and AAR) header fields using the auth
   authentication method "arc".  This auth authentication method is described
   in Section 10.1.

   If necessary data is available, the ptypes and properties defined in
   Section 10.2 SHOULD be recorded in an Authentication-Results header
   field:

   o  smtp.remote-ip - The address of the connection-initiating SMTP
      server, from which the message is being relayed.

   o  header.oldest-pass - The instance number of the oldest AMS that
      still validates, or 0 if all pass.

7.  Use Cases

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

7.1.  Communicate Authentication Assessment Across across Trust Boundaries

   When an intermediary ADMD adds an ARC Set to a message's
   Authenticated Received Chain (or creates the initial ARC Set), the
   ADMD communicates its authentication assessment to the next ARC-
   participating ADMD in the message handling message-handling path.

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

7.1.1.  Message Scanning  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 messages with sanitized links, and/or
   attach footers to messages advertising the abilities of the message 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 scanning service.  Messages destined for the
   Internet domain are initially delivered to the scanning service.
   Once scanning is performed, messages are then routed to the client's
   own mail handling mail-handling infrastructure.  Re-routing  Rerouting messages in this way
   almost always breaks path-based authentication (such as SPF).

   Message scanning

   Message-scanning services can attach Authenticated Received Chains to
   messages to communicate authentication assessment into client ADMDs.
   Clients can then benefit from the message scanning message-scanning service while
   processing messages as if the client's infrastructure were the
   original destination of the Internet domain's MX record.

7.1.2.  Multi-tier MTA Processing

   Large message processing

   A 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 connection handling and enforcement of IP-based
   reputation filtering.  A secondary cluster of MTAs may be dedicated
   and optimized for content-based processing of messages.

   Authenticated Received Chains can be used to communicate
   authentication assessment between processing tiers.

7.1.3.  Mailing Lists

   Mailing lists take delivery of messages and re-post repost them to
   subscribers.  A full description of authentication-related mailing
   list issues can be found in [RFC7960] [RFC7960], Section 3.2.3.

   Mailing list services can implement ARC to convey the authentication
   assessment of posted messages sent to the list's subscriber base.
   The ADMDs of the mailing list subscribers can then use the
   Authenticated Received Chain to determine the authentication
   assessment of the original message before mailing list handling.

7.2.  Inform Message Disposition Decisions

   Intermediaries often break authentication through content
   modification, interfere with path-based authentication (such as SPF),
   and strip authentication results (if an MTA removes Authentication-
   Results header fields).

   Authenticated Received Chains allow ARC Validators to:

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

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

   Through the collection of ARC-related data, an ADMD can identify
   handling paths that have broken authentication.

   An Authenticated Received Chain allows an Internet Mail Handler to
   potentially base decisions of message disposition on authentication
   assessments provided by different ADMDs.

7.2.1.  DMARC Local Policy Overrides

   DMARC introduces a policy model where Domain Owners can request email
   receivers to reject or quarantine messages that fail DMARC alignment.
   Interoperability issues between DMARC and indirect email flows are
   documented in [RFC7960].

   Authenticated Received Chains allow DMARC processors to consider
   authentication assessments provided by other ADMDs.  As a matter of
   local policy, a DMARC processor MAY choose to accept the
   authentication assessments provided by an Authenticated Received
   Chain when determining if a message is DMARC compliant.

   When an Authenticated Received Chain is used to determine message
   disposition, the DMARC processor can communicate this local policy
   decision to Domain Owners as described in Section 7.2.2.

7.2.2.  DMARC Reporting

   DMARC-enabled receivers indicate when ARC Validation validation influences
   DMARC-related local policy decisions.  When an ARC-enabled handler
   generates a DMARC report, it MAY indicate the influence of ARC on
   their local policy decision(s) by adding a reason of "local_policy"
   with a comment string (per [RFC7489] [RFC7489], Appendix C) containing a list
   of data discovered during ARC Validation, validation, which at a minimum
   includes:

   o  the Chain Validation Status,

   o  the domain and selector for each AS, and

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

   EXAMPLE:

   <policy_evaluated>
     <disposition>none</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass as[2].d=d2.example as[2].s=s2
        as[1].d=d1.example as[1].s=s3
        remote-ip[1]=2001:DB8::1A</comment>
     </reason>
   </policy_evaluated>

   In the above example DMARC XML reporting fragment, fragment above, data relating to
   specific validated ARC Sets are enumerated using array syntax (eg, (e.g.,
   "as[2]" means an AS header field with an instance value of 2).
   d2.example is the Sealing sealing domain for ARC Set #2 (i=2) (i=2), and d1.example
   is the
   Sealing sealing domain for ARC Set #1 (i=1).

   Depending on the reporting practices of intermediate message
   handlers, Domain Owners may receive multiple DMARC reports for a
   single message.  Receivers of DMARC reports should be aware of this
   behaviour
   behavior and make the necessary accommodations.

8.  Privacy Considerations

   The Authenticated Received Chain provides a verifiable record of the
   handlers for a message.  This record may include Personally
   Identifiable Information personally
   identifiable information such as an IP address(es) and domain names.
   Such information is also included in existing non-ARC related non-ARC-related header
   fields such as the "Received" header fields.

9.  Security Considerations

   The Security Considerations of [RFC6376] and [I-D-7601bis] [RFC8601] apply directly
   to this specification.

   As with other domain domain-based authentication technologies (such as SPF,
   DKIM, and DMARC), ARC makes no claims about the semantic content of
   messages.  A received message with an a validated ARC chain Chain provides
   evidence (at instance N) that: The

   1.  the sealing domain (ARC-Seal (ARC-Seal[N] d=) processed a emitted the message with this
       body, determined

   2.  the authentication assessment reported in the
   ARC-Authentication-Results, ARC-Authentication-
       Results was determined upon receipt of the corresponding message
       at the sealing domain, and

   3.  the preceding ARC chain 1..N-1 Chain (1..N-1) (with the validation status as
       reported in the cv field). field) existed on the message that was
       received and assessed.

9.1.  Increased Header Field Size

   Inclusion of Authenticated Received Chains into messages may cause
   issues for older or constrained MTAs due to increased total header
   field size.  Large header field blocks, in general, may cause
   failures to deliver or other outage scenarios for such MTAs.  ARC
   itself would not cause problems.

9.2.  DNS Operations

   The validation of an Authenticated Received Chain composed of N ARC
   Sets can require up to 2*N DNS queries (not including any DNS
   redirection mechanisms which that can increase the total number of
   queries).  This leads to two considerations:

   1.  An attacker can send a message to an ARC participant with a
       concocted sequence of ARC Sets bearing the domains of intended
       victims, and all of them will be queried by the participant until
       a failure is discovered.  DNS caching and the difficulty of
       forging the signature values should limit the extent of this load
       to domains under control of the attacker.  Query traffic pattern
       analysis may expose information about a downstream validating
       ADMD infrastructure.

   2.  DKIM only performs one DNS query per signature, while ARC can
       introduce many (per chain).  Absent caching, slow DNS responses
       can cause SMTP timeouts; timeouts and backlogged delivery queues on
       Validating
       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 the same suspicion applied to all other
   messages.  This includes appropriate content scanning and other
   checks for potentially malicious content.

   ARC authenticates the identity of some email handling email-handling actors.  It
   does not make any assessment of their trustworthiness.

   Just as passing message authentication is not an indication of
   message safety, forwarding that information through the mechanism of
   ARC is 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 treat every Sealer of the ARC Chain with
   suspicion.  Just as with a validated DKIM signature, responsibility
   for message handling is attributed to the Sealing sealing domain, but whether
   or not that Sealer is a malicious actor is out of scope of the
   authentication mechanism.  Since ARC aids message delivery in the
   event of an authentication failure, ARC Sealers should be treated
   with suspicion, so that a malicious actor cannot Seal 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 Replay Attack replay attack described in [RFC6376] section [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 passing ARC Chain, Chain
   and then resend it to many recipients without making any modifications
   that invalidate the latest AMS or AS.  The impact to a receiver would
   be more DNS lookups and signature evaluations.  This  The scope of this
   attack can be limited by caching DNS queries and following the same
   signing scope guidance from [RFC6376] section [RFC6376], Section 5.4.1.

10.  IANA Considerations

   [[ *Note to the RFC Editors:* "dkim - header - s" is defined in
   [I-D-7601bis].  Please adjust the list below as appropriate. ]]

   This draft introduces three new headers fields and updates the Email
   Authentication Parameters registry with document defines one new authentication method and several
   status codes. codes (Section 10.1), new ptypes and properties
   (Section 10.2), three new headers fields (Section 10.3), and a new
   enumerated status code (Section 10.4).

10.1.  Update to Email Authentication Results Result Names Registry Update

   This draft adds

   Per this document, IANA has added one Auth Method authentication method with
   three Codes codes to the IANA "Email Authentication Result Names" registry:

   o  Auth Method : Method: arc
      Code: "none", "pass", "fail"
      Specification: this document 2.2 RFC 8617, Section 4.4
      Status: active

10.2.  Update to Email Authentication Methods Registry Update

   This draft adds several new items

   Per this document, IANA has added the following to the Email "Email
   Authentication Methods Methods" registry, most recently which is defined in [I-D-7601bis]: [RFC8601]:

   o  Method: arc
      Definition: this document section RFC 8617, Section 6
      ptype: smtp
      Property: remote-ip
      Value: IP address (v4 or v6) of originating SMTP connection
      Status: active
      Version: 1

   o  Method: arc
      Definition: this document section RFC 8617, Section 6
      ptype: header
      Property: oldest-pass
      Value: The instance id of the oldest validating AMS, AMS or 0 if they
      all pass (see Section 5.2)
      Status: active
      Version: 1

10.3.  Definitions of  New Header Fields in Permanent Message Header Field Registry

   Per this document, IANA has added the ARC header fields

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

   o  Header field name: ARC-Seal
      Applicable protocol: mail
      Status: Experimental experimental
      Author/Change controller: IETF
      Specification document(s): this document RFC 8617
      Related information: [RFC6376] RFC 6376

   o  Header field name: ARC-Message-Signature
      Applicable protocol: mail
      Status: Experimental experimental
      Author/Change controller: IETF
      Specification document(s): this document RFC 8617
      Related information: [RFC6376] RFC 6376

   o  Header field name: ARC-Authentication-Results
      Applicable protocol: mail
      Status: Experimental experimental
      Author/Change controller: IETF
      Specification document(s): this document RFC 8617
      Related information: [I-D-7601bis] RFC 8601

10.4.  New Enhanced Status Code - ARC Validation

   The in Enumerated Status Codes Registry

   Per this document, IANA has added the following value should be added to the [ENHANCED-STATUS]
   registry, as follows:
   "Enumerated Status Codes" registry:

   o  Code: X.7.29
      Sample Text: ARC validation failure
      Associated basic status code: 550
      Description: This status code may be returned when a message fails
      ARC validation validation.
      Reference: this document RFC 8617
      Submitter: K. Andersen
      Change controller: IESG

11.  Experimental Considerations

   The ARC protocol is designed to address common interoperability
   issues introduced by intermediate message handlers.  Interoperability
   issues are described in [RFC6377] and [RFC7960].

   As the ARC protocol is implemented by Internet Mail Handlers over
   time, the following should be evaluated in order to determine the
   success of the protocol in accomplishing the 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 will be a success if the presence of Authenticated Received
   Chains allows for improved decision making when processing legitimate
   messages, specifically resulting in equal or better delivery rates
   than achieve achieved through the use of heuristic approaches.

11.2.  Failure Considerations

   ARC should function without introducing significant new vectors for
   abuse (see Section 9).  If unforeseen vectors are enabled by ARC,
   then
   this protocol will be a failure.  Note that the weaknesses inherent
   in the mail protocols ARC is built upon (such as DKIM replay attacks
   and other known issues) are not new vectors which that can be attributed to
   this specification.

11.3.  Open Questions

   The following open questions are academic and have no clear answer at
   the time of the development of the protocol. this document was published.  However, additional
   deployments should be able to gather the necessary data to answer
   some or all of them.

11.3.1.  Value of the ARC-Seal (AS) Header Field

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

11.3.2.  Usage and/or signals Signals from multiple selectors Multiple Selectors and/or domains Domains in
         ARC sets Sets

   Any selectors and/or (sub)domains (under the control of the sealing
   ADMD) may be used for ARC header field signatures.

   While implementers may choose to use various selectors and/or domains
   for ARC set Set header fields, no compelling argument for or against such
   usage has been made within the working group.  As such such, we have
   chosen to allow maximum freedom for the experimental definition of
   this protocol.

   Wider deployment experience and higher volumes of traffic may show
   whether this is useful.

11.3.3.  DNS Overhead

   Longer Authenticated Received Chains will require more queries to
   retrieve the keys for validating the chain.  While this is not
   believed 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 that were debated at the
   time of the DKIM specification development.

   Data should be collected to better understand usable length and
   distribution of lengths found in valid Authenticated Received Chains
   along with the DNS impact of processing Authenticated Received
   Chains.

   An effective operational maximum will have to be developed through
   deployment experience in the field.

11.3.4.  What Trace Information is Valuable 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 well-known mailing list that seals with ARC
   but doesn't do its own initial DMARC enforcement, an Internet Mail
   Handler with this knowledge could make a delivery decision based upon
   the authentication information it sees in the corresponding AAR
   header field.

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

   Further, 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.

   At this point, however, 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, 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

   [[ Note to the RFC Editor: Please remove this section before
   publication along with the reference to [RFC7942]. ]]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   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 August 2018.

12.1.  GMail test reflector and incoming validation

   Organization: Google
   Description: Internal production implementation with both debug
   analysis and validating + sealing pass-through function
   Status of Operation: Production - Incoming Validation
   Coverage: Full spec implemented as of this document
   Licensing: Internal only
   Implementation Notes:

   o  Full functionality was demonstrated during the interop testing on
      2018-03-17 and 2018-10-12.  All traffic going into GSuite, Google
      Groups, or GMail mailboxes will have ARC validation and sealing.

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

12.2.  AOL test reflector and internal tagging

   Organization: AOL
   Description: Internal prototype implementation with both debug
   analysis and validating + sealing pass-through function
   Status of Operation: Beta
   Coverage: ARC Chain validity status checking is 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 AOL mail infrastructure to
      the integrated OATH environment.  The implementation was based on
      the Apache James DKIM code base.

   o  2018-10: No longer available due to infrastucture changes at AOL/
      Yahoo!/Oath.

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

12.3.  dkimpy

   Organization: dkimpy developers/Scott Kitterman
   Description: Python DKIM package
   Status of Operation: Production
   Coverage: Full spec implemented as of this document

   o  2017-07-15: The internal test suite is incomplete, but the command
      line developmental version of validator was demonstrated to
      interoperate with the Google and AOL implementations during the
      interop on 2017-07-15 and the released version passes the tests in
      [ARC-TEST] arc_test_suite [3] with both python and python3.

   o  2018-10: Re-validated in the interop

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

12.4.  OpenARC

   Organization: TDP/Murray Kucherawy
   Description: Implementation of milter functionality related to the
   OpenDKIM and OpenDMARC packages
   Status of Operation: Beta
   Coverage: Built to support this document
   Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
   Implementation Notes:

   o  2018-10: Validated with one bug discovered during interop

   o  2018-11: Known issues have been resolved with release 1.0.0-Beta2

   Contact Info: arc-discuss@dmarc.org [4], openarc-users@openarc.org
   [5]

12.5.  Mailman 3.x patch

   Organization: Mailman development team
   Description: Integrated ARC capabilities within the 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 at least one beta deployment, but
      waiting on acceptance of the pull request into the mainline of
      mailman development

   o  Discussions continuing with Mailman team to get this integrated

   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 support [ARC-DRAFT-05]
   Licensing: On-line usage only
   Implementation Notes:

   o  Released 2016-10-24

   o  Requires full message content to be pasted into a web form found
      at http://arc.mailerq.com/ (warning - https is not supported).

   o  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  2017-07-15: Testing shows that results match the other
      implementations listed in this section.

   o  2018-10: not tested during interop

   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  2017-06-12: Released with version 1.6.0
   o  2017-07-15: Testing during the interop showed that the validation
      functionality interoperated with the Google, AOL, dkimpy and
      MailerQ implementations

   o  2018-10: Re-validated during the interop

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

   o  2018-10: Revalidated during the interop and used for the creation
      of the Appendix B example

   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: Initial validation completed during IETF99
   hackathon with some follow-on work during the week
   Coverage: Built to 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 week of IETF99,
      the signing functionality was reported to be working

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

   o  2018-10: Revalidated during the interop

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

12.10.  Sympa List Manager

   Organization: Sympa Dev Community
   Description: Beta released Status of Operation: Beta released
   Coverage: Built to support this document, based on Mail::DKIM module
   Licensing: open source
   Implementation Notes:

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

   o  2018-12-08: Sympa 6.2.37 beta 3 incorporates ARC support,
      scheduled for stable release 6.2.38 on 2018-12-21

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

12.11.  Oracle Messaging Server

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

   o  2018-03: Protocol handling components are 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 LUA-enabled Momentum
   processing space
   Status of Operation: Beta
   Coverage: Same as OpenARC
   Licensing: Unknown
   Implementation Notes:

   o  2018-10: Beta version in private evaluation, proprietary or confidential
   to prevent gaming by abusers, it may not tested during
      interop.

   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  Implemented as of Exim 4.91

12.14.  Halon MTA

   Organization: Halon
   Status of Operation: Operational as of May 2018
   Coverage: Full spec implemented as of be viable to reliably answer
   this document Licensing:
   Commercial, trial version available for download
   Contact Info: https://halon.io
   Implementation notes:

   o  GPL'd library with ARC capabilities: https://github.com/halon/
      libdkimpp

   o  2018-10: Validated during interop

12.15.  IIJ

   Organization: Internet Initiative Japan (IIJ) Status of Operation:
   Operational as of October 2018
   Coverage: Full spec implemented as particular question.  The evolving nature of this document
   Licensing: Internal
   Contact Info: https://www.iij.ad.jp/en/
   Implementation notes:

   o  2018-10: Internal MTA implementation validated during attacks can also
   shift the ARC
      interop

13. landscape of "useful" information over time.

12.  References

13.1.

12.1.  Normative References

   [draft-levine-eaiauth]
              Levine, J., "E-mail Authentication for Internationalized
              Mail", August 2018, <https://tools.ietf.org/html/
              draft-levine-appsarea-eaiauth-03>.

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

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

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

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

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

   [RFC8174]  Leiba, B., "Ambiguity 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>.

13.2.

   [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 8601,
              DOI 10.17487/RFC8601, May 2019,
              <https://www.rfc-editor.org/info/rfc8601>.

   [RFC8616]  Levine, J., "Email Authentication for Internationalized
              Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
              <https://www.rfc-editor.org/info/rfc8616>.

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-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., Blank, S., Ed., and J. Levine, Ed., "Using
              Multiple Signing Algorithms with
              ARC", June 2018, <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-multi-02>.

   [ARC-TEST]
              Blank, S., "ARC Test Suite", January 2017,
              <https://github.com/Valimail/arc_test_suite>. the ARC (Authenticated
              Received Chain) Protocol", Work in Progress, draft-ietf-
              dmarc-arc-multi-03, March 2019.

   [ARC-USAGE]
              Jones, S., Adams, T., Rae-Grant, J., Ed. and K. Andersen, "Recommended Usage of the ARC Headers",
              Authenticated Received Chain (ARC)", Work in Progress,
              draft-ietf-dmarc-arc-usage-07, April 2018,
              <https://tools.ietf.org/html/
              draft-ietf-dmarc-arc-usage-05>.

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

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

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [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] mailto:openarc-users@openarc.org

   [6] mailto:dmarc@ietf.org

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

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

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

Appendix A.  Design Requirements

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

A.1.  Primary Design Criteria

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

   o  Not require changes for originators of email;

   o  Support the verification of the ARC header field set by each hop
      in the handling chain;

   o  Work at Internet scale; and

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

A.2.  Out of Scope

   ARC is not a trust framework.  Users of the ARC header fields are
   cautioned against making unsubstantiated conclusions when
   encountering a "broken" ARC sequence.

Appendix B.  Example Usage

   The following message is an example of one which that has passed through
   several intermediary handlers, some of which have modified the
   message and others which have not:

Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
    by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
    for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
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)
Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [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)
Received: from mail-ob0-f188.google.example
    (mail-ob0-f188.google.example [208.69.40.157]) by
    clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
    for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
        clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
        +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
        clochette.example.org; h=message-id:date:from:to:subject; s=
        clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
        LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
        K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
Authentication-Results: clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
    ams.2.gmail.example=pass, as.1.lists.example.org=pass,
    ams.1.lists.example.org=fail (message has been altered))
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
        12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
        8jjLXWpRNuh81yqnT1/jHn086RwezGw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
        gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
        12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
        cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
        9WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@example.org; dmarc=fail; arc=pass
    (as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
         t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
        lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
        lists.example.org; h=message-id:date:from:to:subject; s=
        dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
        Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
        yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
ARC-Authentication-Results: i=1; lists.example.org; spf=pass
    smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
    header.i=@d1.example; dmarc=pass
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
        message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
        AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
        0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
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.example
Subject: [List 2] Example 1

Hey gang,
This is a test message.
--J.

Appendix C.  Acknowledgements

Acknowledgments

   This draft document originated with the work of OAR-Dev Group.

   The authors thank all of the OAR-Dev and the subsequent DMARC-WG
   group DMARC WG for
   the ongoing help and though-provoking thought-provoking discussions from all the
   participants, especially: especially J. Trent Adams, Marc Bradshaw, Alex Brotman, Brandon Long, Dave
   Crocker, Elizabeth Zwicky, Franck Martin,
   Greg Colburn, J.  Trent
   Adams, John Rae-Grant, Dave Crocker, Tim Draegen, Mark Eissler, Peter
   Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Terry
   Zink, Tim Draegen, Gene Shuman, Scott
   Kitterman, Bron Gondwana. Barry Leiba, Franck Martin, John Rae-Grant, Paul Rock,
   Gene Shuman, Terry Zink, and Elizabeth Zwicky.

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

Appendix D.  Comments and Feedback

   Please address all comments, discussions, and questions to
   dmarc@ietf.org [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
   United States of America

   Email: kurt+ietf@drkurt.com
   Brandon Long (editor)
   Google

   Email: blong@google.com

   Seth Blank (editor)
   Valimail

   Email: seth@valimail.com

   Murray Kucherawy (editor)
   TDP

   Email: superuser@gmail.com