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
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).
ドメインキー・アイデンティファイド・メール（DKIM）は、管理管理ドメイン（ADMD）はメッセージのためのいくつかの責任を負うことができます。 DKIMと展開の経験に基づいて、この文書は、リストマネージャ（のMLM）メーリングリストなどがシナリオと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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
ドメインキー・アイデンティファイド・メールは[DKIM]は、管理管理ドメイン（ADMD）は[MAIL]メッセージのいくつかの責任を取ることができます。このような責任は著者の組織、業務リレー（メール転送エージェント、またはMTA）、またはその代理人のいずれかで撮影することができます。責任のアサーションは、暗号署名を介して行われます。受信者への著者からのメッセージトランジットは、一般的に、メッセージの内容に実質的な変更を行いませんので、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:
リレーとは対照的に、積極的に頻繁にDKIM署名を無効に、それらを、メッセージの配信を取るそれらを再フォーマットし、再投稿などメーリングリストマネージャ（のMLM）などの仲介は、あります。この文書の目的は、取得した経験に基づいて、現在のベストプラクティスを仲介が含まれており、お勧めのシナリオのための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 MLMを確認し、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のドメイン内のMTAは、受信側の評価者がその評価を行うことでMLMのドメイン署名を検討することを、それを転送する各メッセージに、自身のDKIM署名を適用していることです。 （第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署名は、それがリレーを通過する際のメッセージに検証ドメインレベル識別子を貼り付けることによって、メッセージの責任の請求を行うために電子メールアーキテクチャ（[EMAIL-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署名は、ハッシュの一つによって覆われたメッセージの一部が変更されたかどうかを確認することができないであろう。 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]故意メッセージ内の任意の他の識別子に署名ドメイン（DKIM署名タグ「= D」）を結ぶの概念を拒否します。メッセージを処理する任意のADMDは関係なく、その起源または著者ドメインの、それに署名できます。特に、DKIMは、例えば、「D =」タグの値の内容との一致が発生するRFC5322.Fromフィールドにドメイン名を任意の意味を定義していない、また明らかな劣化価値がありますそれらが一致しない署名します。任意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、[EMAIL-ARCH]参照）リストのメンバーに他のメッセージと共にそのダイジェストを構築することができる自律エージェントです。しかし、実際にそのようなメッセージのRFC5322.Fromフィールド（非消化ケース）は、典型的には元のメッセージと同じであり、受信者は、元の作成者ではなく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節は、このようにDKIMの知覚価値を減らし、壊れた署名を作り出すのMLMは、一般的に物事のいくつかを説明しています。
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の動作（例えば、[MAIL]、[LIST-ID]、および[LIST-のURL]）に固有の公表基準がありますがまた、彼らの採用はせいぜいむらとなっています。したがって、のMLMの文脈で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の導入として主張することができます。それでも、これらの行動は規格違反ではありません。したがって、このメモはのMLMに可能身を最小限の変更を定義し、すべての関係者のための実践を指定します。
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レポートが送信される）は、この両側登録の一部です。いくつかのFBLsは、DKIMは、登録者による使用が必要です。
See Section 6 for additional discussion.
追加の議論については、セクション6を参照してください。
FBLs tend to use the [ARF] or the [IODEF] formats.
FBLsは[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とのMLM間の可能な相互作用の取り扱いを改善するために、上記の問題について議論を提供します。一般に、嗜好は、署名者と検証ではなく、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のものとはMLMサービスと責任の機能的独立性を強調するために行われます。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「この文書の[KEYWORDS]で説明されるように解釈されるべきです。
See [EMAIL-ARCH] for a general description of the current messaging architecture and for definitions of various terms used in this document.
現在のメッセージング・アーキテクチャの一般的な説明のために、この文書で使用される種々の用語の定義については[EMAIL-ARCH]を参照。
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の主要チュートリアル文書である[DKIM]及び[ADSP]、コア仕様書であり、ならびに[DKIM-概要]および[DKIM展開]に精通することが奨励されます。
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にやさしい」がメッセージを処理し、電子メールの仲介を記述するために使用される用語は、出力に検証するために失敗する入力上のメッセージの[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の活動全体で、メッセージの輸送中のいくつかの重要な役割があります。これらのほとんどは、[EMAIL-ARCH]で定義されているが、すぐに参照のためにここで検討されています。
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).
発信者：著者からのメッセージを受け付け剤は、そのような[MAIL]と関連規格に準拠を保証し、その宛先（複数可）に向けて送信します。これは、多くの場合、メール発信エージェント（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署名（S）を貼付する任意の薬剤。著者の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.
検証：DKIM署名の検証を行って任意の薬剤。一つは、一般的に、公共のインターネットおよび受信者の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.
シンプルなユーザ・ユーザのメールの場合は、これらの役割はかなり簡単です。 1のリストにメールを送信しているメールは、その後、そのリストの購読者のすべてに中継されますときに、特定のエージェントが、複数の重要なものの、分離可能な役割を保持することができるようしかし、役割は、あまり一般の利用者に明確です。上記の定義は、関与するメカニズムのより正確な議論を可能にするために意図されています。
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 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].
エイリアシング：エイリアシングMLMは（[EMAIL-ARCH]のセクション5.1を参照）は、再配布、メッセージ自体には変更をしないものです。すべての変更は、[SMTP]エンベロープ受信者リストの変更（RCPTコマンド）に制約されます。メッセージヘッダまたはボディの変更は[MAIL]トレースヘッダフィールドの追加を除いて、すべてではありません。そのようなMLMの出力は、作成者の元のメッセージ通過の継続であると考えられます。そのようなMLMの例は、内部のみの動作又は他のメッセージを中継するために使用されるローカル・システム管理者のリストとして、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および[EMAIL-ARCH]の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、のではなく、1つまたは複数のメッセージにそれを基づかでオーサリング。これは、メッセージを発信するため、[EMAIL-ARCH]の点では「仲介者」ではありませんが、作成後、そのメッセージ処理と投稿振る舞いそうでない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.
消化：再送MLMの特別な場合は、[MIME]（[MIMEタイプ]を参照）、「マルチパート/ダイジェスト」タイプのメッセージであるかもしれない最近MLM提出の集合を含む単一のメッセージを送信するものです。これは明らかに新しいメッセージであるが、それは自身が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入力：発信ユーザは、著者です。発信元ADMDはオリジネーターと署名者です。 MLMのADMDは検証です。 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 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.
これら2つの異なる相に、全体的なMLM動作の解剖を単離し、論理的な方法で処理されるのMLMに対してDKIM固有の問題を可能にします。主な問題は、MLMによるメッセージの再パッケージ化と再ポストが実際に完全に新しいメッセージの構築であるということである、そのように、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].
これらの活動に関するいくつかの問題は[MAIL]のセクション3.6.4にし、[EMAIL-ARCH]のセクション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.
件名タグ：のMLMの人気のある機能は、「例」と呼ばれるリストについては、「[例]」など、リストの名前を持つフィールドの内容を付けることによって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-のURL]または[MAIL]で定義された「の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.
その他のヘッダーフィールド：追加したり、そのようなリストが識別されるように、メッセージは、メーリングリストのコンテキストで送信されていることを確立するために、または「送信者」「-への返信」（「送信者としてヘッダフィールドを置き換えますいくつかのリスト「）と、任意のユーザーの回答は、リスト（に行く」返信先」）。これらのフィールドは、元のメッセージに含まれていた場合、それらの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.
主な体の変化：など、追加、削除、並べ替え、またはプレーンテキストにHTMLメッセージを「平坦化」[MIME]の部分を、再フォーマット、またはヘッダを挿入するか、などの再配布のためにそれらを準備するとき、メッセージ本文に、より実質的な変化を加えるいくつかのMLMはありますが、 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-認識しているいくつかの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.
一般的に、より多くのDKIM向け実践に向けMLM開発者と事業者による一般的な移動が存在しない、メッセージの前に適用される署名を期待できない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署名付きメールを送信に関する問題の議論が含まれています。具体的には、[DKIM]および[AUTH-結果]によって導入されたヘッダフィールドは、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.
ドメインとは異なるサブドメイン（S） - 厳格な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.)
一般的には、厳しい慣行や政策は、メールは、発信機関によるほとんどのエンド・ツー・エンドの制御対象ストリームのみのために成功する可能性があります。これは、通常のMLMを通過するメールを除外します。そのため、「廃棄」に設定すると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節で述べたようにADMDsが非参加リストを登録し、そのメールがそれらを通過し確認する必要があります受信、署名検証の期待から一部のメールを免除するために。しかし、このようなアプローチは、過度の労力を必要とし、その後も信頼できない可能性が高いです。したがって、スケーラブルなソリューションではありません。
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.
それ以外の場合は非参加MLMにDKIMのサポートを追加するための一つのアプローチは、「ラップ」MLMまたは、本質的には、いくつかのDKIMサービスを提供する（たとえば、MTAのような）他のDKIM対応のコンポーネントの間に配置することです。例えば、ADMDが動作して非参加MLMはMLMに代わって第5の特徴や勧告の一部を強制する、リストの購読者からのメッセージへのDKIM検証の行為を持っている可能性があり、MTAまたはMSAはまたMLMの出力を可能性が受けMLMのドメインのためにDKIM署名を追加します。
This section contains a discussion of issues regarding DKIM-signed mail that transits an MLM that is DKIM-aware.
このセクションでは、DKIMに対応しており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-のURL]、および[MAIL]で指定されたものとして、単に新しいヘッダフィールドを追加した変更は、一般的にDKIM-参加電子メールインフラストラクチャに最も友好的です。これらのフィールドがすでに存在して署名のハッシュによってカバーされた、または署名がそれらの添加を禁止するために特別に作成された場合を除きMLMによって彼らのほかには、既存のDKIM署名には影響しません（[DKIMのセクション3.5で「= H」についての注意事項を参照してください]）。
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-のURL]がすでにサポートしているから、このような一般的な操作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は、検証者または受信機によって重度のアクションにメッセージを施します。これらのメッセージは、すべてのADSP-意識の受信者によって破棄または拒否される可能性があるとして再送MLMは、そのドメインのポストような政策著者からのあからさまな任意のメールを拒否すべきです。また、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プロトコルに基づいて、それを拒否します。その拒絶がリストからU2を除去するために進むL、で受信されます。
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は1で適用される認証 - 結果フィールドは他に信頼されていることがことが可能であるため、ADSPに関してMLM動作のために上記の推奨事項が適用されないように別のADMDといくつかのアウトオブバンド信託契約を確立している場合は有効な著者の署名が1レシート上に存在しない場合であっても推論することができるかどうかを確立します。
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.
例えば、仮定するドメインexample.comとexample.netは、互いの認証アサーションを信頼するように明示的な契約を結んでいます。さて、example.comが運営するメーリングリストに到着するも、同じドメインで有効なDKIM署名を軸受である「example.org」のRFC5322.Fromドメインとのメッセージを、検討してください。評価時に、example.comは、署名を検証し、これを示す[AUTH-結果]フィールドを追加します。しかし、MLMはまた、署名を無効にメッセージ本文を変更します。 MLMは、DKIMを使用して変更されたメッセージの署名を書き直して、リストの購読者、example.netである人のいずれかにそれを送信します。
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に到着すると、example.orgのためのDKIM署名は、もはや有効ではないので、ADSPは失敗し、一般的でしょう。しかし、example.netは、ADSP障害が無視できるように、example.orgから有効な署名があることが示されたexample.comの認証 - 結果フィールドのアサーションを信頼します。
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フィールドで見つかったアドレスを介した著者。 DKIM署名出力（すなわち、署名ドメイン）が評判モジュールへの入力として使用されるように、将来的に、MLMを介してメールを送信する未知の結果による影響からの1つの評判を絶縁する要望が存在してもよいです。その場合、作成者は、具体的の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.
この提案は、より一般的な行うことができます。トランザクションまたは一般エンド・ツー・エンドの性質、及びいずれかのMLMまたはユーザによって周りに転送される可能性はないのであるメールは、より多様な用途を提供していストリームに使用されるものとは異なるメールストリーム識別子を使用して署名されるべきです。
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は、一般的にそれらを介して投稿されたメッセージを認証しよう。彼らは通常、些細な（と安全ではないが）、リストのサブスクリプション・レジストリーに対して（あまり頻繁に、RFC5321.MailFromパラメータ、または）RFC5322.Fromフィールドの電子メールアドレスを検証することによってこれを行います。 DKIM認証の強い形を可能にします：MLMは、与えられたRFC5322.Fromアドレスを使用してメッセージもDKIMを持つことを要求することができます
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 =」ドメインと署名。この機能は、それのための要件はMLMとない著者の組織によって課されることを除いて、ADSPを使用することに多少似ています。
(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.
この論理は、任意のリスト操作だけでなく、リストの提出に適用することができます。特に、この改良された認証は、サブスクリプションに脱退を適用することができる、及び/又は電子メールを介してではなく、ウェブのような認証、インタラクティブチャンネルを介して送信された加入者オプションの変更。
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に到着し、評価の結果は何であったとして提出で観察署名（S）を示すために[AUTH-結果]ヘッダーフィールドを追加する必要があります。下流薬剤はADMD発生（及び、好ましくは、署名）がヘッダフィールドの操作の独自の先験的知識に応じて、そのヘッダフィールドの内容を信用しない場合があります。さらなる議論のための[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は、従来、元の署名（S）を無効になる再ポストにメッセージを変更するように構成されている場合は、更なるアクションは、おそらく不当なフィルタアクションをトリガする、最終的な受信者に到着から無効に署名することを防止することが推奨されます。 （そのようなフィルタリング動作がはっきり間違っていること、しかし、注意してください。[DKIM]無効な署名が全く署名として扱われるべきであると規定）
A possible solution would be to:
可能な解決策は、に次のようになります。
1. Attempt verification of all DKIM signatures present on the input message;
入力メッセージに存在するすべてのDKIM署名の1試み検証。
4. Add an [AUTH-RESULTS] header field to the message to indicate the results of the above;
4.上記の結果を示すために、メッセージに[AUTH-結果]ヘッダーフィールドを追加します。
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.そのハッシュに追加した認証-結果ヘッダーフィールド（セクション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]での議論あたり、ヘッダフィールドの信憑性にどんな信仰を置くために受信者の選択は、それを作成し、エージェントの事前評価が必要です。アセスメント、レシーバーは有効なフィールドを解釈できないことを欠席。このように、メッセージの最終受信者は、自分自身でそのメッセージの著者のアイデンティティの信頼性を検証する方法がありません。しかし、そのフィールドは、検証がそれを取得するメッセージの唯一のものです、そして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.
これは以下のように一般化することができる：受信のみ考慮すべきである[AUTH-結果]サイトレシーバ信託のリストに表示され、それはまたによって追加[DKIM]署名のヘッダハッシュに含まれる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対応の再送のMLMとオーサリングのMLMは自分自身の署名を貼付すべきです。 MLMは、それが再送信され、元のメッセージになり、署名を経てこれを表現する必要があり変更する責任があります。また、これは望ましくないリストのメールが適切な行動を生成することができるように設定している可能性のあるFBLsからフィードバックを得るために有用です。
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のように、そのメッセージはそれ自身のローカル構成またはポリシーに従って署名されなかった場合、メッセージの再分配を省略して自由です。また、再配布したが、このようなメールに署名することができませんでした。しかし、選択的な署名が推奨されていません。本質的には、2件のメッセージがDKIM対応の検証者およびレシーバを混同することができMLM、署名1と1ではない、からストリームを作成します。
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 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.
MLMによって追加されたDKIM署名の「D =」タグで使用されるものと一致するDNSドメインを使用して（[LIST-URLを]参照）：ヘッダフィールド署名MLMリストポストを追加することができます。これは、MLMによって追加されたDKIM署名を識別するために、検証者または受信機によって使用することができます。しかし、これは必要ありません。結合提案よりも、署名者の評判は、より重要なデータポイントになりますと考えられています。さらに、これは、任意の現在の仕様書で認識バインディングではありません。
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対応のオーサリングのMLMは、彼らが[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.
一つの懸念は、MLMは符号なしのメールにその署名を適用有する[DKIM]で定義されているよりも、メッセージの内容により権威や信憑性を付与するよう署名を解釈するために、いくつかの検証者またはレシーバを引き起こす可能性があるということです。これは、の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.
一般的に、検証者と受信機は、他の署名されたメッセージのようなMLMから署名されたメッセージを処理すべきです。例えば[リスト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演算子はリストに送信されたメッセージについて、ユーザーからの苦情に基づいて行動したいかもしれません。いくつかのFBLsは件名メッセージに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オペレータは、大手サービスプロバイダからFBLsに登録する必要があります。 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.
このようにFBLsの使用は、加入者のリストを表示するために明示されるべきです。それは問題のあるメッセージの見かけの送信者だったユーザーを退会により、FBL項目を処理するためのMLMのADMDの方針である場合たとえば、事前にこれを加入者にアドバイスすることは、後に驚きを避けるために役立つだろう。
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レポートのコンテキストで生成されている苦情につながります。しかし、オリジナルの著者は、FBLレポートをアクションではありませんので、望ましくない意味、MLM自体の動作には関与していません。
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によって署名された[AUTH-結果]ヘッダーフィールドにその信頼を拡張することを望むかもしれません。受信者は、その後、認証-結果ヘッダフィールドの代わりに、元の作成者の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によって署名されていないものを削除する必要があります。セクション5およびさらなる議論のために[AUTH-結果]の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 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.
DKIMおよびSMTPセッション中ADSP評価（一般的な実装）されると、エージェントはSMTPセッション中にメッセージを拒否することもできます。これが行われる場合は、[SMTP] 550が正しい応答コードであることを規定しています。しかし、SMTPサーバがサポート[ENHANCED]ステータスコード場合、ステータスコードは、通常、「未知のユーザ」（5.1.1）が好適であるために使用されません。従って、5.7.0コードが使用されるべきです。拒否SMTPサーバーがこれをサポートしている場合、それは、このようにかなりあるため、他の配信の問題により拒否比べによる政策決定に故意に拒否されたメッセージを区別します。特に、ポリシー拒絶は、上記拡張状態コードと応答のテキスト部分にいくつかの適切な文言を使用して中継されるべきです。自動的に（例えば、アカウントの削除など）長期送達の問題を持つユーザーを削除しようとするもののMLMは、このようにポリシー拒絶および他の配信の失敗の差を検出し、それに応じて行動しなければなりません。また、おそらく、明示的にログ内の関連するデータの検索を容易にするために、文字列「ADSP」を使用して、回答のテキスト部分に適切な文言を使用するそうSMTPサーバのために有益であろう。
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-結果]適宜のセクション内の材料に精通しなければなりません。
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は、MLM入力として受信したメッセージの認証ステータスを示すために、[AUTH-結果]ヘッダフィールドの追加を提唱します。 [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】オールマン、E.、フェントン、J.、デラニー、M.、およびJ.レヴァイン、 "ドメインキー・アイデンティファイド・メール（DKIM）著ドメイン署名プラクティス（ADSP）"、RFC 5617、2009年8月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
、RFC 5451、2009年4月 "メッセージ認証ステータスを示すためのメッセージヘッダーフィールド" [AUTH-結果] Kucherawy、M.、。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]クロッカー、D.、編、ハンセン、T.編、及びM. Kucherawy、エド。、 "ドメインキー・アイデンティファイド・メール（DKIM）署名"、RFC 6376、2011年9月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[MAIL]レズニック、P.、エド。、 "インターネットメッセージ形式"、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.、レヴァイン、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展開]ハンセン、T.、シーゲル、E.、ハラム・ベイカー、P.、およびD.クロッカー、 "ドメインキー・アイデンティファイド・メール（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-概要]ハンセン、T.、クロッカー、D.、およびP.ハラム・ベイカー、 "ドメインキー・アイデンティファイド・メール（DKIM）サービスの概要"、RFC 5585、2009年7月。
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月[ENHANCED]。
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[IODEF] Danyliw、R.、マイヤー、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.とG.ウェンガー、 "リスト-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-のURL]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
Appendix A. Acknowledgements
付録A.謝辞
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.
セルジュ・オーモン、ダニエルブラック、デイブ・クロッカー、JDフォーク、トニー・ハンセン、エリオット・リア、チャールズリンジー、ジョン・レヴァイン、ジェフ・マクドナルド、S. Moonesamy、ロルフ：作者は彼らのレビューのために以下の個人と、この文書の建設的な批判を認めることを希望しますE. Sonneveld、そしてアレッサンドロVesely。
Appendix B. Example Scenarios
付録B.シナリオ例
This section describes a few MLM-related DKIM scenarios that were part of the impetus for this work and the recommended resolutions for each.
このセクションでは、この作業のための原動力とそれぞれの推奨解像度の一部であったいくつかのマルチ商法関連のDKIMのシナリオについて説明します。
B.1. MLMs and ADSP
B.1。 MLMとADSP
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者は、署名を無効に非関与MLMにDKIM署名付きメールを送信します
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がReceiverをスクライブ解除された後、数回繰り返さ
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ポリシーからのメールを拒否すべきです。
B.2. MLMs and FBLs
B.2。 MLMとFBLs
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受信者ADMDでFBLは貢献者ではなく、リストマネージャにレポートを送信します
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は、彼らが送ったメールに署名しなければならないし、また、既存の署名を取り除くかもしれません。 FBLsではなく、そのようなものが識別することができる加入者のリストをオペレータに報告しなければなりません。そうでない場合は、FBLsは、有効な署名を持つすべての関係者に報告しなければなりません。
Author's Address
著者のアドレス
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
マレーS. Kucherawy Cloudmarkの128キングセント、2階サンフランシスコ、CA 94107 USA
Phone: +1 415 946 3800 EMail: msk@cloudmark.com
電話：+1 415 946 3800 Eメール：msk@cloudmark.com