<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7208 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml">
<!ENTITY RFC1345 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1345.xml">
<!ENTITY RFC5234 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5321 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC3463 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3463.xml">
<!ENTITY RFC7601 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7601.xml">
<!ENTITY RFC6651 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml">
<!ENTITY RFC6376 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml">
<!ENTITY RFC5598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7489 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml">
<!ENTITY SELF "[I-D.ARC]">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="noDerivativesTrust200902" docName="draft-andersen-arc-03" category="info">

  <front>
    <title abbrev="ARC">Authenticated Received Chain (ARC)</title>

    <author initials="K." surname="Andersen" fullname="Kurt Andersen">
      <organization>LinkedIn</organization>
      <address>
        <postal>
          <street>2029 Stierlin Ct.</street>
          <city>Mountain View</city>
          <region>California</region>
          <code>94043</code>
          <country>USA</country>
        </postal>
        <email>kurta@linkedin.com</email>
      </address>
    </author>
    <author initials="J." surname="Rae-Grant" fullname="John Rae-Grant" role="editor">
      <organization>Google</organization>
      <address>
        <email>johnrg@google.com</email>
      </address>
    </author>
    <author initials="B." surname="Long" fullname="Brandon Long" role="editor">
      <organization>Google</organization>
      <address>
        <email>blong@google.com</email>
      </address>
    </author>
    <author initials="T." surname="Adams" fullname="J. Trent Adams" role="editor">
      <organization>Paypal</organization>
      <address>
        <email>trent.adams@paypal.com</email>
      </address>
    </author>
    <author initials="S." surname="Jones" fullname="Steven Jones" role="editor">
      <organization>TDP</organization>
      <address>
        <email>smj@crash.com</email>
      </address>
    </author>

    <date year="2016" />

    <area>art</area>
    <workgroup>independent</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Authenticated Received Chain (ARC) permits an organization which is creating
or handling email to indicate its involvement with the handling process by
adding a set of cryptographically signed header fields in a manner analagous to
that of DomainKeys Identified Mail (DKIM).  Assertion of responsibility is
validated through a cryptographic signature and by querying the Signer's domain
directly to retrieve the appropriate public key. Changes in the message that
might break DKIM can be tracked through the ARC set of header fields.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The development of strong domain authentication through Sender Policy
Framework (SPF) <xref target="RFC7208"/> and DomainKeys Identified Mail
(DKIM) <xref target="RFC6376"/> has led to the implementation of the
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
framework <xref target="RFC7489"/>.  Implicit within the DMARC
framework is a requirement that any intermediaries between the source system
and ultimate receiver system need to preserve the validity of the DKIM
signature; however, there are common email practices which break the DKIM
validation (<xref target="DMARC-INTEROP"/>).  This
proposal is intended to define an Authenticated Received Chain (ARC) to address
the problems with the untrustworthiness of the standard Received header field
sequence so that receivers can develop a more nuanced interpretation to guide
any local policies related to messages that arrive with broken domain
authentication.</t>

<t>Forgery of the Received header fields is a common tactic for bad actors.
One of the goals of this proposal is to define a comparable set of trace
header fields which can be relied upon by receivers, assuming all
ADministrative Management Domain (ADMD) handlers of a message participate in
ARC.</t>

<t>The Authentication-Results (A-R) mechanism <xref target="RFC7601"/> permits
the output of an email authentication evaluation process to be transmitted from
the evaluating agent to a consuming agent that uses the information.  On its
own, A-R operates within a trust domain.  ARC provides a protection mechanism
for the data, permiting the communication to cross trust domain boundaries.</t>

<t>[MSK: This isn't quite right, because A-R permits communication to cross
trust boundaries.  The issue is that they're hard to trust because they're
easily forged.] </t>
</section>

<section anchor="requirements" title="Requirements">

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

<section anchor="primary-design-criteria" title="Primary Design Criteria">

<t><list style="symbols">
  <t>Provide a method by which a "chain of custody" can be recorded for
email messages;</t>
  <t>Not require changes for senders of email;</t>
  <t>Support the complete verification of the ARC header field set by each
hop in the handling chain;</t>
  <t>Work at Internet scale; and</t>
  <t>Provide a trustable mechanism for the communication of
Authentication-Results across trust boundaries.</t>
</list></t>

</section>
<section anchor="out-of-scope" title="Out of Scope">

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

</section>
<section anchor="utility" title="Utility">

<t>The ARC-related set of header fields can be used (when validated) to
determine the path that an email message has taken between the sending system
and receiver.  Subject to the cautions mentioned in
<xref target="sec"/>, this information can assist in determining any local
policy overrides to for violations of sender domain authentication
policies.</t>

</section>
</section>
<section anchor="terminology" title="Terminology">

<t>This section defines terms used in the rest of the document.</t>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>

