| DMARC Working Group | K. Andersen |
| Internet-Draft | |
| Intended status: Experimental | B. Long, Ed. |
| Expires: September 22, 2018 | |
| S. Jones, Ed. | |
| TDP | |
| S. Blank, Ed. | |
| ValiMail | |
| M. Kucherawy, Ed. | |
| TDP | |
| March 21, 2018 |
Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-13
The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination, and create an attached, authenticated record of the status at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Changes in the message that might break existing authentication mechanisms 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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Modern email authentication techniques such as the Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] have become common. However, their end-to-end utility is limited by the effects of intermediaries along the transmission path, which either are not listed (for SPF) or which break digital signatures (for DKIM). These issues are described in substantial detail in those protocols’ defining documents as well as in [RFC6377] and [RFC7960].
Technologies that build upon the use of SPF and DKIM can reduce the success of fraudulent email campaigns. To this end, Domain-based Mail Authentication, Reporting and Compliance (DMARC) [RFC7489], validates the domain of the RFC5322.From author header field. However its use along email transmission paths that have independent intermediaries, such as some forwarders and essentially all mailing list services, produces false positive rejections that are problematic, both for the message authors, the intermediary service(s), and for those they are interacting with.
What is needed is a mechanism by which legitimate alteration of a message, which invalidates associated SPF and DKIM information, does not ultimately result in a rejection of an email message on delivery.
Authenticated Receive Chain (ARC) builds upon DKIM mechanisms to provide a sequence of signatures that provide a view of the handling sequence for a message, especially the points where alterations of the content might have occurred. Equipped with this more complete information, the recipient system(s) can make a more informed handling choice, reducing or eliminating the rejections that would occur with the use of DKIM and/or SPF alone.
ARC provides a “chain of custody” for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the authentication status of the message was at each step in the handling. The handling entity can then put its own entry into the chain of custody and then relay the message to the next handler.
When the message reaches final delivery, the decision to accept and deliver the message, or, alternatively, to reject, discard, or quarantine it, can take the chain of custody into account, applying local policy in addition to policies advertised by the (purported) sending domain. Consider, for example, this scenario:
Assuming the original message was DKIM-signed and mysender.example published an SPF record, the handling by the mailing list will break the DKIM signature because of the message modification, and the forwarding will cause the SPF check to fail in the next step. But listmania.example can add ARC headers to the message to add itself to the document’s chain of custody. When mail.service.example sees the message, it can see that SPF and DKIM validation fail, but it can also see that both of these succeeded when they were checked by listmania.example, and can verify listmania’s assertion.
As part of its evaluation of the message for delivery, mail.service.example can see that mysender.example publishes a DMARC policy asking that unauthenticated messages be rejected. But is can also see the assertion by listmania.example that the message was correctly authenticated when the message arrived there, and if it accepts that assertion and that modifications made were benign, it can deliver the message, rather than reject it, based on the additional information that ARC has provided.
In DKIM, every participating signing agent attaches a signature that is based on the some of the content of the message, local policy, and the domain name of the signing agent’s Administrative Management Domain (ADMD). Any verifier can process such a signature; a verified signature means that the domain referenced in the signature’s “d=” parameter has some responsibility for handling the message. An artifact of using digital signature technology for this means that verification also ensures that the portion of the message that was “covered” by the signature has not been altered since the signature was applied. The signatures themselves are generally independent of one another.
In contrast, a validated ARC signature conveys the following pieces of information:
The ARC protocol accomplishes this by adding an “ARC Set” of three new header fields to the message as follows:
An ARC participant always adds all of these header fields before relaying a message to the next handling agent en route to its destination. Moreover, as described in Section 3.1, they each have an “instance number” that increases with each ADMD in the handling chain so that their original order can be preserved and the three related header fields can be processed as a set.
[[ possibly including a diagram - this may not be needed any more ]]
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”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP14 ([RFC2119][RFC8174]).
Because many of the core concepts and definitions are found in [RFC5598], readers should to be familiar with the contents of [RFC5598], and in particular, the potential roles of intermediaries in the delivery of email.
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
The following terms are defined in other RFCs. Those definitions can be found as follows:
The three header fields that are part of this specification borrow heavily from existing specifications. Rather than repeating all of the formal definitions that are being reused in ARC, this document only describes and specifies changes in syntax and semantics.
Language, syntax, and other details are imported from DKIM [RFC6376]. Specific references can be found below.
As with other domain authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the contents of the email message it has sealed. However, for a valid and passing ARC chain, a Final Receiver is able to ascertain:
Given this information, a Final Receiver is able to make a more-informed local policy decision regarding message delivery to the end user in spite of an authentication failure.
Every participant in an ARC chain, except for the originating sender and Final Receiver, is both an ARC Validator (when receiving) and then an ARC Sealer (when sending a message onward). The validated chain status as determined at message receipt must be passed to the sealer function in order for sealing to occur properly; how this is done is considered ADMD-specific and an implementation detail.
INFORMATIONAL: It is important to understand that validating and then immediately sealing a message leaves no room for message modification, and many early implementations of ARC did not initially work because both operations were performed in a single pass over the message.
The following protocol features are functional parts and design decisions related the protocol that are not specific to either Validators or Sealers, but ensure the ARC chain conveys this information to a Final Receiver.
At a high level, an ARC chain represents a chain of custody of authentication and other trace information (AAR) related to a message, signed by each handler of the message. Each link in the chain (AMS) is designed to be brittle, insofar as it survives only until the next modification of the message. However, the sequence of intermediaries in the handling chain (AS) is designed to remain intact over the entirety of the chain.
The ARC chain can be conceptualized through an analogy with the chain of custody for legal evidence. The material evidence itself is sealed within an tamper-proof bag (AMS) each time. When handed to a new party, that party both vouches for the state of the received evidence container (AAR) and signs for the evidence on a chain of custody report form (AS). As with all analogies, this one should not be taken to interpretive extremes, but primarily used as a conceptual framework.
An ARC chain that is valid and passing has the attributes listed above in Section 2.
Recipients of an ARC chain that is invalid or does not pass SHOULD NOT draw negative conclusions without a good understanding of the wider handling context. Until ARC usage is widespread, intermediaries will continue to modify messages without ARC seals. As with a failing DKIM signature ([RFC6376] Section-6.3), a failing ARC chain SHOULD be treated the same as a message with no ARC chain. [[ NOTE TO WORKING GROUP: This paragraph probably is better placed in Verifier actions. Ref issue 10 ]]
Validating an existing chain and then adding your own ARC set to a message allows you to claim responsibility for handling the message and modifications, if any, done by your ADMD to benefit message delivery downstream. However, no ADMD is obligated to perform these actions.
A message can have only one ARC chain on it at a time (see Section 3.1). Once broken, the chain cannot be continued, as the chain of custody is no longer valid and responsibility for the message has been lost. For further discussion of this topic and the designed restriction which prevents chain continuation or re-establishment, see [ARC-USAGE].
Because ARC chains are transmitted across multiple intermediaries, all errors, even temporary ones, become unrecoverable and are considered permanent.
Any error validating or sealing a chain, for whatever reason, MUST result in a “cv=fail” verdict.
Even when an ARC chain is valid and passes, its value is limited to very specific cases. An ARC chain is specifically designed to provide value to a Final Receiver evaluating message delivery in the context of an authentication failure. An ARC chain in general, and each ARC set in particular, provide additional information, and otherwise is benign. Specifically:
INFORMATIONAL: If an ADMD is unsure whether it will be re-emitting and/or modifying a message, it may elect to seal all inbound mail. For complex or nested ADMD relationships such as found in some hosted mail solutions, this “inbound seal” can be used to facilitate traversal of internal boundaries as well as properly conveying incoming state to any egress MTAs that may need to assert a seal upon exit from the ADMD. Since these internal relationships are highly implementation dependent, this protocol definition can not usefully explore such usage except to note that it is intentionally allowed within the scope of this specification.
The public keys for ARC header fields follow the same requirements, syntax and semantics as those for DKIM signatures, described in Section 3.6 of [RFC6376]. ARC places no requirements on the selectors and/or domains used for the ARC header field signatures.
ARC includes trace information encoded in the AAR. While section Section 3.2 defines what information must be provided, sealing ADMDs may provide additional information, and validating receivers may use or ignore this trace information as they wish.
ARC introduces an indicator to its header fields to show the order in which the header fields comprising an ARC set were added, and the specific members of an ARC Set. This is known as an “instance”, and the indicator is an “i=”. That is, the members of the first ARC set affixed to a message will all include “i=1”. This is described in detail in section Section 3.1.
ARC introduces a mechanism, also via a new tag, which indicates the state of the ARC Chain at each step. This is the “chain validation status”. This is described in detail in section Section 3.4.1.
The header fields comprising a single ARC set are identified by the presence of a string in the value portion of the header field that complies with the “tag-spec” ABNF found in Section 3.2 of [RFC6376]. The tag-name is “i” and the value is the text representation of a positive integer, indicating the position in the ARC sequence this set occupies, where the first ARC set is numbered 1. In ABNF terms:
instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" position = 1*2DIGIT ; 1 - 50
Valid ARC sets must have exactly one instance of each header field for a given position value and signing algorithm. (Initial development of ARC is only being done with a single allowed signing algorithm, but parallel work in the DCRUP working group is expanding that. For handling multiple signing algorithms, see [ARC-MULTI].)
Because the AMS and AS header field values are made up of tag-spec constructs, the i= tag may be found anywhere within the header field value, but is represented throughout this spec in the initial position for convenience. Implementers are encouraged to place the i= tag at the beginning of the field value to facilitate human inspection of the headers.
The ‘i’ tag value can range from 1-50 (inclusive).
ARC implementations MUST support at least ten (10) ARC sets.
An effective operational maximum will have to be developed through deployment experience in the field and will be documented within [ARC-USAGE] once determined.
ARC chains with more than the defined operational maximum count MUST be marked with “cv=fail”.
The ARC-Authentication-Results header field is syntactically and semantically identical to an Authentication-Results header field (defined in Section 2.2 of [I-D-7601bis] (A-R)). Note that several optional data fields SHOULD be added (smtp.client-ip, dkim header.s, arc.oldest-pass) to enable completeness for DMARC reporting.
Formally, the header field is specified as follows using ABNF [RFC5234]:
arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info arc-info = instance *([CFWS] propspec) [CFWS] ";" authres-payload
The purpose of this header field is to transmit the results of any authentication done on the message downstream to participating ADMDs validating and continuing the chain.
The AAR MUST contain all A-R results from within the participating ADMD, regardless of how many A-R headers are on the message.
The ARC-Message-Signature header field is syntactically and semantically identical to a DKIM-Signature header field [RFC6376], with the following exceptions:
ARC-Seal header fields MUST NOT be included in the content covered by the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already present on the message in the header fields covered by this signature.
The AMS header field SHOULD not include (sign) the AAR header field(s). (Early drafts of this protocol and some older examples included the AAR header(s) within the signing scope for the AMS, but ambiguity regarding which of the potentially multiple AAR headers (one per ARC set) argues against such practice.)
Authentication-Results header fields SHOULD NOT be included since they are likely to be deleted by downstream ADMDs (per Section XXX of [RFC7601]), thereby breaking the AMS signature.
As with a DKIM-Signature, the purpose of this header field is to allow the ADMD generating it to take some responsibility for handling this message as it progresses toward delivery.
The ARC-Seal header field is syntactically and semantically similar to a DKIM-Signature field, with the following exceptions:
A new tag “cv” (chain validation) indicates the the outcome of evaluating the existing ARC chain upon arrival at the ADMD that is adding this header field. It accepts one of three possible values:
In ABNF terms:
seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
The ARC-Seal signs a canonicalized form of the ARC set header values. The ARC set header values are compiled in increasing instance order, starting at 1, and inclue the set being added at the time of sealing the message.
Within a set, the header fields are listed in the following order:
Where the ARC-Seal is the one being generated, it is input to the hash function in its final form except with an empty “b=” value, in the same manner by which a DKIM-Signature signs itself.
Note that the signing scope for the ARC-Seal is modified in the situation where a chain has failed validation (see Section 5.1).
A verifier takes the following steps to determine the state of the ARC chain on a message (cv value). Canonicalization, hash functions, and signature validation methods are imported from Section 5 of [RFC6376].
[[ Note: need markdown flag to have subordinate numbering distinction issue 11 ]]
Whatever the end result of the verifier’s checks via the algorithm specified above, the results MUST be added into the Authentication-Results header(s) for the ADMD.
[[ See issue 12 regarding the final paragraph ]]
The verifier should save the cv state for subsequent use by any sealing which may be done later (potentially after message modification) within the same trust boundary. The cv state may be recorded by sealing at the time of verification in an initial ARC set (for the ADMD) or may be recorded out of band depending on the architecture of the ADMD.
Certain information pertinent to ascertaining message disposition can be lost in transit when messages are handled by intermediaries. For example, failing DKIM signatures are sometimes removed by MTAs, and most DKIM signatures on messages modified by intermediaries will fail. Recording the following information in the A-R provides a mechanism for this information to survive transit.
The ptypes and properties defined in this section SHOULD be recorded in the AR:
[[ Also see issue 20 for another possible field to be added and issue 21 re which document should define these for IANA action. ]]
DNS-based failures to verify a chain are treated no differently than any other ARC violation. They result in a “cv=fail” verdict.
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.
[[ See issue 13 for critique ]]
This section includes a specification of the actions an ARC signer takes when presented with a message.
The signer MUST undertake the following steps:
The header fields signed by the AS header field b= value in the case of a chain failure MUST be only the matching instance headers created by the MTA which detected the malformed chain, as if this newest ARC set was the only set present.
[[ See issue 14 for critique of this section ]]
DKIM-Signatures SHOULD never sign any ARC header fields.
[[ Issue 15 ]]
Email transit can produce broken signatures for a wide variety of benign reasons. This includes possibly breaking one or more ARC signatures. Therefore, 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.
ARC does not attempt to protect an entire message. There are various ways that a message can still be problematic, in spite of having a valid ARC chain. Consequently, all normal, content-based analysis SHOULD still be performed on any message having a valid chain of ARC header sets.
The evaluation of an ARC chain provides information which will be useful to both the receiver (or intermediary) and to the initial sender of the message. This information should be preserved and reported as follows.
The evaluation of an ARC chain produces a list of domain names for participating intermediaries which handled the message, to wit:
In the case of a failed chain, only the terminal ARC set is covered by the ARC-Seal so the reporting is limited to the findings in that terminal ARC set.
Receivers MAY add an “arc=[pass|fail|policy]” method annotation into a locally-affixed Authentication-Results [RFC7601] header field along with any salient comment(s).
Details of the ARC chain which was evaluated should be included in the Authentication-Results and AAR headers per Section Section 4.1.
[[ Note: Move to separate document? (see the additional fields specified in Section 4.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation influenced the results of their local policy determination. DMARC reporting of ARC-informed decisions can be accomplished by adding a local_policy comment explanation containing the list of data discovered in the ARC evaluation (Section 7.1 and Section 4.1):
<policy_evaluated>
<disposition>delivered</disposition>
<dkim>fail</dkim>
<spf>fail <comment>source.ip=10.0.0.1</comment></spf>
<reason>
<type>local_policy</type>
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>
</reason>
</policy_evaluated>
In the suggested sample, d2.example is the sealing domain for ARC[2] and d1.example is the sealing domain for ARC[1].
Mediators SHOULD generate DMARC reports on messages which transit their system just like any other message which they receive. This will result in multiple reports for each mediated message as they transit the series of handlers. DMARC report consumers should be aware of this behaviour and make the necessary accommodations.
This section has been moved to [ARC-MULTI]
The ARC chain provides a verifiable record of the handlers for a message. Anonymous remailers will probably not find this compatible with their operating goals.
[[ See issue 21 regarding which document should be definitive for these fields. ]]
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:
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 have to complete up to 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 chain may be used to provide input to local policy engines in cases where DMARC validation fails (due to mediation impacting SPF attribution, DKIM validity or alignment).
Note that a passing ARC chain may not adequately mean that the message is safe because:
The ARC protocol is designed to mitigate some of the most common failure conditions for email which transits intermediary handlers en route to the final recipient. Some of these problems have happened due to the adoption of the DMARC protocol [RFC7489] and are listed in [RFC6377] and [RFC7960].
As the ARC protocol becomes standardized and implemented amongst intermediary handlers, the following aspects should be evaluated in order to determine the success of the protocol in accomplishing the intended benefits.
NOTE: Terminology within this section does NOT follow [RFC2119] interpretation. This section represents the current thoughts of the working group regarding unanswered questions related to the protocol. Wider deployment will inform these topics and probably expand them.
Currently, many receivers have heuristically determined overrides in order to rescue mail from intermediary-caused failures. Many of those overrides rely on inferrence rather than direct evidence.
ARC will be a success if, for ARC sealed messages, receivers are able to implment ARC-based algorithmic decisions based on the direct evidence found within the ARC chain. This is especially relevant for DMARC processing when the DKIM d= value is aligned with the rfc5322.From author domain.
The intent of ARC is to be at most value-add and at worst benign. If ARC opens up significant new vectors for abuse (see Section 11) then this protocol will be a failure. Note that weaknesses inherent in the mail protocols ARC is built upon (such as DKIM replay attacks and other known issues) are not new vectors which can be attributed to this specification.
The following open questions are academic and have no clear answer at the time of the development of the protocol. However, wide-spread deployment should be able to gather the necessary data to answer some or all of them.
Data should be collected to show if the ARC-Seal (AS) provides value beyond the ARC Message Signature (AMS) for either making delivery decisions or catching malicious actors trying to craft or replay malicious chains.
Longer ARC chains will require more queries to retrieve the keys for validating the chain. While this is not believed to be a security issue (see Section 11.2), it is unclear how much overhead will truly be added. This is similar to some of the initial processing and query load concerns which were debated at the time of the DKIM specification development.
Data should be collected to better understand usable length and distribution of lengths found in valid ARC chains along with the the DNS impact of processing ARC chains.
There are several edge cases where the information in the AAR can make the difference between message delivery or rejection. For example, if there is a well known mailing list that ARC seals but doesn’t do its own initial DMARC enforcement, a Final Receiver with this knowledge could make a delivery decision based upon the authentication information it sees in the corresponding AAR header.
Certain trace information in the AAR is useful/necessary in the construction of DMARC reports. It would be beneficial to identify the value-add of having intermediary-handled mail flow information added into the DMARC reports going back to senders.
Certain receivers believe the entire set of trace information would be valuable to feed into machine learning systems to identify fraud and/or provide other signals related to message delivery.
It is unclear what trace information will be valuable for all receivers, regardless of size.
Data should be collected on what trace information receivers are using that provides useful signals that affect deliverability, and what portions of the trace data are left untouched or provide no useful information.
Since many such systems are intentionly proprietary or confidential to prevent gaming by abusers, it may not be viable to reliably answer this particular question. The evolving nature of attacks can also shift the landscape of “useful” information over time.
[[ 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.
This information is known to be correct as of the seventh interoperability test event which was held on 2017-07-15 & 16 at IETF99.
For a few of the implementations, later status information was available as of December 2017.
Organization: Google
Description: Internal production implementation with both debug analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT-06]
Licensing: Proprietary - Internal only
Implementation Notes:
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 operational, but only applied to email addresses enrolled in the test program. This system conforms to [ARC-DRAFT-06]
Licensing: Proprietary - Internal only
Implementation Notes:
Contact Info: arc-discuss@dmarc.org
Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package
Status of Operation: Production
Coverage:
Licensing: Open/Other (same as dkimpy package = BCD version 2)
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-10]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes:
Contact Info: arc-discuss@dmarc.org
Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.2 package
Status of Operation: Patch submitted
Coverage: Based on OpenARC
Licensing: Same as mailman package - GPL
Implementation Notes:
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-05]
Licensing: On-line usage only
Implementation Notes:
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-06]
Licensing: Open source
Implementation Notes:
Contact Info: https://rspamd.com/doc/modules/arc.html and https://github.com/vstakhov/rspamd
Organization: FastMail
Description: Email domain authentication (sign and/or verify) module, previously included SPF / DKIM / DMARC, now has ARC added
Status of Operation: Production, deployment usage unknown
Coverage: Built to support [ARC-DRAFT-10]
Licensing: Open Source
Implementation Notes:
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
Organization: FastMail
Description: Email domain authentication milter, uses MAIL::DKIM (see above)
Status of Operation: Intial validation completed during IETF99 hackathon with some follow-on work during the week
Coverage: Built to support [I-D.ARC]
Licensing: Open Source
Implementation Notes:
Contact Info: https://github.com/fastmail/authentication_milter
Organization: Sympa Dev Community
Description: Work in progress
Status of Operation: Work in progress
Coverage: unknown
Licensing: open source
Implementation Notes:
Contact Info: https://github.com/sympa-community
Organization: Oracle
Description:
Status of Operation: Intial development work during IETF99 hackathon. Status since then unknown.
Coverage: Built to support [ARC-DRAFT-06]
Licensing: Unknown
Implementation Notes:
Contact Info: Chris Newman
Organization: MessageSystems/SparkPost
Description: OpenARC integration into the LUA-enabled Momentum processing space
Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-10]
Licensing: Unknown
Implementation Notes:
Contact Info:
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3463] | Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008. |
| [RFC5598] | Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009. |
| [RFC6376] | Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011. |
| [RFC6377] | Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011. |
| [RFC7208] | Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014. |
| [RFC7601] | Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
(This section is re-inserted for background information from [ARC-DRAFT-06] and earlier versions.)
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.
[[ 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 which will be included in a future draft. Issue 17 ]]
(Obsolete but retained for illustrative purposes)
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.