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.
                                                        K. Andersen, Ed.
                                                          September 2016

Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows




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.


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


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 ( 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トラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
         Message Encoding ...........................9
         Header Standardization ....................10
         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
         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
         Identifier Alignment ......................16
         Message Modification ......................17
           4.1.2. Mitigations for Receivers ..........................17
         Identifier Alignment ......................17
         Policy Override ...........................17
           4.1.3. Mitigations for ReSenders ..........................18
         Changes to the RFC5322.From ...............18
         Avoiding Message Modification .............18
         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
1. Introduction
1. はじめに

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.


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.


1.1. Document Conventions
1.1. 文書規約

The notation used in this document for structured fields is taken from [RFC5598], Section 1.3.


The term "notification message" ([RFC5321], Section 4.5.5) is used to refer to a message with a null RFC5321.MailFrom.


The terms "Organizational Domain" and "Authenticated Identifiers" are specified in DMARC ([RFC7489], Section 3).


All words that begin with capital letters take their formal meanings from these references.


2. Causes of Interoperability Issues
2. 相互運用性の問題の原因

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.


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.


The rest of this section describes several conceptual causes of interoperability issues.


2.1. Identifier Alignment
2.1. 識別子の配置

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モードでのみ機能します。

2.1.1. DKIM Identifier(s)
2.1.1. DKIM識別子(s)

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].


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ベースのポリシーが誤って適合メッセージに適用されることがあります。

2.1.2. SPF Identifier(s)
2.1.2. SPF識別子

The SPF specification [RFC7208] defines two Authenticated Identifiers for each message. These identifiers derive from:


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.


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レコードの「厳密な」または「リラックスした」指定に基づいて決定されます。

2.1.3. Multiple RFC5322.From Addresses
2.1.3. 複数のRFC5322.Fromアドレス

[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.


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]).


2.2. Message Forwarding
2.2. メッセージ転送

Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture.


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:


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.


2.3. Message Modification
2.3. メッセージの変更

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.


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 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.


3. Internet Mail Architecture, DMARC, and Indirect Email Flows
3. インターネットメールアーキテクチャ、DMARC、および間接電子メールフロー

This section describes components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can be found.


3.1. Message Handling System
3.1. メッセージ処理システム

Section 4 of [RFC5598] describes six basic components that make up the Message Handling System (MHS):


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.


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.


3.1.1. Message Submission Agents
3.1.1. メッセージ発信エージェント

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.


MSAs are split into two sub-components:


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.


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:


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 カレンダーソフトウェア-イベントの招待されたメンバーがイベントを変更し、カレンダーソフトウェアがイベントの作成者からのものであると主張する更新を発行します。

3.1.2. Message Transfer Agents
3.1.2. メッセージ転送エージェント

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署名により、潜在的な相互運用性の問題が明白な問題になります。 Message Encoding メッセージのエンコーディング

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本文を生成します。これは、内部で他のメッセージ表現を使用するシステムの特徴です。 Header Standardization ヘッダーの標準化

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.


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.


Providing solutions for issues relating to non-RFC-compliant emails is outside the scope of this document.

RFCに準拠していない電子メールに関連する問題の解決策を提供することは、このドキュメントの範囲外です。 Content Validation コンテンツ検証

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.


3.1.3. Message Delivery Agents
3.1.3. メッセージ配信エージェント

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.


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]もあります。ふるいの変更が問題になるのは、電子メールがトランスポートインフラストラクチャに再導入された場合のみです。

3.2. Mediators
3.2. 調停者

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.


DMARC interoperability issues are common within the context of Mediators, which are often used precisely for their ability to modify messages.


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.


3.2.1. Alias
3.2.1. エイリアス

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.


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).


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.


3.2.2. ReSenders
3.2.2. 再送信者

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.


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.


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.


3.2.3. Mailing Lists
3.2.3. メーリングリスト

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.


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:


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.


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 List Operational Effects メーリングリストの運用上の影響

Mailing Lists may also have the following DMARC interoperability issues:


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ポリシーをチェックして適用しているサブスクライバーが誤って一時停止されたり、メーリングリストから削除されたりすることがあります。

3.2.4. Gateways
3.2.4. ゲートウェイ

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).


Gateways may also share the same DMARC interoperability issues as MTAs (Section 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).


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署名を無効にします。

3.2.5. Boundary Filters
3.2.5. 境界フィルター

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.


Issues may arise with SPF and DKIM evaluation if performed after filter modifications.


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サーバーに伝達する必要があります。

3.3. Combinations
3.3. 組み合わせ

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.).


4. Possible Mitigations of Interoperability Issues
4. 相互運用性の問題の考えられる緩和策

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.


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 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.


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).


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.


4.1. Mitigations in Current Use
4.1. 現在使用されている緩和策

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.


4.1.1. Mitigations for Senders
4.1.1. 送信者の軽減策 Identifier Alignment 識別子の配置

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ポリシーが異なるドメインを使用できます。ただし、ほとんどの有名なブランドでは、すべてのアクティブなドメインが乱用者によって等しく標的にされる可能性があります。 Message Modification メッセージの変更

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)。

