[要約] RFC 8617は、ARCプロトコルに関する仕様であり、電子メールの認証済み受信チェーンを提供することを目的としています。ARCは、電子メールの送信者認証とメッセージの整合性を確保するためのセキュリティ機能を提供します。
Internet Engineering Task Force (IETF) K. Andersen
Request for Comments: 8617 LinkedIn
Category: Experimental B. Long, Ed.
ISSN: 2070-1721 Google
S. Blank, Ed.
Valimail
M. Kucherawy, Ed.
TDP
July 2019
The Authenticated Received Chain (ARC) Protocol
Authenticated Received Chain（ARC）プロトコル
Abstract
概要
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
Authenticated Received Chain（ARC）プロトコルは、メッセージに認証された「管理チェーン」を提供し、メッセージを処理する各エンティティが、以前に処理したエンティティと、処理の各ステップでのメッセージの認証評価を確認できます。
ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARCにより、インターネットメールハンドラーは、メッセージ認証評価のアサーションを個々のメッセージに添付できます。メッセージがARC対応のインターネットメールハンドラーを通過するときに、追加のARCアサーションをメッセージに添付して、メッセージ処理パスの各ステップでの認証評価を表すARCアサーションの順序付きセットを形成できます。
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.
ARC対応のインターネットメールハンドラーは、一連のARCアサーションを処理してメッセージ処理の決定を通知し、既存の認証メカニズムを壊す可能性のあるインターネットメールハンドラーを特定し、信頼境界を越えて元の認証評価を伝達します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8617.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8617で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8
3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Header Fields to Include in ARC-Seal Signatures . . . 15
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
5.1.3. Only One Authenticated Received Chain per Message . . 16
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 19
6. Communication of Validation Results . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Communicate Authentication Assessment across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
7.2. Inform Message Disposition Decisions . . . . . . . . . . 21
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Increased Header Field Size . . . . . . . . . . . . . . . 23
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 23
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 24
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 24
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Update to Email Authentication Result Names Registry . . 25
10.2. Update to Email Authentication Methods Registry . . . . 25
10.3. New Header Fields in Permanent Message Header Field
Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
10.4. New Status Code in Enumerated Status Codes Registry . . 26
11. Experimental Considerations . . . . . . . . . . . . . . . . . 27
11.1. Success Consideration . . . . . . . . . . . . . . . . . 27
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 27
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 27
11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 27
11.3.2. Usage and/or Signals from Multiple Selectors and/or
Domains in ARC Sets . . . . . . . . . . . . . . . . 28
11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 28
11.3.4. What Trace Information Is Valuable? . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Design Requirements . . . . . . . . . . . . . . . . 32
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 32
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail by intermediate handlers. This impact is thoroughly documented in the defining documents for SPF and DKIM and further discussed in [RFC6377] and [RFC7960].
Sender Policy Framework（SPF）[RFC7208]やDomainKeys Identified Mail（DKIM）[RFC6376]など、広く展開されている電子メール認証技術のユーティリティは、中間ハンドラーによるインターネットメールの処理の影響を受けます。この影響は、SPFとDKIMの定義ドキュメントに完全に文書化されており、[RFC6377]と[RFC7960]でさらに説明されています。
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] also relies upon SPF and DKIM authentication mechanisms. Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected.
ドメインベースのメッセージ認証、レポート、および準拠（DMARC）[RFC7489]も、SPFおよびDKIM認証メカニズムに依存しています。中間ハンドラーのアクションが原因で認証が失敗すると、正当なメールが誤って拒否されたり、誤って送信されたりする可能性があります。
Authenticated Received Chain (ARC) creates a mechanism for individual Internet Mail Handlers to add their authentication assessment to a message's ordered set of handling results. ARC encapsulates the authentication assessment in a DKIM signature derivative to grant other handlers the ability to verify the authenticity of the individual assessment assertion as well as the aggregate set and sequence of results.
Authenticated Received Chain（ARC）は、個々のインターネットメールハンドラーがメッセージの順序付けされた一連の処理結果に認証評価を追加するためのメカニズムを作成します。 ARCは、認証評価をDKIMシグネチャデリバティブにカプセル化して、他のハンドラに、個々の評価アサーションの信頼性、および結果の集計セットとシーケンスを検証する機能を許可します。
Ordered sets of authentication assessments can be used by ARC-enabled Internet Mail Handlers to inform message-handling disposition, identify where alteration of message content might have occurred, and provide additional trace information for use in understanding message-handling paths.
ARC対応のインターネットメールハンドラーは、順序付けられた一連の認証評価を使用して、メッセージ処理の性質を通知し、メッセージコンテンツの変更が発生した場所を特定し、メッセージ処理パスを理解するための追加のトレース情報を提供できます。
ARC is loosely based on concepts from evidence collection. Evidence is usually collected, labeled, stored, and transported in specific ways to preserve the state of evidence and to document all processing steps.
ARCは、証拠収集からの概念に大まかに基づいています。エビデンスは通常、特定の方法で収集、ラベル付け、保存、および転送され、エビデンスの状態を保存し、すべての処理ステップを文書化します。
In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery. Determination of message authentication can be affected when intermediate handlers modify message content (header fields and/or body content), route messages through unforeseen paths, or change envelope information.
ARCの状況では、「証拠」は、発信と最終配信の間の配信パスに沿った任意の時点でのメッセージの認証評価です。中間ハンドラーがメッセージコンテンツ（ヘッダーフィールドや本文のコンテンツ）を変更したり、予期しないパスを介してメッセージをルーティングしたり、エンベロープ情報を変更したりすると、メッセージ認証の決定が影響を受ける可能性があります。
The authentication assessment for a message is determined upon receipt of a message and documented in the Authentication-Results header field(s). ARC extends this mechanism to survive transit through intermediary Administrative Management Domains (ADMDs).
メッセージの認証評価は、メッセージの受信時に決定され、Authentication-Resultsヘッダーフィールドに文書化されます。 ARCは、このメカニズムを拡張して、中間の管理管理ドメイン（ADMD）を通過して生き残るようにします。
Because the first-hand determination of an authentication assessment can never be reproduced by other handlers, the assertion of the authentication assessment is more akin to testimony by a verifiable party than to hard evidence, which can be independently evaluated.
認証評価の直接の決定は他のハンドラーでは再現できないため、認証評価のアサーションは、独立して評価できるハードエビデンスよりも検証可能な当事者による証言に似ています。
"Custody" refers to when an Internet Mail Handler processes a message. When a handler takes custody of a message, the handler becomes a custodian and attaches its own evidence (authentication assessment upon receipt) to the message if it is ARC enabled. Evidence is added in such a way that future handlers can verify the authenticity of both evidence and custody.
「保管」とは、Internet Mail Handlerがメッセージを処理するタイミングを指します。ハンドラーがメッセージを管理すると、ハンドラーはカストディアンになり、ARCが有効になっている場合は、メッセージに独自の証拠（受信時の認証評価）を添付します。証拠は、将来のハンドラーが証拠と保管の両方の信頼性を検証できるように追加されます。
The "chain of custody" of ARC is the entire set of evidence and custody that travels with a message.
ARCの「保管の連鎖」は、メッセージとともに移動する証拠と保管の全体のセットです。
Any ARC-enabled Internet Mail Handler can validate the entire set of custody and the authentication assessments asserted by each party to yield a valid chain of custody. If the evidence-supplying custodians can be trusted, then the validated chain of custody describes the (possibly changing) authentication assessment as the message traveled through various custodians.
ARC対応のインターネットメールハンドラーは、保管のすべてのセットと、有効な保管の連鎖を生成するために各当事者によってアサートされる認証評価を検証できます。証拠を提供するカストディアンが信頼できる場合、検証された保管チェーンは、メッセージがさまざまなカストディアンを通過したときの（おそらく変更される）認証評価を記述します。
Even though a message's authentication assessment might have changed, the validated chain of custody can be used to determine if the changes (and the custodians responsible for the changes) can be tolerated.
メッセージの認証評価が変更された可能性がある場合でも、検証された保管のチェーンを使用して、変更（および変更を担当するカストディアン）が許容できるかどうかを判断できます。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
Readers should to be familiar with the contents, core concepts, and definitions found in [RFC5598]. The potential roles of transit services in the delivery of email are directly relevant.
読者は、[RFC5598]にある内容、コアコンセプト、および定義に精通している必要があります。電子メールの配信における輸送サービスの潜在的な役割は、直接関連しています。
Language, syntax (including some ABNF constructs), and concepts are imported from DKIM [RFC6376]. Specific references to DKIM are made throughout this document. The following terms are imported from [RFC5598]:
言語、構文（一部のABNF構成を含む）、および概念は、DKIM [RFC6376]からインポートされます。このドキュメントでは、DKIMについて具体的に言及しています。次の用語は[RFC5598]からインポートされます。
o Administrative Management Domain (ADMD), Section 2.3
o 管理管理ドメイン（ADMD）、セクション2.3
o Message Transfer Agent (MTA), Section 4.3.2
o メッセージ転送エージェント（MTA）、セクション4.3.2
o Message Submission Agent (MSA), Section 4.3.1
o メッセージ送信エージェント（MSA）、セクション4.3.1
o Message Delivery Agent (MDA), Section 4.3.3
o メッセージ配信エージェント（MDA）、セクション4.3.3
Syntax descriptions use ABNF [RFC5234] [RFC7405].
構文の説明では、ABNF [RFC5234] [RFC7405]を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Section 4.1 introduces three (3) ARC header fields that are added to a message by an ARC-enabled Internet Mail Handler. Together, these three header fields compose a single "ARC Set". An ARC Set provides the means for an Internet Mail Handler to attach an authentication assessment to a message in a manner that can be verified by future handlers. A single message can contain multiple ARC Sets.
セクション4.1では、ARC対応のインターネットメールハンドラーによってメッセージに追加される3つのARCヘッダーフィールドを紹介しています。これら3つのヘッダーフィールドを合わせて、1つの「ARCセット」を構成します。 ARCセットは、インターネットメールハンドラーが将来のハンドラーで検証できる方法で認証評価をメッセージに添付する手段を提供します。 1つのメッセージに複数のARCセットを含めることができます。
In general concept terms, an ARC Set represents Evidence and Custody.
一般的な概念では、ARCセットは証拠と保管を表します。
The sequence of ARC Sets attached to a message at a given time is called the "Authenticated Received Chain" or "ARC". An Authenticated Received Chain is the record of individual authentication assessments as a message traverses through ARC-participating ADMDs.
所定の時間にメッセージに添付されたARCセットのシーケンスは、「認証済み受信チェーン」または「ARC」と呼ばれます。 Authenticated Received Chainは、メッセージがARC参加ADMDを通過する際の個々の認証評価の記録です。
The first attachment of an ARC Set to a message causes an Authenticated Received Chain to be created. Additional attachments of ARC Sets cause the Authenticated Received Chain to be extended.
ARCセットをメッセージに最初に添付すると、認証済み受信チェーンが作成されます。 ARCセットの追加の添付により、認証済み受信チェーンが拡張されます。
In general concept terms, an Authenticated Received Chain represents a chain of custody.
一般的な概念では、認証済み受信チェーンは、管理のチェーンを表します。
Internet Mail Handlers process and deliver messages across the Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as defined in [RFC5598].
インターネットメールハンドラーは、インターネットを介してメッセージを処理および配信し、[RFC5598]で定義されているMSA、MTA、MDA、ゲートウェイ、およびメーリングリストを含みます。
Throughout this document, the term "intermediaries" refers to both regular MTAs as well as delivery/reposting agents such as mailing lists covered within the scope of transit services per [RFC5598].
このドキュメント全体を通じて、「仲介者」という用語は、通常のMTAと、[RFC5598]のトランジットサービスの範囲に含まれるメーリングリストなどの配信/再投稿エージェントの両方を指します。
"Intermediaries" and "Internet Mail Handlers" are used synonymously throughout this document.
「仲介者」と「インターネットメールハンドラー」は、このドキュメント全体で同意語として使用されています。
The authentication assessment that is affixed to a message as part of each ARC Set consists of the "authres-payload" [RFC8601]. For the integrity of an ARC Set, the authentication assessment only needs to be properly encapsulated within the ARC Set as defined in Section 4.1. The accuracy or syntax of the authres-payload field does not affect the validity of the ARC Chain itself.
各ARCセットの一部としてメッセージに添付される認証評価は、「authres-payload」[RFC8601]で構成されます。 ARCセットの整合性のために、認証評価は、セクション4.1で定義されているように、ARCセット内に適切にカプセル化する必要があるだけです。 authres-payloadフィールドの精度または構文は、ARCチェーン自体の有効性には影響しません。
Signing is the process of affixing a digital signature to a message as a header field, such as when a DKIM-Signature (as in [RFC6376], Section 2.1), an AMS, or an AS is added. Sealing is when an ADMD affixes a complete and valid ARC Set to a message to create or continue an Authenticated Received Chain.
署名とは、DKIM-Signature（[RFC6376]、セクション2.1など）、AMS、またはASが追加された場合など、デジタル署名をヘッダーフィールドとしてメッセージに添付するプロセスです。シールとは、ADMDが完全かつ有効なARCセットをメッセージに添付して、認証済み受信チェーンを作成または続行することです。
A Sealer is an Internet Mail Handler that attaches a complete and valid ARC Set to a message.
シーラーは、完全で有効なARCセットをメッセージに添付するインターネットメールハンドラーです。
In general concept terms, a Sealer adds its testimony (assertion of authentication assessment) and proof of custody to the chain of custody.
一般的な概念では、シーラーはその証言（認証評価の主張）と監護の証明を一連の監護に追加します。
A Validator is an ARC-enabled Internet Mail Handler that evaluates an Authenticated Received Chain for validity and content. The process of evaluation of the individual ARC Sets that compose an Authenticated Received Chain is described in Section 5.2.
バリデーターは、ARCが有効なインターネットメールハンドラーであり、認証済み受信チェーンの有効性とコンテンツを評価します。 Authenticated Received Chainを構成する個々のARCセットの評価プロセスについては、セクション5.2で説明しています。
In general concept terms, a Validator inspects the chain of custody to determine the content and validity of individual evidence supplied by custodians.
一般的な概念では、バリデーターは保管のチェーンを検査して、カストディアンによって提供された個々の証拠の内容と有効性を決定します。
The following ABNF tokens are imported:
次のABNFトークンがインポートされます。
o tag-list ([RFC6376], Section 3.2)
o タグリスト（[RFC6376]、セクション3.2）
o authres-payload ([RFC8601], Section 2.2)
o authres-payload（[RFC8601]、セクション2.2）
o CFWS ([RFC5322], Section 3.2.2)
o CFWS（[RFC5322]、セクション3.2.2）
The following ABNF tokens are used elsewhere in this document:
次のABNFトークンは、このドキュメントの他の場所で使用されています。
position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status
ARC introduces three new header fields. The syntax for new header fields adapts existing specifications. This document only describes where ARC-specific changes in syntax and semantics differ from existing specifications.
ARCでは、3つの新しいヘッダーフィールドが導入されています。新しいヘッダーフィールドの構文は、既存の仕様を採用しています。このドキュメントでは、構文およびセマンティクスのARC固有の変更が既存の仕様と異なる場合についてのみ説明します。
The ARC-Authentication-Results (AAR) header field records the message authentication assessment as processed by an ARC-participating ADMD at message arrival time.
ARC-Authentication-Results（AAR）ヘッダーフィールドは、メッセージ到着時にARC参加ADMDによって処理されたメッセージ認証評価を記録します。
In general concept terms, the AAR header field is where evidence is recorded by a custodian.
一般的な概念では、AARヘッダーフィールドは証拠がカストディアンによって記録される場所です。
The AAR header field is similar in syntax and semantics to an Authentication-Results field [RFC8601], with two (2) differences:
AARヘッダーフィールドの構文とセマンティクスは、Authentication-Resultsフィールド[RFC8601]と似ていますが、2つの違いがあります。
o the name of the header field itself and
o ヘッダーフィールド自体の名前と
o the presence of the instance tag. Additional information on the instance tag can be found in Section 4.2.1.
o インスタンスタグの存在。インスタンスタグの詳細については、セクション4.2.1を参照してください。
The formal ABNF for the AAR header field is:
AARヘッダーフィールドの正式なABNFは次のとおりです。
arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
Because there is only one AAR allowed per ARC Set, the AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD, regardless of how many Authentication-Results header fields are attached to the message.
ARCセットごとに許可されるAARは1つだけなので、AARには、メッセージに添付されているAuthentication-Resultsヘッダーフィールドの数に関係なく、参加しているADMD内からのすべての認証結果を含むauthres-payloadを含める必要があります。
The ARC-Message-Signature (AMS) header field allows an ARC-participating ADMD to convey some responsibility (custodianship) for a message and possible message modifications to future ARC-participating custodians.
ARC-Message-Signature（AMS）ヘッダーフィールドを使用すると、ARCに参加しているADMDは、メッセージの責任（カストディアンシップ）と、可能なメッセージの変更を将来のARCに参加しているカストディアンに伝えることができます。
In general concept terms, the AMS header field identifies a custodian.
一般的な概念では、AMSヘッダーフィールドはカストディアンを識別します。
The AMS header field has the same syntax and semantics as the DKIM-Signature field [RFC6376], with three (3) differences:
AMSヘッダーフィールドの構文とセマンティクスは、DKIM-Signatureフィールド[RFC6376]と同じですが、次の3つの違いがあります。
o the name of the header field itself;
o ヘッダーフィールド自体の名前。
o no version tag ("v") is defined for the AMS header field. As required for undefined tags (in [RFC6376]), if seen, a version tag MUST be ignored; and
o AMSヘッダーフィールドにバージョンタグ（ "v"）が定義されていません。未定義のタグ（[RFC6376]内）に必要な場合、表示される場合、バージョンタグは無視する必要があります。そして
o the "i" (Agent or User Identifier (AUID)) tag is not imported from DKIM; instead, this tag is replaced by the instance tag as defined in Section 4.2.1.
o 「i」（エージェントまたはユーザー識別子（AUID））タグはDKIMからインポートされません。代わりに、このタグは、セクション4.2.1で定義されているインスタンスタグに置き換えられます。
ARC places no requirements on the selectors and/or domains used for the AMS header field signatures.
ARCは、AMSヘッダーフィールドの署名に使用されるセレクターやドメインに要件を課しません。
The formal ABNF for the AMS header field is:
AMSヘッダーフィールドの正式なABNFは次のとおりです。
arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
To reduce the chances of accidental invalidation of AMS signatures:
AMS署名が誤って無効になる可能性を減らすには：
o AMS header fields are added by ARC-participating ADMDs as messages exit the ADMD. AMS header fields SHOULD be attached so that any modifications made by the ADMD are included in the signature of the AMS header field.
o AMSヘッダーフィールドは、メッセージがADMDを出るときに、ARC参加ADMDによって追加されます。 ADMSによって行われた変更がAMSヘッダーフィールドのシグネチャに含まれるように、AMSヘッダーフィールドを添付する必要があります。
o Authentication-Results header fields MUST NOT be included in AMS signatures as they are likely to be deleted by downstream ADMDs (per [RFC8601], Section 5).
o Authentication-Resultsヘッダーフィールドは、ダウンストリームADMDによって削除される可能性があるため（A [RFC8601]、セクション5）、AMS署名に含めることはできません。
o ARC-related header fields (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal) MUST NOT be included in the list of header fields covered by the signature of the AMS header field.
o ARC関連のヘッダーフィールド（ARC-Authentication-Results、ARC-Message-Signature、およびARC-Seal）は、AMSヘッダーフィールドの署名の対象となるヘッダーフィールドのリストに含めてはなりません（MUST NOT）。
To preserve the ability to verify the integrity of a message, the signature of the AMS header field SHOULD include any DKIM-Signature header fields already present in the message.
メッセージの整合性を検証する機能を維持するために、AMSヘッダーフィールドの署名には、メッセージにすでに存在するDKIM-Signatureヘッダーフィールドを含める必要があります（SHOULD）。
The AS header field permits ARC-participating ADMDs to verify the integrity of AAR header fields and corresponding AMS header fields.
ASヘッダーフィールドにより、ARCに参加しているADMDは、AARヘッダーフィールドと対応するAMSヘッダーフィールドの整合性を検証できます。
In general concept terms, the AS header field is how custodians bind their authentication assessments (testimonials) into a chain of custody so that Validators can inspect individual evidence and custodians.
一般的な概念では、ASヘッダーフィールドは、カストディアンが認証評価（推薦状）を一連の管理に結び付け、バリデーターが個々の証拠とカストディアンを検査できるようにする方法です。
The AS header field is similar in syntax and semantics to DKIM-Signature header fields [RFC6376], with the following differences:
ASヘッダーフィールドの構文とセマンティクスはDKIM-Signatureヘッダーフィールド[RFC6376]と似ていますが、次の点が異なります。
o the "i" (AUID) tag is not imported from DKIM; instead, this tag is replaced by the instance tag as defined in Section 4.2.1;
o 「i」（AUID）タグはDKIMからインポートされません。代わりに、このタグは、セクション4.2.1で定義されているインスタンスタグに置き換えられます。
o the signature of the AS header field does not cover the body of the message; therefore, there is no "bh" tag. The signature of the AS header field only covers specific header fields as defined in Section 5.1.1;
o ASヘッダーフィールドの署名はメッセージの本文をカバーしません。したがって、「bh」タグはありません。 ASヘッダーフィールドの署名は、セクション5.1.1で定義されている特定のヘッダーフィールドのみを対象とします。
o no body canonicalization is performed as the AS signature does not cover the body of a message;
o AS署名はメッセージの本文をカバーしないため、本文の正規化は行われません。
o only "relaxed" header field canonicalization ([RFC6376], Section 3.4.2) is used;
o 「リラックスした」ヘッダーフィールドの正規化（[RFC6376]、セクション3.4.2）のみが使用されます。
o the only supported tags are "i" (from Section 4.2.1 of this document), and "a", "b", "d", "s", and "t" from [RFC6376], Section 3.5. Note especially that the DKIM "h" tag is NOT allowed and, if found, MUST result in a cv status of "fail" (for more information, see Section 5.1.1); and
o サポートされているタグは「i」（このドキュメントのセクション4.2.1から）、および[RFC6376]の「a」、「b」、「d」、「s」、および「t」、セクション3.5のみです。特に、DKIMの「h」タグは許可されておらず、見つかった場合は、cvステータスが「fail」になる必要があります（詳細については、セクション5.1.1を参照）。そして
o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF definition), is used to communicate the Chain Validation Status to subsequent ADMDs.
o 追加のタグ「cv」（ARC-Seal ABNF定義の「seal-cv-tag」）は、後続のADMDにチェーン検証ステータスを通知するために使用されます。
ARC places no requirements on the selectors and/or domains used for the AS header field signatures.
ARCは、ASヘッダーフィールドの署名に使用されるセレクターやドメインに要件を課しません。
The formal ABNF for the AS header field is:
ASヘッダーフィールドの正式なABNFは次のとおりです。
arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info
In internationalized messages [RFC6532], many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by [RFC8616] and Authentication-Results (A-R) as updated in [RFC8601], but they are called out here for emphasis.
国際化メッセージ[RFC6532]では、多くのヘッダーフィールドにASCIIテキストだけでなくUTF-8を含めることができます。 EAIの変更はすべて、[RFC8616]によって更新されたDKIMと[RFC8601]で更新されたAuthentication-Results（A-R）から継承されますが、ここでは強調のためにそれらを呼び出します。
In all ARC header fields, the d= and s= tags can contain U-labels. In all tags, non-ASCII characters need not be quoted in dkim-quoted-printable.
すべてのARCヘッダーフィールドでは、d =およびs =タグにUラベルを含めることができます。すべてのタグで、非ASCII文字をdkim-quoted-printableで引用する必要はありません。
The AAR header allows UTF-8 in the same places that Authentication-Results does, as described in [RFC8601].
[RFC8601]で説明されているように、AARヘッダーはAuthentication-Resultsと同じ場所でUTF-8を許可します。
An "ARC Set" is a single collection of three ARC header fields (AAR, AMS, and AS). ARC header fields of an ARC Set share the same "instance" value.
「ARCセット」は、3つのARCヘッダーフィールド（AAR、AMS、およびAS）の単一のコレクションです。 ARCセットのARCヘッダーフィールドは、同じ「インスタンス」値を共有します。
By adding all ARC header fields to a message, an ARC Sealer adds an ARC Set to a message. A description of how Sealers add an ARC Set to a message is found in Section 5.1.
すべてのARCヘッダーフィールドをメッセージに追加することにより、ARCシーラーはARCセットをメッセージに追加します。シーラーがメッセージにARCセットを追加する方法の説明は、セクション5.1にあります。
Instance tags describe which ARC header fields belong to an ARC Set. Each ARC header field of an ARC Set shares the same instance tag value.
インスタンスタグは、ARCセットに属するARCヘッダーフィールドを示します。 ARCセットの各ARCヘッダーフィールドは、同じインスタンスタグ値を共有します。
Instance tag values are integers that begin at 1 and are incremented by each addition of an ARC Set. Through the incremental values of instance tags, an ARC Validator can determine the order in which ARC Sets were added to a message.
インスタンスタグ値は1から始まる整数で、ARCセットが追加されるたびに増分されます。 ARCバリデーターは、インスタンスタグの増分値を通じて、ARCセットがメッセージに追加された順序を決定できます。
Instance tag values can range from 1-50 (inclusive).
インスタンスタグの値の範囲は1〜50です。
_INFORMATIONAL_: The upper limit of 50 was picked based on some initial observations reported by early working group members. The value was chosen to balance the risk of excessive header field growth (see Section 9.1) against expert opinion regarding the probability of long-tail, but non-looping, multiple-intermediary mail flows. Longer ARC Chains will also impose a load on Validators and DNS to support additional verification steps. Observed quantities of "Received" header fields were also considered in establishing this as an experimental initial value.
_INFORMATIONAL_：初期の作業グループのメンバーによって報告されたいくつかの初期の観察に基づいて、上限の50が選択されました。この値は、ヘッダーフィールドが過度に増大するリスク（セクション9.1を参照）と、ロングテールではあるがループしない複数の中間メールフローの確率に関する専門家の意見のバランスをとるために選択されました。より長いARCチェーンは、追加の検証手順をサポートするためにバリデーターとDNSに負荷をかけます。 「Received」ヘッダーフィールドの観測された量も、これを実験的な初期値として確立する際に考慮されました。
Valid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm.
有効なARCセットは、特定のインスタンス値と署名アルゴリズムに対して、各ARCヘッダーフィールド（AAR、AMS、およびAS）のインスタンスを1つだけ持っている必要があります。
For handling multiple signing algorithms, see [ARC-MULTI].
複数の署名アルゴリズムの処理については、[ARC-MULTI]を参照してください。
An Authenticated Received Chain is an ordered collection of ARC Sets. As ARC Sets are enumerated sets of ARC header fields, an Authenticated Received Chain represents the output of message authentication assessments along the handling path of ARC-enabled processors.
Authenticated Received Chainは、ARCセットの順序付けられたコレクションです。 ARCセットはARCヘッダーフィールドの列挙されたセットであるため、Authenticated Received Chainは、ARC対応プロセッサの処理パスに沿ったメッセージ認証評価の出力を表します。
Authentication assessments determined at each step of the ARC-enabled handling path are present in an Authenticated Received Chain in the form of AAR header fields. The ability to verify the identity of message handlers and the integrity of message content is provided by AMS header fields. AS header fields allow message handlers to validate the assertions, order, and sequence of the Authenticated Received Chain itself.
ARC対応の処理パスの各ステップで決定された認証評価は、AARヘッダーフィールドの形式で認証済み受信チェーンに存在します。メッセージハンドラーのIDとメッセージコンテンツの整合性を検証する機能は、AMSヘッダーフィールドによって提供されます。 ASヘッダーフィールドを使用すると、メッセージハンドラーは、認証済み受信チェーン自体のアサーション、順序、およびシーケンスを検証できます。
In general concept terms, an Authenticated Received Chain represents a message's chain of custody. Validators can consult a message's chain of custody to gain insight regarding each custodian of a message and the evidence collected by each custodian.
一般的な概念では、認証済み受信チェーンは、メッセージの管理チェーンを表します。検証者は、メッセージの管理チェーンを参照して、メッセージの各カストディアンおよび各カストディアンによって収集された証拠に関する洞察を得ることができます。
The state of the Authenticated Received Chain at a specific processing step is called the "Chain Validation Status". Chain Validation Status information is communicated in several ways:
特定の処理ステップでの認証済み受信チェーンの状態は、「チェーン検証ステータス」と呼ばれます。チェーン検証ステータス情報は、いくつかの方法で伝達されます。
o as the AS header field in the "cv" tag and
o 「cv」タグのASヘッダーフィールドとして
o as part of the Authentication-Results and AAR header field(s).
o Authentication-ResultsおよびAARヘッダーフィールドの一部として。
Chain Validation Status has one of three possible values:
チェーン検証ステータスには、次の3つの値のいずれかがあります。
o none: There was no Authenticated Received Chain on the message when it arrived for validation. Typically, this occurs when a message is received directly from a message's original Message Transfer Agent (MTA) or Message Submission Agent (MSA), or from an upstream Internet Mail Handler that is not participating in ARC handling.
o なし：検証のために到着したときに、メッセージに認証された受信チェーンがありませんでした。通常、これは、メッセージがメッセージの元のメッセージ転送エージェント（MTA）またはメッセージ送信エージェント（MSA）から直接受信された場合、またはARC処理に参加していない上流のインターネットメールハンドラーから受信された場合に発生します。
o fail: The message contains an Authenticated Received Chain whose validation failed.
o fail：メッセージには、検証が失敗したAuthenticated Received Chainが含まれています。
o pass: The message contains an Authenticated Received Chain whose validation succeeded.
o pass：メッセージには、検証が成功したAuthenticated Received Chainが含まれています。
ARC-enabled Internet Mail Handlers generally act as both ARC Validators (when receiving messages) and ARC Sealers (when sending messages onward, not originated locally).
ARC対応のインターネットメールハンドラーは、通常、ARCバリデーター（メッセージを受信する場合）とARCシーラー（メッセージをローカルに発信せずに送信する場合）の両方として機能します。
An Authenticated Received Chain with a Chain Validation Status of "pass" (or "none") allows Internet Mail Handlers to ascertain:
チェーン検証ステータスが「合格」（または「なし」）の認証済み受信チェーンを使用すると、インターネットメールハンドラーは以下を確認できます。
o all ARC-participating ADMDs that claim responsibility for handling (and possibly modifying) the message in transit and
o 送信中のメッセージの処理（および場合によっては変更）の責任を主張するすべてのARC参加ADMD
o the authentication assessments of the message as determined by each ADMD (from AAR header fields).
o 各ADMDによって決定されたメッセージの認証評価（AARヘッダーフィールドから）。
With this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing.
この情報を使用して、インターネットメールハンドラーは、中間処理が原因で認証に失敗したメッセージの処理に関するローカルポリシーの決定を通知できます（MAY）。
To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC header fields AAR, AMS, and AS) to a message. All ARC header fields in an ARC Set share the same instance tag value.
メッセージを「シール」するために、ARCシーラーはARCセット（3つのARCヘッダーフィールドAAR、AMS、およびAS）をメッセージに追加します。 ARCセット内のすべてのARCヘッダーフィールドは、同じインスタンスタグ値を共有します。
To perform sealing (aka to build and attach a new ARC Set), the following actions must be taken by an ARC Sealer when presented with a message:
シーリングを実行するには（新しいARCセットを作成して接続すること）、メッセージが表示されたときにARCシーラーで次のアクションを実行する必要があります。
1. All message modifications (including adding a DKIM-Signature header field(s)) MUST be performed before sealing.
1. すべてのメッセージ変更（DKIM-Signatureヘッダーフィールドの追加を含む）は、封印する前に実行する必要があります。
2. If the message already contains an Authenticated Received Chain with the most recent AS reporting "cv=fail", there is no need to proceed and the algorithm stops here.
2. メッセージに認証済み受信チェーンが含まれており、最新のASが「cv = fail」を報告している場合、続行する必要はなく、アルゴリズムはここで停止します。
3. Calculate the instance value. If the message already contains an Authenticated Received Chain, the instance value is 1 more than the highest instance number found in the Authenticated Received Chain. If no Authenticated Received Chain exists, the instance value is 1.
3. インスタンス値を計算します。メッセージにすでに認証済み受信チェーンが含まれている場合、インスタンス値は、認証済み受信チェーンで見つかった最大のインスタンス番号より1大きくなります。 Authenticated Received Chainが存在しない場合、インスタンス値は1です。
4. Using the calculated instance value, generate and attach a complete ARC Set to the message as follows:
4. 計算されたインスタンス値を使用して、次のように完全なARCセットを生成し、メッセージに添付します。
A. Generate and attach an ARC-Authentication-Results header field as defined in Section 4.1.1.
A.セクション4.1.1で定義されているように、ARC-Authentication-Resultsヘッダーフィールドを生成して添付します。
B. Generate and attach an ARC-Message-Signature header field as defined in Section 4.1.2.
B.セクション4.1.2で定義されているARC-Message-Signatureヘッダーフィールドを生成して添付します。
C. Generate and attach an ARC-Seal header field using the AS definition found in Section 4.1.3, the prescribed headers defined in Section 5.1.1, and the Chain Validation Status as determined during ARC validation.
C.セクション4.1.3にあるAS定義、セクション5.1.1に定義されている規定のヘッダー、およびARC検証中に決定されたチェーン検証ステータスを使用して、ARC-Sealヘッダーフィールドを生成して添付します。
The ARC-Seal is generated in a manner similar to how DKIM-Signature header fields are added to messages ([RFC6376], Section 3.7), with explicit requirements on the header fields and ordering of those fields.
ARC-Sealは、DKIM-Signatureヘッダーフィールドをメッセージに追加する方法（[RFC6376]、セクション3.7）と同様の方法で生成されます。ヘッダーフィールドとそれらのフィールドの順序については明示的な要件があります。
The signature of an AS header field signs a canonicalized form of the ARC Set header field values. The ARC Set header field values are supplied to the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time of sealing the message.
ASヘッダーフィールドの署名は、ARCセットヘッダーフィールド値の正規化された形式に署名します。 ARCセットヘッダーフィールドの値は、1から始まるインスタンスの昇順でハッシュ関数に提供され、メッセージのシール時に追加されるARCセットが含まれます。
Within an ARC Set, header fields are supplied to the hash function in the following order:
ARCセット内では、ヘッダーフィールドは次の順序でハッシュ関数に提供されます。
1. ARC-Authentication-Results
1. ARC-Authentication-Results
2. ARC-Message-Signature
2. ARC-Message-Signature
3. ARC-Seal
3. ARC-Seal
Note that when an Authenticated Received Chain has failed validation, the signing scope for the ARC-Seal is modified as specified in Section 5.1.2.
Authenticated Received Chainが検証に失敗した場合、ARCシールの署名スコープはセクション5.1.2で指定されているように変更されることに注意してください。
In the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set header fields created by the MTA that detected the malformed chain, as if this newest ARC Set was the only set present.
Authenticated Received Chainが失敗した場合、ASヘッダーフィールドのb =値の署名スコープに含まれるヘッダーフィールドには、不正なチェーンを検出したMTAによって作成されたARCセットヘッダーフィールドのみを含める必要があります。存在する唯一のセットでした。
_INFORMATIONAL_: This approach is mandated to handle the case of a malformed or otherwise invalid Authenticated Received Chain. There is no way to generate a deterministic set of AS header fields (Section 5.1.1) in most cases of invalid chains.
_INFORMATIONAL_：このアプローチは、不正な形式の、または無効な認証済み受信チェーンのケースを処理するために必須です。無効なチェーンのほとんどの場合、確定的なASヘッダーフィールドのセット（セクション5.1.1）を生成する方法はありません。
A message can have only one Authenticated Received Chain on it at a time. Once broken, the chain cannot be continued, as the chain of custody is no longer valid, and responsibility for the message has been lost. For further discussion of this topic and the design restriction that prevents chain continuation or re-establishment, see [ARC-USAGE].
メッセージは、一度に1つの認証済み受信チェーンのみを持つことができます。いったん壊れると、管理のチェーンが無効になり、メッセージの責任が失われるため、チェーンを続行できません。このトピックとチェーンの継続または再確立を妨げる設計上の制限の詳細については、[ARC-USAGE]を参照してください。
ARC is not solely intended for perimeter MTAs. Any Internet Mail Handler MAY seal a message by adding a complete ARC Set, whether or not they have modified or are aware of having modified the message. For additional information, see Section 7.1.
ARCは、境界MTAのみを目的としたものではありません。すべてのインターネットメールハンドラーは、完全なARCセットを追加することでメッセージを封印できます（メッセージが変更されているかどうか、またはメッセージが変更されたことを認識しているかどうかは関係ありません）。詳細については、7.1項を参照してください。
The utility of an Authenticated Received Chain is limited to very specific cases. Authenticated Received Chains are designed to provide additional information to an Internet Mail Handler when evaluating messages for delivery in the context of authentication failures. Specifically:
Authenticated Received Chainのユーティリティは、非常に特殊なケースに限定されています。 Authenticated Received Chainsは、認証エラーのコンテキストでメッセージの配信を評価するときに、インターネットメールハンドラーに追加情報を提供するように設計されています。具体的には：
o Properly adding an ARC Set to a message does not damage or invalidate an existing Authenticated Received Chain.
o メッセージにARCセットを適切に追加しても、既存の認証済み受信チェーンが破損したり無効になったりすることはありません。
o Sealing an Authenticated Received Chain when a message has not been modified does not negatively affect the chain.
o メッセージが変更されていないときに認証済み受信チェーンを封印しても、チェーンに悪影響はありません。
o Validating a message exposes no new threat vectors (see Section 9).
o メッセージを検証しても、新しい脅威ベクトルは公開されません（セクション9を参照）。
o An ADMD may choose to seal all inbound messages whether or not a message has been modified or will be retransmitted.
o ADMDは、メッセージが変更されているか、再送信されるかどうかに関係なく、すべての受信メッセージをシールすることを選択できます。
A Validator performs the following steps, in sequence, to process an Authenticated Received Chain. Canonicalization, hash functions, and signature validation methods are imported from [RFC6376], Section 5.
バリデーターは、次の手順を順番に実行して、認証済み受信チェーンを処理します。正規化、ハッシュ関数、および署名検証メソッドは、[RFC6376]のセクション5からインポートされます。
1. Collect all ARC Sets currently attached to the message.
1. メッセージに現在添付されているすべてのARCセットを収集します。
* If there are none, the Chain Validation Status is "none", and the algorithm stops here.
* 何もない場合、チェーン検証ステータスは「なし」であり、アルゴリズムはここで停止します。
* The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist, the Chain Validation Status is "fail", and the algorithm stops here.
* メッセージに添付できるARCセットの最大数は50です。最大数を超える数が存在する場合、チェーン検証ステータスは「失敗」となり、アルゴリズムはここで停止します。
* In the following algorithm, the maximum discovered ARC instance value is referred to as "N".
* 次のアルゴリズムでは、検出された最大のARCインスタンス値は「N」と呼ばれます。
2. If the Chain Validation Status of the highest instance value ARC Set is "fail", then the Chain Validation Status is "fail", and the algorithm stops here.
2. 最高のインスタンス値ARCセットのチェーン検証ステータスが「失敗」の場合、チェーン検証ステータスは「失敗」となり、アルゴリズムはここで停止します。
3. Validate the structure of the Authenticated Received Chain. A valid ARC has the following conditions:
3. Authenticated Received Chainの構造を検証します。有効なARCには次の条件があります。
A. Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS).
A.各ARCセットには、3つのARCヘッダーフィールド（AAR、AMS、およびAS）が1つずつ含まれている必要があります。
B. The instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition.
B. ARCセットのインスタンス値は、ギャップや繰り返しのない1..Nからの連続シーケンスを形成する必要があります。
C. The "cv" value for all ARC-Seal header fields MUST NOT be "fail". For ARC Sets with instance values > 1, the values MUST be "pass". For the ARC Set with instance value = 1, the value MUST be "none".
C.すべてのARC-Sealヘッダーフィールドの「cv」値は「失敗」してはならない。インスタンス値が1より大きいARCセットの場合、値は「合格」である必要があります。インスタンス値= 1のARCセットの場合、値は「なし」でなければなりません。
* If any of these conditions are not met, the Chain Validation Status is "fail", and the algorithm stops here.
* これらの条件のいずれかが満たされない場合、チェーン検証ステータスは「失敗」となり、アルゴリズムはここで停止します。
4. Validate the AMS with the greatest instance value (most recent). If validation fails, then the Chain Validation Status is "fail", and the algorithm stops here.
4. 最大のインスタンス値（最新）でAMSを検証します。検証が失敗した場合、チェーン検証ステータスは「失敗」となり、アルゴリズムはここで停止します。
5. _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by validating each prior AMS beginning with N-1 and proceeding in decreasing order to the AMS with the instance value of 1:
5. _OPTIONAL_：N-1で始まり、インスタンス値が1のAMSまで降順で先行する各AMSを検証して、ARCセットから「最も古いパス」の値を決定します。
A. If an AMS fails to validate (for instance value "M"), then set the oldest-pass value to the lowest AMS instance value that passed (M+1), and go to the next step (there is no need to check any other (older) AMS header fields). This does not affect the validity of the Authenticated Received Chain.
A. AMSが検証に失敗した場合（たとえば、値 "M"）、最も古いパスの値を、渡された最小のAMSインスタンス値（M + 1）に設定し、次の手順に進みます（必要はありません）他の（古い）AMSヘッダーフィールドを確認してください）。これは、Authenticated Received Chainの有効性には影響しません。
B. If all AMS header fields verify, set the oldest-pass value to zero (0).
B.すべてのAMSヘッダーフィールドが確認されたら、最も古いパスの値をゼロ（0）に設定します。
6. Validate each AS beginning with the greatest instance value and proceeding in decreasing order to the AS with the instance value of 1. If any AS fails to validate, the Chain Validation Status is "fail", and the algorithm stops here.
6. 最大のインスタンス値で始まり、インスタンス値が1のASから降順で各ASを検証します。いずれかのASが検証に失敗した場合、チェーン検証ステータスは「失敗」となり、アルゴリズムはここで停止します。
7. If the algorithm reaches this step, then the Chain Validation Status is "pass", and the algorithm is complete.
7. アルゴリズムがこのステップに到達した場合、チェーン検証ステータスは「合格」であり、アルゴリズムは完了です。
The end result of this validation algorithm SHOULD be included within the Authentication-Results header field for the ADMD.
この検証アルゴリズムの最終結果は、ADMDのAuthentication-Resultsヘッダーフィールドに含める必要があります（SHOULD）。
As with a DKIM signature ([RFC6376], Section 6.3) that fails verification, a message with an Authenticated Received Chain with a Chain Validation Status of "fail" MUST be treated the same as a message with no Authenticated Received Chain.
検証に失敗したDKIM署名（[RFC6376]、セクション6.3）と同様に、チェーン検証ステータスが「失敗」の認証済み受信チェーンのメッセージは、認証済み受信チェーンのないメッセージと同じように処理する必要があります。
_INFORMATIONAL_: Recipients of an invalid or failing Authenticated Received Chain can use that information as part of a wider handling context. ARC adoption cannot be assumed by intermediaries; many intermediaries will continue to modify messages without adding ARC seals.
_INFORMATIONAL_：無効または失敗した認証済み受信チェーンの受信者は、より広い処理コンテキストの一部としてその情報を使用できます。仲介業者はARCの採用を想定できません。多くの仲介者は、ARCシールを追加せずにメッセージを変更し続けます。
Authenticated Received Chains represent the traversal of messages through one or more intermediaries. All errors, including DNS failures, become unrecoverable and are considered permanent.
Authenticated Received Chainsは、1つ以上の仲介者を介したメッセージの通過を表します。 DNS障害を含むすべてのエラーは回復不能になり、永続的なものと見なされます。
Any error validating an Authenticated Received Chain results in a Chain Validation Status of "fail". For further discussion of this topic and the design restriction that prevents chain continuation or re-establishment, see [ARC-USAGE].
Authenticated Received Chainの検証中にエラーが発生すると、Chain Validation Statusは「fail」になります。このトピックとチェーンの継続または再確立を妨げる設計上の制限の詳細については、[ARC-USAGE]を参照してください。
5.2.2. Responding to ARC Validation Failures during the SMTP Transaction
5.2.2. SMTPトランザクション中のARC検証エラーへの対応
If an ARC Validator determines that the incoming message fails ARC validation, the Validator MAY signal the breakage through the extended SMTP response code 5.7.29 ("ARC validation failure") and the corresponding SMTP basic response code. Because ARC failures are likely only to be detected in the context of other underlying authentication mechanism failures, Validators MAY use the more general 5.7.26 ("Multiple authentication checks failed") instead of the ARC-specific code.
ARC Validatorが受信メッセージがARC検証に失敗したと判断した場合、Validatorは拡張SMTP応答コード5.7.29（「ARC検証失敗」）と対応するSMTP基本応答コードを介して破損を通知できます（MAY）。 ARCの失敗は他の基本的な認証メカニズムの失敗のコンテキストでのみ検出される可能性が高いため、バリデーターはARC固有のコードの代わりに、より一般的な5.7.26（「複数の認証チェックに失敗しました」）を使用できます（MAY）。
Chain Validation Status (described in Section 4.4) is communicated via Authentication-Results (and AAR) header fields using the authentication method "arc". This authentication method is described in Section 10.1.
チェーン検証ステータス（セクション4.4で説明）は、認証方法「arc」を使用して、Authentication-Results（およびAAR）ヘッダーフィールドを介して通信されます。この認証方法については、10.1項で説明しています。
If necessary data is available, the ptypes and properties defined in Section 10.2 SHOULD be recorded in an Authentication-Results header field:
必要なデータが利用可能な場合は、セクション10.2で定義されているptypeとプロパティをAuthentication-Resultsヘッダーフィールドに記録する必要があります（SHOULD）。
o smtp.remote-ip - The address of the connection-initiating SMTP server, from which the message is being relayed.
o smtp.remote-ip-メッセージのリレー元である、接続を開始するSMTPサーバーのアドレス。
o header.oldest-pass - The instance number of the oldest AMS that still validates, or 0 if all pass.
o header.oldest-pass-まだ検証している最も古いAMSのインスタンス番号。すべて合格した場合は0。
This section explores several message handling use cases that are addressed by ARC.
このセクションでは、ARCが対応するいくつかのメッセージ処理の使用例について説明します。
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.
中間ADMDがARCセットをメッセージのAuthenticated Received Chainに追加する（または最初のARCセットを作成する）と、ADMDはその認証評価をメッセージ処理パス内の次のARC参加ADMDに伝達します。
If ARC-enabled ADMDs are trusted, Authenticated Received Chains can be used to bridge administrative boundaries.
ARCが有効なADMDが信頼されている場合、認証された受信チェーンを使用して管理境界をブリッジできます。
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).
スパム対策、マルウェア対策、フィッシング対策のスキャンを実行するメッセージサービスを利用できます。このようなサービスは通常、悪意のあるコンテンツを削除し、メッセージ内のHTTPリンクをサニタイズされたリンクに置き換え、メッセージスキャンサービスの機能を宣伝するメッセージにフッターを添付します。これらの変更により、ほとんどの場合、署名ベースの認証（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).
スキャンサービスでは通常、クライアントがインターネットドメインのMXレコードをスキャンサービスにポイントする必要があります。インターネットドメイン宛てのメッセージは、最初にスキャンサービスに配信されます。スキャンが実行されると、メッセージはクライアント自身のメール処理インフラストラクチャにルーティングされます。この方法でメッセージを再ルーティングすると、ほとんどの場合、パスベースの認証（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.
メッセージスキャンサービスは、Authenticated Received Chainsをメッセージに添付して、クライアントADMDに認証評価を伝達できます。クライアントは、クライアントのインフラストラクチャがインターネットドメインのMXレコードの元の宛先であるかのようにメッセージを処理しながら、メッセージスキャンサービスを利用できます。
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.
大規模なメッセージ処理インフラストラクチャは、多くの場合、階層間の認証情報を破壊する可能性のあるいくつかの処理階層に分割されています。たとえば、大規模なサイトでは、接続処理とIPベースのレピュテーションフィルタリングの実施に特化したMTAのクラスターを維持できます。 MTAのセカンダリクラスタは、メッセージのコンテンツベースの処理専用に最適化されている場合があります。
Authenticated Received Chains can be used to communicate authentication assessment between processing tiers.
Authenticated Received Chainsを使用して、処理階層間で認証評価を伝達できます。
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.
メーリングリストはメッセージの配信を受け取り、サブスクライバーに再投稿します。認証関連のメーリングリストの問題の詳細については、[RFC7960]のセクション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.
メーリングリストサービスはARCを実装して、リストのサブスクライバーベースに送信された投稿メッセージの認証評価を伝達できます。メーリングリストのサブスクライバーのADMDは、Authenticated Received Chainを使用して、メーリングリストを処理する前に、元のメッセージの認証評価を決定できます。
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).
多くの場合、仲介者はコンテンツの変更を通じて認証を破り、パスベースの認証（SPFなど）を妨害し、認証結果を取り除きます（MTAがAuthentication-Resultsヘッダーフィールドを削除する場合）。
Authenticated Received Chains allow ARC Validators to:
Authenticated Received Chainsを使用すると、ARCバリデーターは次のことができます。
1. identify ARC-enabled ADMDs that break authentication while processing messages and
1. メッセージの処理中に認証を解除するARC対応ADMDを特定し、
2. gain extended visibility into the authentication-preserving abilities of ADMDs that relay messages into ARC-enabled ADMDs.
2. ARCが有効なADMDにメッセージをリレーするADMDの認証保持機能の可視性を拡大します。
Through the collection of ARC-related data, an ADMD can identify handling paths that have broken authentication.
ADMDは、ARC関連のデータを収集することで、認証に失敗した処理パスを特定できます。
An Authenticated Received Chain allows an Internet Mail Handler to potentially base decisions of message disposition on authentication assessments provided by different ADMDs.
Authenticated Received Chainを使用すると、インターネットメールハンドラーは、さまざまなADMDによって提供される認証評価に基づいてメッセージの処理を決定することができます。
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].
DMARCは、DMARCの調整に失敗したメッセージを拒否または隔離するようドメイン所有者が電子メール受信者に要求できるポリシーモデルを導入します。 DMARCと間接的な電子メールフロー間の相互運用性の問題は、[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.
Authenticated Received Chainsにより、DMARCプロセッサは他のADMDによって提供される認証評価を考慮することができます。ローカルポリシーの問題として、DMARCプロセッサは、メッセージがDMARCに準拠しているかどうかを判断するときに、認証済み受信チェーンによって提供される認証評価を受け入れることを選択できます（MAY）。
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.
Authenticated Received Chainがメッセージの後処理を決定するために使用される場合、DMARCプロセッサは、セクション7.2.2で説明されているように、このローカルポリシー決定をドメイン所有者に通知できます。
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:
DMARC対応のレシーバーは、ARC検証がDMARC関連のローカルポリシー決定に影響を与える時期を示します。 ARCが有効なハンドラーがDMARCレポートを生成する場合、「local_policy」の理由とコメント文字列（[RFC7489]の付録Cによる）を追加して、ARCがローカルポリシーの決定に及ぼす影響を示します（リストを含む）。 ARC検証中に発見されたデータの数。
o the Chain Validation Status,
o チェーン検証ステータス、
o the domain and selector for each AS, and
o 各ASのドメインとセレクター
o the originating IP address from the first ARC Set.
o 最初のARCセットからの発信元IPアドレス。
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).
上記のDMARC XMLレポートフラグメントの例では、特定の検証済みARCセットに関連するデータが配列構文を使用して列挙されています（たとえば、「as [2]」はインスタンス値が2のASヘッダーフィールドを意味します）。 d2.exampleはARCセット＃2（i = 2）のシーリングドメインであり、d1.exampleはARCセット＃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.
中間メッセージハンドラーのレポート方法に応じて、ドメイン所有者は1つのメッセージに対して複数のDMARCレポートを受け取る場合があります。 DMARCレポートの受信者はこの動作を認識し、必要な調整を行う必要があります。
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.
Authenticated Received Chainは、メッセージのハンドラーの検証可能なレコードを提供します。このレコードには、IPアドレスやドメイン名などの個人を特定できる情報が含まれる場合があります。このような情報は、「Received」ヘッダーフィールドなど、既存の非ARC関連ヘッダーフィールドにも含まれています。
The Security Considerations of [RFC6376] and [RFC8601] apply directly to this specification.
[RFC6376]および[RFC8601]のセキュリティに関する考慮事項は、この仕様に直接適用されます。
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:
他のドメインベースの認証技術（SPF、DKIM、DMARCなど）と同様に、ARCはメッセージのセマンティックコンテンツについて何の主張もしません。検証されたARCチェーンを含む受信メッセージは、（インスタンスNで）次の証拠を提供します。
1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body,
1. シーリングドメイン（ARC-Seal [N] d =）は、この本文でメッセージを送信しました。
2. the authentication assessment reported in the ARC-Authentication-Results was determined upon receipt of the corresponding message at the sealing domain, and
2. ARC-Authentication-Resultsで報告される認証評価は、シーリングドメインで対応するメッセージを受信したときに決定されました。
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.
3. 前のARCチェーン（1..N-1）（検証ステータスがcvフィールドで報告されている）は、受信および評価されたメッセージに存在していました。
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.
Authenticated Received Chainsをメッセージに含めると、ヘッダーフィールドの合計サイズが大きくなるため、古いMTAまたは制約付きMTAで問題が発生する可能性があります。大きなヘッダーフィールドブロックは、通常、このようなMTAの配信の失敗やその他の停止シナリオを引き起こす可能性があります。 ARC自体は問題を引き起こしません。
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:
N個のARCセットで構成される認証済み受信チェーンの検証には、最大2 * N個のDNSクエリが必要になる場合があります（クエリの総数を増やす可能性のあるDNSリダイレクトメカニズムは含まれません）。これは2つの考慮事項につながります。
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.
1. 攻撃者は、意図された被害者のドメインを含むARCセットの組み立てられたシーケンスでメッセージをARC参加者に送信することができ、障害が発見されるまで、それらすべてが参加者に照会されます。 DNSキャッシングと署名値の偽造の困難さにより、攻撃者の制御下にあるドメインへのこの負荷の範囲が制限されます。クエリトラフィックパターン分析は、ダウンストリーム検証ADMDインフラストラクチャに関する情報を公開する場合があります。
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.
2. DKIMは署名ごとに1つのDNSクエリのみを実行しますが、ARCは（チェーンごとに）多くのDNSクエリを導入できます。キャッシュがないと、DNS応答が遅いため、検証システムでSMTPタイムアウトとバックログ配信キューが発生する可能性があります。これは、DoS攻撃として悪用される可能性があります。
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.
受信者は、他のすべてのメッセージに同じ疑惑が適用された、Authenticated Received Chainsを含むメッセージを扱うように警告されています。これには、適切なコンテンツのスキャンや、悪意のある可能性のあるコンテンツのその他のチェックが含まれます。
ARC authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness.
ARCは、一部の電子メール処理俳優の身元を認証します。彼らの信頼性の評価は行いません。
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.
メッセージ認証の通過がメッセージの安全性を示すものではないのと同様に、ARCのメカニズムを通じてその情報を転送することも、メッセージの安全性を示すものではありません。 ARCが有効なすべてのADMDが信頼されている場合でも、ADMDが危険にさらされているか、安全でないコンテンツを見逃しているか、メッセージを適切に認証していない可能性があります。
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.
受信者は、ARCチェーンのすべてのシーラーを疑いを持って扱うように警告されています。検証済みのDKIM署名と同様に、メッセージ処理の責任はシーリングドメインにありますが、そのシーラーが悪意のある俳優であるかどうかは、認証メカニズムの範囲外です。 ARCは認証が失敗した場合のメッセージ配信を支援するため、悪意のある俳優がスパムやその他の詐欺メッセージを封印して配信を支援できないように、ARCシーラーを疑いを持って扱う必要があります。
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.
ARCはDKIMから大きく継承しているため、同様の攻撃ベクトルがあります。特に、[RFC6376]のセクション8.6で説明されているリプレイ攻撃は、ARCの連鎖ステータスによって増幅される可能性があります。 ARCリプレイ攻撃では、悪意のあるアクターがそのままの状態でARCチェーンを渡し、最新のAMSまたはASを無効にする変更を行わずに、ARCチェーンを多くの受信者に再送信します。受信者への影響は、より多くのDNSルックアップと署名評価になります。この攻撃の範囲は、DNSクエリをキャッシュし、[RFC6376]のセクション5.4.1の同じ署名範囲ガイダンスに従うことで制限できます。
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).
このドキュメントでは、1つの新しい認証方法といくつかのステータスコード（セクション10.1）、新しいptypesとプロパティ（セクション10.2）、3つの新しいヘッダーフィールド（セクション10.3）、および新しい列挙ステータスコード（セクション10.4）を定義しています。
Per this document, IANA has added one authentication method with three codes to the IANA "Email Authentication Result Names" registry:
このドキュメントに従って、IANAはIANAの「Email Authentication Result Names」レジストリに3つのコードを持つ1つの認証方法を追加しました。
o Auth Method: arc Code: "none", "pass", "fail" Specification: RFC 8617, Section 4.4 Status: active
o 認証方法：アークコード：「none」、「pass」、「fail」仕様：RFC 8617、セクション4.4ステータス：アクティブ
Per this document, IANA has added the following to the "Email Authentication Methods" registry, which is defined in [RFC8601]:
このドキュメントに従って、IANAは、[RFC8601]で定義されている「Email Authentication Methods」レジストリに以下を追加しました。
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 方法：arc定義：RFC 8617、セクション6 ptype：smtpプロパティ：remote-ip値：発信SMTP接続のIPアドレス（v4またはv6）ステータス：アクティブバージョン：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
o 方法：弧定義：RFC 8617、セクション6 ptype：ヘッダープロパティ：oldest-pass値：最も古い検証AMSのインスタンスID、またはすべてが合格した場合は0（セクション5.2を参照）ステータス：アクティブバージョン：1
Per this document, IANA has added the following three new header fields to the "Permanent Message Header Field Names" registry:
このドキュメントに従って、IANAは次の3つの新しいヘッダーフィールドを「Permanent Message Header Field Names」レジストリに追加しました。
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 ヘッダーフィールド名：ARC-Seal該当プロトコル：メールステータス：試験的な作成者/変更コントローラー：IETF仕様ドキュメント：RFC 8617関連情報：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 ヘッダーフィールド名：ARC-Message-Signature該当プロトコル：メールステータス：実験的な作成者/変更コントローラー：IETF仕様ドキュメント：RFC 8617関連情報：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
o ヘッダーフィールド名：ARC-Authentication-Results該当するプロトコル：メールステータス：試験的な作成者/変更コントローラー：IETF仕様ドキュメント：RFC 8617関連情報：RFC 8601
Per this document, IANA has added the following value to the "Enumerated Status Codes" registry:
このドキュメントに従って、IANAは「列挙型ステータスコード」レジストリに次の値を追加しました。
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
o コード：X.7.29サンプルテキスト：ARC検証エラー関連する基本ステータスコード：550説明：このステータスコードは、メッセージがARC検証に失敗した場合に返されることがあります。参照：RFC 8617提出者：K.アンデルセン変更コントローラー：IESG
The ARC protocol is designed to address common interoperability issues introduced by intermediate message handlers. Interoperability issues are described in [RFC6377] and [RFC7960].
ARCプロトコルは、中間メッセージハンドラーによって発生する一般的な相互運用性の問題に対処するように設計されています。相互運用性の問題は、[RFC6377]と[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.
ARCプロトコルは時間の経過とともにインターネットメールハンドラーによって実装されるため、意図した利点を達成する上でのプロトコルの成功を判断するには、以下を評価する必要があります。
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.
Authenticated Received Chainsの存在により正当なメッセージを処理する際の意思決定が改善され、具体的にはヒューリスティックなアプローチを使用した場合と同等以上の配信率が得られる場合、ARCは成功します。
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.
ARCは、悪用の重要な新しいベクターを導入せずに機能する必要があります（セクション9を参照）。予期しないベクターがARCによって有効にされている場合、このプロトコルは失敗します。 ARCが構築しているメールプロトコルに固有の弱点（DKIMリプレイ攻撃やその他の既知の問題など）は、この仕様に起因する新しいベクターではないことに注意してください。
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.
次の未解決の質問は学術的なものであり、このドキュメントの公開時点では明確な回答はありません。ただし、追加の展開では、それらの一部またはすべてに応答するために必要なデータを収集できる必要があります。
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.
データを収集して、配信の決定を行うか、悪意のあるチェーンを作成または再生しようとする悪意のあるアクターをキャッチするために、ASがAMSを超える価値を提供するかどうかを示す必要があります。
11.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in ARC Sets
11.3.2. ARCセット内の複数のセレクターやドメインからの使用法や信号
Any selectors and/or (sub)domains (under the control of the sealing ADMD) may be used for ARC header field signatures.
（シーリングADMDの制御下にある）セレクターや（サブ）ドメインは、ARCヘッダーフィールドの署名に使用できます。
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.
実装者はARC Setヘッダーフィールドにさまざまなセレクターやドメインを使用することを選択できますが、ワーキンググループ内ではそのような使用法に対する賛成論や反対論はありません。そのため、このプロトコルの実験的定義に最大限の自由を与えることを選択しました。
Wider deployment experience and higher volumes of traffic may show whether this is useful.
展開の経験が広く、トラフィック量が多い場合は、これが有用かどうかがわかる場合があります。
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.
Authenticated Received Chainsが長いほど、チェーンを検証するためのキーを取得するためにより多くのクエリが必要になります。これはセキュリティの問題であるとは考えられていませんが（セクション9.2を参照）、実際にどの程度のオーバーヘッドが追加されるかは不明です。これは、DKIM仕様の開発時に議論された初期処理とクエリ負荷の問題の一部に似ています。
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.
Authenticated Received Chainsの処理がDNSに与える影響とともに、有効なAuthenticated Received Chainsで見つかった使用可能な長さと長さの分布をよりよく理解するために、データを収集する必要があります。
An effective operational maximum will have to be developed through deployment experience in the field.
効果的な運用上の最大値は、現場での展開経験を通じて開発する必要があります。
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.
AARの情報がメッセージの配信と拒否の違いを生む可能性のあるエッジケースがいくつかあります。たとえば、ARCで封印されているが、独自の初期DMARC実施を行わない有名なメーリングリストがある場合、この知識を持つインターネットメールハンドラは、対応するAARに表示される認証情報に基づいて配信を決定できます。ヘッダーフィールド。
Certain trace information in the AAR is useful/necessary in the construction of DMARC reports.
AARの特定のトレース情報は、DMARCレポートの作成に役立ちます。
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.
そのようなシステムの多くは、悪用者によるゲームを防ぐために意図的に専有または機密であるため、この特定の質問に確実に回答することは現実的ではない場合があります。攻撃の進化する性質は、「有用な」情報の状況を時間とともに変化させる可能性もあります。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<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>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<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>.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<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>.
[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>.
[RFC6377] Kucherawy、M。、「DomainKeys Identified Mail（DKIM）and Mailing Lists」、BCP 167、RFC 6377、DOI 10.17487 / RFC6377、2011年9月、<https://www.rfc-editor.org/info/rfc6377 >。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、DOI 10.17487 / RFC6532、2012年2月、<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>.
[RFC7208] Kitterman、S。、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<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>.
[RFC7405] Kyzivat、P。、「ABNFでの大文字と小文字を区別する文字列のサポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8601] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 8601、DOI 10.17487 / RFC8601、2019年5月、<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>.
[RFC8616] Levine、J。、「国際化メールのメール認証」、RFC 8616、DOI 10.17487 / RFC8616、2019年6月、<https://www.rfc-editor.org/info/rfc8616>。
[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-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、2019年3月。
[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.
[ARC-USAGE]ジョーンズ、S、エド。 And K. Andersen、「Recommended Usage of the Authenticated Received Chain（ARC）」、Work in Progress、draft-ietf-dmarc-arc-usage-07、2019年4月。
[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>.
[RFC7489] Kucherawy、M.、Ed。およびE. Zwicky、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https://www.rfc-editor.org/info/ rfc7489>。
[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>.
[RFC7960]マーティン、F。、編、リア、E、編、ドレーゲン。 Ed。、T.、Zwicky、E.、Ed。、およびK. Andersen、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）と間接的な電子メールフロー間の相互運用性の問題」、RFC 7960、DOI 10.17487 / RFC7960、2016年9月、<https://www.rfc-editor.org/info/rfc7960>。
The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.
ARCフレームワークの仕様は、次の高レベルの目標、セキュリティに関する考慮事項、および実際の運用要件によって決定されます。
o Provide a verifiable "chain of custody" for email messages;
o 電子メールメッセージに検証可能な「管理の連鎖」を提供します。
o Not require changes for originators of email;
o メールの発信者の変更は不要です。
o Support the verification of the ARC header field set by each hop in the handling chain;
o 処理チェーンの各ホップによって設定されたARCヘッダーフィールドの検証をサポートします。
o Work at Internet scale; and
o インターネット規模で働く;そして
o Provide a trustable mechanism for the communication of Authentication-Results across trust boundaries.
o 信頼境界を越えてAuthentication-Resultsを通信するための信頼できるメカニズムを提供します。
ARC is not a trust framework. Users of the ARC header fields are cautioned against making unsubstantiated conclusions when encountering a "broken" ARC sequence.
ARCは信頼フレームワークではありません。 ARCヘッダーフィールドのユーザーは、「壊れた」ARCシーケンスに遭遇したときに根拠のない結論を下すことに対して警告されます。
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
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.
こんにちは、これはテストメッセージです。 --J。
Acknowledgments
謝辞
This document originated with the work of OAR-Dev Group.
このドキュメントは、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.
著者は、すべての参加者、特にJ.トレントアダムス、マークブラッドショー、アレックスブロットマン、グレッグコルバーン、デイブクロッカー、ティムドレーゲン、マークからの進行中のヘルプと示唆に富む議論について、OAR-Devとその後のDMARC WGに感謝します。アイスラー、ピーターゴールドスタイン、ブロンゴンドワナ、マイクハマー、マイクジョーンズ、スティーブジョーンズ、スコットキッターマン、バリーレイバ、フランクマーティン、ジョンレイグラント、ポールロック、ジーンシューマン、テリージンク、エリザベスズウィッキー。
Grateful appreciation is extended to the people who provided feedback through the arc-discuss mailing list.
arc-discussメーリングリストを通じてフィードバックを提供してくれた人々に感謝の意を表します。
Authors' Addresses
著者のアドレス
Kurt Andersen LinkedIn 1000 West Maude Ave Sunnyvale, California 94085 United States of America
カート・アンデルセンLinkedIn 1000 West Maude Aveサニーベール、カリフォルニア州94085アメリカ合衆国
Email: kurt+ietf@drkurt.com
Brandon Long (editor) Google
Brandon Long（editor）Google
Email: blong@google.com
Seth Blank (editor) Valimail
Seth Blanc（編集）Valimile
Email: seth@valimail.com
Murray Kucherawy (editor) TDP
マレー・クチェラウィ（編集者）TDP
Email: superuser@gmail.com