[要約] RFC 7960は、DMARCと間接的なメールフローの間の相互運用性の問題について説明しています。このRFCの目的は、DMARCの実装における問題を特定し、解決策を提供することです。
Internet Engineering Task Force (IETF) F. Martin, Ed.
Request for Comments: 7960 LinkedIn
Category: Informational E. Lear, Ed.
ISSN: 2070-1721 Cisco Systems GmbH
T. Draegen, Ed.
dmarcian, inc.
E. Zwicky, Ed.
Yahoo
K. Andersen, Ed.
LinkedIn
September 2016
Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
ドメインベースのメッセージ認証、レポート、および準拠（DMARC）と間接的な電子メールフロー間の相互運用性の問題
Abstract
概要
Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.
ドメインベースのメッセージ認証、レポート、および適合性（DMARC）は、ドメインレベルのポリシーと、電子メールメッセージの検証、廃棄、およびレポートに関する設定を表現するためのメカニズムを導入します。ただし、DMARCメカニズムは、メッセージが作成者の管理ドメインから最終的な受信者に直接流れない場合に、破壊的な相互運用性の問題を引き起こす可能性があります。これらの電子メールフローは総称して「間接電子メールフロー」と呼ばれます。このドキュメントでは、これらの相互運用性の問題について説明し、それらに対処するための可能な方法を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate 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 http://www.rfc-editor.org/info/rfc7960.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7960で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Conventions .......................................4
2. Causes of Interoperability Issues ...............................4
2.1. Identifier Alignment .......................................4
2.1.1. DKIM Identifier(s) ..................................5
2.1.2. SPF Identifier(s) ...................................6
2.1.3. Multiple RFC5322.From Addresses .....................6
2.2. Message Forwarding .........................................6
2.3. Message Modification .......................................7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
3.1. Message Handling System ....................................8
3.1.1. Message Submission Agents ...........................8
3.1.2. Message Transfer Agents .............................9
3.1.2.1. Message Encoding ...........................9
3.1.2.2. Header Standardization ....................10
3.1.2.3. Content Validation ........................10
3.1.3. Message Delivery Agents ............................10
3.2. Mediators .................................................11
3.2.1. Alias ..............................................11
3.2.2. ReSenders ..........................................12
3.2.3. Mailing Lists ......................................12
3.2.3.1. Mailing List Operational Effects ..........13
3.2.4. Gateways ...........................................13
3.2.5. Boundary Filters ...................................14
3.3. Combinations ..............................................15
4. Possible Mitigations of Interoperability Issues ................15
4.1. Mitigations in Current Use ................................16
4.1.1. Mitigations for Senders ............................16
4.1.1.1. Identifier Alignment ......................16
4.1.1.2. Message Modification ......................17
4.1.2. Mitigations for Receivers ..........................17
4.1.2.1. Identifier Alignment ......................17
4.1.2.2. Policy Override ...........................17
4.1.3. Mitigations for ReSenders ..........................18
4.1.3.1. Changes to the RFC5322.From ...............18
4.1.3.2. Avoiding Message Modification .............18
4.1.3.3. Mailing Lists .............................18
4.2. Proposed and In-Progress Mitigations ......................20
4.2.1. Getting More Radical: Requiring New
Communication Paths between MUAs ...................21
5. Security Considerations ........................................21
6. References .....................................................22
6.1. Normative References ......................................22
6.2. Informative References ....................................23
Appendix A. Example SPF Bounce ...................................24
A.1. Initial Message ...........................................24
A.2. Notification Message ......................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................27
DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism, especially when employed with restrictive policies, encounters several different types of interoperability issues due to third-party message sourcing, message transformation, or rerouting. In particular, DMARC with restrictive policies causes problems for many Mailing Lists.
DMARC [RFC7489]は、ドメインレベルのポリシーと、メッセージの検証、処理、およびレポートに関する設定を表現するためのメカニズムを導入しています。 DMARCメカニズムは、特に制限付きポリシーで採用されている場合、サードパーティのメッセージソース、メッセージ変換、または再ルーティングが原因で、いくつかの異なるタイプの相互運用性の問題が発生します。特に、制限付きのポリシーを使用するDMARCは、多くのメーリングリストで問題を引き起こします。
At the time of writing this document, the DMARC base specification has been published as Informational RFC 7489 [RFC7489] and has seen significant deployment within the email community.
このドキュメントの執筆時点で、DMARC基本仕様はInformational RFC 7489 [RFC7489]として公開されており、電子メールコミュニティ内での重要な展開が確認されています。
Cases in which email does not flow directly from the author's administrative domain to the recipient's domain(s) are collectively referred to in this document as "indirect email flows". Due to existing and increasing adoption of DMARC, the impact of DMARC-based email rejection policies on indirect email flows can be significant for a select subset of general email traffic.
この文書では、電子メールが作成者の管理ドメインから受信者のドメインに直接流れない場合を総称して、「間接的な電子メールフロー」と呼びます。 DMARCの採用が増加しているため、DMRCベースの電子メール拒否ポリシーが間接的な電子メールフローに与える影響は、一般的な電子メールトラフィックの選択したサブセットにとって重要な場合があります。
Several known causes of interoperability issues are presented, followed by a description of components within the Internet Mail Architecture [RFC5598] where interoperability issues can arise.
相互運用性の問題のいくつかの既知の原因が提示され、相互運用性の問題が発生する可能性があるインターネットメールアーキテクチャ[RFC5598]内のコンポーネントの説明が続きます。
Finally, known and possible methods for addressing interoperability issues are presented. There are often multiple ways to address any given interoperability issue. While this document strives to be comprehensive in its review, it should not be treated as complete.
最後に、相互運用性の問題に対処するための既知の可能な方法を紹介します。特定の相互運用性の問題に対処するには、多くの方法があります。このドキュメントはレビューで包括的であることを目指していますが、完全なものとして扱うべきではありません。
Note that some practices that are in use at the time of this document may or may not be "best practices", especially as future standards evolve.
このドキュメントの時点で使用されている一部のプラクティスは、特に将来の標準が発展するにつれて、「ベストプラクティス」になる場合とそうでない場合があることに注意してください。
The notation used in this document for structured fields is taken from [RFC5598], Section 1.3.
このドキュメントで構造化フィールドに使用されている表記法は、[RFC5598]のセクション1.3からの引用です。
The term "notification message" ([RFC5321], Section 4.5.5) is used to refer to a message with a null RFC5321.MailFrom.
「通知メッセージ」（[RFC5321]、セクション4.5.5）という用語は、RFC5321.MailFromがnullのメッセージを指すために使用されます。
The terms "Organizational Domain" and "Authenticated Identifiers" are specified in DMARC ([RFC7489], Section 3).
「組織ドメイン」および「認証済み識別子」という用語は、DMARC（[RFC7489]、セクション3）で指定されています。
All words that begin with capital letters take their formal meanings from these references.
大文字で始まるすべての単語は、これらの参照から正式な意味を持ちます。
Interoperability issues between DMARC and indirect email flows arise when conformance to the DMARC specification leads a receiving implementation to apply DMARC-based policy restrictions to messages that are both compliant with the architecture as specified in [RFC5598] and viewed as legitimate by the intended Recipient.
DMARC仕様への準拠により受信実装がDMARCベースのポリシー制限を[RFC5598]で指定されたアーキテクチャに準拠し、意図された受信者によって正当であると見なされるメッセージに適用するように導いた場合、DMARCと間接電子メールフロー間の相互運用性の問題が発生します。
Note that domains that assert a "p=none" policy and email messages that pass standard DMARC validation do not have any interoperability issues.
「p = none」ポリシーを表明するドメインと標準のDMARC検証に合格する電子メールメッセージには、相互運用性の問題がないことに注意してください。
Email messages that do not conform to IETF email specifications but are considered legitimate by the intended Recipients are not discussed in this document.
IETFの電子メール仕様に準拠していないが、対象の受信者によって正当であると見なされる電子メールメッセージについては、このドキュメントでは説明しません。
The rest of this section describes several conceptual causes of interoperability issues.
このセクションの残りの部分では、相互運用性の問題のいくつかの概念的な原因について説明します。
Note to operators and administrators: The identifiers that are used by the Sender Policy Framework (SPF) are technical components of the transport process for SMTP. They may or may not, as described below, bear a meaningful relationship to the content or source of the message itself. This "relationship by proximity" can be a point of confusion for non-technical end users, either recipients or senders.
オペレーターと管理者への注意：Sender Policy Framework（SPF）で使用される識別子は、SMTPのトランスポートプロセスの技術コンポーネントです。それらは、以下で説明するように、メッセージ自体のコンテンツまたはソースとの意味のある関係を持つ場合とそうでない場合があります。この「近接性による関係」は、技術者ではないエンドユーザー（受信者または送信者）にとって混乱のポイントになる可能性があります。
DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF [RFC7208] to perform message source validation. The DMARC [RFC7489] specification refers to source domains that are validated by DKIM or SPF as "Authenticated Identifiers". To be used by DMARC, an "Authenticated Identifier" must also be related to the domain found in the message's RFC5322.From header field [RFC5322]. This relationship between an Authenticated Identifier's domain and the domain of the RFC5322.From is referred to as "Identifier Alignment".
DMARCは、DomainKeys Identified Mail（DKIM）[RFC6376]およびSPF [RFC7208]を使用してメッセージソースの検証を実行します。 DMARC [RFC7489]仕様では、DKIMまたはSPFによって検証されたソースドメインを「認証済み識別子」と呼びます。 DMARCで使用するには、「Authenticated Identifier」もメッセージのRFC5322.Fromヘッダーフィールド[RFC5322]にあるドメインに関連付けられている必要があります。認証済み識別子のドメインとRFC5322.Fromのドメインの間のこの関係は、「識別子の配置」と呼ばれます。
DMARC allows for Identifier Alignment to be determined in two different modes: strict and relaxed. Strict mode requires an exact match between the domain of any of the Authenticated Identifiers and the message's RFC5322.From header field [RFC5322]. Relaxed mode allows for Identifier Alignment if Authenticated Identifiers and the message's RFC5322.From header field [RFC5322] share the same Organizational Domain. In general, DMARC interoperability issues are the same for both strict and relaxed alignment, but strict alignment constrains the possible solutions because of the more rigorous matching requirement. Some of the mitigations described in this document only work with the relaxed mode of Identifier Alignment.
DMARCでは、識別子の配置を2つの異なるモード（厳密モードと緩和モード）で決定できます。厳格モードでは、認証済み識別子のドメインとメッセージのRFC5322.Fromヘッダーフィールド[RFC5322]の完全一致が必要です。リラックスモードでは、認証済み識別子とメッセージのRFC5322.Fromヘッダーフィールド[RFC5322]が同じ組織ドメインを共有している場合、識別子の整列が可能です。一般に、DMARCの相互運用性の問題は、厳密なアライメントと緩和されたアライメントの両方で同じですが、厳密なアライメントは、厳密なマッチング要件のため、可能な解決策を制約します。このドキュメントで説明されている緩和策の一部は、Identifier Alignmentのrelaxedモードでのみ機能します。
DKIM provides a cryptographic means for one or more domain identifiers to be associated with a particular message. As a standalone technology, DKIM identifiers are not required to be related to the source of the message's content. However, for a DKIM identifier to align in DMARC, the signing domain of a valid signature must be part of the same Organizational Domain as the domain in the RFC5322.From header field [RFC5322].
DKIMは、1つ以上のドメイン識別子を特定のメッセージに関連付けるための暗号化手段を提供します。スタンドアロンテクノロジーとして、DKIM識別子はメッセージのコンテンツのソースに関連付けられている必要はありません。ただし、DKIM識別子をDMARCで調整するには、有効な署名の署名ドメインがRFC5322.Fromヘッダーフィールド[RFC5322]のドメインと同じ組織ドメインの一部である必要があります。
In addition, DKIM allows for the possibility of multiple valid signatures. These multiple signatures may be from the same or different domains; there are no restrictions within the DKIM specification. The DMARC mechanism will process Authenticated Identifiers that are based on DKIM signatures until an aligned Authenticated Identifier is found (if any). However, operational experience has shown that some implementations have difficulty processing multiple signatures. Implementations that cannot process multiple DKIM signatures may incorrectly flag messages as "not passing" (DMARC alignment) and erroneously apply DMARC-based policy to otherwise conforming messages.
さらに、DKIMでは、複数の有効な署名が可能です。これらの複数の署名は、同じドメインまたは異なるドメインからのものである可能性があります。 DKIM仕様には制限がありません。 DMARCメカニズムは、整列された認証済み識別子が（存在する場合）見つかるまで、DKIM署名に基づく認証済み識別子を処理します。ただし、運用上の経験から、一部の実装では複数の署名の処理が困難であることがわかっています。複数のDKIMシグネチャを処理できない実装では、メッセージに「不合格」（DMARCアライメント）のフラグが誤って付けられ、DMARCベースのポリシーが誤って適合メッセージに適用されることがあります。
The SPF specification [RFC7208] defines two Authenticated Identifiers for each message. These identifiers derive from:
SPF仕様[RFC7208]では、メッセージごとに2つの認証済み識別子が定義されています。これらの識別子は次のものから派生します。
a. the RFC5321.MailFrom [RFC5321] domain, and
a. RFC5321.MailFrom [RFC5321]ドメイン、および
b. the RFC5321.HELO/.EHLO SMTP domain.
b. RFC5321.HELO / .EHLO SMTPドメイン。
In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is defined to be based on RFC5321.MailFrom unless that value is absent (as in the case of notification messages), in which case, the second (RFC5321.HELO/.EHLO) identifier value is used. This "fallback" definition has occasionally been misunderstood by operators of MTA systems since notification messages are often an "automatic" feature of MTA software. Some MTA software does not provide the ability to apply a DKIM signature to such notification messages.
SPF仕様では、RFC7208.MAILFROM [RFC7208]の値は、RFC5321.MailFromに基づいて定義されています（ただし、通知メッセージの場合のように）その値がない場合、2番目の値（RFC5321.HELO / .EHLO） ）識別子の値が使用されます。通知メッセージはMTAソフトウェアの「自動」機能であることが多いため、この「フォールバック」定義はMTAシステムのオペレーターによって誤解されることがあります。一部のMTAソフトウェアは、そのような通知メッセージにDKIM署名を適用する機能を提供しません。
See Appendix A for an example treatment of this scenario.
このシナリオの処理例については、付録Aを参照してください。
For the purposes of DMARC validation/alignment, the hybrid RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if it is aligned with the RFC5322.From [RFC5322] domain. The alignment of the validated domain is determined based on the DMARC record's "strict" or "relaxed" designation as described above for the DKIM identifiers and in [RFC7489].
DMARC検証/調整の目的で、RFC5322.From [RFC5322]ドメインと調整されている場合にのみ、ハイブリッドRFC7208.MAILFROM [RFC7208]識別子のドメインが使用されます。検証済みドメインの配置は、DKIM識別子について上記で説明されている[RFC7489]で説明されているように、DMARCレコードの「厳密な」または「リラックスした」指定に基づいて決定されます。
[RFC5322] permits only one From header field, but it may contain multiple mailboxes. Since this is an extremely rare usage, DMARC specifies that the handling of this situation is implementation dependent.
[RFC5322]は1つのFromヘッダーフィールドのみを許可しますが、複数のメールボックスを含めることができます。これは非常にまれな使用方法であるため、DMARCは、この状況の処理は実装に依存することを指定しています。
Because the presence of multiple domains can be used by an attacker (an attacker could add their domain to the RFC5322.From field, provide arbitrary new content, and sign the message), the DMARC specification recommends that the strictest policy be applied to such messages (Section 6.6.1 of [RFC7489]).
攻撃者は複数のドメインの存在を使用できるため（攻撃者は自分のドメインをRFC5322.Fromフィールドに追加し、任意の新しいコンテンツを提供し、メッセージに署名できます）、DMARC仕様では、そのようなメッセージに最も厳しいポリシーを適用することを推奨しています（[RFC7489]のセクション6.6.1）。
Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture.
セクション3では、インターネットメールアーキテクチャのコンポーネントに関連する転送動作について説明します。
All forwarding operations involve the retransmission of email. As discussed above, in order for SPF to yield an Authenticated Identifier that is pertinent to DMARC, the domain of the RFC7208.MAILFROM must be in alignment with the RFC5322.From header field. Forwarding introduces specific issues to the availability of SPF-based Authenticated Identifiers:
すべての転送操作には、電子メールの再送信が含まれます。上記のように、SPFがDMARCに関連する認証済み識別子を生成するためには、RFC7208.MAILFROMのドメインがRFC5322.Fromヘッダーフィールドと一致している必要があります。転送は、SPFベースの認証済み識別子の可用性に特定の問題をもたらします。
o If the RFC5321.MailFrom is present and the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321.MailFrom with its own domain, SPF might pass, but Identifier Alignment with the RFC5322.From header field will fail.
o RFC5321.MailFromが存在し、フォワーダーが元のRFC5321.MailFromを維持している場合、フォワーダーが発信者の電子メール送信インフラストラクチャの承認された部分でない限り、SPF検証は失敗します。フォワーダーがRFC5321.MailFromを独自のドメインに置き換えると、SPFは通過する可能性がありますが、RFC5322.Fromヘッダーフィールドを使用した識別子の整列は失敗します。
o If the RFC5321.MailFrom is empty (as in the case of Delivery Status Notifications), the RFC5321.HELO/.EHLO domain of the forwarder will likely be in a different Organizational Domain than the original RFC5322.From header field's domain. SPF may pass, but Identifier Alignment with the RFC5322.From header field will fail.
o RFC5321.MailFromが空の場合（配信ステータス通知の場合など）、フォワーダーのRFC5321.HELO / .EHLOドメインは、元のRFC5322.Fromヘッダーフィールドのドメインとは異なる組織ドメインにある可能性があります。 SPFは成功する可能性がありますが、RFC5322.Fromヘッダーフィールドとの識別子の整列は失敗します。
In both cases, SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon to produce results that are relevant to DMARC.
どちらの場合も、SPFは関連する認証済み識別子を生成できず、DMARCに関連する結果を生成するにはDKIMに依存する必要があります。
Modification of email content invalidates most DKIM signatures, and many message-forwarding systems modify email content. Mailing List processors are a common example of such systems, but other forwarding systems also make modifications.
電子メールコンテンツを変更すると、ほとんどのDKIM署名が無効になり、多くのメッセージ転送システムが電子メールコンテンツを変更します。メーリングリストプロセッサはそのようなシステムの一般的な例ですが、他の転送システムも変更を加えます。
Although DKIM provides a length flag so that content can be appended without invalidating the signature, in practice, particularly with MIME-encoded [RFC2045] messages, a Mailing List processor will do more than simply append content (see Section 5.3 of [RFC5598] for details). Furthermore, the length flag is seldom used due to security issues (see Section 8.2 of [RFC6376] for additional security considerations). Therefore, this method is only mentioned here for completeness.
DKIMには長さフラグが用意されているため、署名を無効にすることなくコンテンツを追加できますが、実際には、特にMIMEエンコードされた[RFC2045]メッセージの場合、メーリングリストプロセッサは単にコンテンツを追加するだけではありません（[RFC5598]のセクション5.3を参照）。詳細）。さらに、セキュリティの問題のため、長さフラグはめったに使用されません（セキュリティに関するその他の考慮事項については、[RFC6376]のセクション8.2を参照してください）。したがって、このメソッドは完全を期すためにここでのみ言及されています。
DKIM describes two canonicalizations for use when preparing the header and body for DKIM processing: simple and relaxed. The latter is designed to accommodate trivial modifications to whitespace and folding that, at least in the header case, generally have no semantic significance. However, the relaxed canonicalization is more computationally intensive and may not have been preferred in the early deployment of DKIM, leaving some deployments using the less forgiving "simple" canonicalization. While the prevalence is unknown, there are some DKIM verifiers that have problems evaluating relaxed canonicalization correctly.
DKIMでは、DKIM処理のためにヘッダーと本文を準備するときに使用する2つの正規化について説明します。後者は、少なくともヘッダーの場合、一般的に意味論的な意味を持たない空白と折りたたみに対する些細な変更に対応するように設計されています。ただし、緩和された正規化はより計算集約的であり、DKIMの初期展開では優先されなかった可能性があり、一部の展開では許容度の低い「単純な」正規化が使用されます。普及率は不明ですが、緩和された正規化を正しく評価するのに問題があるDKIM検証者がいます。
This section describes components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can be found.
このセクションでは、DMARCと間接的な電子メールフロー間の相互運用性の問題が見つかるインターネットメールアーキテクチャ[RFC5598]内のコンポーネントについて説明します。
Section 4 of [RFC5598] describes six basic components that make up the Message Handling System (MHS):
[RFC5598]のセクション4では、メッセージ処理システム（MHS）を構成する6つの基本コンポーネントについて説明しています。
o Message
o メッセージ
o Message User Agent (MUA)
o メッセージユーザーエージェント（MUA）
o Message Submission Agent (MSA)
o メッセージ発信エージェント（MSA）
o Message Transfer Agent (MTA)
o メッセージ転送エージェント（MTA）
o Message Delivery Agent (MDA)
o メッセージ配信エージェント（MDA）
o Message Store (MS)
o メッセージストア（MS）
Of these components, MSA, MTA, and MDA are discussed in relation to interoperability with DMARC.
これらのコンポーネントのうち、MSA、MTA、およびMDAは、DMARCとの相互運用性に関連して説明されています。
Section 5 of [RFC5598] also defines a Mediator as a hybrid of several component types. A Mediator is given special consideration in this section due to the unique issues they face when attempting to interoperate with DMARC.
[RFC5598]のセクション5でも、メディエーターをいくつかのコンポーネントタイプのハイブリッドとして定義しています。メディエーターは、DMARCとの相互運用を試みる際に直面する固有の問題により、このセクションで特別な考慮が与えられます。
An MSA accepts messages submitted by a Message User Agent (MUA) and enforces the policies of the hosting ADministrative Management Domain (ADMD) and the requirements of Internet standards.
MSAは、メッセージユーザーエージェント（MUA）によって送信されたメッセージを受け入れ、ホストしている管理管理ドメイン（ADMD）のポリシーとインターネット標準の要件を適用します。
MSAs are split into two sub-components:
MSAは2つのサブコンポーネントに分かれています。
o Author-focused MSA functions (aMSA)
o 著者向けのMSA関数（aMSA）
o MHS-focused MSA functions (hMSA)
o MHSに焦点を合わせたMSA関数（hMSA）
MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain that is outside of the ADMD of the MSA. This situation manifests in one of several ways, such as when someone uses a mail service with their own domain but has failed to properly configure an SPF record or when an MUA attempts to transmit mail as someone else. Examples of the latter situation include "forward-to-friend" functionality commonly found on news/article websites or "send-as" functionality present on some MUAs.
MSAのDMARCとの相互運用性の問題は、aMSAがRFC5322.FromヘッダーフィールドにMSAのADMDの外部にあるドメインを含むメッセージを受け入れると始まります。この状況は、誰かが独自のドメインでメールサービスを使用しているが、SPFレコードを正しく構成できなかった場合や、MUAが他のユーザーとしてメールを送信しようとした場合などに発生します。後者の状況の例には、ニュース/記事のWebサイトで一般的に見られる「友達に転送」機能や、一部のMUAにある「送信」機能が含まれます。
When an hMSA takes responsibility for transit of a message containing a domain in the RFC5322.From header field that is outside of the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the domain publishes a DMARC policy of "quarantine" or "reject". These issues are marked by the inherent difficulty of establishing alignment with the domain present in a message's RFC5322.From header field. Examples of this issue include:
hMSAのADMDの外部にあるRFC5322.Fromヘッダーフィールドにドメインを含むメッセージの転送をhMSAが担当する場合、ドメインが「検疫」または「拒否」のDMARCポリシーを公開すると、hMSAはDMARCの相互運用性の問題に直面します。これらの問題は、メッセージのRFC5322.Fromヘッダーフィールドに存在するドメインとの整合を確立することの本質的な難しさによって特徴付けられます。この問題の例は次のとおりです。
o Partially open relays - a residential ISP that allows its customers to relay non-local domains through its infrastructure.
o 部分的にオープンリレー-顧客がインフラストラクチャを介して非ローカルドメインをリレーできるようにする住宅用ISP。
o Embedded devices - cable/DSL modems, firewalls, wireless access points, and printers that send email using hardcoded domains.
o 組み込みデバイス-ハードコードされたドメインを使用して電子メールを送信するケーブル/ DSLモデム、ファイアウォール、ワイヤレスアクセスポイント、およびプリンター。
o Devices that send mail on behalf of a user - scanners, security cameras, and alarms that send mail as their owner or a device user.
o ユーザーに代わってメールを送信するデバイス-所有者またはデバイスユーザーとしてメールを送信するスキャナー、防犯カメラ、およびアラーム。
o Email service providers - ESPs that service customers who are using domains that publish a DMARC "reject" policy.
o メールサービスプロバイダー-DMARC「拒否」ポリシーを公開するドメインを使用している顧客にサービスを提供するESP。
o Calendaring software - an invited member of an event modifies the event, causing the calendaring software to emit an update that claims to come from the creator of the event.
o カレンダーソフトウェア-イベントの招待されたメンバーがイベントを変更し、カレンダーソフトウェアがイベントの作成者からのものであると主張する更新を発行します。
MTAs relay a message until the message reaches a destination MDA. Some common message-handling strategies break the integrity of DKIM signatures. A restrictive DMARC policy along with a broken DKIM signature causes latent interoperability problems to become overt problems.
MTAは、メッセージが宛先MDAに到達するまでメッセージを中継します。いくつかの一般的なメッセージ処理戦略は、DKIM署名の整合性を壊します。制限のあるDMARCポリシーと壊れたDKIM署名により、潜在的な相互運用性の問題が明白な問題になります。
An MTA may modify the message encoding, for instance, by converting 8-bit MIME sections to quoted-printable 7-bit sections. This modification is outside the scope of DKIM canonicalization and will invalidate DKIM signatures that include message content.
MTAは、たとえば、8ビットMIMEセクションをquoted-printable 7ビットセクションに変換することにより、メッセージエンコーディングを変更できます。この変更はDKIM正規化の範囲外であり、メッセージコンテンツを含むDKIM署名を無効にします。
An MTA could also re-encode the message without changing the encoding type: receiving a MIME-encoded message and producing a semantically and semiotically equivalent MIME body that is not identical to the original. This is characteristic of systems that use some other message representation internally.
MTAは、エンコードの種類を変更せずにメッセージを再エンコードすることもできます。つまり、MIMEエンコードされたメッセージを受信し、意味的にも記号的にも同等の、元のMIME本体とは異なるMIME本文を生成します。これは、内部で他のメッセージ表現を使用するシステムの特徴です。
An MTA may rewrite headers to bring them into compliance with existing RFCs. For example, some common MTAs will correct comprehensible but non-compliant date formats to compliant ones.
MTAはヘッダーを書き換えて、既存のRFCに準拠させることができます。たとえば、一部の一般的なMTAは、包括的ではあるが準拠していない日付形式を準拠している日付形式に修正します。
Header rewriting is outside the scope of DKIM canonicalization and will invalidate DKIM signatures. All downstream DMARC processing with be unable to utilize DKIM to yield Authenticated Identifiers due to header rewriting.
ヘッダーの書き換えはDKIM正規化の範囲外であり、DKIM署名を無効にします。ヘッダーの書き換えが原因で、DKIMを利用して認証済み識別子を生成できないすべてのダウンストリームDMARC処理。
Providing solutions for issues relating to non-RFC-compliant emails is outside the scope of this document.
RFCに準拠していない電子メールに関連する問題の解決策を提供することは、このドキュメントの範囲外です。
An MTA may also implement security-motivated changes to the content of email messages, dropping or altering sections of messages, causing breakage of DKIM signatures.
MTAは、電子メールメッセージのコンテンツにセキュリティに起因する変更を実装し、メッセージのセクションを削除または変更し、DKIM署名の破損を引き起こす可能性もあります。
The MDA transfers a message from the MHS to a mailbox. Like the MSA, the MDA consists of two sub-components:
MDAはMHSからメールボックスにメッセージを転送します。 MSAと同様に、MDAは2つのサブコンポーネントで構成されています。
o MHS-focused MDA functions (hMDA)
o MHSに特化したMDA関数（hMDA）
o Recipient-focused MDA functions (rMDA)
o 受信者重視のMDA関数（rMDA）
Both the hMDA and the rMDA can redirect a message to an alternative address. DMARC interoperability issues related to redirecting of messages are described in Section 3.2.
hMDAとrMDAはどちらも、メッセージを代替アドレスにリダイレクトできます。メッセージのリダイレクトに関連するDMARC相互運用性の問題については、セクション3.2で説明します。
Sieve [RFC5228] functionality often lives in the rMDA sub-component and can cause DMARC interoperability issues. The Sieve 'addheader' and 'deleteheader' filtering actions can modify messages and invalidate DKIM signatures, removing DKIM-supplied Authenticated Identifiers as inputs to the DMARC mechanism. There are also Sieve extensions [RFC5703] that modify the body. Sieve alterations may only become an issue when the email is reintroduced into the transport infrastructure.
Sieve [RFC5228]機能は、多くの場合rMDAサブコンポーネントに存在し、DMARCの相互運用性の問題を引き起こす可能性があります。 Sieveの「addheader」および「deleteheader」フィルタリングアクションは、メッセージを変更し、DKIM署名を無効化し、DKIM提供の認証済み識別子をDMARCメカニズムへの入力として削除することができます。ボディを変更するSieve拡張[RFC5703]もあります。ふるいの変更が問題になるのは、電子メールがトランスポートインフラストラクチャに再導入された場合のみです。
Mediators [RFC5598] forward messages through a re-posting process. Mediators share some functionality with basic MTA relaying but have greater flexibility in both addressing and content modifications.
調停者[RFC5598]は、再投稿プロセスを通じてメッセージを転送します。メディエーターは、一部の機能を基本的なMTAリレーと共有しますが、アドレッシングとコンテンツの変更の両方に高い柔軟性があります。
DMARC interoperability issues are common within the context of Mediators, which are often used precisely for their ability to modify messages.
DMARCの相互運用性の問題は、メディエーターのコンテキスト内でよく見られます。メディエーターは、メッセージを変更するために正確に使用されることがよくあります。
The DMARC design does not cope with some Mediator functionality such as content modifications that invalidate DKIM signatures and RFC5321.MailFrom rewriting to support SPF authentication of re-sent mail when the new Recipient receives the message from the Mediator rather than the initial organization.
DMARCの設計は、DKIM署名を無効にするコンテンツの変更や、新しい組織が初期組織ではなくメディエーターからメッセージを受信したときに再送信メールのSPF認証をサポートするためのRFC5321.MailFromの書き換えなど、一部のメディエーター機能に対応していません。
An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one. A message continues through the transfer service for delivery to one or more alternative addresses.
エイリアスは、単一の内部アドレスではなく、1つ以上の新しいインターネットメールアドレスを提供する単純な再アドレス指定機能です。メッセージは、1つ以上の代替アドレスに配信するために転送サービスを介して続行されます。
Aliases can be implemented by mailbox-level forwarding (e.g., through "dot-forwarding"), Sieve-level forwarding (through the Sieve "redirect" action), or other methods. When an Alias preserves message content and does not make significant header changes, DKIM signatures may remain valid. However, Aliases often extend the delivery path outside of the scope covered by the originating ADMD's SPF record(s).
エイリアスは、メールボックスレベルの転送（「ドット転送」など）、Sieveレベルの転送（Sieveの「リダイレクト」アクションによる）、またはその他の方法で実装できます。エイリアスがメッセージコンテンツを保持し、重要なヘッダー変更を行わない場合、DKIM署名は有効なままになる場合があります。ただし、エイリアスは、元のADMDのSPFレコードの対象範囲外で配信パスを拡張することがよくあります。
Examples of Aliasing include:
エイリアシングの例は次のとおりです。
o Forwarding email between free email (freemail) providers to try different interfaces while maintaining an original email address;
o 無料の電子メール（freemail）プロバイダー間で電子メールを転送して、元の電子メールアドレスを維持しながらさまざまなインターフェイスを試す。
o Consolidating many email addresses into a single account to centralize processing; and
o 多くのメールアドレスを単一のアカウントに統合して、処理を一元化します。そして
o Services that provide "activity-based", "role-based", "vanity", or "temporary" email addresses such as universities and professional associations. For instance, professional or alumni institutions may offer their members an Alias for the duration of their membership but may not want to deal with the long-term storage of emails.
o 「活動ベース」、「役割ベース」、「虚栄心」、または「一時的な」メールアドレスを提供するサービス（大学や専門家協会など）。たとえば、専門または同窓生機関は、メンバーシップの期間中、メンバーにエイリアスを提供することができますが、メールの長期保存に対処したくない場合があります。
In most cases, the aMSA providing Alias services has no administrative relationship to the ADMD of the originator or the Final Recipient, so solutions to Alias-related DMARC failure should not assume such a relationship.
ほとんどの場合、エイリアスサービスを提供するaMSAは、発信者のADMDまたは最終受信者との管理上の関係を持たないため、エイリアス関連のDMARC障害のソリューションでは、このような関係を想定しないでください。
ReSenders "splice" a message's addressing information to connect the Author of the original message with the Recipient(s) of the new message. The new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.
ReSenderは、メッセージのアドレス情報を「スプライス」して、元のメッセージの作成者と新しいメッセージの受信者を関連付けます。新しい受信者は、メディエーターが注釈を追加した場合でも、メッセージを元の作成者からのメッセージと見なします。
Without Authenticated Identifiers aligned with the Author's RFC5322.From header field domain, the new Recipient has no way to achieve a passing DMARC evaluation.
AuthorのRFC5322.Fromヘッダーフィールドドメインに合わせた認証済み識別子がないと、新しい受信者はDMARC評価に合格する方法がありません。
Examples of ReSenders include MUA-level forwarding by resending a message to a new Recipient or by forwarding a message "inline" to a new Recipient (this does not include forwarding a message "as an attachment"). An additional example comes in the form of calendaring software that allows a meeting attendee (not the meeting organizer) to modify the content of an invite generating new invitations that claim to be reissued from the meeting organizer.
ReSenderの例には、メッセージを新しい受信者に再送信する、またはメッセージを「インライン」で新しい受信者に転送する（これには、「添付ファイルとして」メッセージを転送することは含まれません）MUAレベルの転送が含まれます。もう1つの例は、会議の出席者（会議の開催者ではない）が招待の内容を変更して、会議の開催者から再発行されると主張する新しい招待を生成できるカレンダーソフトウェアの形式です。
A Mailing List receives messages as an explicit addressee and then reposts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender actions.
メーリングリストは、明示的な宛先としてメッセージを受信し、購読しているメンバーのリストに再投稿します。メーリングリストは、ReSenderアクションの詳細と見なすことができるタスクを実行します。
Mailing Lists share the same DMARC interoperability issues as ReSenders (Section 3.2.2) and very commonly modify headers or message content in ways that will cause DKIM to fail, including:
メーリングリストは、ReSenders（セクション3.2.2）と同じDMARC相互運用性の問題を共有し、DKIMが失敗する原因となる方法でヘッダーまたはメッセージコンテンツを変更します。
o prepending the RFC5322.Subject header field with a tag, to allow the Recipient to easily identify the Mailing List within a subject line listing;
o RFC5322.Subjectヘッダーフィールドにタグを付加して、受信者が件名行リスト内のメーリングリストを簡単に識別できるようにします。
o adding a footer to the email body to contain administrative instructions;
o 電子メールの本文にフッターを追加して、管理手順を含める。
o removing some MIME-parts from the email or converting the message to text only;
o 電子メールから一部のMIME部分を削除するか、メッセージをテキストのみに変換します。
o encrypting the body with the Recipient's key using PGP (Pretty Good Privacy) or S/MIME;
o PGP（Pretty Good Privacy）またはS / MIMEを使用して、受信者のキーでボディを暗号化します。
o enforcing community standards by rewriting banned words; and
o 禁止されている単語を書き換えることにより、コミュニティ標準を実施する。そして
o allowing moderators to add arbitrary commentary to messages (discussed in [RFC6377]).
o モデレーターがメッセージに任意のコメントを追加できるようにします（[RFC6377]で説明）。
Any such modifications would invalidate a DKIM signature.
このような変更を行うと、DKIM署名が無効になります。
Header and content modifications are common for many Mailing Lists and are often central to present Mailing List functionality and usage. Furthermore, MUAs have come to rely on Mailing List message modifications to present messages to end users in expected ways.
ヘッダーとコンテンツの変更は多くのメーリングリストに共通であり、多くの場合、メーリングリストの機能と使用法を提示するための中心となります。さらに、MUAは、予想される方法でエンドユーザーにメッセージを表示するために、メーリングリストのメッセージの変更に依存するようになりました。
Mailing Lists may also have the following DMARC interoperability issues:
メーリングリストには、次のDMARC相互運用性の問題がある可能性があります。
o Subscribed members may not receive email from members that post using domains that publish a DMARC "p=reject" policy.
o サブスクライブしたメンバーは、DMARC "p = reject"ポリシーを公開しているドメインを使用して投稿したメンバーからメールを受信できない場合があります。
o Mailing Lists may interpret DMARC-related email rejections as an inability to deliver email to the Recipients that are checking and enforcing DMARC policy. This processing may cause subscribers that are checking and enforcing DMARC policy to be inadvertently suspended or removed from the Mailing List.
o メーリングリストは、DMARC関連の電子メール拒否を、DMARCポリシーをチェックおよび適用している受信者に電子メールを配信できないと解釈する場合があります。この処理により、DMARCポリシーをチェックして適用しているサブスクライバーが誤って一時停止されたり、メーリングリストから削除されたりすることがあります。
A Gateway performs the basic routing and transfer work of message relaying, but it is also permitted to modify content, structure, addressing, and/or other attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies.
ゲートウェイは、メッセージリレーの基本的なルーティングと転送の作業を実行しますが、異なる標準または互換性のないポリシーで動作するメッセージング環境にメッセージを送信するために、必要に応じてコンテンツ、構造、アドレス指定、および/またはその他の属性を変更することもできます。
Gateways share the same DMARC interoperability issues as ReSenders (Section 3.2.2).
ゲートウェイは、ReSenderと同じDMARC相互運用性の問題を共有します（セクション3.2.2）。
Gateways may also share the same DMARC interoperability issues as MTAs (Section 3.1.2).
ゲートウェイは、MTAと同じDMARC相互運用性の問題も共有する場合があります（セクション3.1.2）。
Receiver systems on the non-SMTP side of a protocol Gateway may be unable to evaluate DKIM and SPF. If a message passes through a second protocol Gateway back into the SMTP domain, the transformations commonly break the original DKIM signature(s).
プロトコルゲートウェイの非SMTP側の受信側システムは、DKIMおよびSPFを評価できない場合があります。メッセージが2番目のプロトコルゲートウェイを通過してSMTPドメインに戻る場合、変換は通常、元のDKIM署名を破壊します。
Gateway-level forwarding can introduce DMARC interoperability issues if the Gateway is configured to rewrite the message into alternate receiving domains. For example, an acquisition may lead an acquiring company to decide to decommission the acquired company's domains by rewriting messages to use the domain of the acquiring company. Since the RFC5322.To header field is usually DKIM-signed, this kind of rewriting will invalidate such DKIM signatures.
ゲートウェイがメッセージを別の受信ドメインに書き換えるように構成されている場合、ゲートウェイレベルの転送によりDMARC相互運用性の問題が発生する可能性があります。たとえば、買収により、買収企業は、買収企業のドメインを使用するようにメッセージを書き換えることにより、買収企業のドメインの廃止を決定する場合があります。 RFC5322.Toヘッダーフィールドは通常DKIM署名されているため、この種の書き換えはそのようなDKIM署名を無効にします。
To enforce security boundaries, organizations can subject messages to analysis for conformance with their safety policies. A filter might alter the content to render it safe, such as by removing or otherwise altering content deemed unacceptable.
セキュリティの境界を適用するために、組織はメッセージに分析を適用して、安全ポリシーに準拠することができます。フィルターは、コンテンツを変更して、それを安全にするために、たとえば、容認できないと見なされたコンテンツを削除または変更する場合があります。
Boundary Filters share the same DMARC interoperability issues as ReSenders.
境界フィルターは、ReSenderと同じDMARC相互運用性の問題を共有します。
Issues may arise with SPF and DKIM evaluation if performed after filter modifications.
フィルターの変更後に実行すると、SPFおよびDKIM評価で問題が発生する可能性があります。
Examples of Boundary Filters include:
境界フィルターの例は次のとおりです。
o Malware scanning: To protect readers and its reputation, an MTA that transfers a message may remove content believed to be harmful from messages, reformulate content to canonical formats in order to make them more trustworthy or easier to scan, and/or add text in the body to indicate the message has been scanned. Any such modifications would invalidate a DKIM signature.
o マルウェアスキャン：リーダーとその評判を保護するために、メッセージを転送するMTAは、メッセージから有害であると思われるコンテンツを削除し、コンテンツを正規形式に再構成して、より信頼性の高い、または簡単にスキャンしたり、テキストをメッセージがスキャンされたことを示す本文。このような変更を行うと、DKIM署名が無効になります。
o Spam filtering: To protect its reputation and assist other MTAs, an MTA may modify a message to indicate its decision that the message is likely to be unwanted and/or add text in the body to indicate that such filtering has been done.
o スパムフィルタリング：レピュテーションを保護し、他のMTAを支援するために、MTAはメッセージを変更して、メッセージが不要である可能性が高いという決定を示すか、本文にテキストを追加して、そのようなフィルタリングが行われたことを示すことができます。
o Other text additions: An MTA may add an organizational disclaimer or advertisement, for instance.
o その他のテキストの追加：MTAは、たとえば、組織の免責事項や広告を追加する場合があります。
o URL alteration: Some systems will rewrite or alter embedded URLs as a way to control the potential threat from malware.
o URLの変更：一部のシステムでは、マルウェアからの潜在的な脅威を制御する方法として、埋め込まれたURLを書き換えたり変更したりします。
o Secondary MX services: The secondary MX for an organization may be external to the normal mail processing for the organization, and it may queue and forward to the primary when it becomes available. This will not invalidate DKIM but will prevent the primary from validating SPF normally. In this case, however, it is inappropriate for a primary MX server to perform an SPF check against its own secondaries. Rather, the secondary MX should perform this function and employ some trusted mechanism to communicate the results of the SPF, DKIM, and DMARC evaluation(s) to the primary MX server.
o セカンダリMXサービス：組織のセカンダリMXは、組織の通常のメール処理の外部にある場合があり、キューが利用可能になったときにプライマリに転送する場合があります。これによってDKIMが無効になることはありませんが、プライマリがSPFを正常に検証できなくなります。ただし、この場合、プライマリMXサーバーが自身のセカンダリに対してSPFチェックを実行することは不適切です。むしろ、セカンダリMXはこの機能を実行し、信頼できるメカニズムを使用して、SPF、DKIM、およびDMARC評価の結果をプライマリMXサーバーに伝達する必要があります。
Indirect email flows can be combined. For example, a university student may subscribe to a Mailing List (using his university email address) while this university email address is configured to forward all emails to a freemail or a post-education corporate account provider where a more permanent email address for this student exists.
間接的な電子メールフローは組み合わせることができます。たとえば、大学生がメーリングリストに登録すると（大学の電子メールアドレスを使用）、この大学の電子メールアドレスは、すべての電子メールをフリーメールまたは教育後の企業アカウントプロバイダーに転送するように構成されます。存在します。
Within an organization, the message may pass through various MTAs (Section 3.1.2), each of which performs a different function (authentication, filtering, distribution, etc.).
組織内では、メッセージはさまざまなMTA（セクション3.1.2）を通過でき、それぞれが異なる機能（認証、フィルタリング、配布など）を実行します。
Solutions to interoperability issues between DMARC and indirect email flows vary widely in their scope and implications. They range from improvements to underlying processing, such as proper handling of multiple DKIM signatures, to more radical changes to the messaging architecture. This section describes possible ways to address interoperability issues. Note that these particular mechanisms may not be considered "best practices" and may, in some cases, violate various conventions or expectations.
DMARCと間接的な電子メールフローの間の相互運用性の問題に対するソリューションは、その範囲と意味で大きく異なります。それらは、複数のDKIM署名の適切な処理などの基礎となる処理の改善から、メッセージングアーキテクチャへのより根本的な変更にまで及びます。このセクションでは、相互運用性の問題に対処するための考えられる方法について説明します。これらの特定のメカニズムは「ベストプラクティス」とは見なされず、場合によっては、さまざまな規則や期待に違反する可能性があることに注意してください。
Receivers sometimes need to deliver email messages that do not conform to any standard or protocol, but are otherwise desired by end users. Mitigating the impact of DMARC on indirect email flows is especially important to receivers that operate services where ease of use and compatibility with existing email flows is a priority.
受信者は、標準またはプロトコルに準拠していないが、それ以外の場合はエンドユーザーが希望する電子メールメッセージを配信する必要がある場合があります。間接的な電子メールフローに対するDMARCの影響を軽減することは、使いやすさと既存の電子メールフローとの互換性が優先されるサービスを運用する受信者にとって特に重要です。
DMARC provides a mechanism (local policy) for receivers to make decisions about identity alignment acceptability based on information outside DMARC and communicate those decisions as "overrides" to the sender. This facility can be used to ease some interoperability issues, although care is needed to ensure that this does not create loopholes for abuse.
DMARCは、レシーバーがDMARCの外部の情報に基づいてIDアライメントの受け入れ可能性に関する決定を行い、それらの決定を「オーバーライド」として送信者に伝達するためのメカニズム（ローカルポリシー）を提供します。この機能は、相互運用性の問題を緩和するために使用できますが、乱用の抜け穴が発生しないように注意する必要があります。
To further complicate the usage of mitigations, mitigation may not be desired if the email in question is of a certain category of high value or high risk (security-related) transactional messages (dealing with financial transactions or medical records, for example). In these cases, mitigating the impact of DMARC due to indirect email flows may not be desirable (counterproductive or allowing for abuse).
緩和策の使用をさらに複雑にするために、問題の電子メールが特定のカテゴリの高価値または高リスク（セキュリティ関連）のトランザクションメッセージ（たとえば、金融取引や医療記録の取引）である場合、緩和策は望ましくない場合があります。これらの場合、間接的な電子メールフローによるDMARCの影響を軽減することは望ましくない場合があります（逆効果または悪用を可能にする）。
As a final note, mail systems are diverse and widely deployed. Systems of various ages and capabilities are expected to preserve interoperability with the rest of the SMTP ecosystem. For instance, Qmail is still used, although the base code has not been updated since 1998. ezmlm, a once popular MLM, is still deployed but has not been updated since 1997, although a new version (ezmlm-idx) exists. Old versions of other open- and closed-source MTAs are still commonly in operation. When dealing with aging or unsupported systems, some solutions may be time-consuming and/or disruptive to implement.
最後に、メールシステムは多様であり、広く展開されています。さまざまな年齢や機能のシステムは、SMTPエコシステムの他の部分との相互運用性を維持することが期待されています。たとえば、Qmailは引き続き使用されますが、ベースコードは1998年以降更新されていません。かつて人気のMLMであるezmlmはまだ導入されていますが、新しいバージョン（ezmlm-idx）は存在しますが、1997年以降は更新されていません。他のオープンソースおよびクローズドソースMTAの古いバージョンは、まだ一般的に使用されています。古くなったシステムやサポートされていないシステムを処理する場合、一部のソリューションは実装に時間がかかり、混乱を招く場合があります。
Because DMARC is already widely deployed, many operators already have mitigations in use. These mitigations vary in their effectiveness and side effects but have the advantage that they are currently available.
DMARCはすでに広く展開されているため、多くの事業者がすでに緩和策を使用しています。これらの緩和策は、効果と副作用は異なりますが、現在利用できるという利点があります。
o MTAs handling multiple domains may choose to change RFC5321.MailFrom to align with RFC5322.From to improve SPF usability for DMARC.
o 複数のドメインを処理するMTAは、RFC5321.MailFromを変更してRFC5322.Fromに合わせるように選択して、DMARCのSPFの使いやすさを向上させることができます。
o MTAs handling multiple domains may also choose to align RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending notification messages. Dynamically adjusting the RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible for some MTA software.
o 複数のドメインを処理するMTAは、特に通知メッセージを送信するときに、RFC5321.HELO / .EHLOをRFC5322.Fromに揃えることも選択できます。一部のMTAソフトウェアでは、RFC5322.Fromに基づいてRFC5321.HELO / .EHLOを動的に調整できない場合があります。
o MTAs may choose to DKIM-sign notification messages with an aligned domain to allow a DKIM-based DMARC pass.
o MTAは、DKIMベースのDMARCパスを許可するために、整列されたドメインで通知メッセージにDKIM署名することを選択できます。
o MTAs sending email on behalf of multiple domains may require Domain Owners to provide DKIM keys to use DKIM to avoid SPF validation issues, given the requirement for DMARC alignment with the RFC5322.From header field. Managing DKIM keys with a third party has security risks that should be carefully managed (see also [RFC6376], Section 8). Methods involving CNAMEs and/or subdomains may alleviate some risks.
o 複数のドメインに代わってメールを送信するMTAは、RFC5322.FromヘッダーフィールドとのDMARCアラインメントの要件を前提として、SPF検証の問題を回避するためにDKIMを使用するDKIMキーをドメイン所有者に提供するよう要求する場合があります。サードパーティによるDKIM鍵の管理には、慎重に管理する必要があるセキュリティリスクがあります（[RFC6376]、セクション8も参照）。 CNAMEまたはサブドメイン、あるいはその両方を含むメソッドは、いくつかのリスクを軽減する可能性があります。
o Senders who are sending on behalf of users in other administrative domains may choose to use an RFC5322.From under the sender's control. The new From can be either a forwarding address in a domain controlled by the Sender or a placeholder address, with the original user's address in an RFC5322.Reply-to header field. However, performing this modification may cause the Recipient's MUA to deviate from customary behavior.
o 他の管理ドメインのユーザーに代わって送信している送信者は、送信者の制御下でRFC5322.Fromを使用することを選択できます。新しいFromは、Senderによって制御されるドメインの転送アドレスか、RFC5322.Reply-toヘッダーフィールドに元のユーザーのアドレスが含まれるプレースホルダーアドレスのいずれかです。ただし、この変更を実行すると、受信者のMUAが通常の動作から逸脱する可能性があります。
o When implementing "forward-to-friend" functionality, one approach to avoid DMARC failures is to pass a well-formed message to the user's MUA so that it may fill in an appropriate identity and submit through its own MSA.
o 「友達に転送」機能を実装する場合、DMARCの失敗を回避する1つの方法は、適切なIDを入力して独自のMSAを通じて送信できるように、整形式のメッセージをユーザーのMUAに渡すことです。
o Senders can use domains with distinct DMARC policies for email sent directly and email known to use indirect mail flows. However, for most well-known brands, all active domains are likely to be targeted equally by abusers.
o 送信者は、直接送信される電子メールと、間接的なメールフローを使用することがわかっている電子メールに、DMARCポリシーが異なるドメインを使用できます。ただし、ほとんどの有名なブランドでは、すべてのアクティブなドメインが乱用者によって等しく標的にされる可能性があります。
o Senders can maximize survivability of DKIM signatures by limiting the header fields they sign and using relaxed canonicalization. Using the DKIM length tag to allow appended signatures is discouraged due to the security risk created by allowing arbitrary content to be appended to legitimate email.
o 送信者は、署名するヘッダーフィールドを制限し、緩和された正規化を使用することで、DKIM署名の存続性を最大化できます。 DKIMの長さタグを使用して署名を追加できるようにすることはお勧めしません。正当な電子メールに任意のコンテンツを追加できるようにすることでセキュリティリスクが生じるためです。
o Senders can also maximize survivability by starting with RFC-compliant headers and common body formats.
o 送信者は、RFC準拠のヘッダーと共通の本文形式から始めることで、存続可能性を最大化することもできます。
o In order to minimize transport-based conversions, Senders can convert messages to a lowest denominator MIME content-transfer encoding such as quoted-printable or base64 before signing ([RFC6376], Section 5.3).
o トランスポートベースの変換を最小限に抑えるために、送信者は署名する前に、メッセージをquoted-printableやbase64などの最小のMIMEコンテンツ転送エンコーディングに変換できます（[RFC6376]、セクション5.3）。
o Receivers should update DKIM handling libraries to ensure that they process all valid DKIM signatures and check each signature for alignment.
o 受信者はDKIM処理ライブラリを更新して、すべての有効なDKIM署名を処理し、各署名の整合をチェックする必要があります。
o Receivers can amalgamate data from their user base to create lists of forwarders and use such lists to inform DMARC local policy overrides. This process may be easier for large receivers where data and resources to create such lists are more readily available than at smaller sites, where there are fewer accounts that receive forwarded mail and other resources may be scarce.
o 受信者は、ユーザーベースのデータを統合してフォワーダーのリストを作成し、そのリストを使用してDMARCローカルポリシーのオーバーライドを通知できます。このプロセスは、そのようなリストを作成するためのデータとリソースが、転送されたメールを受信するアカウントが少なく、他のリソースが不足している小さなサイトよりも容易に利用できる大規模な受信者にとっては簡単です。
Many ReSender issues can be avoided by using an RFC5322.From header field under the ReSender's control, instead of the initial RFC5322.From. This will correct Identifier Alignment issues and allow arbitrary message modification as long as the ReSender signs the message with an aligned domain signature. When ReSenders change the RFC5322.From, it is desirable to preserve the information about the original initiator of the message.
多くのReSenderの問題は、最初のRFC5322.Fromの代わりに、ReSenderの制御下にあるRFC5322.Fromヘッダーフィールドを使用することで回避できます。これにより、識別子の整列の問題が修正され、ReSenderが整列されたドメイン署名でメッセージに署名する限り、任意のメッセージ変更が可能になります。 ReSenderがRFC5322.Fromを変更する場合、メッセージの元の発信者に関する情報を保持することが望ましいです。
A first option is to use the Original-From [RFC5703] (or X-Original-From) header field for this purpose in various contexts (X- header field names are discouraged by [RFC6648]). However, handling of Original-From (or X-Original-From) is not defined anywhere. It is not currently used consistently or displayed to the user, and in any situation where it is used, it is a new unauthenticated identifier available for exploitation unless included within the scope of the new DKIM signature(s).
最初のオプションは、さまざまなコンテキストでこの目的のためにOriginal-From [RFC5703]（またはX-Original-From）ヘッダーフィールドを使用することです（X-ヘッダーフィールド名は[RFC6648]で推奨されていません）。ただし、Original-From（またはX-Original-From）の処理はどこにも定義されていません。これは現在一貫して使用されていないか、ユーザーに表示されていません。また、使用されている状況では、新しいDKIM署名の範囲に含まれていない限り、悪用に利用できる新しい未認証の識別子です。
Another option for ReSenders is to rewrite the RFC5322.From header field address to a locally controlled address that will be forwarded back to the original sender (subject to its own ReSender forwarding mitigations).
ReSendersの別のオプションは、RFC5322.Fromヘッダーフィールドアドレスを、元の送信者に転送されるローカルに制御されたアドレスに書き換えることです（独自のReSender転送軽減策に従う必要があります）。
o Forwarders can choose to add email header fields instead of modifying existing headers or bodies, for instance, to indicate a message may be spam.
o フォワーダーは、たとえば、メッセージがスパムである可能性があることを示すために、既存のヘッダーや本文を変更する代わりに、電子メールヘッダーフィールドを追加することを選択できます。
o Forwarders can minimize the circumstances in which they choose to fix messages, preferring to preserve non-compliant headers to creating DKIM failures.
o フォワーダーは、メッセージの修正を選択する状況を最小限に抑え、非準拠のヘッダーを保持してDKIM障害を作成することを優先できます。
o Forwarders can choose to reject messages with suspect or harmful content instead of modifying them.
o フォワーダーは、疑わしいまたは有害なコンテンツを含むメッセージを変更する代わりに拒否することを選択できます。
[RFC6377] provides some guidance on using DKIM with Mailing lists. The following mitigation techniques can be used to ease interoperability issues with DMARC and Mailing lists:
[RFC6377]は、メーリングリストでのDKIMの使用に関するガイダンスを提供します。 DMARCおよびメーリングリストとの相互運用性の問題を緩和するために、次の緩和手法を使用できます。
o Configuring the Mailing List Manager (MLM) to alter the RFC5322.From header field to use the domain of the MLM is a mitigation policy that is now present in several different Mailing List software distributions. Since most list subscribers prefer to know the identity of the Author of the original message, typically this information may be provided in the display name part of the RFC5322.From header field. This display name needs to be carefully crafted so as to not collide with the original display name of the Author, nor contain something that looks like an email address or domain name. These modifications may to some extent defeat the purpose of DMARC itself. It may make it difficult to ensure that users of all email clients can easily reply to the Author, the list, or all using the email client features provided for that purpose. Use of the RFC5322.Reply-To header field can alleviate this problem depending on whether the Mailing List is configured to reply-to-list, reply-to-author, or reply-to-fixed-address; however, it is important to note that this header field can take multiple email addresses. When altering the RFC5322.From, there are three possibilities:
o RFC5322.Fromヘッダーフィールドを変更してMLMのドメインを使用するようにメーリングリストマネージャー（MLM）を構成することは、現在いくつかの異なるメーリングリストソフトウェア配布に存在する緩和ポリシーです。ほとんどのリストサブスクライバーは元のメッセージの作成者のIDを知りたいため、通常、この情報はRFC5322.Fromヘッダーフィールドの表示名の部分で提供されます。この表示名は、作成者の元の表示名と衝突したり、電子メールアドレスやドメイン名のように見えるものを含めたりしないように、注意深く作成する必要があります。これらの変更は、DMARC自体の目的をある程度損なう可能性があります。すべての電子メールクライアントのユーザーが、その目的のために提供されている電子メールクライアント機能を使用して、作成者、リスト、またはすべてに簡単に返信できるようにするのは難しい場合があります。 RFC5322.Reply-Toヘッダーフィールドを使用すると、メーリングリストがreply-to-list、reply-to-author、またはreply-to-fixed-addressのどちらに設定されているかに応じて、この問題を緩和できます。ただし、このヘッダーフィールドには複数のメールアドレスが含まれる可能性があることに注意してください。 RFC5322.Fromを変更する場合、3つの可能性があります。
1. change it to put the Mailing List email address,
1. メーリングリストのメールアドレスを入力するように変更します。
2. change it to a locally defined address that will be forwarded back to the original sender, or
2. 元の送信者に転送されるローカルで定義されたアドレスに変更する、または
3. "break" the address by modifying the domain to a non-existent domain (such as by adding a suffix like ".invalid").
3. ドメインを存在しないドメインに変更して（「.invalid」のようなサフィックスを追加するなどして）、アドレスを「破壊」します。
The latter modification may create issues because it is an invalid domain name, and some MTAs may pay particular attention to the validity of email addresses in RFC5322.From and the reputation of the domains present there.
後者の変更は無効なドメイン名であるため問題が発生する可能性があり、一部のMTAはRFC5322.Fromの電子メールアドレスの有効性とそこに存在するドメインの評判に特に注意を払う場合があります。
o Configuring the MLM to "wrap" the message in a MIME message/rfc822 part and to send as the Mailing List email address. Many email clients (as of the publication of this document), especially mobile clients, have difficulty reading such messages, and this is not expected to change soon.
o メッセージをMIMEメッセージ/ rfc822部分に「ラップ」し、メーリングリストの電子メールアドレスとして送信するようにMLMを構成します。多くの電子メールクライアント（このドキュメントの発行時点）、特にモバイルクライアントは、このようなメッセージを読むことが困難であり、これはすぐには変更されないと予想されます。
o Configuring the MLM to not modify the message so that the DKIM signature remains valid. Some Mailing Lists are set up this way and require few additional changes to ensure the DKIM signature is preserved. Moving lists that currently modify mail to a policy like this may be too much of a change for the members of such lists.
o DKIM署名が有効なままになるようにメッセージを変更しないようにMLMを構成します。一部のメーリングリストはこのように設定されており、DKIM署名を確実に保持するためにいくつかの追加の変更が必要です。現在メールをこのようなポリシーに変更しているリストを移動すると、そのようなリストのメンバーにとっては変更が多すぎる可能性があります。
o Rejecting posts or membership requests from domains with a DMARC policy other than "p=none". However, members or potential members of such Mailing Lists may complain of unfair exclusion.
o 「p = none」以外のDMARCポリシーを持つドメインからの投稿またはメンバーシップ要求を拒否します。ただし、このようなメーリングリストのメンバーまたは潜在的なメンバーは、不当な除外について不満を言う可能性があります。
o To alleviate unsubscribes to the Mailing List due to the messages bouncing because of DMARC, the MLM needs to not act on notification messages due to message authentication issues. [RFC3463] specifies Enhanced Mail System Status Codes, which help differentiate between various failure conditions. Correctly interpreting Extended SMTP error messages is useful in this case. In particular, extended status codes for SPF and DKIM causes are defined in [RFC7372], and DMARC-related failure indications are discussed in DMARC ([RFC7489], Section 10.3).
o DMARCによるメッセージのバウンスによるメーリングリストへの登録解除を軽減するために、MLMはメッセージ認証の問題のために通知メッセージを処理しないようにする必要があります。 [RFC3463]は、さまざまな障害状態を区別するのに役立つ拡張メールシステムステータスコードを指定します。この場合、拡張SMTPエラーメッセージを正しく解釈すると役立ちます。特に、SPFとDKIMの原因の拡張ステータスコードは[RFC7372]で定義されており、DMARC関連の障害表示はDMARCで説明されています（[RFC7489]、セクション10.3）。
All these techniques may provide some specific challenges to MUAs and different operational usages for end users (like rewriting filters to sort emails in folders). There will be some time before all implications are understood and accommodated.
これらの手法はすべて、MUAにいくつかの特定の課題をもたらし、エンドユーザーのさまざまな運用上の使用法（フォルダー内の電子メールを並べ替えるためのフィルターの書き換えなど）を提供します。すべての影響が理解され、対応されるまでにはしばらく時間がかかります。
The following mitigations are based on Internet-Drafts (I-Ds) that are still in process. They are described here to offer an exploratory path for solutions. These solutions should not be used in a production environment. Because of the transient nature of I-Ds, specific citations are not included because a number of them will inevitably become obsolete, and those that gain consensus in the community will become RFCs and should be discovered as such.
次の緩和策は、現在進行中のインターネットドラフト（I-D）に基づいています。ここでは、ソリューションの探索パスを提供するために説明します。これらのソリューションは、実稼働環境では使用しないでください。 I-Dの一時的な性質のため、特定の引用は含まれません。それらの多くは必然的に陳腐化し、コミュニティでコンセンサスを得たものはRFCになり、そのように発見されるべきです。
o Third-party authorization schemes provide ways to extend Identifier Alignment under control of the Domain Owner.
o サードパーティの承認スキームは、ドメイン所有者の制御下で識別子の配置を拡張する方法を提供します。
o Ways to canonicalize messages that transit Mailing Lists so that their alterations can be isolated from the original signed content.
o メーリングリストを通過するメッセージを正規化して、元の署名付きコンテンツから変更を分離できるようにする方法。
o Mechanisms to record message transformations applied at each hop so they can be reversed and the original signed content recovered.
o 各ホップで適用されたメッセージ変換を記録し、それらを元に戻して元の署名済みコンテンツを復元できるようにするメカニズム。
o "Conditional" DKIM signatures, whereby the Author domain indicates its signature is only good if accompanied by a signature from an expected downstream relay.
o 「条件付き」のDKIMシグネチャ。これにより、Authorドメインは、予期されるダウンストリームリレーからのシグネチャを伴う場合にのみ、そのシグネチャが有効であることを示します。
o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, creating a provable chain of custody as well as a view of message authentication results at each handling step.
o Authentication-Results [RFC7601]を複数のホップに拡張するメカニズム。証明可能な一連の保管と、各処理ステップでのメッセージ認証結果のビューを作成します。
4.2.1. Getting More Radical: Requiring New Communication Paths between MUAs
4.2.1. より急進的になる：MUA間の新しい通信パスの要求
In practice, a number of operators are using strict alignment mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic email through systems purporting to be Mailing List handlers. The receiving ADMD has no knowledge of which lists the user has subscribed to and which they have not. One avenue of exploration would be for the user to authorize Mailing Lists as proxies for authentication, at which point the receiving ADMD would be vesting some trust in the Mailing List service. The creators of DKIM foresaw precisely this possibility at the time by not tightly binding any semantics to the RFC5322.From header field. Some experimental work has taken place in this area, as mentioned above. Additional work might examine a new communication path to the user to authorize some form of transitive trust.
実際には、多くのオペレーターがDMARCで厳格な調整モードを使用して、メーリングリストハンドラーであると主張するシステムを介して、新しく革新的な形の不要で認証されていない電子メールを受信しないようにしています。受信ADMDは、ユーザーが購読しているリストと購読していないリストを認識していません。調査の1つの方法は、ユーザーがメーリングリストを認証のプロキシとして承認することです。この時点で、受信側のADMDは、メーリングリストサービスにある程度の信頼を与えます。 DKIMの作成者は、RFC5322.Fromヘッダーフィールドにセマンティクスを緊密にバインドしないことで、この時点でこの可能性を正確に予測しました。上記のように、この領域ではいくつかの実験的な作業が行われています。追加の作業では、ユーザーへの新しい通信パスを調べて、何らかの推移的な信頼を承認します。
This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial of service that can be created by rejections of messages by DMARC-aware mail receivers.
このドキュメントは、DMARCの間接的な電子メールフローへの影響を分析したものです。 DMARC対応のメール受信者によるメッセージの拒否によって作成される可能性のある、偶発的なサービス拒否の可能性について説明します。
Section 4.1.1.1 discusses the importance of appropriate DKIM key management vis-a-vis third-party email senders.
セクション4.1.1.1では、サードパーティの電子メール送信者に対する適切なDKIMキー管理の重要性について説明します。
Section 4.1.3.3 warns that rewriting the RFC5322.From header field to create an artificial domain name should not be done with any domain.
4.1.3.3項では、RFC5322.Fromヘッダーフィールドを書き換えて人工的なドメイン名を作成することは、どのドメインでも行わないように警告しています。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, <http://www.rfc-editor.org/info/rfc3463>.
[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、DOI 10.17487 / RFC3463、2003年1月、<http://www.rfc-editor.org/info/rfc3463>。
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <http://www.rfc-editor.org/info/rfc5228>.
[RFC5228] Guenther、P.、Ed。 T. Showalter、Ed。、「Sieve：An Email Filtering Language」、RFC 5228、DOI 10.17487 / RFC5228、2008年1月、<http://www.rfc-editor.org/info/rfc5228>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<http://www.rfc-editor.org/info/rfc5598>。
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, DOI 10.17487/RFC5703, October 2009, <http://www.rfc-editor.org/info/rfc5703>.
[RFC5703] Hansen、T.、C。Daboo、「Sieve Email Filtering：MIME Part Tests、Iteration、Extraction、Replacement、and Enclosure」、RFC 5703、DOI 10.17487 / RFC5703、2009年10月、<http：//www.rfc -editor.org/info/rfc5703>。
[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, <http://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 、<http://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, <http://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月、<http://www.rfc-editor.org/info/rfc6377 >。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <http://www.rfc-editor.org/info/rfc6648>.
[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、DOI 10.17487 / RFC6648、2012年6月、 <http://www.rfc-editor.org/info/rfc6648>。
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[RFC7208]キッターマンS.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<http://www.rfc-editor.org / info / rfc7208>。
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <http://www.rfc-editor.org/info/rfc7372>.
[RFC7372] Kucherawy、M。、「Email Authentication Status Codes」、RFC 7372、DOI 10.17487 / RFC7372、2014年9月、<http://www.rfc-editor.org/info/rfc7372>。
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <http://www.rfc-editor.org/info/rfc7489>.
[RFC7489] Kucherawy、M.、Ed。およびE. Zwicky、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<http://www.rfc-editor.org/info/ rfc7489>。
[RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, <http://www.rfc-editor.org/info/rfc7601>.
[RFC7601] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7601、DOI 10.17487 / RFC7601、2015年8月、<http://www.rfc-editor.org/info/rfc7601>。
This example illustrates a notification message "bounce".
この例は、通知メッセージ「バウンス」を示しています。
Here is the message as it exits the Origin MTA (segv.d1.example):
Origin MTA（segv.d1.example）を終了するときのメッセージは次のとおりです。
Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang, This is a test message. --J.
こんにちは、これはテストメッセージです。 --J。
When dmarc.org rejects the message without a DKIM signature, it specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has no SPF record. dmarc.org has a reject policy in place for such non-passing cases. Since there is no DKIM signature on the notification message, the failed SPF lookup results in a dmarc=fail, and d1.example could be expected to discard the notification message itself:
dmarc.orgがDKIM署名のないメッセージを拒否すると、RFC5321.HELO / .EHLOドメインがSPFレコードのないdmarc.org.localとして指定されます。 dmarc.orgには、このような不合格のケースに対して拒否ポリシーが設定されています。通知メッセージにはDKIM署名がないため、SPFルックアップが失敗するとdmarc = failが発生し、d1.exampleは通知メッセージ自体を破棄することが期待されます。
Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
by mx.d1.example with ESMTPS id Lkm25302jJR5
for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=;
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0
Received: from segv.d1.example (segv.d1.example [198.51.100.1])
by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example
Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8
This is an automatically generated Delivery Status Notification
これは自動的に生成された配信状態通知です
Delivery to the following recipient failed permanently:
次の受信者へ配信することはできませんでした：
no-recipient@dmarc.org
のーれしぴえんｔ＠ｄまｒｃ。おｒｇ
Technical details of permanent failure: Your message was rejected by the server for the recipient domain dmarc.org by mail.dmarc.org [192.0.2.1].
永続的な障害の技術的な詳細：メッセージは、mail.dmarc.org [192.0.2.1]によって受信者のドメインdmarc.orgのサーバーによって拒否されました。
The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown
----- Original message -----
Return-Path: <jqd@d1.example>
Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
[203.252.0.131]) (authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: no-recipient@dmarc.org
Subject: Example 1
Hey gang, This is a test message. --J.
こんにちは、これはテストメッセージです。 --J。
Acknowledgments
謝辞
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF DMARC Working Group's wiki page listing all known interoperability issues with DMARC and indirect email flows.
Miles Fidelman、John Levine、David Crocker、Stephen J. Turnbull、Rolf E. Sonneveld、Tim Draegen、Franck Martinは、DMARCとの既知の相互運用性に関するすべての問題と間接的なメールフローをリストしたIETF DMARCワーキンググループのwikiページに貢献しました。
Tim Draegen created the first draft of this document from these contributions and by ham-fistedly mapping contributions into the language of [RFC5598].
Tim Draegenは、これらの貢献から、そして貢献を[RFC5598]の言語に手作業でマッピングすることにより、このドキュメントの最初のドラフトを作成しました。
Authors' Addresses
著者のアドレス
Franck Martin (editor) LinkedIn Mountain View, CA United States of America
フランク・マーティン（編集者）LinkedIn Mountain View、CAアメリカ合衆国
Email: fmartin@linkedin.com
Eliot Lear (editor) Cisco Systems GmbH Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland
Eliot Lear（編集者）Cisco Systems GmbH Richtistrasse 7 Wallisellen、ZH CH-8304スイス
Phone: +41 44 878 9200
Email: lear@cisco.com
Tim Draegen (editor) dmarcian, inc. PO Box 1007 Brevard, NC 28712 United States of America
Tim Draegen（editor）dmarcian、inc。 PO Box 1007 Brevard、NC 28712アメリカ合衆国
Email: tim@dmarcian.com
Elizabeth Zwicky (editor) Yahoo Sunnyvale, CA United States of America
Elizabeth Zwicky（editor）Yahoo Sunnyvale、CAアメリカ合衆国
Email: zwicky@yahoo-inc.com
Kurt Andersen (editor) LinkedIn 2029 Stierlin Court Mountain View, CA 94043 United States of America
カート・アンデルセン（編集者）LinkedIn 2029 Stierlin Court Mountain View、CA 94043 United States of America
Email: kandersen@linkedin.com