<t>Readers are encouraged to be familiar with the contents of
<xref target="RFC5598"/>, and in particular, the potential roles of
intermediaries in the delivery of email.</t>

<t>Syntax descriptions use Augmented BNF (ABNF) <xref target="RFC5234"/>.</t>

</section>
<section anchor="overview" title="Overview">

<t>When an email message is received without a properly valildated domain
author, the inability to believe the accuracy of a series of Received header
fields prevents receiving systems from having a way to infer anything about
the handling of the message by looking at the ADMDs through which the message
has traveled.</t>

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

<t>The ARC set of header fields provides a method by which participating
intermediaries can indicate the hand-offs for email messages.</t>

</section>
<section anchor="definition" title="Definition">

<t>This proposal defines three new header fields:</t>

<t><list style="symbols">
  <t>Header field name: ARC-Seal (abbreviated below as AS)</t>
  <t>Header field name: ARC-Message-Signature (abbreviated below as AMS)</t>
  <t>Header field name: ARC-Authentication-Results (abbreviated below as AAR)</t>
</list></t>

<t>Collectively, these header fields form a connected set of attribution
information by which receivers can identify the handling path for a message.
As described below, a distinct set of these fields share a common sequence
number, identified in an "i=" tag.  The collective group is referred to in
this document as the "ARC header field sets" or "set of ARC header fields".</t>

<t> [MSK: What about calling it an "ARC set"?]</t>

<t>Specific references to individual header fields use the header field names
to distinguish such references.</t>

<t>The ARC header sets SHOULD be added at the top of a message as it transits
MTAs that do authentication checks, so some idea of how far away the checks
were done can be inferred. They are therefore considered to be a trace field
as defined in <xref target="RFC5321"/>, and all of the related definitions
in that document apply.</t>

<t>Relative ordering of different trace header fields
(the ARC sets, DKIM, Received, etc.) is unimportant for this specification.
In general, trace header fields, such as ARC, SHOULD be added at the top
of the email header fields, but receivers MUST be able to process the header
fields from wherever they are found in the message header.  Ordering amongst
the individual ARC header fields and header field sets is specified 
below and MUST be followed for proper canonicalized signing and evaluation.</t>

<section anchor="description-of-the-new-header-fields" title="Description of the New Header Fields">

<section anchor="arc-seal" title="ARC-Seal">

<t>ARC-Seal is a Structured Header Field as defined in Internet Message Format
(<xref target="RFC5322"/>).  All of the related definitions in that document
apply.</t>

<t>The ARC-Seal makes use of Tag=Value Lists as defined in
<xref target="RFC6376"/>, Section 3.2.</t>

<t>The value of the header field consists of an authentication sequence
identifier, and a series of statements and supporting data. The statements
indicate relevant data about the signing of the ARC set of header fields.
The header field can appear more than once in a single message, but each
instance MUST have a unique "i=" value.</t>

<t>The ARC-Seal header field includes a digital signature of all other
ARC message header fields present on the message. </t>

<section anchor="tags-in-the-arc-seal-header-field-value"
  title="Tags in the ARC-Seal Header Field Value">

<t> The following tags are the supported tags for an ARC-Seal field.
All of them MUST be present, and the presence of any unknown tags
MUST be interpreted as an error. </t>

<t>[MSK: Is that a good idea?  It prevents easy extensions, like DKIM has.] </t>

<t><list style="hanging">
  <t hangText="a:">hash algorithm; syntax is the same as the "a=" tag
    defined in Section 3.5 of <xref target="RFC6376"/></t>
  <t hangText="b:">digital signature; syntax is the same as the "b=" tag
    defined in Section 3.5 of <xref target="RFC6376"/></t>
  <t hangText="cv:">chain validation status; valid values:
    <list style="symbols">
      <t>N: no pre-existing chain;</t>
      <t>P: permanent error, the chain as received does not validate;</t>
      <t>T: temporary error, such as a DNS lookup error; or</t>
      <t>V: valid chain received.</t>
    </list></t>
  <t hangText="d:">domain for key; syntax is the same as the "d=" tag
    defined in Section 3.5 of <xref target="RFC6376"/></t>
  <t hangText="i:">"instance" or sequence number; monotonically increasing at
    each "sealing" entity, beginning with 1</t>
  <t hangText="s:">selector for key; syntax is the same as the "s=" tag
    defined in Section 3.5 of <xref target="RFC6376"/></t>
  <t hangText="t:">timestamp; syntax is the same as the "t=" tag defined in
    Section 3.5 of <xref target="RFC6376"/></t>
</list></t>

</section>
</section>
<section anchor="differences-between-dkim-signature-and-arc-seal" title="Differences between DKIM-Signature and ARC-Seal">

<t>[MSK: I suggest moving this to an appendix.]</t>

<t>No "bh" value is defined for ARC-Seal, since only the message header is
ever signed by ARC. </t>

