Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8617

The Authenticated Received Chain (ARC) Protocol

Pages: 35
Group: DMARC
Experimental
Part 2 of 2 – Pages 19 to 35
First   Prev   None

Top   ToC   RFC8617 - Page 19   prevText
7.  Use Cases

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

7.1.  Communicate Authentication Assessment across Trust Boundaries

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

   If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
   be used to bridge administrative boundaries.
Top   ToC   RFC8617 - Page 20
7.1.1.  Message-Scanning Services

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

   Scanning services typically require clients to point MX records of an
   Internet domain to the scanning service.  Messages destined for the
   Internet domain are initially delivered to the scanning service.
   Once scanning is performed, messages are then routed to the client's
   own mail-handling infrastructure.  Rerouting messages in this way
   almost always breaks path-based authentication (such as SPF).

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

7.1.2.  Multi-tier MTA Processing

   A large message-processing infrastructure is often divided into
   several processing tiers that can break authentication information
   between tiers.  For example, a large site may maintain a cluster of
   MTAs dedicated to connection handling and enforcement of IP-based
   reputation filtering.  A secondary cluster of MTAs may be dedicated
   and optimized for content-based processing of messages.

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

7.1.3.  Mailing Lists

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

   Mailing list services can implement ARC to convey the authentication
   assessment of posted messages sent to the list's subscriber base.
   The ADMDs of the mailing list subscribers can then use the
   Authenticated Received Chain to determine the authentication
   assessment of the original message before mailing list handling.
Top   ToC   RFC8617 - Page 21
7.2.  Inform Message Disposition Decisions

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

   Authenticated Received Chains allow ARC Validators to:

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

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

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

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

7.2.1.  DMARC Local Policy Overrides

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

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

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

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

   o  the Chain Validation Status,

   o  the domain and selector for each AS, and

   o  the originating IP address from the first ARC Set.

   EXAMPLE:

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

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

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

8.  Privacy Considerations

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

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

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

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

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

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

9.1.  Increased Header Field Size

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

9.2.  DNS Operations

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

   1.  An attacker can send a message to an ARC participant with a
       concocted sequence of ARC Sets bearing the domains of intended
       victims, and all of them will be queried by the participant until
       a failure is discovered.  DNS caching and the difficulty of
       forging the signature values should limit the extent of this load
       to domains under control of the attacker.  Query traffic pattern
       analysis may expose information about a downstream validating
       ADMD infrastructure.
Top   ToC   RFC8617 - Page 24
   2.  DKIM only performs one DNS query per signature, while ARC can
       introduce many (per chain).  Absent caching, slow DNS responses
       can cause SMTP timeouts and backlogged delivery queues on
       validating systems.  This could be exploited as a DoS attack.

9.3.  Message Content Suspicion

   Recipients are cautioned to treat messages bearing Authenticated
   Received Chains with the same suspicion applied to all other
   messages.  This includes appropriate content scanning and other
   checks for potentially malicious content.

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

   Just as passing message authentication is not an indication of
   message safety, forwarding that information through the mechanism of
   ARC is also not an indication of message safety.  Even if all ARC-
   enabled ADMDs are trusted, ADMDs may have become compromised, may
   miss unsafe content, or may not properly authenticate messages.

9.4.  Message Sealer Suspicion

   Recipients are cautioned to treat every Sealer of the ARC Chain with
   suspicion.  Just as with a validated DKIM signature, responsibility
   for message handling is attributed to the sealing domain, but whether
   or not that Sealer is a malicious actor is out of scope of the
   authentication mechanism.  Since ARC aids message delivery in the
   event of an authentication failure, ARC Sealers should be treated
   with suspicion, so that a malicious actor cannot seal spam or other
   fraudulent messages to aid their delivery, too.

9.5.  Replay Attacks

   Since ARC inherits heavily from DKIM, it has similar attack vectors.
   In particular, the replay attack described in [RFC6376], Section 8.6
   is potentially amplified by ARC's chained statuses.  In an ARC replay
   attack, a malicious actor would take an intact and passing ARC Chain
   and resend it to many recipients without making any modifications
   that invalidate the latest AMS or AS.  The impact to a receiver would
   be more DNS lookups and signature evaluations.  The scope of this
   attack can be limited by caching DNS queries and following the same
   signing scope guidance from [RFC6376], Section 5.4.1.
Top   ToC   RFC8617 - Page 25
10.  IANA Considerations

   This document defines one new authentication method and several
   status codes (Section 10.1), new ptypes and properties
   (Section 10.2), three new headers fields (Section 10.3), and a new
   enumerated status code (Section 10.4).

10.1.  Update to Email Authentication Result Names Registry

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

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

