[要約] RFC 6377は、DKIMとメーリングリストの関係についてのガイドラインです。このRFCの目的は、メーリングリストでのDKIMの適切な実装と使用方法を提供することです。
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6377 Cloudmark
BCP: 167 September 2011
Category: Best Current Practice
ISSN: 2070-1721
DomainKeys Identified Mail (DKIM) and Mailing Lists
DomainKeysは、メール（DKIM）とメーリングリストを識別しました
Abstract
概要
DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs).
DomainKeys Idefied Mail（DKIM）により、管理管理ドメイン（ADMD）がメッセージに対する責任を負うことができます。DKIMの展開エクスペリエンスに基づいて、このドキュメントは、メーリングリストマネージャー（MLMS）を含むシナリオを使用してDKIMを使用するためのガイダンスを提供します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
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). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 5741のセクション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/rfc6377.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6377で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MLMs in Infrastructure . . . . . . . . . . . . . . . . . . 4
1.3. Feedback Loops and Other Bilateral Agreements . . . . . . 5
1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 6
2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 6
2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7
3.2. Types of Mailing Lists . . . . . . . . . . . . . . . . . . 8
3.3. Current MLM Effects on Signatures . . . . . . . . . . . . 10
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13
4.4. Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 16
5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 17
5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
5.9. Verification Outcomes at Final Receiving Sites . . . . . . 20
5.10. Use with FBLs . . . . . . . . . . . . . . . . . . . . . . 20
5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 21
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Security Considerations from DKIM and ADSP . . . . . . . . 22
7.2. Authentication Results When Relaying . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25
DomainKeys Identified Mail [DKIM] allows an ADministrative Management Domain (ADMD) to take some responsibility for a [MAIL] message. Such responsibility can be taken by an Author's organization, an operational relay (Mail Transfer Agent, or MTA), or one of their agents. Assertion of responsibility is made through a cryptographic signature. Message transit from Author to recipient is through relays that typically make no substantive change to the message content and thus preserve the validity of the DKIM signature.
domainkeys識別されたメール[DKIM]により、管理管理ドメイン（ADMD）が[メール]メッセージに対して何らかの責任を負うことができます。このような責任は、著者の組織、運用リレー（メール転送エージェント、またはMTA）、またはそのエージェントの1人によって取得できます。責任の主張は、暗号化の署名を通じて行われます。著者から受信者へのメッセージトランジットは、通常、メッセージコンテンツに実質的な変更を行わないリレーを介しており、したがってDKIM署名の有効性を維持します。
In contrast to relays, there are intermediaries, such as Mailing List Managers (MLMs), that actively take delivery of messages, reformat them, and repost them, often invalidating DKIM signatures. The goal for this document is to explore the use of DKIM for scenarios that include intermediaries and recommend best current practices based on acquired experience. Questions that will be discussed include:
リレーとは対照的に、メーリングリストマネージャー（MLM）などの仲介者が、メッセージの配信を積極的に採用し、それらを再フォーマットし、再投稿し、しばしばDKIMの署名を無効にします。このドキュメントの目標は、仲介者を含むシナリオへのDKIMの使用を調査し、獲得した経験に基づいて最良の現在のプラクティスを推奨することです。議論される質問は次のとおりです。
o Under what circumstances is it advisable for an Author, or its organization, to apply DKIM to mail sent to mailing lists?
o 著者またはその組織がDKIMをメーリングリストに送信したメールに適用することは、どのような状況で推奨されますか？
o What are the trade-offs regarding having an MLM verify and use DKIM identifiers?
o DKIM識別子を検証および使用することに関するトレードオフは何ですか？
o What are the trade-offs regarding having an MLM remove existing DKIM signatures prior to reposting the message?
o メッセージを再投稿する前に、MLMに既存のDKIM署名を削除することに関するトレードオフは何ですか？
o What are the trade-offs regarding having an MLM add its own DKIM signature?
o MLMに独自のDKIM署名を追加することに関するトレードオフは何ですか？
These are open questions for which there may be no definitive answers. However, based on experience since the publication of the original version of [DKIM] and its gradual deployment, there are some views that are useful to consider and some recommended procedures.
これらは、決定的な答えがないかもしれない未解決の質問です。ただし、[DKIM]の元のバージョンの公開以来の経験に基づいて、その漸進的な展開には、考慮するのに役立ついくつかのビューと推奨手順があります。
In general, there are two categories of MLMs in relation to DKIM: participating and non-participating. As each type has its own issues regarding DKIM-signed messages that are either handled or produced by them (or both), the types are discussed in separate sections.
一般に、DKIMに関連するMLMには2つのカテゴリがあります。参加と非参加者です。各タイプには、DKIMに署名されたメッセージに関する独自の問題があり、それら（またはその両方）によって処理または作成されたメッセージがあるため、タイプは別々のセクションで説明されています。
The best general recommendation for dealing with MLMs is that the MLM or an MTA in the MLM's domain apply its own DKIM signature to each message it forwards and that assessors on the receiving end consider the MLM's domain signature in making their assessments. (See Section 5, especially Section 5.2.)
MLMを扱うための最良の一般的な推奨事項は、MLMまたはMLMのドメインのMLMまたはMTAが、それをフォワードする各メッセージに独自のDKIM署名を適用し、受信側の評価者が評価を行う際にMLMのドメイン署名を検討することです。（セクション5、特にセクション5.2を参照してください。）
With the understanding that this is not always possible or practical and the consideration that it might not always be sufficient, this document provides additional guidance.
これが常に可能または実用的であるとは限らないという理解と、それが常に十分ではないかもしれないという考慮事項により、このドキュメントは追加のガイダンスを提供します。
DKIM signatures permit an agent of the email architecture (see [EMAIL-ARCH]) to make a claim of responsibility for a message by affixing a validated domain-level identifier to the message as it passes through a relay. Although not the only possibility, this is most commonly done as a message passes through a boundary Mail Transport Agent (MTA) as it departs an ADministrative Management Domain (ADMD) across the open Internet.
DKIM署名は、電子メールアーキテクチャのエージェント（[電子メール-Arch]を参照）に、検証済みのドメインレベル識別子をリレーを通過するときにメッセージに貼り付けてメッセージの責任を主張することを許可します。唯一の可能性ではありませんが、これは、オープンインターネット全体で管理管理ドメイン（ADMD）を出発するため、メッセージが境界メールトランスポートエージェント（MTA）を通過するときに最も一般的に行われます。
A DKIM signature will fail to verify if a portion of the message covered by one of its hashes is altered. An MLM commonly alters messages to provide information specific to the mailing list for which it is providing service. Common modifications are enumerated and described in Section 3.3. However, note that MLMs vary widely in behavior and often allow subscribers to select individual behaviors. Further, the MTA might make changes that are independent of those applied by the MLM.
DKIMの署名は、ハッシュの1つでカバーされているメッセージの一部が変更されているかどうかを確認できません。MLMは一般にメッセージを変更して、サービスを提供しているメーリングリストに固有の情報を提供します。一般的な変更は列挙され、セクション3.3で説明されています。ただし、MLMの動作は大きく異なり、多くの場合、サブスクライバーが個々の動作を選択できることが多いことに注意してください。さらに、MTAは、MLMによって適用されたものとは独立した変更を加える可能性があります。
The DKIM Signatures specification [DKIM] deliberately rejects the notion of tying the signing domain (the "d=" tag in a DKIM signature) to any other identifier within a message; any ADMD that handles a message could sign it, regardless of its origin or Author domain. In particular, DKIM does not define any meaning to the occurrence of a match between the content of a "d=" tag and the value of, for example, a domain name in the RFC5322.From field, nor is there any obvious degraded value to a signature where they do not match. Since any DKIM signature is merely an assertion of "some" responsibility by an ADMD, a DKIM signature added by an MLM has no more or less meaning than a signature with any other "d=" value.
DKIM署名仕様[DKIM]は、メッセージ内の他の識別子に署名ドメイン（ "d ="タグ）を結び付けるという概念を故意に拒否します。メッセージを処理するADMDは、その起源または著者ドメインに関係なく、それに署名することができます。特に、DKIMは、「D =」タグのコンテンツと、たとえばRFC5322.フィールドからドメイン名の値の間の一致の発生に対する意味を定義していません。また、明らかな劣化値はありません。それらが一致しない署名に。DKIMの署名はADMDによる「ある程度の」責任の単なる主張であるため、MLMによって追加されたDKIM署名は、他の「D =」値の署名よりも多くの意味がありません。
An MLM is an autonomous agent that takes delivery of a message and can repost it as a new message or construct a digest of it along with other messages to the members of the list (see [EMAIL-ARCH], Section 5.3). However, the fact that the RFC5322.From field of such a message (in the non-digest case) is typically the same as that of the original message, and that recipients perceive the message as "from" the original Author rather than the MLM, creates confusion about responsibility and autonomy for the reposted message. This has important implications for the use of DKIM.
MLMは、メッセージを配信し、新しいメッセージとして再投稿したり、リストのメンバーに他のメッセージとともにダイジェストを作成したりする自律エージェントです（[メールアーチ]、セクション5.3を参照）。ただし、そのようなメッセージのフィールドから（非消化の場合）のRFC5322.が通常元のメッセージの分野と同じであり、その受信者はメッセージをMLMではなく「元の著者から」と認識しているという事実は、、再投稿されたメッセージの責任と自律性に関する混乱を引き起こします。これは、DKIMの使用に重要な意味を持ちます。
Section 3.3 describes some of the things MLMs commonly do that produce broken signatures, thus reducing the perceived value of DKIM.
セクション3.3では、MLMが一般的に行うことのいくつかについて、壊れた署名を生成し、DKIMの知覚値を減らします。
Further, while there are published standards that are specific to MLM behavior (e.g., [MAIL], [LIST-ID], and [LIST-URLS]), their adoption has been spotty at best. Hence, efforts to specify the use of DKIM in the context of MLMs need to be incremental and value-based.
さらに、MLMの動作に固有の公開された標準（[メール]、[List-ID]、[List-urls]）がありますが、それらの採用はせいぜいむらがあります。したがって、MLMSのコンテキストでDKIMの使用を指定する努力は、漸進的かつ価値ベースである必要があります。
Some MLM behaviors are well-established and their effects on DKIM signature validity can be argued as frustrating wider DKIM adoption. Still, those behaviors are not standards violations. Hence, this memo specifies practices for all parties involved, defining the minimum changes possible to MLMs themselves.
一部のMLM行動は確立されており、DKIMの署名の妥当性に対するそれらの影響は、より広いDKIMの採用をイライラさせると主張することができます。それでも、これらの行動は標準違反ではありません。したがって、このメモは、関係するすべての関係者のプラクティスを指定し、MLMS自体に可能な最小変更を定義します。
A DKIM signature on a message is an expression of some responsibility for the message taken by the signing domain. An open issue that is addressed by this document is the ways a signature might be used by a recipient's evaluation module, after the message has gone through a mailing list and might or might not have been rendered invalid. The document also considers how invalidation might have happened.
メッセージのDKIM署名は、署名ドメインが取得したメッセージに対する何らかの責任の表現です。このドキュメントで扱われる未解決の問題は、メッセージがメーリングリストを通過した後、受信者の評価モジュールによって署名が使用される方法であり、無効になった場合とされなかった可能性があります。ドキュメントでは、無効化がどのように発生したかを検討しています。
Note that where in this document there is discussion of an MLM conducting validation of DKIM signatures or Author Domain Signing Practices ([ADSP]) policies, the actual implementation could be one where the validation is done by the MTA or an agent attached to it, and the results of that work are relayed by a trusted channel not specified here. See [AUTH-RESULTS] for a discussion of this. This document does not favor any particular arrangement of these agents over another; it merely talks about the MLM itself doing the work as a matter of simplicity.
このドキュメントでは、DKIM署名または著者ドメイン署名プラクティス（[ADSP]）ポリシーの検証を実施するMLMの議論がある場合、実際の実装は、MTAまたはそれに付随するエージェントによって検証が行われる場所である可能性があることに注意してください。そして、その作業の結果は、ここでは指定されていない信頼できるチャネルによって中継されます。これについての議論については、[auth-results]を参照してください。このドキュメントは、これらのエージェントの特定の配置を他のエージェントよりも好まない。MLM自体が単純さの問題として作業を行っていることについて単に語っています。
A Feedback Loop (FBL) is a bilateral agreement between two parties to exchange reports of abuse. Typically, a sender registers with a receiving site to receive abuse reports from that site for mail coming from the sender.
フィードバックループ（FBL）は、虐待の報告を交換するための2つの当事者間の二国間合意です。通常、送信者は、送信者からのメールについて、そのサイトから悪用レポートを受け取るために受信サイトを登録します。
An FBL reporting address (i.e., an address to which FBL reports are sent) is part of this bilateral registration. Some FBLs require DKIM use by the registrant.
FBLレポートアドレス（つまり、FBLレポートが送信されるアドレス）は、この二国間登録の一部です。一部のFBLは、登録者がDKIMを使用する必要があります。
See Section 6 for additional discussion.
追加の議論については、セクション6を参照してください。
FBLs tend to use the [ARF] or the [IODEF] formats.
FBLは[ARF]または[IODEF]形式を使用する傾向があります。
This document provides discussion on the above issues to improve the handling of possible interactions between DKIM and MLMs. In general, the preference is to impose changes to behavior at the Signer and Verifier rather than at the MLM.
このドキュメントは、DKIMとMLMS間の可能な相互作用の処理を改善するための上記の問題に関する議論を提供します。一般に、好みは、MLMではなく署名者と検証者に行動に変化を課すことです。
Wherever possible, the document's discussion of MLMs is conceptually decoupled from MTAs despite the very tight integration that is sometimes observed in implementation. This is done to emphasize the functional independence of MLM services and responsibilities from those of an MTA.
可能な限り、MLMのドキュメントの議論は、実装で時々観察される非常に厳しい統合にもかかわらず、MTAから概念的に分離されています。これは、MTAのサービスと責任の機能的独立性を強調するために行われます。
Parts of this document explore possible changes to common practice by Signers, Verifiers, and MLMs. The suggested enhancements are largely predictive in nature, taking into account the current email infrastructure, the facilities DKIM can provide as it gains wider deployment, and working group consensus. There is no substantial implementation history upon which these suggestions are based, and their efficacy, performance, and security characteristics have not yet been fully explored.
このドキュメントの一部は、署名者、検証剤、およびMLMによる一般的な実践の可能な変更を調査します。推奨される拡張機能は、現在の電子メールインフラストラクチャを考慮して、DKIMがより広い展開を獲得し、ワーキンググループのコンセンサスを提供できる施設を考慮して、本質的に主に予測的です。これらの提案が基づいている実質的な実装履歴はなく、その有効性、パフォーマンス、セキュリティの特性はまだ完全には検討されていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[キーワード]で説明されているように解釈されます。
See [EMAIL-ARCH] for a general description of the current messaging architecture and for definitions of various terms used in this document.
現在のメッセージングアーキテクチャの一般的な説明と、このドキュメントで使用されているさまざまな用語の定義については、[メールアーチ]を参照してください。
Readers are encouraged to become familiar with [DKIM] and [ADSP], which are core specification documents, as well as [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
読者は、[dkim]と[adsp]に精通することをお勧めします。これは、[dkim-overview]と[dkim-deployment]（dkim-deployment]）です。
The term "DKIM-friendly" is used to describe an email intermediary that, when handling a message, makes no changes to the message that cause valid [DKIM] signatures present on the message on input to fail to verify on output.
「dkim-frendly」という用語は、メッセージを処理するときに、出力にメッセージに存在する有効な[dkim]署名を引き起こす有効な[dkim]署名を出力で確認しないというメッセージに変更を加えないという電子メール仲介を説明するために使用されます。
Various features of MTAs and MLMs seen as helpful to users often have side effects that do render DKIM signatures unverifiable. These would not qualify for this label.
MTAとMLMのさまざまな機能は、ユーザーに役立つと見なされるさまざまな機能に、DKIMシグネチャを検証できないようにする副作用がよくあります。これらはこのラベルの資格がありません。
A "message stream" identifies a group of messages originating from within an ADMD that are distinct in intent, origin, and/or use and partitions them somehow (e.g., via changing the value in the "d=" tag value in the context of DKIM) so as to keep them associated to users yet distinct in terms of their evaluation and handling by Verifiers or Receivers.
「メッセージストリーム」は、意図、起源、および/または使用および分割に明確なADMD内から発生するメッセージのグループを識別します（たとえば、「d =」タグ値の値を変更することにより、dkim）検証者または受信機による評価と取り扱いの点で、ユーザーに関連付けられていることを明確にしておくことができます。
A good example might be user mail generated by a company's employees, versus operational or transactional mail that comes from automated sources or marketing or sales campaigns. Each of these could have different sending policies imposed against them, or there might be a desire to insulate one from the other (e.g., a marketing campaign that gets reported by many spam filters could cause the marketing stream's reputation to degrade without automatically punishing the transactional or user streams).
良い例は、自動化されたソースまたはマーケティングまたは販売キャンペーンから来る運用または取引のメールと比較して、企業の従業員によって生成されたユーザーメールです。これらのそれぞれが異なる送信ポリシーを課している可能性があるか、片方のポリシーを互いに隔離したい場合があります（たとえば、多くのスパムフィルターによって報告されるマーケティングキャンペーンにより、トランザクションを自動的に罰することなくマーケティングストリームの評判が低下する可能性があります。またはユーザーストリーム）。
It is important to make some distinctions among different styles of intermediaries, their typical implementations, and the effects they have in a DKIM-aware environment.
さまざまなスタイルの仲介者、それらの典型的な実装、およびDKIMを意識した環境で持つ効果の間でいくつかの区別を作成することが重要です。
Across DKIM activities, there are several key roles in the transit of a message. Most of these are defined in [EMAIL-ARCH] but are reviewed here for quick reference.
DKIMアクティビティ全体で、メッセージの通過にはいくつかの重要な役割があります。これらのほとんどは[メールアーチ]で定義されていますが、ここでは迅速な参照のためにレビューされています。
Author: The agent that provided the content of the message being sent through the system. The Author delivers that content to the Originator in order to begin a message's journey to its intended final recipients. The Author can be a human using an MUA (Mail User Agent) or an automated process that may send mail (for example, the "cron" Unix system utility).
著者：システムを介して送信されるメッセージの内容を提供したエージェント。著者は、意図した最終受信者へのメッセージの旅を始めるために、そのコンテンツをオリジネーターに配信します。著者は、MUA（メールユーザーエージェント）を使用して人間であるか、メールを送信できる自動化されたプロセス（「Cron」UNIXシステムユーティリティなど）です。
Originator: The agent that accepts a message from the Author, ensures it conforms to the relevant standards such as [MAIL], and then sends it toward its destination(s). This is often referred to as the Mail Submission Agent (MSA).
Originator：著者からのメッセージを受け入れるエージェントは、[メール]などの関連する基準に適合してから、宛先に向かって送信します。これは、多くの場合、メール提出エージェント（MSA）と呼ばれます。
Signer: Any agent that affixes one or more DKIM signature(s) to a message on its way toward its ultimate destination. There is typically a Signer running at the MTA that sits between the Author's ADMD and the general Internet. The Originator and/or Author might also be a Signer.
署名者：1つ以上のDKIM署名を究極の目的地に向かう途中のメッセージに接続するエージェント。通常、著者のADMDと一般的なインターネットの間に位置するMTAで走っている署名者がいます。創始者および/または著者も署名者である可能性があります。
Verifier: Any agent that conducts DKIM signature validation. One is typically running at the MTA that sits between the public Internet and the Receiver's ADMD. Note that any agent that handles a signed message can conduct verification; this document only considers that action and its outcomes either at an MLM or at the Receiver. Filtering decisions could be made by this agent based on verification results.
Verifier：DKIM署名検証を実施するエージェント。1つは通常、パブリックインターネットと受信者のADMDの間にあるMTAで実行されています。署名されたメッセージを処理するエージェントは、検証を実施できることに注意してください。このドキュメントは、そのアクションとその結果のみをMLMまたはレシーバーで考慮します。検証結果に基づいて、このエージェントがフィルタリングを行うことができます。
Receiver: The agent that is the final transit relay for the message and performs final delivery to the recipient(s) of the message. Filtering decisions based on results made by the Verifier could be applied by the Receiver. The Verifier and the Receiver could be the same agent. This is sometimes the same as or coupled with the Mail Delivery Agent (MDA).
受信機：メッセージの最終トランジットリレーであり、メッセージの受信者に最終配信を実行するエージェント。検証剤による結果に基づく決定のフィルタリングは、受信機によって適用される可能性があります。検証剤とレシーバーは同じエージェントである可能性があります。これは、郵便配送エージェント（MDA）と同じまたは組み合わされることがあります。
In the case of simple user-to-user mail, these roles are fairly straightforward. However, when one is sending mail to a list and the mail then gets relayed to all of that list's subscribers, the roles are often less clear to the general user as particular agents may hold multiple important but separable roles. The above definitions are intended to enable more precise discussion of the mechanisms involved.
単純なユーザーからユーザーへのメールの場合、これらの役割はかなり簡単です。ただし、リストにメールを送信し、メールがすべてのリストのサブスクライバーに中継されると、特定のエージェントが複数の重要であるが分離可能な役割を保持する可能性があるため、役割は一般ユーザーにとってあまり明確ではないことがよくあります。上記の定義は、関連するメカニズムのより正確な議論を可能にすることを目的としています。
There are four common MLM implementation modes:
4つの一般的なMLM実装モードがあります。
aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one that makes no changes to the message itself as it redistributes; any modifications are constrained to changes to the [SMTP] envelope recipient list (RCPT commands) only. There are no changes to the message header or body at all, except for the addition of [MAIL] trace header fields. The output of such an MLM is considered to be a continuation of the Author's original message transit. An example of such an MLM is an address that
エイリアシング：エイリアシングMLM（[電子メールアーチ]のセクション5.1を参照）は、再分配されるときにメッセージ自体に変更を加えないものです。変更は、[SMTP]エンベロープ受信者リスト（RCPTコマンド）のみの変更に制約されます。[メール]トレースヘッダーフィールドの追加を除いて、メッセージヘッダーまたはボディに変更はまったくありません。このようなMLMの出力は、著者の元のメッセージトランジットの継続であると考えられています。そのようなMLMの例は、
expands directly in the MTA, such as a list of local system administrators used for relaying operational or other internal-only messages. See also Section 3.9.2 of [SMTP].
運用上のメッセージやその他の内部のみのメッセージを中継するために使用されるローカルシステム管理者のリストなど、MTAで直接拡張します。[SMTP]のセクション3.9.2も参照してください。
resending: A resending MLM (see Sections 5.2 and 5.3 of [EMAIL-ARCH]) is one that may make changes to a message. The output of such an MLM is considered to be a new message; delivery of the original has been completed prior to distribution of the reposted message. Such messages are often reformatted, such as with list-specific header fields or other properties, to facilitate discussion among list subscribers.
復活：復活MLM（[電子メール]のセクション5.2および5.3を参照）は、メッセージを変更する可能性のあるものです。このようなMLMの出力は、新しいメッセージと見なされます。元の配信は、再投稿されたメッセージの配布前に完了しました。リストサブスクライバー間の議論を容易にするために、このようなメッセージは、リスト固有のヘッダーフィールドやその他のプロパティなど、再フォーマットされます。
authoring: An authoring MLM is one that creates the content being sent as well as initiating its transport, rather than basing it on one or more messages received earlier. This is not a "mediator" in terms of [EMAIL-ARCH] since it originates the message, but after creation, its message processing and posting behavior otherwise do match the MLM paradigm. Typically, replies are not generated, or if they are, they go to a specific recipient and not back to the list's full set of recipients. Examples include newsletters and bulk marketing mail.
オーサリング：オーサリングMLMは、以前に受信した1つ以上のメッセージに基づいて、送信中のコンテンツを作成するだけでなく、その輸送を開始するものです。これはメッセージを発信するため[メールアーチ]という点では「メディエーター」ではありませんが、作成後、そのメッセージ処理と投稿の動作はMLMパラダイムと一致します。通常、返信は生成されません。または、もしそうであれば、特定の受信者に移動し、リストのフルセットの受信者に戻りません。例には、ニュースレターとバルクマーケティングメールが含まれます。
digesting: A special case of the resending MLM is one that sends a single message comprising an aggregation of recent MLM submissions, which might be a message of [MIME] type "multipart/ digest" (see [MIME-TYPES]). This is obviously a new message, but it may contain a sequence of original messages that may themselves have been DKIM-signed.
消化：RESENDING MLMの特別なケースは、[MIME]タイプ「MultiPart/ Digest」のメッセージである可能性がある最近のMLM提出の集約を含む単一のメッセージを送信するものです（[Mime-Typesを参照））。これは明らかに新しいメッセージですが、それ自体がDKIMに署名された可能性のある一連の元のメッセージが含まれている場合があります。
In the remainder of this document, we distinguish two relevant steps corresponding to the following SMTP transactions:
このドキュメントの残りの部分では、次のSMTPトランザクションに対応する2つの関連する手順を区別します。
MLM Input: Originating user is Author; originating ADMD is Originator and Signer; MLM's ADMD is Verifier; MLM's input function is Receiver.
MLM入力：元のユーザーは著者です。起源は発信者であり署名者です。MLMのADMDはVerifierです。MLMの入力関数はレシーバーです。
MLM Output: MLM (sending its reconstructed copy of the originating user's message) is Author; MLM's ADMD is Originator and Signer; the ADMD of each subscriber of the list is a Verifier; each subscriber is a Receiver.
MLM出力：MLM（元のユーザーのメッセージの再構築コピーの送信）は著者です。MLMのADMDは発信者であり署名者です。リストの各サブスクライバーのADMDは検証剤です。各サブスクライバーはレシーバーです。
Much of this document focuses on the resending class of MLM as it has the most direct conflict operationally with DKIM.
このドキュメントの多くは、DKIMとの運用上最も直接的な紛争を備えているため、MLMの復活クラスに焦点を当てています。
The dissection of the overall MLM operation into these two distinct phases allows the DKIM-specific issues with respect to MLMs to be isolated and handled in a logical way. The main issue is that the repackaging and reposting of a message by an MLM is actually the
これらの2つの異なるフェーズにMLM全体の操作を解剖することにより、MLMに関するDKIM固有の問題を、論理的な方法で分離して処理することができます。主な問題は、MLMによるメッセージの再梱包と再投稿が実際に
construction of a completely new message, and as such, the MLM is introducing new content into the email ecosystem, consuming the Author's copy of the message, and creating its own. When considered in this way, the dual role of the MLM and its ADMD becomes clear.
まったく新しいメッセージの構築、そのため、MLMは電子メールエコシステムに新しいコンテンツを導入し、著者のメッセージのコピーを消費し、独自のコピーを作成しています。このように考慮すると、MLMとそのADMDの二重の役割が明らかになります。
Some issues about these activities are discussed in Section 3.6.4 of [MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
これらの活動に関するいくつかの問題は、[メール]のセクション3.6.4および[電子メール]のセクション3.4.1で説明されています。
As described above, an aliasing MLM does not affect any existing signature, and an authoring MLM is always creating new content; thus, there is never an existing signature. However, the changes a resending MLM typically makes affect the RFC5322.Subject header field, the addition of some list-specific header fields, and/or the modification of the message body. The effects of each of these on DKIM verification are discussed below.
上記のように、エイリアシングMLMは既存の署名には影響しません。オーサリングMLMは常に新しいコンテンツを作成しています。したがって、既存の署名はありません。ただし、変更するMLMの変更により、通常、RFC5322.Subjectヘッダーフィールド、リスト固有のヘッダーフィールドの追加、および/またはメッセージ本文の変更に影響します。これらのそれぞれがDKIMの検証に及ぼす影響については、以下で説明します。
Subject tags: A popular feature of MLMs is the "tagging" of an RFC5322.Subject field by prefixing the field's contents with the name of the list, such as "[example]" for a list called "example". Altering the RFC5322.Subject field on new submissions by adding a list-specific prefix or suffix will invalidate the Signer's signature if that header field was included in the hash when creating that signature. Section 5.5 of [DKIM] lists RFC5322.Subject as one that should be covered as it contains important user-visible text, so this is expected to be an issue for any list that makes such changes.
サブジェクトタグ：MLMSの一般的な機能は、「例」と呼ばれるリストの「[例]」など、フィールドの内容をリストの名前に接頭することにより、RFC5322.Subjectフィールドの「タグ付け」です。リスト固有のプレフィックスまたはサフィックスを追加して、新しい提出物のrfc5322.subjectフィールドを変更すると、その署名を作成するときにそのヘッダーフィールドがハッシュに含まれている場合、署名者の署名が無効になります。[DKIM]のセクション5.5には、RFC5322.Subjectが重要なユーザー可視テキストが含まれているためカバーする必要があるものとしてリストされているため、これはそのような変更を行うリストの問題になると予想されます。
List-specific header fields: Some lists will add header fields specific to list administrative functions such as those defined in [LIST-ID] and [LIST-URLS] or the "Resent-" fields defined in [MAIL]. It is unlikely that a typical MUA would include such fields in an original message, and DKIM is resilient to the addition of header fields in general (see notes about the "h=" tag in Section 3.5 of [DKIM]). Therefore, this is not seen as a concern.
リスト固有のヘッダーフィールド：一部のリストでは、[list-id]および[list-urls]で定義されているものや[メール]で定義されている「resent-」フィールドなどの管理関数に固有のヘッダーフィールドを追加します。典型的なMUAが元のメッセージにそのようなフィールドを含める可能性は低く、DKIMは一般的なヘッダーフィールドの追加に復元されます（[dkim]のセクション3.5の「h =」タグに関するメモを参照）。したがって、これは懸念事項とは見なされません。
Other header fields: Some lists will add or replace header fields such as "Reply-To" or "Sender" in order to establish that the message is being sent in the context of the mailing list, so that the list is identified ("Sender") and any user replies go to the list ("Reply-To"). If these fields were included in the original message, it is possible that one or more of them may have been included in the signature hash, and those signatures will thus be broken.
その他のヘッダーフィールド：一部のリストは、メッセージがメーリングリストのコンテキストで送信されていることを確認するために、「返信」や「送信者」などのヘッダーフィールドを追加または置き換えます。"）そして、ユーザーの返信はリストに移動します（" Reply-to "）。これらのフィールドが元のメッセージに含まれている場合、それらの1つ以上が署名ハッシュに含まれている可能性があり、したがってそれらの署名が破損する可能性があります。
Minor body changes: Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, of list policy, etc. Changes to the body will alter the body hash computed at the DKIM Verifier, so these will render any existing signatures that cover those portions of the message body unverifiable. [DKIM] includes the capability to limit the length of the body covered by its body hash so that appended text will not interfere with signature validation, but this has security implications.
マイナーボディの変更：一部のリストは、各メッセージにいくつかのリストを追加または追加して、サブスクリプションの問題、リストポリシーなどの管理URLをサブスクライバーに思い出させます。身体の変更は、DKIM検証で計算されたボディハッシュを変更するため、これらはメッセージ本文のそれらの部分を検証できない既存の署名をレンダリングします。[DKIM]には、ボディハッシュで覆われた身体の長さを制限する機能が含まれているため、追加されたテキストが署名検証に干渉しないようにしますが、これにはセキュリティの意味があります。
Major body changes: There are some MLMs that make more substantial changes to message bodies when preparing them for redistribution, such as adding, deleting, reordering, or reformatting [MIME] parts, "flattening" HTML messages into plain text, or inserting headers or footers within HTML messages. Most or all of these changes will invalidate a DKIM signature.
主要な身体の変更：再配布の準備をする際にメッセージボディをより実質的に変更するMLMがあります。たとえば、[MIME]部品の追加、削除、再注文、再フォーマット、[HTMLメッセージのフラット化]を平易なテキストに「フラット化する、ヘッダーまたはヘッダーの挿入」HTMLメッセージ内のフッター。これらの変更のほとんどまたはすべては、DKIMの署名を無効にします。
MIME part removal: Some MLMs that are MIME-aware will remove large MIME parts from submissions and replace them with URLs to reduce the size of the distributed form of the message and to prevent inadvertent automated malware delivery. Except in some cases where a body length limit is applied in generation of the DKIM signature, the signature will be broken.
MIME部品の除去：MIME-AWAREの一部のMLMは、提出から大きなMIME部品を除去し、それらをURLに置き換えて、メッセージの分散形式のサイズを縮小し、不注意な自動マルウェア配信を防ぎます。DKIMの署名の生成に体の長さの制限が適用される場合を除き、署名は破損します。
There reportedly still exist some mailing lists in operation that are actually run manually by a human list manager, whose workings in preparing a message for distribution could include the above or even some other changes.
伝えられるところによると、実際には人間のリストマネージャーが手動で実行されるメーリングリストが存在しています。
In general, absent a general movement by MLM developers and operators toward more DKIM-friendly practices, an MLM subscriber cannot expect signatures applied before the message was processed by the MLM to be valid on delivery to a Receiver. Such an evolution is not expected in the short term due to general development and deployment inertia. Moreover, even if an MLM currently passes messages unmodified such that Author signatures validate, it is possible that a configuration change or software upgrade to that MLM will cause that no longer to be true.
一般に、MLM開発者とオペレーターによるよりDKIMに優しいプラクティスに向けて一般的な動きがなければ、MLMサブスクライバーは、メッセージがMLMによって処理される前に、受信者への配信時に有効であるとメッセージが処理される前に適用される署名を期待できません。このような進化は、一般的な開発と展開慣性のために短期的には予想されません。さらに、MLMが現在署名が検証されるように修正されていないメッセージを渡している場合でも、そのMLMへの構成の変更またはソフトウェアのアップグレードにより、それはもはや真実ではない可能性があります。
This section contains a discussion of issues regarding sending DKIM-signed mail to or through an MLM that is not DKIM-aware. Specifically, the header fields introduced by [DKIM] and [AUTH-RESULTS] carry no special meaning to such an MLM.
このセクションには、DKIMに署名したMLMを介して、DKIM-AwareではないMLMを介して、DKIMに署名したメールの送信に関する問題の議論が含まれています。具体的には、[dkim]と[auth-results]によって導入されたヘッダーフィールドは、そのようなMLMに特別な意味を持ちません。
In an idealized world, if an Author knows that the MLM to which a message is being sent is a non-participating resending MLM, the Author needs to be cautious when deciding whether or not to send a signed message to the list. The MLM could make a change that would invalidate the Author's signature but not remove it prior to redistribution. Hence, list recipients would receive a message purportedly from the Author but bearing a DKIM signature that would not verify. Some mail filtering software incorrectly penalizes a message containing a DKIM signature that fails verification. This may have detrimental effects outside of the Author's control. (Additional discussion of this is below.) This problem can be compounded if there are Receivers that apply signing policies (e.g., [ADSP]) and the Author publishes any kind of strict policy, i.e., a policy that requests that Receivers reject or otherwise deal severely with non-compliant messages.
理想化された世界では、著者がメッセージが送信されているMLMが参加していないMLMであることを知っている場合、著者は署名入りのメッセージをリストに送信するかどうかを決定する際に注意する必要があります。MLMは、著者の署名を無効にするが、再分配する前にそれを削除しない変更を加えることができます。したがって、リストの受信者は、著者からのメッセージを受け取るが、検証されないDKIMの署名を担当するメッセージを受け取ります。一部のメールフィルタリングソフトウェアは、検証に失敗するDKIM署名を含むメッセージを誤ってペナルティします。これは、著者のコントロール以外で有害な影響を与える可能性があります。（これについての追加の議論は以下を示します。）この問題は、署名ポリシー（[ADSP]など）を適用する受信者がある場合、著者があらゆる種類の厳格なポリシー、つまり受信者が拒否またはそれ以外の場合は要求するポリシーを公開している場合にさらに複雑にすることができます。準拠していないメッセージに厳しく対処します。
For domains that do publish strict ADSP policies, the originating site SHOULD use a separate message stream (see Section 2.5), such as a signing and Author subdomain, for the "personal" mail -- a subdomain that is different from domain(s) used for other mail streams. This allows each to develop an independent reputation, and more stringent policies (including ADSP) can be applied to the mail stream(s) that do not go through mailing lists or perhaps do not get signed at all.
厳格なADSPポリシーを公開するドメインの場合、発信元のサイトは、「個人」メールの署名や著者サブドメインなどの個別のメッセージストリーム（セクション2.5を参照）を使用する必要があります。他のメールストリームに使用されます。これにより、それぞれが独立した評判を育てることができ、より厳しいポリシー（ADSPを含む）をメールストリームに適用することができます。
However, all of this presupposes a level of infrastructure understanding that is not expected to be common. Thus, it will be incumbent upon site administrators to consider how support of users wishing to participate in mailing lists might be accomplished as DKIM achieves wider adoption.
ただし、これはすべて、一般的であるとは予想されていないインフラストラクチャのレベルの理解を前提としています。したがって、DKIMがより広範な採用を達成するにつれて、メーリングリストに参加したいユーザーのサポートがどのように達成されるかを検討することは、サイト管理者に義務付けられます。
In general, the stricter practices and policies are likely to be successful only for the mail streams subject to the most end-to-end control by the originating organization. That typically excludes mail going through MLMs. Therefore, site administrators wishing to employ ADSP with a "discardable" setting SHOULD separate the controlled mail stream warranting this handling from other mail streams that are less controlled, such as personal mail that transits MLMs. (See also Section 5.7 below.)
一般に、より厳しい慣行とポリシーは、発信元の組織による最もエンドツーエンドの制御の対象となるメールストリームのみで成功する可能性があります。通常、MLMSを使用するメールは除外されます。したがって、「廃棄可能な」設定でADSPを使用したいサイト管理者は、MLMをトランジングする個人メールなど、この取り扱いがあまり制御されていない他のメールストリームから保証する制御されたメールストリームを分離する必要があります。（以下のセクション5.7も参照してください。）
There is no reliable way to determine that a piece of mail arrived via a non-participating MLM. Sites whose users subscribe to non-participating MLMs SHOULD ensure that such user mail streams are not subject to strict DKIM-related handling policies.
参加していないMLMを介してメールが到着したことを判断する信頼できる方法はありません。ユーザーが参加していないMLMを購読しているサイトは、そのようなユーザーメールストリームが厳格なDKIM関連の処理ポリシーの対象ではないことを保証する必要があります。
In order to exempt some mail from the expectation of signature verification, as discussed in Section 4.1, receiving ADMDs would need to register non-participating lists and confirm that mail transited them. However, such an approach requires excessive effort and even then is likely to be unreliable. Hence, it is not a scalable solution.
セクション4.1で説明したように、署名の検証の期待から郵便を免除するために、受け取ることは、参加していないリストを登録し、メールがそれらを通過したことを確認する必要があります。ただし、このようなアプローチには過度の努力が必要であり、それでも信頼できない可能性があります。したがって、それはスケーラブルなソリューションではありません。
Any treatment of a verification failure as having special meaning is a violation of the basic DKIM Signatures specification [DKIM]. The only valid, standardized basis for going beyond that specification is with specific ADSP direction.
特別な意味を持つ検証障害の扱いは、基本的なDKIM署名仕様[DKIM]の違反です。その仕様を超える唯一の有効で標準化された基盤は、特定のADSP方向を使用することです。
Use of restrictive domain policies such as [ADSP] "discardable" presents an additional challenge. In that case, when a message is unsigned or the signature can no longer be verified, discarding of the message is requested. There is no exception in the policy for a message that may have been altered by an MLM, nor is there a reliable way to identify such mail. Therefore, participants SHOULD honor the policy and disallow the message.
[ADSP]「廃棄可能」などの制限ドメインポリシーの使用は、追加の課題を提示します。その場合、メッセージが署名されていない場合、または署名を検証できなくなった場合、メッセージの破棄が要求されます。ポリシーには、MLMによって変更された可能性のあるメッセージについて例外はありません。また、そのようなメールを識別する信頼できる方法もありません。したがって、参加者はポリシーを尊重し、メッセージを禁止する必要があります。
One approach for adding DKIM support to an otherwise non-participating MLM is to "wrap" the MLM or, in essence, place it between other DKIM-aware components (such as MTAs) that provide some DKIM services. For example, the ADMD operating a non-participating MLM could have its DKIM Verifier act on messages from list subscribers, enforcing some of the features and recommendations of Section 5 on behalf of the MLM, and the MTA or MSA receiving the MLM Output could also add a DKIM signature for the MLM's domain.
DKIMサポートを他の点では参加していないMLMに追加するための1つのアプローチは、MLMを「ラップ」するか、本質的に、DKIMサービスを提供する他のDKIM対応コンポーネント（MTAなど）の間に配置することです。たとえば、参加していないMLMを操作しているADMDは、リストサブスクライバーからのメッセージにDKIM検証を行うことができ、MLMに代わってセクション5の機能と推奨事項の一部を実施することができ、MLM出力を受信するMTAまたはMSAもMLMのドメインにDKIM署名を追加します。
This section contains a discussion of issues regarding DKIM-signed mail that transits an MLM that is DKIM-aware.
このセクションには、DKIM-AwareのMLMを通過するDKIMに署名したメールに関する問題の議論が含まれています。
Changes that merely add new header fields, such as those specified by [LIST-ID], [LIST-URLS], and [MAIL], are generally the most friendly to a DKIM-participating email infrastructure. Their addition by an MLM will not affect any existing DKIM signatures unless those fields were already present and covered by a signature's hash, or a signature was created specifically to disallow their addition (see the note about "h=" in Section 3.5 of [DKIM]).
[list-id]、[list-urls]、および[mail]で指定されたものなど、新しいヘッダーフィールドを追加するだけの変更は、一般にDKIMに参加する電子メールインフラストラクチャに最も友好的です。MLMによる追加は、それらのフィールドがすでに存在し、署名のハッシュでカバーされていない場合を除き、既存のDKIM署名には影響しません。]）。
However, the practice of applying headers and footers to message bodies is common and not expected to fade regardless of what documents any standards body might produce. This sort of change will invalidate the signature on a message where the body hash covers the entire message. Thus, the following sections also discuss and suggest other processing alternatives.
ただし、メッセージボディにヘッダーとフッターを適用する慣行は一般的であり、ボディが生成する基準の文書に関係なくフェードすることは期待されていません。この種の変更は、ボディハッシュがメッセージ全体をカバーするメッセージの署名を無効にします。したがって、次のセクションでは、他の処理の代替案についても説明し、提案します。
A possible mitigation to this incompatibility is use of the "l=" tag to bound the portion of the body covered by the DKIM body hash, but this is not workable for [MIME] messages; moreover, it has security considerations (see Section 3.5 of [DKIM]). Therefore, its use is discouraged.
この非互換性に対する緩和の可能性は、「l =」タグを使用して、dkimボディハッシュで覆われた体の部分をバインドすることですが、これは[mime]メッセージでは実行できません。さらに、セキュリティ上の考慮事項があります（[DKIM]のセクション3.5を参照）。したがって、その使用は落胆します。
Expressions of list-specific policy (e.g., rules for participation, small advertisements, etc.) are often added to outgoing messages by MLM operators. There is currently no header field proposed for relaying such general operational MLM details apart from what [LIST-URLS] already supports. This sort of information is commonly included footer text appended to the body of the message or header text prepended above the original body. It is RECOMMENDED that periodic, automatic mailings to the list are sent to remind subscribers of list policy. It is also RECOMMENDED that standard header fields, rather than body changes, be used to express list operation parameters. These periodic mailings will be repetitive, of course, but by being generally the same each time, they can be easily filtered if desired.
リスト固有のポリシーの表現（例：参加、小さな広告などのルールなど）は、MLMオペレーターによる発信メッセージにしばしば追加されます。現在、[List-urls]がすでにサポートしているものとは別に、このような一般的な運用MLMの詳細を中継するために提案されているヘッダーフィールドはありません。この種の情報は、一般に、元の本体の上に前に完成したメッセージまたはヘッダーテキストの本文に追加されたフッターテキストが含まれています。リストへの定期的な自動郵送は、リストポリシーを加入者に思い出させるために送信することをお勧めします。また、ボディの変化ではなく、標準のヘッダーフィールドを使用して、リスト操作パラメーターを表現することをお勧めします。もちろん、これらの定期的な郵送は繰り返されますが、一般的に毎回同じであることにより、必要に応じて簡単にフィルタリングできます。
ADSP presents a particular challenge. An Author domain posting a policy of "discardable" imposes a very tight restriction on the use of mailing lists, essentially constraining that domain's users to lists operated by aliasing MLMs only; any MLM that alters a message from such a domain or removes its signature subjects the message to severe action by Verifiers or Receivers. A resending MLM SHOULD reject outright any mail from an Author whose domain posts such a policy, as those messages are likely to be discarded or rejected by any ADSP-aware recipients. See also the discussion in Section 5.3.
ADSPは特定の課題を提示します。「破棄可能」のポリシーを投稿する著者ドメインは、メーリングリストの使用に非常に厳しい制限を課し、MLMのみをエイリアシングすることによって操作されるリストをドメインのユーザーに本質的に制約します。このようなドメインからのメッセージを変更するMLMまたはその署名を削除すると、検証剤または受信機による厳しいアクションへのメッセージを署名します。復活MLMは、これらのメッセージがADSPに認識された受信者によって破棄または拒否される可能性が高いため、ドメインがそのようなポリシーを投稿する著者からの任意のメールを完全に拒否する必要があります。セクション5.3の説明も参照してください。
Where such rejection of "discardable" mail is not enforced, and such mail arrives to a Verifier that applies ADSP checks that fail, the message SHOULD be either discarded (i.e., accept the message at the [SMTP] level but discard it without delivery) or rejected by returning a 5xx error code. In the latter case, some advice for how to conduct the rejection in a potentially meaningful way can be found in Section 5.11.
「廃棄可能な」メールのそのような拒否が施行されておらず、そのようなメールが故障するADSPチェックを適用する検証剤に到着する場合、メッセージは廃棄する必要があります（つまり、[SMTP]レベルでメッセージを受け入れますが、配信なしでそれを破棄します）または、5xxエラーコードを返すことにより拒否されます。後者の場合、潜在的に意味のある方法で拒否を行う方法についてのアドバイスは、セクション5.11にあります。
The reason for these recommendations is best illustrated by example. Suppose the following:
これらの推奨事項の理由は、例で最もよく示されています。次のとおりです。
o users U1 and U2 are subscribers of list L;
o ユーザーU1とU2はリストLのサブスクライバーです。
o U1 is within an ADMD that advertises a "discardable" policy using ADSP;
o U1は、ADSPを使用して「廃棄可能な」ポリシーを宣伝するADMDの範囲内です。
o L alters submissions prior to resending in a way that invalidates the DKIM signature added by U1's ADMD;
o lは、U1のADMDが追加したDKIM署名を無効にする方法で、控える前に提出物を変更します。
o U2's ADMD enforces ADSP at the border by issuing an SMTP error code; and
o U2のADMDは、SMTPエラーコードを発行することにより、境界線でADSPを実施します。と
o L is configured to remove subscribers whose mail is bouncing.
o Lは、メールがバウンスしている加入者を削除するように構成されています。
It follows then that a submission to L from U1 will be received at U2, but since the DKIM signature fails to verify, U2's ADMD will reject it based on the ADSP protocol. That rejection is received at L, which proceeds to remove U2 from the list.
そのため、U1からLへの提出がU2で受信されますが、DKIMの署名が検証できないため、U2のADMDはADSPプロトコルに基づいて拒否します。その拒否はLで受け取られ、リストからU2を削除するようになります。
See also Appendix B.5 of [ADSP] for further discussion.
詳細については、[ADSP]の付録B.5も参照してください。
At subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain. If the policy specifies "discardable", the MLM SHOULD disallow the subscription or present a warning that the subscriber's submissions to the mailing list might not be deliverable to some recipients because of the published policy of the subscriber's ADMD.
サブスクリプション時に、ADSPを認識したMLMは、新しいサブスクライバーのドメインの公開されたADSPレコードを確認する必要があります。ポリシーが「廃棄可能」を指定した場合、MLMはサブスクリプションを許可するか、サブスクライバーのメーリングリストへの提出がサブスクライバーのADMDの公開ポリシーのために一部の受信者に配信できないという警告を提示する必要があります。
Of course, such a policy record could be created after subscription, so this is not a universal solution. An MLM implementation MAY do periodic checks of its subscribers and issue warnings where such a policy is detected or simply check upon each submission.
もちろん、このようなポリシー記録はサブスクリプション後に作成される可能性があるため、これは普遍的な解決策ではありません。MLMの実装は、サブスクライバーの定期的なチェックを行い、そのようなポリシーが検出された場合に警告を発行するか、各提出物を確認することができます。
Where an ADMD has established some out-of-band trust agreement with another ADMD such that an Authentication-Results field applied by one is trusted by the other, the above recommendations for MLM operation with respect to ADSP do not apply because it is then possible to establish whether or not a valid Author signature can be inferred even if one is not present on receipt.
ADMDが別のADMDとの帯域外の信託契約を確立した場合、1つによって適用される認証応答フィールドが他方によって信頼されるように、ADSPに関するMLM操作に関する上記の推奨事項は、それが可能であるため適用されません。有効な著者の署名が領収書に存在しない場合でも、有効な著者の署名を推測できるかどうかを確立するため。
For example, suppose domains example.com and example.net have an explicit agreement to trust one another's authentication assertions. Now, consider a message with an RFC5322.From domain of "example.org" that is also bearing a valid DKIM signature by the same domain, which arrives at a mailing list run by example.com. Upon evaluation, example.com validates the signature and adds an [AUTH-RESULTS] field indicating this. However, the MLM also makes changes to the message body that invalidate the signature. The MLM then re-signs the modified message using DKIM and sends it on to the list's subscribers, one of whom is at example.net.
たとえば、domains example.comとexample.netには、互いの認証アサーションを信頼する明示的な合意があると仮定します。次に、rfc5322.のrfc5322を含むメッセージを検討してください。「embles.org」のドメインは、同じドメインによって有効なdkim署名も搭載されており、example.comが実行するメーリングリストに到着します。評価時に、Example.comは署名を検証し、これを示す[Auth-Results]フィールドを追加します。ただし、MLMは、署名を無効にするメッセージ本文に変更を加えます。次に、MLMはDKIMを使用して変更されたメッセージを再署名し、リストのサブスクライバーに送信します。
On arrival at example.net, the DKIM signature for example.org is no longer valid, so ADSP would generally fail. However, example.net trusts the assertion of example.com's Authentication-Results field that indicated that there was a valid signature from example.org, so the ADSP failure can be ignored.
example.netに到着すると、dkim署名は有効ではなくなるため、一般にADSPは失敗します。ただし、example.NETは、example.orgから有効な署名があることを示すexample.comの認証応答フィールドのアサーションを信頼しているため、ADSP障害は無視できます。
An important consideration is that Authors rarely have any direct influence over the management of an MLM. Specifically, the behavior of an intermediary (e.g., an MLM that is not careful about filtering out junk mail or being diligent about unsubscription requests) can trigger recipient complaints that reflect back on those agents that appear to be responsible for the message, in this case an Author via the address found in the RFC5322.From field. In the future, as DKIM signature outputs (i.e., the signing domain) are used as inputs to reputation modules, there may be a desire to insulate one's reputation from influence by the unknown results of sending mail through an MLM. In that case, Authors SHOULD create a mail stream specifically used for generating DKIM signatures when sending traffic to MLMs.
重要な考慮事項は、著者がMLMの管理に直接影響を与えることはめったにないことです。具体的には、仲介者の動作（たとえば、ジャンクメールのフィルタリングやサブスクリプションのリクエストについて勤勉であることに注意しないMLM）は、メッセージの原因と思われるエージェントを反映する受信者の苦情を引き起こす可能性があります。rfc5322.from from from from from from from the dordressを介した著者。将来的には、DKIMの署名出力（つまり、署名ドメイン）が評判モジュールへの入力として使用されるため、MLMを介してメールを送信することの未知の結果によって影響から人の評判を隔離したいという願望があるかもしれません。その場合、著者は、MLMにトラフィックを送信するときにDKIM署名を生成するために特別に使用されるメールストリームを作成する必要があります。
This suggestion can be made more general. Mail that is of a transactional or generally end-to-end nature, and not likely to be forwarded around by either MLMs or users, SHOULD be signed with a mail stream identifier different from that used for a stream that serves more varied uses.
この提案はより一般的にすることができます。トランザクションまたは一般的にエンドツーエンドの性質であり、MLMSまたはユーザーのいずれかによって転送される可能性は低いメールは、より多様な用途を提供するストリームに使用されるものとは異なるメールストリーム識別子で署名する必要があります。
MLMs typically attempt to authenticate messages posted through them. They usually do this through the trivial (and insecure) means of verifying the RFC5322.From field email address (or, less frequently, the RFC5321.MailFrom parameter) against a list subscription registry. DKIM enables a stronger form of authentication: the MLM can require that messages using a given RFC5322.From address also have a DKIM
MLMは通常、それらを介して投稿されたメッセージを認証しようとします。彼らは通常、RFC5322を検証する些細な（および不安定な）手段を通じてこれを行います。DKIMはより強力な形式の認証を有効にします：MLMは、特定のRFC5322を使用してメッセージを要求できます。
signature with a corresponding "d=" domain. This feature would be somewhat similar to using ADSP, except that the requirement for it would be imposed by the MLM and not the Author's organization.
対応する「d =」ドメインを使用した署名。この機能は、ADSPの使用に多少似ていますが、著者の組織ではなくMLMによってその要件が課されることを除きます。
(Note, however, that this goes beyond DKIM's documented semantics. It is presented as a possible workable enhancement.)
（ただし、これはDKIMの文書化されたセマンティクスを超えていることに注意してください。実行可能な強化の可能性として提示されています。）
As described, the MLM might conduct DKIM verification of a signed message to attempt to confirm the identity of the Author. Although it is a common and intuitive conclusion, few signed messages will include an Author signature (see [ADSP]). MLM implementers adding such support would have to accommodate this. For example, an MLM might be designed to accommodate a list of possible signing domains (the "d=" portion of a DKIM signature) for a given Author and determine at verification time if any of those are present. This enables a more reliable method of authentication at the expense of having to store a mapping of authorized signing domains for subscribers and trusting that it will be kept current.
説明されているように、MLMは署名されたメッセージのDKIM検証を実施して、著者の身元を確認しようとするかもしれません。それは一般的で直感的な結論ですが、著者の署名を含む署名されたメッセージはほとんどありません（[ADSP]を参照）。このようなサポートを追加するMLM実装者は、これに対応する必要があります。たとえば、MLMは、特定の著者の署名ドメインの可能性（dkim署名の「d =」部分）のリストに対応し、検証時にそれらのいずれかが存在するかどうかを決定するように設計されている場合があります。これにより、サブスクライバーのための承認された署名ドメインのマッピングを保存し、最新の状態に保つと信頼することを犠牲にして、より信頼性の高い認証方法が可能になります。
A message that cannot be thus authenticated MAY be held for moderation or rejected outright.
したがって、認証できないメッセージは、節度のために保持されるか、完全に拒否される場合があります。
This logic could apply to any list operation, not just list submission. In particular, this improved authentication MAY apply to subscription, unsubscription, and/or changes to subscriber options that are sent via email rather than through an authenticated, interactive channel such as the web.
このロジックは、リストの提出だけでなく、任意のリスト操作に適用できます。特に、この改善された認証は、Webなどの認証されたインタラクティブなチャネルではなく、電子メールで送信されるサブスクリプション、および/またはサブスクライバーオプションの変更に適用される場合があります。
In the case of verification of signatures on submissions, MLMs SHOULD add an [AUTH-RESULTS] header field to indicate the signature(s) observed on the submission as it arrived at the MLM and what the outcome of the evaluation was. Downstream agents might or might not trust the content of that header field depending on their own a priori knowledge of the operation of the ADMD generating (and, preferably, signing) that header field. See [AUTH-RESULTS] for further discussion.
提出に関する署名の検証の場合、MLMは[認証]ヘッダーフィールドを追加して、MLMに到達した際に提出時に観察された署名と評価の結果を示す必要があります。ダウンストリームエージェントは、ヘッダーフィールドの生成（そしてできれば署名）の操作に関する先験的な知識に応じて、そのヘッダーフィールドのコンテンツを信頼する場合と信頼している場合があります。詳細については、[auth-results]を参照してください。
A message that arrives signed with DKIM means some domain prior to MLM Input has made a claim of some responsibility for the message. An obvious benefit to leaving the input-side signatures intact, then, is to preserve that original assertion of responsibility for the message so that the Receivers of the final message have an opportunity to evaluate the message with that information available to them.
DKIMで署名されたメッセージは、MLM入力の前にいくつかのドメインがメッセージに対するある程度の責任を主張したことを意味します。入力側の署名をそのまま残すことの明らかな利点は、最終メッセージの受信者がその情報を利用できる情報を評価する機会を持つように、メッセージに対する責任の元の主張を保持することです。
However, if the MLM is configured to make changes to the message prior to reposting that would invalidate the original signature(s), further action is RECOMMENDED to prevent invalidated signatures from arriving at final recipients, possibly triggering unwarranted filter actions. (Note, however, that such filtering actions are plainly wrong; [DKIM] stipulates that an invalid signature is to be treated as no signature at all.)
ただし、元の署名を無効にする再投稿前にメッセージを変更するようにMLMが構成されている場合、無効な署名が最終受信者に到着するのを防ぎ、おそらく不当なフィルターアクションを引き起こすことを防ぐために、さらなるアクションが推奨されます。（ただし、そのようなフィルタリングアクションは明らかに間違っていることに注意してください。[DKIM]は、無効な署名がまったく署名として扱われることを規定しています。
A possible solution would be to:
可能な解決策は次のとおりです。
1. Attempt verification of all DKIM signatures present on the input message;
1. 入力メッセージに存在するすべてのDKIM署名の検証を試みます。
2. Apply local policy to authenticate the identity of the Author;
2. 著者の身元を認証するためにローカルポリシーを適用します。
3. Remove all existing [AUTH-RESULTS] fields (optional);
3. 既存のすべての[auth-results]フィールド（オプション）を削除します。
4. Add an [AUTH-RESULTS] header field to the message to indicate the results of the above;
4. [Auth-Results]ヘッダーフィールドをメッセージに追加して、上記の結果を示します。
5. Remove all previously evaluated DKIM signatures;
5. 以前に評価されたすべてのDKIM署名を削除します。
6. Affix a new signature that includes in its hashes the entire message on the output side, including the Authentication-Results header field just added (see Section 5.8).
6. 追加されたAuthentication-Results Headerフィールドを含む、出力側のメッセージ全体をハッシュすることを含む新しい署名を貼り付けます（セクション5.8を参照）。
Removing the original signature(s) seems particularly appropriate when the MLM knows it is likely to invalidate any or all of them due to the nature of the reformatting it will do. This avoids false negatives for list subscribers in their roles as Receivers of the message; although [DKIM] stipulates that an invalid signature is the same as no signature, it is anticipated that there will be some implementations that ignore this advice.
元の署名を削除することは、MLMが、それが行う改良の性質のためにそれらのいずれかまたはすべてを無効にする可能性が高いことを知っている場合、特に適切と思われます。これにより、メッセージの受信者としての役割におけるリストサブスクライバーの誤ったネガが回避されます。[dkim]は、無効な署名が署名なしと同じであると規定していますが、このアドバイスを無視するいくつかの実装があると予想されます。
The MLM could re-evaluate existing signatures after making its message changes to determine whether or not any of them have been invalidated. The cost of this is reduced by the fact that, presumably, the necessary public keys have already been downloaded and one or both of the message hashes could be reused.
MLMは、メッセージ変更を行った後に既存の署名を再評価して、それらのいずれかが無効になっているかどうかを判断することができます。これのコストは、おそらく必要な公開キーがすでにダウンロードされており、メッセージの1つまたは両方が再利用できるという事実によって削減されます。
Per the discussion in [AUTH-RESULTS], a Receiver's choice to put any faith in the veracity of the header field requires an a priori assessment of the agent that created it. Absent that assessment, a Receiver cannot interpret the field as valid. Thus, the final recipients of the message have no way to verify on their own the authenticity of the Author's identity on that message. However, if that field is the only one on the message when the Verifier gets it, and the Verifier explicitly trusts the Signer that included the
[auth-results]の議論によると、ヘッダーフィールドの真実性に信頼を置くという受信者が選択するには、それを作成したエージェントの先験的評価が必要です。その評価がなければ、受信者はフィールドを有効であると解釈することはできません。したがって、メッセージの最終的な受信者は、そのメッセージに対する著者のアイデンティティの信ity性を自分で確認する方法がありません。ただし、そのフィールドがVerifierがそれを取得したときにメッセージの唯一のフィールドであり、Verifierがを含む署名者を明示的に信頼している場合
Authentication-Results field in its header hash (in this case, the MLM), the Verifier is in a position to believe that a valid Author signature was present on the message.
ヘッダーハッシュ（この場合はMLM）に認証結果がフィールドに、検証剤は、有効な著者署名がメッセージに存在していると信じる立場にあります。
This can be generalized as follows: a Receiver SHOULD consider only [AUTH-RESULTS] fields bearing an authserv-id that appears in a list of sites the Receiver trusts and that is also included in the header hash of a [DKIM] signature added by a domain in the same trusted list.
これは次のように一般化できます。受信者は、受信機が信頼しているサイトのリストに表示され、[dkim]署名のヘッダーハッシュに含まれる[auth-results] authserv-idのみを考慮する必要があります。同じ信頼できるリストのドメイン。
Since an aliasing MLM makes no substantive changes to a message, it need not consider the issue of signature removal as the original signatures should at least arrive to the next MTA unmodified. It is possible that future domain-based reputations would prefer a richer data set on receipt of a message, and, in that case, signature removal would be undesirable.
エイリアシングMLMはメッセージに実質的な変更を加えることはないため、元の署名は少なくとも次のMTAに到着する必要があるため、署名削除の問題を考慮する必要はありません。将来のドメインベースの評判は、メッセージの受信時により豊富なデータセットを好む可能性があり、その場合、署名の削除は望ましくありません。
An authoring MLM is closed to outside submitters; thus, much of this discussion does not apply in that case.
オーサリングMLMは外部の提出者に閉鎖されています。したがって、この議論の多くはその場合には適用されません。
DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own signatures when distributing messages. The MLM is responsible for the alterations it makes to the original messages it is resending and should express this via a signature. This is also helpful for getting feedback from any FBLs that might be set up so that undesired list mail can generate appropriate action.
DKIM-AWARE RESHENDING MLMSおよびAuthoring MLMは、メッセージを配布するときに独自の署名を貼り付ける必要があります。MLMは、復活している元のメッセージに対して行う変更を担当し、署名を介してこれを表現する必要があります。これは、望ましくないリストメールが適切なアクションを生成できるように、セットアップされる可能性のあるFBLからフィードバックを取得するのにも役立ちます。
MLM signatures will likely be used by recipient systems to recognize list mail, and they give the MLM's ADMD an opportunity to develop a good reputation for the list itself.
MLM署名は、受信者システムがリストメールを認識するために使用する可能性が高く、MLMのADMDにリスト自体に対して良い評判を得る機会を与えます。
A signing MLM, as any other MLM, is free to omit redistribution of a message if that message was not signed in accordance with its own local configuration or policy. It could also redistribute but not sign such mail. However, selective signing is NOT RECOMMENDED; essentially that would create two message streams from the MLM, one signed and one not, which can confuse DKIM-aware Verifiers and Receivers.
他のMLMと同様に、署名MLMは、そのメッセージが独自のローカル構成またはポリシーに従って署名されていない場合、メッセージの再配布を自由に省略できます。また、そのようなメールに署名することはできませんが、再配布することもできます。ただし、選択的な署名は推奨されません。基本的に、それはMLMから2つのメッセージストリームを作成します。1つは署名され、もう1つはDKIMに認識された検証剤とレシーバーを混乱させることができます。
A signing MLM could add a List-Post: header field (see [LIST-URLS]) using the DNS domain matching the one used in the "d=" tag of the DKIM signature that is added by the MLM. This can be used by Verifiers or Receivers to identify the DKIM signature that was added by the MLM. This is not required, however; it is believed the
署名MLMは、MLMによって追加されたDKIM署名の「d =」タグで使用されたドメインと一致するDNSドメインを使用して、list-post：headerフィールド（[list-urls]を参照）を追加できます。これは、Verifiersまたは受信機がMLMによって追加されたDKIM署名を識別するために使用できます。ただし、これは必要ありません。それは信じられています
reputation of the Signer will be a more critical data point than this suggested binding. Furthermore, this is not a binding recognized by any current specification document.
署名者の評判は、これが示唆する拘束力よりも重要なデータポイントになります。さらに、これは現在の仕様文書によって認識される拘束力ではありません。
A DKIM-aware resending MLM SHOULD sign the entire message after the message is prepared for distribution (i.e., the MLM Output from Section 3.2). Any other configuration might generate signatures that will not validate.
DKIMを認識しているMLMは、メッセージが配布用に準備された後、メッセージ全体に署名する必要があります（つまり、セクション3.2からのMLM出力）。他の構成は、検証されない署名を生成する場合があります。
DKIM-aware authoring MLMs sign the mail they send according to the regular signing guidelines given in [DKIM].
DKIM-AWARE AUTHORING MLMSは、[DKIM]で与えられた通常の署名ガイドラインに従って送信されるメールに署名します。
One concern is that having an MLM apply its signature to unsigned mail might cause some Verifiers or Receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is, nevertheless, worth noting here.
懸念事項の1つは、MLMに署名を署名していないメールに適用すると、[DKIM]で定義されているよりも多くの権限または信ity性をメッセージコンテンツに付与するものとして、いくつかの検証者または受信機が署名を解釈する可能性があることです。これはMLMを超えた問題であり、主に[dkim]の範囲外で受信側の処理を伴います。それにもかかわらず、ここで注目する価値があります。
In general, Verifiers and Receivers SHOULD treat a signed message from an MLM like any other signed message; indeed, it would be difficult to discern any difference since specifications such as [LIST-URLS] and [LIST-ID] are not universally deployed and can be trivially spoofed.
一般に、Verifiersと受信機は、他の署名されたメッセージと同様に、MLMから署名されたメッセージを扱う必要があります。実際、[list-urls]や[list-id]などの仕様が普遍的に展開されず、些細なスプーフィングが可能であるため、違いを識別することは困難です。
However, because the Author domain will commonly be different from the MLM's signing domain, there may be a conflict with [ADSP] as discussed in Sections 4.3 and 5.7, especially where an ADMD has misused ADSP.
ただし、著者ドメインは一般にMLMの署名ドメインとは異なるため、特にADMDがADSPを誤用した場合、セクション4.3および5.7で説明したように、[ADSP]と競合する可能性があります。
An FBL operator might wish to act on a complaint from a user about a message sent to a list. Some FBLs could choose to generate feedback reports based on DKIM verifications in the subject message. Such operators SHOULD send a report to each domain with a valid signature that has an FBL agreement established, as DKIM signatures are claims of some responsibility for that message. Because Authors generally have limited control over the operation of a list, this point makes MLM signing all the more important.
FBLオペレーターは、リストに送信されたメッセージについて、ユーザーからの苦情に対処することをお勧めします。一部のFBLは、サブジェクトメッセージのDKIM検証に基づいてフィードバックレポートを生成することを選択できます。このようなオペレーターは、DKIM署名がそのメッセージに対する何らかの責任の主張であるため、FBL契約が確立された有効な署名を使用して各ドメインにレポートを送信する必要があります。著者は一般にリストの操作を制御しているため、この点はMLMにさらに重要になります。
MLM operators SHOULD register with FBLs from major service providers. In the context of DKIM, there SHOULD be an exchange of information with the FBL provider including what signing domain the MLM will use, if any.
MLMオペレーターは、主要なサービスプロバイダーからFBLに登録する必要があります。DKIMのコンテキストでは、MLMが使用する署名ドメインなど、FBLプロバイダーとの情報交換があるはずです。
Where the FBL wishes to be more specific, it MAY act solely on a DKIM signature where the signing domain matches the DNS domain found in a List-Post: header field (or similar).
FBLがより具体的になりたい場合、署名ドメインがリストポスト：ヘッダーフィールド（または同様）で見つかったDNSドメインと一致するDKIM署名のみに作用する場合があります。
Use of FBLs in this way SHOULD be made explicit to list subscribers. For example, if it is the policy of the MLM's ADMD to handle an FBL item by unsubscribing the user that was the apparent sender of the offending message, advising subscribers of this in advance would help to avoid surprises later.
この方法でのFBLの使用は、サブスクライバーをリストするために明示的にする必要があります。たとえば、MLMのADMDが、問題のメッセージの明らかな送信者であるユーザーを登録解除してFBLアイテムを処理することを許可する場合、これを事前に加入者にアドバイスすることは、後で驚きを避けるのに役立ちます。
A DKIM-signed message sent to an MLM, and then distributed to all of a list's recipients, could result in a complaint from one of the final recipients for some reason. This could be an actual complaint from some subscriber that finds the message abusive or otherwise undesirable, or it could be an automated complaint such as Receiver detection of an invalidated DKIM signature or some other condition. It could also be a complaint that results from antagonistic behavior, such as is common when a subscriber to a list is having trouble unsubscribing and then begins issuing complaints about all submissions to the list. This would result in a complaint being generated in the context of an FBL report back to the message Author. However, the original Author has no involvement in operation of the MLM itself, meaning the FBL report is not actionable and is thus undesirable.
MLMに送信されたDKIMに署名したメッセージ、そしてリストのすべての受信者に配布されると、何らかの理由で最終受信者の1人から苦情が発生する可能性があります。これは、メッセージが虐待的またはそうでなければ望ましくないことを発見する一部のサブスクライバーからの実際の苦情であるか、無効なDKIM署名の受信機検出やその他の条件などの自動化された苦情である可能性があります。また、リストのサブスクライバーが登録解除に問題を抱えている場合に一般的であるように、敵対的な行動に起因する苦情である可能性があり、その後、リストへのすべての提出に関する苦情の発行を開始します。これにより、FBLレポートのコンテキストで、メッセージ作成者に戻る苦情が生成されます。ただし、元の著者はMLM自体の操作に関与していません。つまり、FBLレポートは実行可能ではないため、望ましくありません。
A recipient that explicitly trusts signatures from a particular MLM MAY wish to extend that trust to an [AUTH-RESULTS] header field signed by that MLM. The recipient MAY then do additional processing of the message, using the results recorded in the Authentication-Results header field instead of the original Author's DKIM signature. This includes possibly processing the message as per ADSP requirements.
特定のMLMからの署名を明示的に信頼する受信者は、そのMLMが署名した[認証]ヘッダーフィールドにその信頼を拡張したい場合があります。その後、受信者は、元の著者のDKIM署名の代わりに、認証応答ヘッダーフィールドに記録された結果を使用して、メッセージの追加処理を行うことができます。これには、ADSP要件に従ってメッセージを処理する可能性が含まれます。
Receivers SHOULD ignore or remove all unsigned externally applied Authentication-Results header fields and those not signed by an ADMD that can be trusted by the Receiver. See Sections 5 and 7 of [AUTH-RESULTS] for further discussion.
受信機は、署名されていないすべての外部的に適用された認証と除去ヘッダーフィールドと、受信者が信頼できるADMDによって署名されていないすべてのすべてのものを無視または削除する必要があります。詳細については、[Auth-Results]のセクション5および7を参照してください。
Upon DKIM and ADSP evaluation during an SMTP session (a common implementation), an agent MAY decide to reject a message during an SMTP session. If this is done, [SMTP] stipulates that 550 is the correct response code. However, if the SMTP server supports [ENHANCED] status codes, a status code not normally used for "user unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be used. If the rejecting SMTP server supports this, it thus makes a distinction between messages rejected deliberately due to policy
SMTPセッション中にDKIMとADSPの評価（一般的な実装）がある場合、エージェントはSMTPセッション中にメッセージを拒否することを決定する場合があります。これが行われた場合、[SMTP]は550が正しい応答コードであると規定しています。ただし、SMTPサーバーが[拡張]ステータスコードをサポートする場合、「ユーザー不明」（5.1.1）に通常使用されていないステータスコードが推奨されます。したがって、5.7.0コードを使用する必要があります。SMTPサーバーを拒否するとこれがサポートされている場合、ポリシーのために意図的に拒否されたメッセージを区別します
decisions rather than those rejected because of other delivery issues. In particular, a policy rejection SHOULD be relayed using the above enhanced status code and some appropriate wording in the text part of the reply. Those MLMs that automatically attempt to remove users with prolonged delivery problems (such as account deletion) SHOULD thus detect the difference between policy rejection and other delivery failures and act accordingly. It would also be beneficial for SMTP servers doing so to use appropriate wording in the text portion of the reply, perhaps explicitly using the string "ADSP" to facilitate searching for relevant data in logs.
他の配信の問題のために拒否されたものではなく、決定。特に、上記の強化されたステータスコードと、返信のテキスト部分に適切な文言を使用して、ポリシーの拒否を中継する必要があります。したがって、配信の長期の問題（アカウントの削除など）でユーザーを自動的に削除しようとするMLMは、ポリシーの拒否とその他の配信障害の違いを検出し、それに応じて行動する必要があります。また、SMTPサーバーが応答のテキスト部分で適切な言葉遣いを使用するためにそうすることは有益であり、おそらく文字列「ADSP」を明示的に使用して、ログ内の関連データの検索を容易にします。
The preceding paragraph does not apply to an [ADSP] policy of "discardable". In such cases where the submission fails that test, the Receiver or Verifier SHOULD discard the message but return an SMTP success code, i.e., accept the message but drop it without delivery. An SMTP rejection of such mail instead of the requested discard action causes more harm than good.
前の段落は、「廃棄可能」の[ADSP]ポリシーには適用されません。そのような場合、そのテストに失敗した場合、受信者または検証者はメッセージを破棄する必要がありますが、SMTP成功コードを返します。つまり、メッセージを受け入れますが、配信なしでドロップします。要求された廃棄アクションの代わりにそのようなメールのSMTP拒否は、善よりも多くの害を引き起こすことになります。
As mechanisms become available for reporting forensic details about DKIM verification failures, MLMs will benefit from their use.
DKIM検証障害に関する法医学的な詳細を報告するメカニズムが利用可能になると、MLMはその使用から恩恵を受けるでしょう。
MLMs SHOULD apply DKIM failure-reporting mechanisms as a method for providing feedback to Signers about issues with DKIM infrastructure. This is especially important for MLMs that implement DKIM verification as a mechanism for authentication of list configuration commands and submissions from subscribers.
MLMは、DKIMインフラストラクチャの問題に関する署名者にフィードバックを提供する方法として、DKIM障害報告メカニズムを適用する必要があります。これは、DKIM検証をリスト構成コマンドとサブスクライバーからの提出のメカニズムとして実装するMLMにとって特に重要です。
This document provides suggested or best current practices for use with DKIM and, as such, does not introduce any new technologies for consideration. However, the following security issues should be considered when implementing the practices described in this document.
このドキュメントは、DKIMで使用するための提案または最良の現在のプラクティスを提供し、そのため、検討のための新しいテクノロジーを導入していません。ただし、このドキュメントで説明されているプラクティスを実装する場合は、次のセキュリティの問題を考慮する必要があります。
Readers should be familiar with the material in the "Security Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as appropriate.
読者は、必要に応じて[DKIM]、[ADSP]、および[auth-results]の「セキュリティ上の考慮事項」セクションの資料に精通している必要があります。
Section 5 advocates addition of an [AUTH-RESULTS] header field to indicate authentication status of a message received as MLM Input. Per Section 7.2 of [AUTH-RESULTS], Receivers generally should not trust such data without a good reason to do so, such as an a priori agreement with the MLM's ADMD.
セクション5は、[auth-results]ヘッダーフィールドを追加して、MLM入力として受信したメッセージの認証ステータスを示すことを提唱しています。[auth-results]のセクション7.2によると、受信者は一般に、MLMのADMDとの先験的な契約など、そうする正当な理由がなければそのようなデータを信頼すべきではありません。
Such agreements are strongly advised to include a requirement that those header fields be covered by a [DKIM] signature added by the MLM's ADMD.
このような契約は、MLMのADMDによって追加された[DKIM]署名によってこれらのヘッダーフィールドをカバーするという要件を含めることを強くお勧めします。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[ADSP] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「Domainkeys Idified Mail（DKIM）著者ドメイン署名プラクティス（ADSP）」、RFC 5617、2009年8月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[Auth-Results] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[Dkim] Crocker、D.、ed。、Hansen、T.、ed。、およびM. Kucherawy、ed。、「Domainkeys Idefied Mail（DKIM）署名」、RFC 6376、2011年9月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーチ] Crocker、D。、「Internet Mail Architecture」、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張形式」、RFC 5965、2010年8月。
[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[dkim-deployment] Hansen、T.、Siegel、E.、Hallam-Baker、P。、およびD. Crocker、「Domainkeys Idified Mail（DKIM）開発、展開、および運用」、RFC 5863、2010年5月。
[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[dkim-overview] Hansen、T.、Crocker、D。、およびP. Hallam-Baker、「Domainkeys Idified Mail（DKIM）サービスの概要」、RFC 5585、2009年7月。
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[Enhanced] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[Iodef] Danyliw、R.、Meijer、J。、およびY. Demchenko、「インシデントオブジェクト説明交換形式」、RFC 5070、2007年12月。
[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[List-Id] Chandhok、R。and G. Wenger、「List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間」、RFC 2919、2001年3月。
[LIST-URLS] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[List-urls] Neufeld、G。およびJ. Baer、「コアメールリストコマンドのメタシンタックスとしてのURLの使用とメッセージヘッダーフィールドを介したその輸送」、RFC 2369、1998年7月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[Mime-Types] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
The author wishes to acknowledge the following individuals for their review and constructive criticism of this document: Serge Aumont, Daniel Black, Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and Alessandro Vesely.
著者は、この文書に対するレビューと建設的な批判のために、次の個人に認めたいと考えています：セルジュ・オーモント、ダニエル・ブラック、デイブ・クロッカー、J.D。フォーク、トニー・ハンセン、エリオット・リア、チャールズ・リンジー、ジョン・レヴァイン、ジェフ・マクドナルド、S。ムーナミー、ロルフE. Sonneveld、およびAlessandro Vesely。
This section describes a few MLM-related DKIM scenarios that were part of the impetus for this work and the recommended resolutions for each.
このセクションでは、この作業の推進力の一部であるいくつかのMLM関連のDKIMシナリオとそれぞれの推奨解像度について説明します。
Problem:
問題：
o Author ADMD advertises an ADSP policy of "dkim=discardable"
o 著者ADMDは、「DKIM =廃棄可能」のADSPポリシーを宣伝しています
o Author sends DKIM-signed mail to a non-participating MLM, which invalidates the signature
o 著者はDKIMに署名したメールを参加していないMLMに送信します。これは署名を無効にします
o Receiver MTA checks DKIM and ADSP at SMTP time and is configured to reject ADSP failures, so rejects this message
o 受信機MTAはSMTP時間にDKIMとADSPをチェックし、ADSP障害を拒否するように構成されているため、このメッセージを拒否します
o process repeats a few times, after which the MLM unsubscribes the Receiver
o プロセスは数回繰り返され、その後MLMは受信機を登録しません
Solution: MLMs should refuse mail from domains advertising ADSP policies of "discardable" unless the MLMs are certain they make no changes that invalidate DKIM signatures.
解決策：MLMは、MLMがDKIMの署名を無効にする変更を行わないと確信していない限り、「破棄可能」のADSPポリシーを広告するドメインからメールを拒否する必要があります。
Problem:
問題：
o subscriber sends signed mail to a non-participating MLM that does not invalidate the signature
o サブスクライバーは、署名を無効にしない参加していないMLMに署名郵便を送信します
o a recipient reports the message as spam
o 受信者はメッセージをスパムとして報告します
o FBL at recipient ADMD sends report to contributor rather than list manager
o FBL AT受信者ADMDは、リストマネージャーではなく貢献者にレポートを送信します
Solution: MLMs should sign mail they send and might also strip existing signatures. FBLs should report to list operators instead of subscribers where such can be distinguished; otherwise, FBLs should report to all parties with valid signatures.
解決策：MLMは、送信するメールに署名する必要があり、既存の署名も剥がれる可能性があります。FBLは、そのようなものを区別できる加入者ではなく、オペレーターをリストするように報告する必要があります。それ以外の場合、FBLは有効な署名を持つすべての関係者に報告する必要があります。
Author's Address
著者の連絡先
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy Cloudmark 128 King St.、2階サンフランシスコ、CA 94107 USA
Phone: +1 415 946 3800
EMail: msk@cloudmark.com