| DMARC Working Group | K. Andersen |
| Internet-Draft | |
| Intended status: Standards Track | B. Long, Ed. |
| Expires: January 19, 2018 | |
| S. Jones, Ed. | |
| TDP | |
| July 18, 2017 |
Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-06
Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of 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 identified through the ARC set of header fields.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The development of strong domain authentication through Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] has led to the implementation of the DMARC framework [RFC7489] which extends the authentication to the author’s “From:” (RFC5322.From) field and permits publishing policies for non-compliant messages. 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 legitimate email practices which break the DKIM validation ([RFC7960]). This specification defines an Authenticated Received Chain (ARC). ARC addresses the problems with the untrustworthiness of the standard Received header field sequence. Through the information tracked in the ARC series of headers, receivers can develop a more nuanced interpretation to guide any local policies related to messages that arrive with broken domain authentication (DMARC).
Forgery of the Received header fields is a common tactic used by bad actors. One of the goals of this specification defines a comparable set of trace header fields which can be relied upon by receivers, assuming all ADministrative Management Domain (ADMD) ([RFC5598], section 2.2) intermediary handlers of a message participate in ARC.
The Authentication-Results (A-R) mechanism [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 is believable only within a trust domain. ARC provides a protection mechanism for the data, permiting the communication to cross trust domain boundaries.
The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.
ARC is not a trust framework. Users of the ARC header fields are cautioned against making unsubstantiated conclusions when encountering a “broken” ARC sequence.
The ARC-related set of header fields can be used (when validated) to determine the path that an email message has taken between the originating system and receiver. Subject to the cautions mentioned in Section 10, this information can assist in determining any local policy overrides to for violations of origination domain authentication policies.
This section defines terms used in the rest of the document.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
Readers are encouraged to be familiar with the contents of [RFC5598], and in particular, the potential roles of intermediaries in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
When an email message is received without a properly validated originating domain, 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.
With ARC, participating ADMDs are able to securely register their handling of an email message. If all mediators ([RFC5598]) participate in the ARC process, receivers will be able to rely upon the chain and make local policy decisions informed by that information.
The ARC set of header fields provides a method by which participating intermediaries can indicate the hand-offs for email messages.
This specification defines three new header fields:
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. Such a correlated group of header fields is referred to as an “ARC set”.
Specific references to individual header fields use the header field names to distinguish such references.
The ARC sets SHOULD be added at the top of a message header 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 [RFC5321], and all of the related definitions in that document apply.
Relative ordering of different trace header fields (the ARC sets, DKIM, Received, etc.) is unimportant for 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 sets is specified below and MUST be followed for proper canonicalized signing and evaluation.
ARC-Seal is a Structured Header Field as defined in Internet Message Format ([RFC5322]). All of the related definitions in that document apply.
The ARC-Seal makes use of Tag=Value Lists as defined in [RFC6376], Section 3.2.
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. The header field can appear more than once in a single message, but each instance MUST have a unique “i=” value.
The ARC-Seal header field includes a digital signature of all preceding ARC message header fields on the message.
The following tags are the only supported tags for an ARC-Seal field. All of them MUST be present. Unknown tags MUST be ignored and do not affect the validity of the header.
The minimum valid ‘i’ tag value is one (1).
ARC implementations MUST support at least ten (10) intermediary steps.
More than fifty (50) intermediaries is considered extremely unlikely so ARC chains with more than fifty intermediaries may be marked with “cv=fail”.
The maximum valid ‘i’ tag value is 1024, but values more that the supported number of intermediaries are meaningless.
No ‘bh’ value is defined for ARC-Seal, since only message header fields are ever signed by the ARC-Seal.
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 Section 5.1.1.3).
ARC-Seal does not use the ‘c’ (canonicalization) tag because only ‘relaxed’ canonicalization [RFC6376] is allowed for ARC-Seal header field canonicalization.
In this section, the term “scope” is used to indicate those header fields signed by an ARC-Seal header field. A number in parentheses indicates 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 [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.
Generally, the scope of an ARC set for a message containing “n” ARC sets is the concatenation of the following, for x (instance number) from 1 to n:
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).
Note: Typically header field sets appear within the header in descending instance order.
The ARC-Seal generation process mirrors the procedure used for DKIM-Signature fields described in Section 5 of [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.
In particular, signing calculation MUST be done in bottom-up order as specified in Section 5.4.2 of [RFC6376] and as illustrated above Section 5.1.1.3.
In order for a series of ARC sets to be considered valid, the following statements MUST be satisfied:
In the algorith below, a “hop” is represented by the ARC set bearing a particular instance number. The number of hops is the same as the highest instance number found in the ARC sets, or 0 (zero) if there are no ARC sets found within the header.
“Success” means that the signature found in the referenced header validates when checked against the specified content.
if (lastest_hop.AS.cv == "fail") {
terminate analysis - no further ARC processing
}
if (chain not structurally valid) {
return "fail"
} else if (num_hops == 0) {
return "none"
} else {
if (validate(latest_hop.AMS) != success) {
return "fail"
} else {
// note that instance is always >= 1 by definition
for each hop (from highest instance to lowest) {
if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or
(hop_num == 1 and hop.ARC-Seal.cv == "none")) {
if (validate(hop.ARC-Seal) != success) {
return "fail"
}
} else {
return "fail"
}
}
}
return "pass"
}
The ARC-Message-Signature header field is a special variant of a DKIM-Signature [RFC6376].
The ARC-Message-Signature header field can appear multiple times in a single message but each instance MUST have a unique “i=” value.
Participants may include any other header fields within the scope of the ARC-Message-Signature signature except that they MUST NOT include ARC-Seal headers fields. In particular, including all DKIM-Signature header fields and all ARC-Authentication-Results header fields is RECOMMENDED. The advice regarding headers to include or avoid for ARC-Message-Signature is otherwise identical to that specified in section 5.4 of [RFC6376].
The ARC-Message-Signature header field MUST be created using the header and body canonicalization rules mechanisms in Section 3.4 of [RFC6376]. The corresponding “c=” tag value MUST be specified in the AMS header field value.
Contrary to DKIM, the ‘i’ tag for ARC-Message-Signature identifies the sequential instance of the field, thus indicating that it is part of a particular ARC set. 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 set (see Section 5.1.1.1).
There is no “v” tag for ARC-Message-Signature.
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 affixing the ARC-Message-Signature to the message.
As with ARC-Seal and DKIM-Signature header fields, the order of header fields signed MUST be done in bottom-up order.
[[ Note: The intent of the AAR header is to provide the necessary information for meaningful DMARC reporting back to the originating ADMD. As such, it needs to include additional information than the user-focused Authentication-Results header [RFC7601] but the details of that incremental information have not yet been fully determined. ]]
ARC-Authentication-Results is a copy of the Authentication-Results header field [RFC7601] value with the corresponding ARC-set instance (“i=”) tag value prefixed to the Authentication-Results value string. Since Authentication-Results headers are frequently deleted from a message’s header list, the AAR is created for archival purposes by each ARC-participating ADMD outside of the trust boundary of the originating system.
The instance identifier MUST be separated from the rest of the Authentication-Results value contents with a semi-colon (‘;’, 0x3b).
The value of the header field (after removing comments) consists of an instance identifier, an authentication identifier, and then a series of statements and supporting data, as described in [RFC7601]. The header field can appear multiple times in a single message but each instance MUST have a unique “i=” value.
ARC-Authentication-Results requires inclusion of an “i=” tag before the “authserv-id” which indicates the ARC set to which it belongs as described in the previous section (see Section 5.1.1.1).
The “i=” tag MUST be separated from the rest of the Authentication-Results value contents with a semi-colon (‘;’, 0x3b).
The ARC-Seal is built in the same fashion as the analogous DKIM-Signature [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:
Thus, when prefixing ARC header fields to the existing header,
The ARC-Message-Signature field(s) MUST not include any of the ARC-Seal header field(s) (from prior ARC sets) in their signing scope in order maintain a separation of responsibilities. When adding an ARC-Authentication-Results header field, it MUST be added before computing the ARC-Message-Signature. When “sealing” the message, an operator MUST create and attach the ARC-Message-Signature before the ARC-Seal in order to reference it and embed the ARC-Message-Signature within the ARC-Seal signature scope.
Each ARC-Seal is connected to its respective ARC-Message-Signature and ARC-Authentication-Results through the common value of the “i=” tag.
When ordering the ARC header field sets, misordering of header fields MUST be resolved as follows:
The intent of specifying this ordering is to allow downstream message handlers to add their own ARC sets in a deterministic manner and to provide some resiliance against downstream MTAs which may reorder header fields.
Gross violations of the ARC protocol definition (e.g., such as duplicated instance numbers or missing header fields or header field sets) MUST be terminated by the detecting system setting ‘cv=fail’ in the ARC-Seal header. The status of the ARC evaluation reported in the corresponding AAR header field MUST be ‘unknown’.
Because the violations can not be readily enumerated, the header fields signed by the AS header field in the case of a major violation MUST be only the matching ‘i=’ instance headers created by the MTA which detected the malformed chain, as if this newest ARC set was the only set present.
Downstream MTAs SHOULD NOT attempt any analysis on an ARC chain that has been marked ‘fail’.
The public keys for ARC header fields follow the same requirements and semantics as those for DKIM-Signatures, described in Section 3.6 of [RFC6376]. Operators may use distinct selectors for the ARC header fields at their own discretion.
All ARC-related keys are stored in the same namespace as DKIM keys [RFC6376]: “_domainkey” specifically by adding the “._domainkey” suffix to the name of the key (the “selector”). For example, given an ARC-Seal (or ARC-Message-Signature) field of a “d=” tag value of “example.com” and an “s=” value of “foo.bar”, the DNS query seeking the public key will a query at the name “foo.bar._domainkey.example.com”.
In the following branch diagrams, each algorithm is represented by an ‘A’ or ‘B’ at each hop to depict the ARC chain that develops over a five hop scenario. ‘x’ represents a hop that does not support that algorithm.
Intermediaries MUST be able to validate ARC chains build with either algorithm but MAY create ARC sets with either (or both) algorithm.
The introductory period should be at least six (6) months.
Intermediaries MUST be able to validate ARC chains build with either algorithm and MUST create ARC sets with both algorithms. Chains ending with either algorithm may be used for the result.
ARC sets built with algorithms that are being deprecated MAY be considered valid within an ARC chain, however, intermediaries MUST not create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years.
ARC sets which are created with obsolete algorithms must be ignored.
For a more thorough treatment of the recommended usage of the ARC header fields for both intermediaries and end receivers, please consult [ARC-USAGE].
The inclusion of additional ARC sets is to be done whenever a trust boundary is crossed, and especially when prior DKIM-Signatures might not survive the handling being performed such as some mailing lists that modify the content of messages or some gateway transformations. Note that trust boundaries might or might not exactly correspond with ADMD boundaries. Some organizations may have internal trust boundaries within a single ADMD or have trust boundaries which span more than one ADMD.
Each participating ADMD MUST validate the preceding ARC set as a part of asserting their own seal. Until the chain is determined to be failed, and marked with an ARC set bearing the “cv=fail” indication, each participating ADMD SHOULD apply their own seal.
ARC-aware DKIM signers do not DKIM-sign any ARC header fields.
Determining the validity of a chain of ARC sets is defined above in Section 5.1.1.5. Validation failures MUST be indicated with a “cv=” tag value of ‘fail’ when attaching a subsequent ARC-Seal header field.
There are a wide variety of ways in which the ARC set of header fields can be broken. Receivers need to be wary of ascribing motive to such breakage although patterns of common behaviour may provide some basis for adjusting local policy decisions.
This specification is exclusively focused on well-behaved, participating intermediaries that result in a valid chain of ARC-related header fields. The value of such a well-formed, valid chain needs to be interpreted with care since malicious content can be easily introduced by otherwise well-intended senders through machine or account compromises. All normal content-based analysis still needs to be performed on any messages bearing a valid chain of ARC header sets.
The header fields signed by the AS header field b= value in the case of a major violation MUST be only the matching ‘i=’ instance headers created by the MTA which detected the malformed chain, as if this newest ARC set was the only set present. (This is the same procedure required for handling major/structural validity problems.)
If a receiver determines that the ARC chain has failed, the receiver MAY signal the breakage through the extended SMTP response code 5.7.7 [RFC3463] “message integrity failure” [ENHANCED-STATUS] and corresponding SMTP response code.
Receivers MAY add an “arc=pass” or “arc=fail” method annotation into a locally-affixed Authentication-Results [RFC7601] header field.
The evaluation of a series of ARC sets results in the following data which MAY be used to inform local-policy decisions:
[[ Note: Discussion on the IETF DMARC-WG list has indicated some interest in more substantial reporting for analytic purposes. To support that effort, the following guidance is provided only as an interim, minimal data set. A more complete reporting construct will be specified in a related spec - TBD. (see also the note at Section 5.1.3) ]]
Receivers SHOULD indicate situations in which ARC evaluation influenced the results of their local policy determination. DMARC reporting of ARC-informed decisions is augmented by adding a local_policy comment explanation as follows:
<policy_evaluated> <disposition>delivered</disposition> <dkim>fail</dkim> <spf>fail</spf> <reason> <type>local_policy</type> <comment>arc=pass ams=d1.example d=d1.example,d2.example</comment> </reason> </policy_evaluated>
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.
This specification adds three new header fields as defined below.
This draft adds one item to the IANA “Email Authentication Methods” registry:
This specification adds three new header fields to the “Permanent Message Header Field Registry”, as follows:
[[ Note to the RFC Editor: Please remove this section before publication along with the reference to [RFC6982]. ]]
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to [RFC6982], “this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit”.
This information is known to be correct as of the third interoperability test event which was held on 2016-06-17.
Organization: Google
Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT]
Licensing: Proprietary - Internal only
Implementation Notes: Full functionality was demonstrated during the interop testing on 2016-06-17
In place for reporting usage only as of 2016-11-21 on all GMail flows.
Rechecked general incoming validation as of 2017-02-24 interop event.
Contact Info: arc-discuss@dmarc.org
Organization: AOL
Description: Internal prototype implementation with both debug analysis and validating + sealing pass-through function
Status of Operation: Beta
Coverage: ARC chain validity status checking is not operational, but otherwise this system conforms to [ARC-DRAFT]
Licensing: Proprietary - Internal only
Implementation Notes: Full functionality with the exception of chain validity checking was demonstrated during the interop testing on 2016-06-17
Available for production mail via selected account whitelisting for test validation only.
Intermittent stability problems discovered at the interop event on 2017-02-24. Remediation underway as of the publication of this draft.
Contact Info: arc-discuss@dmarc.org
Organization: dkimpy developers
Description: Python DKIM package
Status of Operation: Production
Coverage: The internal test suite is incomplete, but the command line developmental version of validator was demonstrated to interoperate with the Google and AOL implementations during the interop on 2016-06-17 and the released version passes the tests in [ARC-TEST] https://github.com/ValiMail/arc_test_suite with both python and python3.
Licensing: Open/Other (same as dkimpy package)
Contact Info: https://launchpad.net/dkimpy
Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the OpenDKIM and OpenDMARC packages
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: The build is FreeBSD oriented and takes some tweaks to build on RedHat-based Linux platforms.
Initial testing during the interop event on 2016-06-17 showed that it can be operational, but the documentation regarding configuration settings is unclear and the generated signature values do not validate when compared to the Google, AOL or dkimpy implementations. Testing during the 2017-02-24 interop event showed that some of the problems have been fixed, but there are still interoperability problems when trying to use OpenARC in a "sandwich" configuration around a MLM.
Contact Info: arc-discuss@dmarc.org
Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman package
Status of Operation: Patch submitted
Coverage: Unknown
Licensing: Same as mailman package - GPL
Implementation Notes: Incomplete at this time
Contact Info: [https://www.gnu.org/software/mailman/contact.html]
Organization: Copernica
Description: Web-based validation of ARC-signed messages
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT]
Licensing: On-line usage only
Implementation Notes: Released 2016-10-24
Requires full message content to be pasted into a web form found at [http://arc.mailerq.com/] (warning - https is not supported).
An additional instance of an ARC signature can be added if one is willing to paste a private key into an unsecured web form.
Initial testing shows that results match the other implementations listed in this section.
Contact Info: [https://www.copernica.com/]
Organization: Rspamd community
Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT]
Licensing: Open source
Implementation Notes: Released with version 1.6.0 on 2017-06-12
Contact Info: [https://rspamd.com/doc/modules/arc.html] and [https://github.com/vstakhov/rspamd]
The Security Considerations of [RFC6376] and [RFC7601] apply directly to this specification.
Inclusion of ARC sets in the header of emails may cause problems for some older or more constrained MTAs if they are unable to accept the greater size of the header.
Operators who receive a message bearing N ARC sets has to complete N+1 DNS queries to evaluate the chain (barring DNS redirection mechanisms which can increase the lookups for a given target value). This has at least two effects:
Recipients are cautioned to treat messages bearing ARC sets with the same suspicion that they apply to all other email messages. This includes appropriate content scanning and other checks for potentially malicious content. The handlers which are identified within the ARC-Seal chain may be used to provide input to local policy engines in cases where the sending system’s DKIM-Signature does not validate.
| [ARC-DRAFT] | Andersen, K., Rae-Grant, J., Long, B., Adams, T. and S. Jones, "Authenticated Received Chain (ARC) Protocol (I-D-03)", April 2017. |
| [ARC-TEST] | Blank, S., "ARC Test Suite", January 2017. |
| [ARC-USAGE] | Jones, S., Adams, T., Rae-Grant, J. and K. Andersen, "Recommended Usage of the ARC Headers", December 2017. |
| [ENHANCED-STATUS] | "IANA SMTP Enhanced Status Codes", n.d.. |
| [RFC6982] | Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013. |
| [RFC7489] | Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015. |
| [RFC7960] | Martin, F., Lear, E., Draegen. Ed., T., Zwicky, E. and K. Andersen, "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016. |
[[ Note: The following examples were mocked up early in the definition process for the spec. They no longer reflect the current definition and need various updates. ]]
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.
Processing at example.org:
Here’s the message as it exits example.org:
Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1F5
vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+m4bw
a6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
Let’s say that the Recipient is example.com
Processing at example.com:
Here’s what the message looks like at this point:
Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
by clothilde.example.com with ESMTP id
d200mr22663000ykb.93.1421363207
for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
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.
Processing at example.org:
Here’s the message as it exits Step A:
Return-Path: <jqd@d1.example>
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
The message is delivered to a mailbox at gmail.com
Processing at gmail.com:
Here’s what the message looks like at this point:
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender:
x-original-authentication-results:precedence:mailing-list:
list-id:list-post:list-help:list-archive:sender:reply-to:
list-unsubscribe:DKIM-Signature;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
bQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=2; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none:
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
Let’s say that the Recipient is example.com
Processing at example.com:
Here’s what the message looks like at this point:
Return-Path: <jqd@d1.example>
Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
[208.69.40.157]) by clothilde.example.com with ESMTP id
d200mr22663000ykb.93.1421363268
for <fmartin@example.com>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@gmail.com; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDWR
YbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/sut
txO+RRNr0fCFw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender:
x-original-authentication-results:precedence:mailing-list:
list-id:list-post:list-help:list-archive:sender:reply-to:
:list-unsubscribe:DKIM-Signature;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBmfhS
LF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJRFeM
KdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwDBJtXw
bQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=2; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=1; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61T
X6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69EU
8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrv
Qwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3
TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: Example 1
Hey gang,
This is a test message.
--J.
Processing at example.org:
Here’s the message as it exits Step A:
Return-Path: <jqd@d1.example>
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:From:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF
1F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3
A+m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
The message is delivered to a mailbox at gmail.com
Processing at gmail.com:
Here’s what the message looks like at this point:
Return-Path: <jqd@d1.example>
ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwD
WRYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF
/suttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender
:x-original-authentication-results:precedence:mailing-list
:list-id:list-post:list-help:list-archive:sender
:list-unsubscribe:reply-to;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
BJtXwbQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=3; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:CC:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYij
rvQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD
4Gd3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
Let’s say that the Recipient is example.com
Processing at example.com:
Here’s what the message looks like at this point:
Return-Path: <jqd@d1.example>
Received: from mail-ob0-f188.google.com (mail-ob0-f188.google.com
[208.69.40.157]) by clothilde.example.com with ESMTP id
d200mr22663000ykb.93.1421363268
for <fmartin@example.com>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
Authentication-Results: clothilde.example.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@gmail.com; dmarc=fail; arc=pass
ARC-Seal: i=3; a=rsa-sha256; t=1421363253;
s=notary01; d=gmail.com; cv=pass;
b=sjHDMriRZ0Mui5eVEOGscRHWbQHcy97lvrduHQ8h+f2CfIrxUiKOE44x3LQwDW
RYbDjf5fcM9MdcIahC+cP59BQ9Y9DHwMDzwRTnM7NVb4kY+tSaVnLoIOaP9lF/s
uttxO+RRNr0fCFw==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120806;
h=mime-version:content-type:x-original-sender
:x-original-authentication-results:precedence
:mailing-list:list-id:list-post:list-help:list-archive:sender
:list-unsubscribe:reply-to;
bh=2+gZwZhUK2V7JbpoO2MTrU19WvhcA4JnjiohFm9ZZ/g=;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0Ab8Oi1ebYV/hIBm
fhSLF1E80hMPcMijONfTQB6g5Hoh/kE6N2fgp6aSngL/WA3+g3Id8ElhXHvIGcJ
RFeMKdJqiW5cxdqPTRW+BnR5ee6Tzg06kr265NTDIAU8p8fQNuLfZj49MMA+QwD
BJtXwbQoZyRtb6X6q0mYaszUB8kw==
Received: by mail-yk0-f179.google.com with SMTP id 19so2728865ykq.10
for <mailbox@gmail.com>; Thu, 14 Jan 2015 15:02:45 -0800 (PST)
Authentication-Results: i=3; gmail.com; spf=fail
smtp.from=jqd@d1.example; dkim=pass (1024-bit key)
header.i=@example.org; dmarc=fail; arc=pass
ARC-Seal: i=2; a=rsa-sha256; t=1421363107;
s=seal2015; d=example.org; cv=pass;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz6
1TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L
69EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=example.org; s=clochette; t=1421363105;
bh=FjQYm3HhXStuzauzV4Uc02o55EzATNfL4uBvEoy7k3s=;
h=List-Id:List-Unsubscribe:List-Archive:List-Post:
List-Help:List-Subscribe:Reply-To:DKIM-Signature;
b=Wb4EiVANwAX8obWwrRWpmlhxmdIvj0dv0psIkiaGOOug32iTAcc74/iWvlPXpF1
F5vYVF0mw5cmKOa824tKkUOOE3yinTAekqnly7GJuFCDeSA1fQHhStVV7BzAr3A+
m4bwa6RIDgr3rOPJil678dZTHfztFWyjwIUxB5Ajxj/M=
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Authentication-Results: i=2; lists.example.org;
spf=pass smtp.mfrom=jqd@d1.example;
dkim=pass (1024-bit key) header.i=@d1.example;
dmarc=pass
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
ARC-Seal: i=1; a=rsa-sha256; t=1421363107;
s=origin2015; d=d1.example; cv=none;
b=pCw3Qxgfs9E1qnyNZ+cTTF3KHgAjWwZz++Rju0BceSiuwIg0Pkk+3RZH/kaiz61
TX6RVT6E4gs49Sstp41K7muj1OR5R6Q6llahLlQJZ/YfDZ3NImCU52gFWLUD7L69
EU8TzypfkUhscqXjOJgDwjIceBNNOfh3Jy+V8hQZrVFCw0A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=d1.example; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijr
vQwbv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4G
d3TRJlgotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@example.org
Subject: [Lists] Example 1
Hey gang,
This is a test message.
--J.
This draft is the work of OAR-Dev Group.
The authors thank all of the OAR-Dev group for the ongoing help and though-provoking discussions from all the participants, especially: Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
Grateful appreciation is extended to the people who provided feedback through the discuss mailing list.
Please address all comments, discussions, and questions to dmarc@ietf.org. Earlier discussions can be found at arc-discuss@dmarc.org.