10.2.  Update to Email Authentication Methods Registry

   Per this document, IANA has added the following to the "Email
   Authentication Methods" registry, which is defined in [RFC8601]:

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

   o  Method: arc
      Definition: RFC 8617, Section 6
      ptype: header
      Property: oldest-pass
      Value: The instance id of the oldest validating AMS or 0 if they
      all pass (see Section 5.2)
      Status: active
      Version: 1
Top   ToC   RFC8617 - Page 26
10.3.  New Header Fields in Permanent Message Header Field Registry

   Per this document, IANA has added the following three new header
   fields to the "Permanent Message Header Field Names" registry:

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

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

   o  Header field name: ARC-Authentication-Results
      Applicable protocol: mail
      Status: experimental
      Author/Change controller: IETF
      Specification document(s): RFC 8617
      Related information: RFC 8601

10.4.  New Status Code in Enumerated Status Codes Registry

   Per this document, IANA has added the following value to the
   "Enumerated Status Codes" registry:

   o  Code: X.7.29
      Sample Text: ARC validation failure
      Associated basic status code: 550
      Description: This status code may be returned when a message fails
      ARC validation.
      Reference: RFC 8617
      Submitter: K. Andersen
      Change controller: IESG
Top   ToC   RFC8617 - Page 27
11.  Experimental Considerations

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

   As the ARC protocol is implemented by Internet Mail Handlers over
   time, the following should be evaluated in order to determine the
   success of the protocol in accomplishing the intended benefits.

11.1.  Success Consideration

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

   ARC will be a success if the presence of Authenticated Received
   Chains allows for improved decision making when processing legitimate
   messages, specifically resulting in equal or better delivery rates
   than achieved through the use of heuristic approaches.

11.2.  Failure Considerations

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

11.3.  Open Questions

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

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

   Data should be collected to show if the AS provides value beyond the
   AMS for either making delivery decisions or catching malicious actors
   trying to craft or replay malicious chains.
Top   ToC   RFC8617 - Page 28
11.3.2.  Usage and/or Signals from Multiple Selectors and/or Domains in
         ARC Sets

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

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

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

11.3.3.  DNS Overhead

   Longer Authenticated Received Chains will require more queries to
   retrieve the keys for validating the chain.  While this is not
   believed to be a security issue (see Section 9.2), it is unclear how
   much overhead will truly be added.  This is similar to some of the
   initial processing and query load concerns that were debated at the
   time of the DKIM specification development.

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

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

11.3.4.  What Trace Information Is Valuable?

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

   Certain trace information in the AAR is useful/necessary in the
   construction of DMARC reports.
Top   ToC   RFC8617 - Page 29
   Further, certain receivers believe the entire set of trace
   information would be valuable to feed into machine learning systems
   to identify fraud and/or provide other signals related to message
   delivery.

   At this point, however, it is unclear what trace information will be
   valuable for all receivers, regardless of size.

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

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

12.  References

12.1.  Normative References

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

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

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

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

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
              September 2011, <https://www.rfc-editor.org/info/rfc6377>.
Top   ToC   RFC8617 - Page 30
   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

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

12.2.  Informative References

   [ARC-MULTI]
              Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using
              Multiple Signing Algorithms with the ARC (Authenticated
              Received Chain) Protocol", Work in Progress, draft-ietf-
              dmarc-arc-multi-03, March 2019.

   [ARC-USAGE]
              Jones, S., Ed. and K. Andersen, "Recommended Usage of the
              Authenticated Received Chain (ARC)", Work in Progress,
              draft-ietf-dmarc-arc-usage-07, April 2019.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.
Top   ToC   RFC8617 - Page 31
   [RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
              E., Ed., and K. Andersen, Ed., "Interoperability Issues
              between Domain-based Message Authentication, Reporting,
              and Conformance (DMARC) and Indirect Email Flows",
              RFC 7960, DOI 10.17487/RFC7960, September 2016,
              <https://www.rfc-editor.org/info/rfc7960>.
Top   ToC   RFC8617 - Page 32
Appendix A.  Design Requirements

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

A.1.  Primary Design Criteria

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

   o  Not require changes for originators of email;

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

   o  Work at Internet scale; and

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

A.2.  Out of Scope

   ARC is not a trust framework.  Users of the ARC header fields are
   cautioned against making unsubstantiated conclusions when
   encountering a "broken" ARC sequence.
Top   ToC   RFC8617 - Page 33
Appendix B.  Example Usage

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

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

Hey gang,
This is a test message.
--J.
Top   ToC   RFC8617 - Page 35
Acknowledgments

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

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

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

Authors' Addresses

   Kurt Andersen
   LinkedIn
   1000 West Maude Ave
   Sunnyvale, California  94085
   United States of America

   Email: kurt+ietf@drkurt.com


   Brandon Long (editor)
   Google

   Email: blong@google.com


   Seth Blank (editor)
   Valimail

   Email: seth@valimail.com


   Murray Kucherawy (editor)
   TDP

   Email: superuser@gmail.com