4.1.2. Mitigations for Receivers
4.1.2. レシーバーの緩和策 Identifier Alignment 識別子の配置

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署名を処理し、各署名の整合をチェックする必要があります。 Policy Override ポリシーの上書き

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ローカルポリシーのオーバーライドを通知できます。このプロセスは、そのようなリストを作成するためのデータとリソースが、転送されたメールを受信するアカウントが少なく、他のリソースが不足している小さなサイトよりも容易に利用できる大規模な受信者にとっては簡単です。

4.1.3. Mitigations for ReSenders
4.1.3. 再送信者の軽減策 Changes to the RFC5322.From RFC5322.Fromへの変更

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転送軽減策に従う必要があります)。 Avoiding Message Modification メッセージの変更を回避する

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 フォワーダーは、疑わしいまたは有害なコンテンツを含むメッセージを変更する代わりに拒否することを選択できます。 Mailing Lists メーリングリスト

[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.


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.


4.2. Proposed and In-Progress Mitigations
4.2. 提案された進行中の緩和策

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ヘッダーフィールドにセマンティクスを緊密にバインドしないことで、この時点でこの可能性を正確に予測しました。上記のように、この領域ではいくつかの実験的な作業が行われています。追加の作業では、ユーザーへの新しい通信パスを調べて、何らかの推移的な信頼を承認します。

5. Security Considerations
5. セキュリティに関する考慮事項

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 discusses the importance of appropriate DKIM key management vis-a-vis third-party email senders.


Section warns that rewriting the RFC5322.From header field to create an artificial domain name should not be done with any domain.項では、RFC5322.Fromヘッダーフィールドを書き換えて人工的なドメイン名を作成することは、どのドメインでも行わないように警告しています。

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[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, <>.

[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->。

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, <>.

[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、DOI 10.17487 / RFC3463、2003年1月、<>。

[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <>.

[RFC5228] Guenther、P.、Ed。 T. Showalter、Ed。、「Sieve:An Email Filtering Language」、RFC 5228、DOI 10.17487 / RFC5228、2008年1月、<>。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <>.

[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<>。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <>.

[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<>。

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <>.

[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<>。

[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, <>.

[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>。

[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, <>.

[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 、<>。

[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <>.

[RFC6377] Kucherawy、M。、「DomainKeys Identified Mail(DKIM)and Mailing Lists」、BCP 167、RFC 6377、DOI 10.17487 / RFC6377、2011年9月、< >。

[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, <>.

[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、DOI 10.17487 / RFC6648、2012年6月、 <>。

[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <>.

[RFC7208]キッターマンS.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク(SPF)、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、< / info / rfc7208>。

[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <>.

[RFC7372] Kucherawy、M。、「Email Authentication Status Codes」、RFC 7372、DOI 10.17487 / RFC7372、2014年9月、<>。

6.2. Informative References
6.2. 参考引用

[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <>.

[RFC7489] Kucherawy、M.、Ed。およびE. Zwicky、編、「ドメインベースのメッセージ認証、レポート、および準拠(DMARC)」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、< rfc7489>。

[RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, <>.

[RFC7601] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7601、DOI 10.17487 / RFC7601、2015年8月、<>。

Appendix A. Example SPF Bounce
付録A. SPFバウンスの例

This example illustrates a notification message "bounce".


A.1. Initial Message
A.1. 最初のメッセージ

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 [] ( [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;
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 Subject: Example 1

Hey gang, This is a test message. --J.

こんにちは、これはテストメッセージです。 --J。

A.2. Notification Message
A.2. 通知メッセージ

When rejects the message without a DKIM signature, it specifies the RFC5321.HELO/.EHLO domain as, which has no SPF record. 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には、このような不合格のケースに対して拒否ポリシーが設定されています。通知メッセージにはDKIM署名がないため、SPFルックアップが失敗するとdmarc = failが発生し、d1.exampleは通知メッセージ自体を破棄することが期待されます。

 Return-Path: <>
 Received: from ( [])
    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: does not designate
    permitted sender hosts) smtp.mail=;
    dmarc=fail (p=REJECT dis=NONE)
 MIME-Version: 1.0
 Received: from segv.d1.example (segv.d1.example [])
  by with SMTP id u67mr102828634qge33; Thu,
  14 Jan 2015 15:00:24 -0800 (PST)
 From: Mail Delivery Subsystem <>
 To: jqd@d1.example
 Subject: Delivery Status Notification (Failure)
 Message-ID: <>
 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:



Technical details of permanent failure: Your message was rejected by the server for the recipient domain by [].

永続的な障害の技術的な詳細:メッセージは、 []によって受信者のドメインdmarc.orgのサーバーによって拒否されました。

 The error that the other server returned was:
 550 5.1.1 <>... User unknown
 ----- Original message -----
 Return-Path: <jqd@d1.example>
 Received: from [] (
     []) (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;
 Message-ID: <54B84785.1060301@d1.example>
 Date: Thu, 14 Jan 2015 15:00:01 -0800
 From: John Q Doe <jqd@d1.example>
 Subject: Example 1

Hey gang, This is a test message. --J.

こんにちは、これはテストメッセージです。 --J。



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アメリカ合衆国


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

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アメリカ合衆国


Elizabeth Zwicky (editor) Yahoo Sunnyvale, CA United States of America

Elizabeth Zwicky(editor)Yahoo Sunnyvale、CAアメリカ合衆国


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