<t>ARC-Seal does not use the "h" tag -- the list of signed header
fields -- that is defined for DKIM-Signatures because the list of applicable
header fields is fully determined by the construction rules (see
<xref target="build-hdrs"/>).</t>

<t>ARC-Seal does not use the "c" (canonicalization) tag defined for
DKIM because only its "relaxed" canonicalization is allowed for ARC-Seal
header field canonicalization.</t>

<t>[MSK: What body canonicalization do we use?  If it's selectable, how is
it specified?]</t>

</section>
<section anchor="implicit-as-h" title="Implicit 'h' Value for ARC-Seal">

<t>In this section, the term "scope" is used to indicate those header fields
signed by an ARC set.  A number in parentheses indicates the instance of
that field, starting at 1.
The suffix "-no-b" is used with an ARC-Seal field to indicate that its
"b" field is empty at the time the signature is computed, as described
in Section 3.5 of <xref target="RFC6376"/>.  "AAR" refers to
ARC-Authentication-Results, "AMS" to ARC-Message-Signature, "AS" to
ARC-Seal, and "ASB" to an ARC-Seal with an empty "b" tag. </t>

<t> Generally, the scope of an ARC set for a message containing "n" ARC
sets is the concatenation of the following, for x from 1 to n:
  <list style="symbols">
    <t> AAR(x); </t>
    <t> AMS(x); </t>
    <t> ASB(x) if x = n, else AS(x) </t>
  </list> </t>

<t>Thus for a message with no seals (i.e., upon injection), the scope of the
first ARC set is AAR(1):AMS(1):ASB(1).  The ARC set thus generated would
produce a first ARC-Seal with a "b" value.  The next ARC set would include
in its signed content the prior scope, so it would have a
scope of AAR(1):AMS(1):AS(1):AAR(2):AMS(2):ASB(2). </t>

</section>

<section anchor="computing-the-b-signature-value-for-arc-seal"
  title="Computing the 'b' Tag Value for ARC-Seal">

<t>The ARC-Seal generation process mirrors the procedure used for
DKIM-Signature fields described in Section 5 of <xref target="RFC6376"/>
in that it is at first generated with empty "b" field for the purpose of
signature generation, and then the "b" value is added just prior to adding
the ARC-Seal field to the message. </t>

<t>In particular, signing calculation MUST be done in bottom-up order as
specified in section 5.4.2 of <xref target="RFC6376"/> and as illustrated
above in <xref target="implicit-as-h"/>.</t>

</section>

<section anchor="cv-tag" title="The ARC-Seal 'cv' Tag'">
<t>[MSK: A description of this should go here.  Right now it doesn't appear
until much later, long after we're done defining this field, and only one of
its possible values is described and then only barely.]</t>
</section>

<section anchor="arc-message-signature" title="ARC-Message-Signature">

<t>The ARC-Message-Signature header field is a special variant of a
DKIM-Signature <xref target="RFC6376"/>, using only the relaxed header
canonicalization rules specified in <xref target="RFC6376"/>.</t>

<t>The ARC-Message-Signature header field can appear multiple times in a
single message but each instance must have a unique "i" value.</t>

<t> [MSK: The document doesn't talk about if or when these get validated.] </t>

<section anchor="header-fields-eligible-for-arc-message-signature-h"
  title="Header Fields Eligible For ARC-Message-Signature Inclusion">

<t>Participants MAY include any other header fields within the scope of the
ARC-Message-Signature signature, except that they MUST NOT include ARC-Seal
header fields.  In particular, including all DKIM-Signature header fields 
and all ARC-Authentication-Results header fields is
RECOMMENDED.  The advice regarding header fields to include or avoid
for ARC-Message-Signature is otherwise identical to that specified
in Section 5.4 of <xref target="RFC6376"/>. </t>

<t>The ARC-Message-Signature header field MUST be created using the
"relaxed" header canonicalization defined in Section 3.4.2 of
<xref target="RFC6376"/>. </t>

<t>Contrary to DKIM, the "i" tag for ARC-Message-Signature identifies the
sequential instance of the field, thus indicating it is part of a particular
set of ARC header fields.  That is, an ARC-Message-Signature, ARC-Seal,
and ARC-Authentication-Results all bearing an "i" tag with the same value
are part of the same ARC header set. </t>

<t>There is no "v" tag for ARC-Message-Signature, and its presence is an
error. </t>

<t>[MSK: Same issue as above about versioning and extensions.]</t>

<t>As with DKIM-Signature and ARC-Seal header fields, the "b" tag of
the ARC-Message-Signature is empty until the signature is actually computed,
and only then is it added to the header field, before actually attaching it
to the message. </t>

<t>As with ARC-Seal and DKIM-Signature header fields, the order of header
fields signed MUST be done in bottom-up order.</t>

</section>
</section>

<section anchor="arc-authentication-results"
  title="ARC-Authentication-Results">

<t>ARC-Authentication-Results is a direct copy of the
Authentication-Results header field <xref target="RFC7601"/> created for
archival purposes by the each MTA outside of the trust boundary of the
originating system which is contributing to the chain of ARC header
fields. (See also <xref target="OAR"/> for a similar usage.) The
corresponding instance ("i=") value MUST be prefixed to the
Authentication-Results.</t>

<t>[MSK: I don't think OAR is a useful reference here.  It was never deployed
widely, so it's unlikely anyone reading this will need that background.] </t>

<t>The value of the header field (after removing comments) consists of an
instance identifier, an authentication identifier, and then a series of
statements and supporting data, as described in <xref target="RFC7601"/>.
properties were evaluated to reach that conclusion. The header field can appear
multiple times in a single message but each instance must have a unique
"i=" value.</t>

<t>ARC-Authentication-Results requries inclusion of an "i=" tag before the
"authserv-id" which indicates to which ARC set it belongs, as described in the
previous section. </t>

</section>
</section>
</section>

<section anchor="build-hdrs" title="Constructing the ARC-Seal Header Set">

<t>The ARC-Seal is built in the same fashion as the analogous DKIM-Signature
<xref target="RFC6376"/>, using the relaxed header canonicalization rules
specified in that document, but with a strict ordering component for the header fields covered by the cryptographic signature:</t>

<t><list style="numbers">
  <t>The ARC header fields MUST be ordered in descending instance (i=) order.
  </t>
  <t>The referenced ARC-Message-Signatures (matching i= value) MUST
     immediately follow the ARC-Seal instance which included the reference.</t>
  <t>The associated ARC-Authentication-Results header field (matching i= value)
     MUST be the last item in the list for each set of ARC header fields.</t>
</list></t>

<t>[MSK: This is confusing.  <xref target="implicit-as-h"/> suggests
they are in opposite order.  Are you talking here about how they are attached
to the message, or in what order they are hashed when preparing a
signature?]</t>

<t>Thus, when prefixing ARC header fields to the existing header,
<list style="numbers">
  <t>the AAR header would be prefixed first; then</t>
  <t>the AMS would be calculated and prefixed;</t>
  <t>lastly the AS would be calculated and prefixed.</t>
</list></t>

<section anchor="handling-violations-in-the-arc-header-field-set"
  title="Handling Violations in the ARC Header Field Set">

<t>When ordering the ARC set header fields, if there are violations
of this protocol (e.g., duplicated instance numbers), such header field set(s) 
MUST be ordered as follows when analyzing for validity or subsequent
signing:

<list style="symbols">
  <t>Within each set, header fields are sorted as specified in
     <xref target="build-hdrs"/>; then</t>
  <t>Any header field sets that are complete duplicates are removed, leaving
     only one instance of each unique header field set; then</t>
  <t>Any remaining order dependencies between sets are ordered as follows:
     <list style="numbers">
     <t>By descending order of i=; then</t>
     <t>By descending order of t= (from the ARC-Seal header field within the
        set); then</t>
     <t>By ascending US-ASCII <xref target="RFC1345"/> sort order for the
        entire canonicalized header field set</t>
     </list></t>
</list></t>

<t>The intent of specifying this ordering is to allow downstream message
handlers to add their own ARC header field sets in a deterministic manner and
to provide some resiliance against misbehaving downstream MTAs. Participants
that wish to have ARC information accrue to their benefit are advised to
ensure proper implementation so that this section would never need to be
invoked for their ARC header fields.</t>

<t>[MSK: I think it would be better to flip the logic here and explain the
possible detriment of a broken implementation rather than encouraging
full compliance.]</t>

</section>
</section>

<section anchor="key-management-and-binding"
  title="Key Management and Binding">

<t>The public keys for ARC-Seal header fields follow the same requirements and
semantics as those for DKIM-Signatures, described in Section 3.6 of
<xref target="RFC6376"/>. Operators MAY use distinct selectors for the
ARC-Seal header fields at their own discretion.</t>

<section anchor="namespace" title="Namespace">

<t>All ARC-Seal keys are stored in the same namespace as DKIM keys,
specifically by adding the "._domainkey" suffix to the name of the key
(the "selector").  For example, given an ARC-Seal field of a "d=" tag
value of "example.com" and an "s=" value of "foo.bar", the DNS query seeking
the public key will be a query at the name
"foo.bar._domainkey.example.com". </t>
</section>
</section>

<section anchor="usage" title="Usage">

<t>For a more thorough treatment of the recommended usage of the ARC header
fields for both intermediaries and end receivers, please consult
<xref target="ARC-USAGE"/>.</t>

<section anchor="participation" title="Participation">

<t>The inclusion of additional ARC header field sets is to be done whenever
a trust boundary is crossed, and especially when prior DKIM-Signatures might
not survive the handling being performed such as some mailing lists that
modify the content of messages, or some gateway transformations.  Note that
trust boundaries might or might not exactly correspond with ADMD
boundaries.</t>

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

</section>
<section anchor="relationship-between-dkim-signatures-and-arc-sets"
  title="Relationship between DKIM Signatures and ARC Sets">

<t>Any DKIM-Signature fields SHOULD NOT include any of the ARC-Seal,
ARC-Message-Signature, or ARC-Authentication-Results header fields in the
content they sign.</t>

<t>However, ARC-Message-Signatures SHOULD include all DKIM-Signature fields
within their scope.</t>

<t>[MSK: I think this should me merged into the above sections.]</t>

<t>[MSK: "SHOULD" and "SHOULD NOT" typically draw the question: "Under what
circumstances would one legitimately deviate from this advice?"  If there is
no good answer, then either the requirement should become a MUST, or it should
come out.  What do we think about these two?]</t>

</section>

<section anchor="relationship-of-arc-message-signatures-and-arc-seals"
  title="Relationship of ARC-Message-Signature and ARC-Seal Fields">

<t>The ARC-Message-Signature fields SHOULD NOT include any of the ARC-Seal
header fields in their coverage scope in order maintain a separation of
responsibilities.  When adding an ARC-Authentication-Results header field, it
SHOULD be added before computing the ARC-Message-Signature field.
When "sealing" the message, an operator MUST create the ARC-Message-Signature
field before the ARC-Seal field in order to reference it and embed the
ARC-Message-Signature within the ARC-Seal signature scope.
(See also <xref target="build-hdrs"/>.)</t>

</section>

<section anchor="validating-the-arc-set-of-header-fields"
  title="Validating the ARC Set of Header Fields">

<t>Validation of the ARC header fields can be performed step-wise by building
up the sequence in order as defined in <xref target="build-hdrs"/> and 
evaluating the correctness of the "b=" signature at each step. If a violation
of the construction rules is found, for instance missing or repeated instance 
numbers or an otherwise invalid ARC-Seal header field, validation fails and
SHOULD be indicated with a "cv" value of "P" (permanent error) in the
generated ARC-Seal field. </t>

</section>
<section anchor="assessing-violations-of-arc-set-validity"
title="Assessing Violations of ARC Set Validity">

<t>There are a variety of ways in which the ARC set of header fields can be
broken.  Receivers need to be wary of ascribing motive to such breakage
although patterns of common behaviour can provide some basis for adjusting
local policy decisions.</t>

<t>This proposal is exclusively focused on well-behaved, participating
intermediaries that result in a valid chain of ARC-related header fields. The
value of such a well-formed valid chain needs to be moderated since
malicious content can be easily introduced by otherwise well-intended senders
through machine or account compromises. All normal content-based analysis
still needs to be performed on any messages bearing an ARC sequence.</t>

</section>

<section anchor="reporting-violations-of-arc-set-validity"
  title="Reporting Violations of ARC Set Validity">

<t>If a receiver determines that the ARC set of header fields has a
permanent error, the receiver MAY signal the breakage through the extended
SMTP response code 5.7.7 <xref target="RFC3463"/> "message integrity
failure" and corresponding SMTP response code. </t>

</section>

<section anchor="recording-results-of-arc-evaluation"
  title="Recording Results of ARC Evaluation">

<t>Receivers can add an "arc=pass" or "arc=fail" method annotation into a
locally-affixed Authentication-Results header field.</t>

<section anchor="rfc6651-failure-reporting-for-arc"
  title="RFC6651 Failure Reporting for ARC">

<t>Due to very limited adoption, ARC evaluation results are not recommended
for failure reporting as described for DKIM in <xref target="RFC6651"/>.</t>

<t>[MSK: Not sure what this is for.  I would just remove it.]</t>

</section>
<section anchor="reporting-arc-effects-for-dmarc-local-policy"
title="Reporting ARC Effects for DMARC Local Policy">

<t>Receivers SHOULD indicate situations in which ARC evaluation influenced the
results of their local policy determination.  Usage in the DMARC reporting
might look something like (utilizing a list of the ARC participants that were
found):

<figure><artwork><![CDATA[
<policy_evaluated>
  <disposition>delivered</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
   <type>local_policy</type>
   <comment>arc=pass d=d1.example,d2.example</comment>
  </reason>
</policy_evaluated>
]]></artwork></figure></t>

<t>[MSK: Spec-wise this is mushy.  We should either say "DMARC reporting is
augmented as follows: ...", or move this to an appendix as purely a proposal,
and drop the SHOULD.  Also, A-R has specific provisions for reporting
augmented results, so that could be mentioned here.] </t>

</section>
</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

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

<t>[MSK: Wouldn't an anonymous remailer likely break the chain by messing
with the From: field, or at least by not participating?] </t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This proposal adds three new header fields as defined below.</t>

<section anchor="update-to-rfc7601-header-field-method-list"
  title="Update to Email Authentication Method Registry">

<t>This proposal adds a new method to the Authentication-Results
header field registry, "ar", for recording the results of the ARC
header field validation. </t>

<t>[MSK: This would be rejected.  You need to produce a registration,
like the ones you produced in the next section.
The template is in Section 6.2 of RFC7601.] </t>

</section>

<section anchor="definitions-of-the-arc-header-fields"
  title="Definitions of the ARC Header Fields">

<t>This proposal adds three new header fields to the Permanent Message
Header Field Registry, as follows:</t>

<t><list style="symbols">
  <t>Header field name: ARC-Seal  <vspace blankLines='1'/>
Applicable protocol:  mail  <vspace blankLines='1'/>
Status:  draft  <vspace blankLines='1'/>
Author/Change controller:  OAR-Dev Group  <vspace blankLines='1'/>
Specification document(s):  &SELF;  <vspace blankLines='1'/>
Related information:  <xref target="RFC6376"/></t>
  <t>Header field name:  ARC-Message-Signature  <vspace blankLines='1'/>
Applicable protocol:  mail  <vspace blankLines='1'/>
Status:  draft  <vspace blankLines='1'/>
Author/Change controller:  OAR-Dev Group  <vspace blankLines='1'/>
Specification document(s):  &SELF;  <vspace blankLines='1'/>
Related information: <xref target="RFC6376"/></t>
  <t>Header field name:  ARC-Authentication-Results  <vspace blankLines='1'/>
Applicable protocol:  mail  <vspace blankLines='1'/>
Status:  standard  <vspace blankLines='1'/>
Author/Change controller:  IETF  <vspace blankLines='1'/>
Specification document(s):  &SELF;  <vspace blankLines='1'/>
Related information:  <xref target="RFC7601"/> <xref target="OAR"/></t>
</list></t>

<t> [MSK: "OAR-DEV Group" probably can't own this if you go for an IETF Stream
status.  You may also need to ensure the longevity of that group if it's going
to own a registration long term.] </t>

<t> [MSK: I would drop the OAR reference here as well.] </t>

</section>
</section>
<section anchor="sec" title="Security Considerations">

<t>[MSK: Some topics you should cover here:]
  <list style="symbols">
    <t> The Security Considerations of (DKIM, A-R) apply to this specification
        as well.  It can't hurt to remind people of this. </t>
    <t> This adds bulk to headers, and simple MTAs might not be able to handle
        the additional bulk. </t>
    <t> A message bearing N ARC sets has to do N DNS queries to evaluate the
        chain.  This has at least two effects:
        <list style="numbers">
          <t> An attacker can send a message to an ARC partipant with a
              concocted sequence of ARC sets bearing the domains of intended
              victims, and all of them will be queried by the participant.
              (Should ARC chain evaluation stop when a failure is discovered?
              We don't actually say that.) </t>
          <t> DKIM only does one DNS check, while this one can do many.
              Absent caching, slow DNS can cause SMTP timeouts; this could be
              exploited as a DoS attack. </t>
        </list></t>
  </list> </t>

<section anchor="sec-scan-it-anyway" title="Content Scanning">
<t>Recipients are cautioned to treat messages bearing ARC sets with the
same suspicion that they apply to all other email messages. This includes
appropriate content scanning and other checks for potentially malicious
content. The handlers that are identified within the ARC sets can be
used to provide input to local policy engines in cases where the sending
system's DKIM-Signature does not validate.</t>
</section>

<section anchor="preventing-repurposing-of-arc-headers"
  title="Preventing Repurposing of ARC Headers">

<t>ARC sets can not be re-used as DKIM-Signatures because the header field
names are incorporated in the signed content of both the AMS and AS header
fields.</t>

<t> [MSK: I don't understand why this is here.  Security Considerations
is for highlighting weaknesses in the proposal, not its strengths.  Think
of it as "If you implement this, you should be aware of this other thing."]</t>

</section>

<section anchor="messages-that-transit-the-same-admd-more-than-once"
  title="Messages That Transit the Same ADMD More Than Once">

<t>Messages that loop in and out of a single ADMD can lead to confusion about
the scope of a particular set of ARC header fields.  The use of coordinated
instance (i=) values and the non-confusability of the ARC-Message-Signature
vs. a DKIM-Signature are designed to prevent misunderstandings.</t>

<t>[MSK: This really belongs up in the discussion sections, not here.]</t>

</section>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC1345;
&RFC5234;
&RFC5321;
&RFC5322;
&RFC3463;
&RFC7601;
&RFC6651;
&RFC6376;
&RFC5598;
&RFC2119;
&RFC7208;


    </references>

    <references title='Informative References'>

&RFC7489;
<reference anchor="OAR" target="https://tools.ietf.org/html/draft-kucherawy-original-authres-00">
  <front>
    <title>Original-Authentication-Results Header Field</title>
    <author initials="M." surname="Chew" fullname="Michael Chew">
      <organization></organization>
    </author>
    <author initials="M." surname="Kucherawy" fullname="Murray Kucherawy">
      <organization></organization>
    </author>
    <date year="2012" month="February" day="20"/>
  </front>
</reference>
<reference anchor="DMARC-INTEROP" target="https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-14">
  <front>
    <title>Interoperability Issues Between DMARC and Indirect Email Flows</title>
    <author initials="F." surname="Martin" fullname="Franck Martin">
      <organization></organization>
    </author>
    <author initials="E." surname="Lear" fullname="Elliot Lear">
      <organization></organization>
    </author>
    <author initials="T." surname="Draegen" fullname="Tim Draegen">
      <organization></organization>
    </author>
    <author initials="E." surname="Zwicky" fullname="Elizabeth Zwicky">
      <organization></organization>
    </author>
    <author initials="K." surname="Andersen" fullname="Kurt Andersen">
      <organization></organization>
    </author>
    <date year="2016" month="January" day="14"/>
  </front>
</reference>
<reference anchor="ARC-USAGE" target="https://tools.ietf.org/html/draft-jones-arc-usage-00">
  <front>
    <title>Recommended Usage of the ARC Headers</title>
    <author initials="S." surname="Jones" fullname="Steven Jones">
      <organization></organization>
    </author>
    <author initials="T." surname="Adams" fullname="Trent Adams">
      <organization></organization>
    </author>
    <author initials="J." surname="Rae-Grant" fullname="John Rae-Grant">
      <organization></organization>
    </author>
    <author initials="K." surname="Andersen" fullname="Kurt Andersen">
      <organization></organization>
    </author>
    <date year="2015" month="October" day="16"/>
  </front>
</reference>


    </references>


<section anchor="appendix-a-example-usage" title="Appendix A - Example Usage">

<t>[[ TODO [-03]: update these examples ]]</t>

<section anchor="example-1-simple-mailing-list" title="Example 1: Simple mailing list">

<section anchor="heres-the-message-as-it-exits-the-origin" title="Here’s the message as it exits the Origin:">

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

</section>
<section anchor="message-is-then-received-at-exampleorg" title="Message is then received at example.org">

<section anchor="example-1-step-a-message-forwarded-to-list-members" title="Example 1, Step A: Message forwarded to list members">

<t>Processing at example.org:</t>

<t><list style="symbols">
  <t>example.org performs authentication checks</t>
  <t>No previous Auth-Results or ARC-Seal headers are present</t>
  <t>example.org adds ARC-Auth-Results header</t>
  <t>example.org adds Received: header</t>
  <t>example.org adds a ARC-Seal header</t>
</list></t>

<t>Here’s the message as it exits example.org:</t>

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

</section>
</section>
<section anchor="example-1-message-received-by-recipient" title="Example 1: Message received by Recipient">

<t>Let’s say that the Recipient is example.com</t>

<t>Processing at example.com:</t>

<t><list style="symbols">
  <t>example.com performs usual authentication checks</t>
  <t>example.com adds Auth-Results: header, Received header</t>
  <t>Determines that message fails DMARC</t>
  <t>Checks for ARC-Seal: header; finds one</t>
  <t>Validates the signature in the ARC-Seal: header, which covers the ARC-Authentication-Results: header</t>
  <t>example.com can use the ARC-Authentication-Results values or verify the DKIM-Signature from lists.example.org</t>
</list></t>

<t>Here’s what the message looks like at this point:</t>

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

</section>
</section>
<section anchor="example-2-mailing-list-to-forwarded-mailbox" title="Example 2: Mailing list to forwarded mailbox">

<section anchor="heres-the-message-as-it-exits-the-origin-1" title="Here’s the message as it exits the Origin:">

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

</section>
<section anchor="message-is-then-received-at-exampleorg-1" title="Message is then received at example.org">

<section anchor="example-2-step-a-message-forwarded-to-list-members" title="Example 2, Step A: Message forwarded to list members">

<t>Processing at example.org:</t>

<t><list style="symbols">
  <t>example.org performs authentication checks</t>
  <t>example.org applies standard DKIM signature</t>
  <t>No previous Auth-Results or ARC-Seal headers are present</t>
  <t>example.org adds ARC-Auth-Results header</t>
  <t>example.org adds usual Received: header</t>
  <t>example.org adds a ARC-Seal header</t>
</list></t>

<t>Here’s the message as it exits Step A:</t>

<figure><artwork><![CDATA[
Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=N; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; 
    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.
]]></artwork></figure>

</section>
<section anchor="example-2-step-b-message-from-list-forwarded" title="Example 2, Step B: Message from list forwarded">

<t>The message is delivered to a mailbox at gmail.com<vspace />
Processing at gmail.com:</t>

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

<t>Here’s what the message looks like at this point:</t>

<figure><artwork><![CDATA[
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
    s=notary01; d=gmail.com; cv=V; 
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
     YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
     txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256;
    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=N:
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256;
    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.
]]></artwork></figure>

<t> </t>

</section>
</section>
<section anchor="example-2-message-received-by-recipient" title="Example 2: Message received by Recipient">

<t>Let’s say that the Recipient is example.com<vspace />
Processing at example.com:</t>

<t><list style="symbols">
  <t>example.com performs usual authentication checks</t>
  <t>example.com adds Auth-Results: header, Received header</t>
  <t>Determines that message fails DMARC</t>
  <t>Checks for ARC-Seal: header; finds two</t>
  <t>Validates the signature in the highest numbered (“i=2”) ARC-Seal: header, which covers all previous ARC-Seal: and ARC-Authentication-Results: headers</t>
  <t>Validates the other ARC-Seal header (“i=1”), which covers the ARC-Authentication-Results: header</t>
  <t>example.com uses the ARC-Authentication-Results: values</t>
</list></t>

<t>Here’s what the message looks like at this point:</t>

<figure><artwork><![CDATA[
Return-Path: <jqd@d1.example>
Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
    [208.69.40.157]) by clothilde.example.com with ESMTP id
    d200mr22663000ykb.93.1421363268
    for <fmartin@example.com>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
    smtp.from=jqd@d1.example; dkim=pass (1024-bit key) 
    header.i=@gmail.com; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
    s=notary01; d=gmail.com; cv=V; 
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
     YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
     txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256;
    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=N; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256;
    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.
]]></artwork></figure>

</section>
</section>
<section anchor="example-3-mailing-list-to-forwarded-mailbox-with-source" title="Example 3: Mailing list to forwarded mailbox with source">

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

</section>
<section anchor="message-is-then-received-at-exampleorg-2" title="Message is then received at example.org">

<t> </t>

<section anchor="example-3-step-a-message-forwarded-to-list-members-with-source" title="Example 3, Step A: Message forwarded to list members with source">

<t>Processing at example.org:</t>

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

<t>Here’s the message as it exits Step A:</t>

<figure><artwork><![CDATA[
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
    s=seal2015; d=example.org; cv=V; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256;
    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=N; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256;
    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.
]]></artwork></figure>

</section>
<section anchor="example-3-step-b-message-from-list-forwarded-with-source" title="Example 3, Step B: Message from list forwarded with source">

<t>The message is delivered to a mailbox at gmail.com<vspace />
Processing at gmail.com:</t>

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

<t>Here’s what the message looks like at this point:</t>

<figure><artwork><![CDATA[
Return-Path: <jqd@d1.example>
ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
    s=notary01; d=gmail.com; cv=V; 
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
     WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
     /suttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256;
    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=V; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256;
    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=N; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256;
    d=d1.example; s=20130426; t=1421363082;
    bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
    h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
    b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
     rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
     4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
 
Hey gang,
This is a test message.
--J.
]]></artwork></figure>

</section>
</section>
<section anchor="example-3-message-received-by-recipient" title="Example 3: Message received by Recipient">

<t>Let’s say that the Recipient is example.com<vspace />
Processing at example.com:</t>

<t><list style="symbols">
  <t>example.com performs usual authentication checks</t>
  <t>example.com adds Auth-Results: header, Received header</t>
  <t>Determines that message fails DMARC</t>
  <t>Checks for ARC-Seal: header; finds three</t>
  <t>Validates the signature in the highest numbered (“i=2”) ARC-Seal: header, which covers all previous ARC-Seal: and ARC-Authentication-Results: headers</t>
  <t>Validates the other ARC-Seal header (“i=2”), which covers the ARC-Authentication-Results: header</t>
  <t>Validates the other ARC-Seal header (“i=1”), which covers the d1.example ARC-Message-Signature: header</t>
  <t>example.com uses the ARC-Authentication-Results: values</t>
</list></t>

<t>Here’s what the message looks like at this point:</t>

<figure><artwork><![CDATA[
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=V; 
    b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
     RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
     uttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256;
    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=V; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
     1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
     69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256;
    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=N; 
    b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
     TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
     EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256;
    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.
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>This draft is the work of OAR-Dev Group.</t>

<t>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.</t>

<t>Grateful appreciation is extended to the people who provided feedback through the discuss
mailing list.</t>

</section>
<section anchor="comments-and-feedback" title="Comments and Feedback">

<t>Please address all comments, discussions,  and questions to <eref target="mailto:arc-discuss@dmarc.org">arc-discuss@dmarc.org</eref>[mailto:arc-discuss@dmarc.org].</t>

</section>
<section anchor="compat" title="Historical Note">

<t>The ARC-Authentication-Results header is a direct copy of the normal Authentication-Results
header (<xref target="RFC7601"/>) used in a similar fashion as that proposed in <xref target="OAR"/> but has the instance (i=)
value added to provide correlation within the set of ARC headers.</t>

</section>


  </back>
</rfc>

