[要約] RFC 5863は、DKIMの開発、展開、および運用に関するガイドラインです。このRFCの目的は、DKIMの実装と運用に関するベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 5863 AT&T Laboratories
Category: Informational E. Siegel
ISSN: 2070-1721 Consultant
P. Hallam-Baker
Default Deny Security, Inc.
D. Crocker
Brandenburg InternetWorking
May 2010
DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
DomainKeysは、郵便物（DKIM）の開発、展開、および運用を識別しました
Abstract
概要
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM.
Domainkeys Idefied Mail（DKIM）により、組織は、受信者が検証できる方法で、メッセージを送信する責任を請求することができます。組織は、著者の著者、発信中の送信サイト、仲介者、またはそのエージェントの1人です。メッセージには、メッセージに関係する同じまたは異なる組織から、複数の署名を含めることができます。 DKIMは、電子メールのドメインレベルのデジタル署名認証フレームワークを定義し、公開キー暗号化を使用し、ドメイン名サービスをキーサーバーテクノロジーとして使用します。これにより、責任ある組織の検証、およびメッセージコンテンツの完全性が可能になります。 DKIMは、潜在的な電子メール署名者が電子メールの署名慣行に関する情報を公開できるメカニズムも提供します。これにより、電子メール受信者はメッセージに関する追加の評価を行うことができます。 DKIMの電子メールIDの認証は、「スパム」と「フィッシング」のグローバルな制御を支援できます。このドキュメントは、DKIMの実装、展開、運用、および移行に関する考慮事項を提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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/rfc5863.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5863で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Using DKIM as Part of Trust Assessment ..........................4
2.1. A Systems View of Email Trust Assessment ...................4
2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
2.3. Choosing the Signing Domain Name ...........................8
2.4. Recipient-Based Assessments ...............................10
2.5. Filtering .................................................12
3. DKIM Key Generation, Storage, and Management ...................15
3.1. Private Key Management: Deployment and Ongoing
Operations ................................................16
3.2. Storing Public Keys: DNS Server Software Considerations ...17
3.3. Per-User Signing Key Management Issues ....................18
3.4. Third-Party Signer Key Management and Selector
Administration ............................................19
3.5. Key Pair / Selector Life Cycle Management .................19
4. Signing ........................................................21
4.1. DNS Records ...............................................21
4.2. Signing Module ............................................21
4.3. Signing Policies and Practices ............................22
5. Verifying ......................................................23
5.1. Intended Scope of Use .....................................23
5.2. Signature Scope ...........................................23
5.3. Design Scope of Use .......................................24
5.4. Inbound Mail Filtering ....................................24
5.5. Messages Sent through Mailing Lists and Other
Intermediaries ............................................25
5.6. Generation, Transmission, and Use of Results Headers ......25
6. Taxonomy of Signatures .........................................26
6.1. Single Domain Signature ...................................26
6.2. Parent Domain Signature ...................................27
6.3. Third-Party Signature .....................................27
6.4. Using Trusted Third-Party Senders .........................29
6.5. Multiple Signatures .......................................30
7. Example Usage Scenarios ........................................31
7.1. Author's Organization - Simple ............................32
7.2. Author's Organization - Differentiated Types of Mail ......32
7.3. Author Domain Signing Practices ...........................32
7.4. Delegated Signing .........................................34
7.5. Independent Third-Party Service Providers .................35
7.6. Mail Streams Based on Behavioral Assessment ...............35
7.7. Agent or Mediator Signatures ..............................36
8. Usage Considerations ...........................................36
8.1. Non-Standard Submission and Delivery Scenarios ............36
8.2. Protection of Internal Mail ...............................37
8.3. Signature Granularity .....................................38
8.4. Email Infrastructure Agents ...............................39
8.5. Mail User Agent ...........................................40
9. Security Considerations ........................................41
10. Acknowledgements ..............................................41
11. References ....................................................42
11.1. Normative References .....................................42
11.2. Informative References ...................................42
Appendix A. Migration Strategies .................................43
A.1. Migrating from DomainKeys .................................43
A.2. Migrating Hash Algorithms .................................48
A.3. Migrating Signing Algorithms ..............................49
Appendix B. General Coding Criteria for Cryptographic
Applications .........................................50
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. This document provides practical tips for those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys [RFC4870]; and those who are responsible for the ongoing operations of an email infrastructure that has deployed DKIM.
Domainkeys Idefied Mail（DKIM）により、組織は、受信者が検証できる方法で、メッセージを送信する責任を請求することができます。このドキュメントは、DKIMソフトウェアを開発している人、メーリングリストマネージャー、DKIM検証からの出力に基づいたフィルタリング戦略、およびDNSサーバーのための実用的なヒントを提供します。DKIMソフトウェア、キー、メーリングリストソフトウェア、およびドメインキーからの移行[RFC4870]を展開している人。DKIMを展開した電子メールインフラストラクチャの継続的な操作に責任を負う人々。
The reader is encouraged to read the DKIM Service Overview document [RFC5585] before this document. More detailed guidance about DKIM and Author Domain Signing Practices (ADSP) can also be found in the protocol specifications [RFC4871], [RFC5617], and [RFC5672].
読者は、このドキュメントの前にDKIMサービスの概要ドキュメント[RFC5585]を読むことをお勧めします。DKIMおよび著者ドメイン署名プラクティス（ADSP）に関するより詳細なガイダンスは、プロトコル仕様[RFC4871]、[RFC5617]、および[RFC5672]にもあります。
The document is organized around the key concepts related to DKIM. Within each section, additional considerations specific to development, deployment, or ongoing operations are highlighted where appropriate. The possibility of the use of DKIM results as input to a local reputation database is also discussed.
このドキュメントは、DKIMに関連する重要な概念を中心に編成されています。各セクション内で、開発、展開、または進行中の操作に固有の追加の考慮事項が、必要に応じて強調表示されます。ローカルレピュテーションデータベースへの入力としてのDKIM結果を使用する可能性についても説明します。
DKIM participates in a trust-oriented enhancement to the Internet's email service, to facilitate message handling decisions, such as for delivery and for content display. Trust-oriented message handling has substantial differences from the more established approaches that consider messages in terms of risk and abuse. With trust, there is a collaborative exchange between a willing participant along the sending path and a willing participant at a recipient site. In contrast, the risk model entails independent, unilateral action by the recipient site, in the face of a potentially unknown, hostile, and deceptive sender. This translates into a very basic technical difference: in the face of unilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms are based on heuristics, that is, on guessing. Guessing produces statistical results with some false negatives and some false positives. For trust-based exchanges, the goal is the deterministic exchange of information. For DKIM, that information is the one identifier that represents a stream of mail for which an independent assessment is sought (by the signer).
DKIMは、インターネットの電子メールサービスへの信頼指向の強化に参加して、配信やコンテンツディスプレイなどのメッセージ処理決定を促進します。信頼指向のメッセージ処理には、リスクと虐待の観点からメッセージを考慮するより確立されたアプローチと大きな違いがあります。信頼すると、送信パスに沿った意欲的な参加者と受取人サイトの喜んでいる参加者との間の共同交換があります。対照的に、リスクモデルは、潜在的に未知の敵対的で欺cept的な送信者に直面して、受信者サイトによる独立した一方的な行動を伴います。これは非常に基本的な技術的違いにつながります。受信者による一方的な行動に直面して、送信者による敵対的努力でさえ、リスク指向のメカニズムはヒューリスティック、つまり推測に基づいています。推測は、いくつかの偽陰性といくつかの誤検知を伴う統計的結果を生成します。信頼ベースの交換の場合、目標は情報の決定論的交換です。 DKIMの場合、その情報は、独立した評価が求められるメールのストリームを表す1つの識別子です（署名者によって）。
A trust-based service is built upon a validated Responsible Identifier that labels a stream of mail and is controlled by an identity (role, person, or organization). The identity is acknowledging some degree of responsibility for the message stream. Given a basis for believing that an identifier is being used in an authorized manner, the recipient site can make and use an assessment of the associated identity. An identity can use different identifiers, on the assumption that the different streams might produce different assessments. For example, even the best-run marketing campaigns will tend to produce some complaints that can affect the reputation of the associated identifier, whereas a stream of transactional messages is likely to have a more pristine reputation.
信頼ベースのサービスは、メールのストリームをラベル付けし、ID（役割、個人、または組織）によって制御される検証済みの責任ある識別子の上に構築されます。アイデンティティは、メッセージストリームに対するある程度の責任を認めています。識別子が承認された方法で使用されていると信じるための根拠を考えると、受信者サイトは関連するアイデンティティの評価を行い、使用できます。IDは、異なるストリームが異なる評価を生成する可能性があるという仮定で、異なる識別子を使用できます。たとえば、ベストランマーケティングキャンペーンでさえ、関連する識別子の評判に影響を与える可能性のある苦情を引き起こす傾向がありますが、トランザクションメッセージのストリームはより手付かずの評判を持つ可能性があります。
Determining that the identifier's use is valid is quite different from determining that the content of a message is valid. The former means only that the identifier for the responsible role, person, or organization has been legitimately associated with a message. The latter means that the content of the message can be believed and, typically, that the claimed author of the content is correct. DKIM validates only the presence of the identifier used to sign the message. Even when this identifier is validated, DKIM carries no implication that any of the message content, including the RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to the semantics of a DKIM signature applies even when the validated signing identifier is the same domain name as is used in the RFC5322.From field! DKIM's only claim about message content is that the content cited in the DKIM-Signature: field's h= tag has been delivered without modification. That is, it asserts message content integrity -- between signing and verifying -- not message content validity.
識別子の使用が有効であると判断することは、メッセージの内容が有効であると判断することとはまったく異なります。前者は、責任ある役割、個人、または組織の識別子がメッセージに合法的に関連付けられていることのみを意味します。後者は、メッセージのコンテンツを信じられ、通常、コンテンツの主張された著者が正しいと信じられることを意味します。 DKIMは、メッセージの署名に使用される識別子の存在のみを検証します。この識別子が検証されている場合でも、DKIMは、RFC5322.Fromフィールド[RFC5322]を含むメッセージコンテンツのいずれかが有効であるという意味を持ちません。驚くべきことに、DKIM署名のセマンティクスのこの制限は、検証済みの署名識別子がRFC5322.Fromフィールドで使用されているのと同じドメイン名である場合でも適用されます。メッセージコンテンツに関するDKIMの唯一の主張は、DKIM-Signature：FieldのH =タグで引用されているコンテンツが変更なしで配信されたことです。つまり、メッセージコンテンツの妥当性ではなく、署名と検証の間にメッセージコンテンツの整合性を主張します。
As shown in Figure 1, this enhancement is a communication between a responsible role, person, or organization that signs the message and a recipient organization that assesses its trust in the signer. The recipient then makes handling decisions based on a collection of assessments, of which the DKIM mechanism is only a part. In this model, as shown in Figure 1, validation is an intermediary step, having the sole task of passing a validated Responsible Identifier to the Identity Assessor. The communication is of a single Responsible Identifier that the Responsible Identity wishes to have used by the Identity Assessor. The Identifier is the sole, formal input and output value of DKIM signing. The Identity Assessor uses this single, provided Identifier for consulting whatever assessment databases are deemed appropriate by the assessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter
図1に示すように、この強化は、メッセージに署名する責任ある役割、個人、または組織との間のコミュニケーションと、署名者への信頼を評価する受信組織です。その後、受信者は、DKIMメカニズムが一部の一部である評価のコレクションに基づいて、処理決定を行います。このモデルでは、図1に示すように、検証は中間ステップであり、検証済みの責任ある識別子をID評価者に渡す唯一のタスクを持っています。コミュニケーションは、責任あるアイデンティティがアイデンティティ評価者によって使用することを望んでいる単一の責任ある識別子のものです。識別子は、DKIM署名の唯一の正式な入力値と出力値です。ID評価者は、このシングルを使用して、評価データベースが評価エンティティによって適切であるとみなされるものをコンサルティングするために識別子を提供します。次に、ID評価者からの出力が処理フィルターに供給されます
engine that considers a range of factors, along with this single output value. The range of factors can include ancillary information from the DKIM validation.
この単一の出力値とともに、さまざまな要因を考慮するエンジン。一連の要因には、DKIM検証からの補助情報を含めることができます。
Identity Assessment covers a range of possible functions. It can be as simple as determining whether the identifier is a member of some list, such as authorized operators or participants in a group that might be of interest for recipient assessment. Equally, it can indicate a degree of trust (reputation) that is to be afforded the actor using that identifier. The extent to which the assessment affects the handling of the message is, of course, determined later, by the Handling Filter.
アイデンティティ評価は、可能な機能の範囲をカバーしています。識別子が、受信者評価に興味のあるグループの認定オペレーターや参加者など、いくつかのリストのメンバーであるかどうかを判断するのと同じくらい簡単です。同様に、その識別子を使用してアクターに与えられる程度の信頼（評判）を示すことができます。評価がメッセージの処理にどの程度影響するかは、もちろん、ハンドリングフィルターによって後で決定されます。
+------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
Figure 1: Actors in a Trust Sequence Using DKIM
図1：DKIMを使用した信頼シーケンスの俳優
The signer of a message needs to be able to provide precise data and know what that data will mean upon delivery to the Assessor. If there is ambiguity in the choice that will be made on the recipient side, then the sender cannot know what basis for assessment will be used. DKIM has three values that specify identification information and it is easy to confuse their use, although only one defines the
メッセージの署名者は、正確なデータを提供し、そのデータが評価者への配信時に何を意味するかを知ることができる必要があります。受信者側で行われる選択にあいまいさがある場合、送信者はどのような評価の基礎が使用されるかを知ることができません。DKIMには識別情報を指定する3つの値があり、使用を混乱させるのは簡単ですが、
formal input and output of DKIM, with the other two being used for internal protocol functioning and adjunct purposes, such as auditing and debugging.
DKIMの正式な入力と出力、他の2つは、監査やデバッグなどの内部プロトコル機能および補助目的に使用されます。
The salient values include the s=, d= and i= parameters in the DKIM-Signature: header field. In order to achieve the end-to-end determinism needed for this collaborative exchange from the signer to the assessor, the core model needs to specify what the signer is required to provide to the assessor. The update to RFC 4871 [RFC5672] specifies:
顕著な値には、dkim-signature：headerフィールドのs =、d =、i =パラメーターが含まれます。署名者から評価者とのこの共同交換に必要なエンドツーエンドの決定論を達成するために、コアモデルは、署名者が評価者に提供するために必要なものを指定する必要があります。RFC 4871 [RFC5672]の更新は次のように指定しています。
DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible Agent or User Identifier
(AUID)... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if
present.... To the extent that a receiver attempts to intuit any
structured semantics for either of the identifiers, this is a
heuristic function that is outside the scope of DKIM's
specification and semantics.
The single, mandatory value that DKIM supplies as its output is:
DKIMがその出力として提供する単一の必須値は次のとおりです。
d= This specifies the "domain of the signing entity". It is a domain name and is combined with the selector to form a DNS query. A receive-side DKIM verifier needs to communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and can also communicate the User Agent Identifier (i=) if present.
d =これは「署名エンティティのドメイン」を指定します。これはドメイン名であり、セレクターと組み合わせてDNSクエリを形成します。受信側のDKIM検証者は、署名ドメイン識別子（d =）を消費するアイデンティティ評価者モジュールに通信する必要があり、存在する場合はユーザーエージェント識別子（i =）を通信することもできます。
The adjunct values are:
補助値は次のとおりです。
s= This tag specifies the selector. It is used to discriminate among different keys that can be used for the same d= domain name. As discussed in Section 4.3 of [RFC5585], "If verifiers were to employ the selector as part of an assessment mechanism, then there would be no remaining mechanism for making a transition from an old, or compromised, key to a new one". Consequently, the selector is not appropriate for use as part or all of the identifier used to make assessments.
s =このタグはセレクターを指定します。同じd =ドメイン名に使用できるさまざまなキーを区別するために使用されます。[RFC5585]のセクション4.3で説明したように、「検証剤が評価メカニズムの一部としてセレクターを使用する場合、古い、または侵害された新しいものへの鍵から移行するための残りのメカニズムはありません」。したがって、セレクターは、評価を行うために使用される識別子の一部またはすべてとして使用するのに適していません。
i= This tag is optional and provides the "[t]he Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility" [RFC5672]. The identity can be in the syntax
i =このタグはオプションであり、「SDIDが責任を負っている」[RFC5672]に代わって「[t] HEエージェントまたはユーザー識別子（AUID）を提供します。アイデンティティは構文に含まれます
of an entire email address or only a domain name. The domain name can be the same as for d= or it can be a sub-name of the d= name.
電子メールアドレス全体またはドメイン名のみの。ドメイン名はd =と同じであるか、d = nameのサブ名にすることができます。
NOTE: Although the i= identity has the syntax of an email address, it is not required to have those semantics. That is, "the identity of the user" need not be the same as the user's mailbox. For example, the signer might wish to use i= to encode user-related audit information, such as how they were accessing the service at the time of message posting. Therefore, it is not possible to conclude anything from the i= string's (dis)similarity to email addresses elsewhere in the header.
注：i = IDには電子メールアドレスの構文がありますが、それらのセマンティクスを持つ必要はありません。つまり、「ユーザーの身元」は、ユーザーのメールボックスと同じである必要はありません。たとえば、署名者はi =を使用して、メッセージの投稿時にサービスにアクセスする方法など、ユーザー関連の監査情報をエンコードしたい場合があります。したがって、i = string（dis）の類似性から、ヘッダーの他の場所にある電子メールアドレスと何も締めくくることはできません。
So, i= can have any of these properties:
したがって、i =これらのプロパティのいずれかを持つことができます。
* Be a valid domain when it is the same as d=
* それがd =と同じ場合、有効なドメインになります
* Appear to be a subdomain of d= but might not even exist
* d =のサブドメインのように見えますが、存在しないかもしれません
* Look like a mailbox address but might have different semantics and therefore not function as a valid email address
* メールボックスアドレスのように見えますが、セマンティクスが異なる場合があるため、有効なメールアドレスとして機能しない可能性があります
* Be unique for each message, such as indicating access details of the user for the specific posting
* 特定の投稿のユーザーのアクセスの詳細を示すなど、各メッセージに対して一意であること
This underscores why the tag needs to be treated as being opaque, since it can represent any semantics, known only to the signer.
これは、タグが署名者のみに知られているセマンティクスを表すことができるため、タグを不透明であると扱う必要がある理由を強調しています。
Hence, i= serves well as a token that is usable like a Web cookie, for return to the signing Administrative Management Domain (ADMD) -- such as for auditing and debugging. Of course in some scenarios the i= string might provide a useful adjunct value for additional (heuristic) processing by the Handling Filter.
したがって、i = i =は、監査やデバッグなど、署名管理管理ドメイン（ADMD）に戻るために、Web Cookieのように使用可能なトークンとしてうまく機能します。もちろん、いくつかのシナリオでは、i =文字列は、ハンドリングフィルターによる追加（ヒューリスティック）処理に有用な補助値を提供する場合があります。
A DKIM signing entity can serve different roles, such as being the author of content, the operator of the mail service, or the operator of a reputation service that also provides signing services on behalf of its customers. In these different roles, the basis for distinguishing among portions of email traffic can vary. For an entity creating DKIM signatures, it is likely that different portions of its mail will warrant different levels of trust. For example:
DKIM署名エンティティは、コンテンツの著者、メールサービスのオペレーター、または顧客に代わってサービスに署名する評判サービスのオペレーターなど、さまざまな役割を果たすことができます。これらの異なる役割では、電子メールトラフィックの一部を区別するための基礎はさまざまです。DKIM署名を作成するエンティティの場合、そのメールのさまざまな部分がさまざまなレベルの信頼を保証する可能性があります。例えば：
* Mail is sent for different purposes, such as marketing versus transactional, and recipients demonstrate different patterns of acceptance between these.
* メールは、マーケティングとトランザクションなどのさまざまな目的のために送信され、受信者はこれらの間でさまざまな受け入れパターンを示しています。
* For an operator of an email service, there often are distinct sub-populations of users warranting different levels of trust or privilege, such as paid versus free users, or users engaged in direct correspondence versus users sending bulk mail.
* 電子メールサービスのオペレーターの場合、多くの場合、有料ユーザーと無料ユーザー、または直接通信に従事するユーザーとバルクメールを送信するユーザーなど、さまざまなレベルの信頼や特権を保証するユーザーの明確なサブポピュレーションがあります。
* Mail originating outside an operator's system, such as when it is redistributed by a mailing-list service run by the operator, will warrant a different reputation from mail submitted by users authenticated with the operator.
* オペレーターが運営する郵送リストサービスによって再配布されたときなど、オペレーターのシステムの外部から発信されるメールは、オペレーターに認証されたユーザーが提出したメールとは異なる評判を保証します。
It is therefore likely to be useful for a signer to use different d= subdomain names, for different message traffic streams, so that receivers can make differential assessments. However, too much differentiation -- that is, too fine a granularity of signing domains -- makes it difficult for the receiver to discern a sufficiently stable pattern of traffic for developing an accurate and reliable assessment. So the differentiation needs to achieve a balance. Generally, in a trust system, legitimate signers have an incentive to pick a small stable set of identities, so that recipients and others can attribute reputations to them. The set of these identities a receiver trusts is likely to be quite a bit smaller than the set it views as risky.
したがって、署名者が異なるメッセージトラフィックストリームに対して異なるd =サブドメイン名を使用することが役立つ可能性が高いため、受信者は微分評価を行うことができます。ただし、あまりにも多くの差別化 - つまり、署名ドメインの粒度が細かすぎると、受信者が正確で信頼できる評価を開発するためのトラフィックの十分に安定したパターンを識別することが困難になります。したがって、差別化はバランスをとる必要があります。一般的に、信頼システムでは、合法的な署名者には、小さな安定した一連のアイデンティティを選択するインセンティブがあり、受信者や他の人が評判を彼らに帰することができます。受信者の信頼が信頼するこれらのアイデンティティのセットは、それが危険と見なすセットよりもかなり小さくなる可能性があります。
The challenge in using additional layers of subdomains is whether the extra granularity will be useful for the Assessor. In fact, excessive levels invite ambiguity: if the Assessor does not take advantage of the added granularity in the entire domain name that is provided, they might unilaterally decide to use only some rightmost part of the identifier. The signer cannot know what portion will be used. That ambiguity would move the use of DKIM back to the realm of heuristics, rather than the deterministic processing that is its goal.
サブドメインの追加層を使用する際の課題は、追加の粒度が評価者にとって有用であるかどうかです。実際、過度のレベルはあいまいさを招きます。評価者が提供されているドメイン名全体の追加の粒度を利用しない場合、識別子の右端部分の一部のみを使用することを一方的に決定する場合があります。署名者は、どの部分が使用されるかを知ることができません。その曖昧さは、DKIMの使用を、目標である決定論的処理ではなく、ヒューリスティックの領域に戻すでしょう。
Hence, the challenge is to determine a useful scheme for labeling different traffic streams. The most obvious choices are among different types of content and/or different types of authors. Although stability is essential, it is likely that the choices will change, over time, so the scheme needs to be flexible.
したがって、課題は、さまざまなトラフィックストリームにラベルを付けるための有用なスキームを決定することです。最も明白な選択肢は、さまざまな種類のコンテンツやさまざまな種類の著者の1つです。安定性は不可欠ですが、選択肢が時間とともに変化する可能性が高いため、スキームは柔軟である必要があります。
For those originating message content, the most likely choice of subdomain naming scheme will by based upon type of content, which can use content-oriented labels or service-oriented labels. For example:
これらの発信するメッセージコンテンツの場合、サブドメインネーミングスキームの最も可能性の高い選択は、コンテンツ指向のラベルまたはサービス指向ラベルを使用できるコンテンツのタイプに基づいています。例えば：
transaction.example.com newsletter.example.com bugreport.example.com support.example.com sales.example.com marketing.example.com
transaction.example.com Newsletter.example.com bugreport.example.com Support.example.com Sales.example.com Marketing.example.com
where the choices are best dictated by whether they provide the Identity Assessor with the ability to discriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety. Again, the danger in providing too fine a granularity is that related message streams that are labeled separately will not benefit from an aggregate reputation.
選択は、財務評価者に、受信者の受け入れまたは安全性の著しく異なる程度の程度を示す郵便ストリーム間で有用に区別する能力を提供するかどうかによって最も決定されます。繰り返しになりますが、あまりにも細かい粒度を提供する危険性は、個別にラベル付けされた関連メッセージストリームが総評判から利益を得ないことです。
For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different subdomain label for each customer. For example:
さまざまな顧客に代わってメッセージングサービスを運営するために、使用する明白なスキームには、各顧客に異なるサブドメインラベルがあります。例えば：
widgetco.example.net moviestudio.example.net bigbank.example.net
Widgetco.example.net moviestudio.example.net bigbank.example.net
However, it can also be appropriate to label by the class of service or class of customer, such as:
ただし、以下など、サービスのクラスや顧客のクラスでラベルを付けることも適切です。
premier.example.net free.example.net certified.example.net
premer.example.net free.example.net cortified.example.net
Prior to using domain names for distinguishing among sources of data, IP Addresses have been the basis for distinction. Service operators typically have done this by dedicating specific outbound IP Addresses to specific mail streams -- typically to specific customers. For example, a university might want to distinguish mail from the administration, versus mail from the student dorms. In order to make the adoption of a DKIM-based service easier, it can be reasonable to translate the same partitioning of traffic, using domain names in place of the different IP Addresses.
データソースを区別するためにドメイン名を使用する前に、IPアドレスは区別の基礎となっています。通常、サービスオペレーターは、特定のメールストリーム、通常は特定の顧客に特定のアウトバウンドIPアドレスを捧げることにより、これを行いました。たとえば、大学は、学生の寮からの郵便と比較して、郵便物を管理者と区別したいと思うかもしれません。DKIMベースのサービスの採用を容易にするために、異なるIPアドレスの代わりにドメイン名を使用して、トラフィックの同じパーティションを翻訳することが合理的です。
DKIM gives the recipient site's Identity Assessor a verifiable identifier to use for analysis. Although the mechanism does not make claims that the signer is a Good Actor or a Bad Actor, it does make
DKIMは、レシピエントサイトのID評価者に分析に使用する検証可能な識別子を与えます。メカニズムは、署名者が良い俳優または悪い俳優であるという主張をしていませんが、それは作ります
it possible to know that use of the identifier is valid. This is in marked contrast with schemes that do not have authentication. Without verification, it is not possible to know whether the identifier -- whether taken from the RFC5322.From field, the RFC5321.MailFrom command, or the like -- is being used by an authorized agent. DKIM solves this problem. Hence, with DKIM, the Assessor can know that two messages with the same DKIM d= identifier are, in fact, signed by the same person or organization. This permits a far more stable and accurate assessment of mail traffic using that identifier.
識別子の使用が有効であることを知ることができます。これは、認証を持たないスキームと顕著なコントラストです。確認がなければ、識別子がRFC5322から取得したかどうかを知ることはできません。フィールドから、RFC5321.Mailfromコマンドなどが認定エージェントによって使用されているかどうかを確認することはできません。DKIMはこの問題を解決します。したがって、DKIMを使用すると、評価者は同じDKIM D =識別子を持つ2つのメッセージが実際に同じ個人または組織によって署名されていることを知ることができます。これにより、その識別子を使用して、メールトラフィックのはるかに安定した正確な評価が可能になります。
DKIM is distinctive, in that it provides an identifier that is not necessarily related to any other identifier in the message. Hence, the signer might be the author's ADMD, one of the operators along the transit path, or a reputation service being used by one of those handling services. In fact, a message can have multiple signatures, possibly by any number of these actors.
DKIMは、メッセージ内の他の識別子に必ずしも関連していない識別子を提供するという点で独特です。したがって、署名者は、著者のADMD、トランジットパスに沿ったオペレーターの1つ、またはそれらの取り扱いサービスの1つによって使用されている評判サービスである可能性があります。実際、メッセージには、おそらくこれらの俳優の任意の数によって複数の署名を持つことができます。
As discussed above, the choice of identifiers needs to be based on differences that the signer thinks will be useful for the recipient Assessor. Over time, industry practices establish norms for these choices.
上記で説明したように、識別子の選択は、署名者が受信者の評価者に役立つと考える違いに基づいている必要があります。時間が経つにつれて、業界の慣行はこれらの選択の規範を確立します。
Absent such norms, it is best for signers to distinguish among streams that have significant differences, while consuming the smallest number of identifiers possible. This will limit the burden on recipient Assessors.
そのような規範がなければ、署名者は、可能な限り少ない数の識別子を消費しながら、大きな違いを持つストリームを区別するのが最適です。これにより、受信者評価者の負担が制限されます。
A common view about a DKIM signature is that it carries a degree of assurance about some or all of the message contents, and in particular, that the RFC5322.From field is likely to be valid. In fact, DKIM makes assurances only about the integrity of the data and not about its validity. Still, presumptions of the RFC5322.From field validity remain a concern. Hence, a signer using a domain name that is unrelated to the domain name in the RFC5322.From field can reasonably expect that the disparity will warrant some curiosity, at least until signing by independent operators has produced some established practice among recipient Assessors.
DKIMの署名に関する一般的な見解は、メッセージの内容の一部またはすべて、特にRFC5322.Fromフィールドが有効である可能性が高いことについてある程度の保証があるということです。実際、DKIMは、データの整合性についてのみ保証を行い、その有効性についてではありません。それでも、RFC5322の推定。フィールドの妥当性から依然として懸念事項です。したがって、RFC5322のドメイン名とは無関係のドメイン名を使用する署名者。
With the identifier(s) supplied by DKIM, the Assessor can consult an independent assessment service about the entity associated with the identifier(s). Another possibility is that the Assessor can develop its own reputation rating for the identifier(s). That is, over time, the Assessor can observe the stream of messages associated with the identifier(s) developing a reaction to associated content. For example, if there is a high percentage of user complaints regarding
DKIMが提供する識別子を使用すると、評価者は識別子に関連するエンティティに関する独立した評価サービスに相談できます。別の可能性は、評価者が識別子に対する独自の評判評価を開発できることです。つまり、時間の経過とともに、評価者は、関連するコンテンツに対する反応を開発する識別子に関連付けられたメッセージのストリームを観察できます。たとえば、ユーザーの苦情の割合が高い場合
signed mail with a d= value of "widgetco.example.net", the Assessor might include that fact in the vector of data it provides to the Handling Filter. This is also discussed briefly in Section 5.4.
「Widgetco.example.net」のd =値を備えた署名郵便で、評価者はその事実を処理フィルターに提供するデータのベクトルに含めることができます。これについては、セクション5.4で簡単に説明します。
The assessment of the signing identifier is given to a Handling Filter that is defined by local policies, according to a potentially wide range of different factors and weightings. This section discusses some of the kinds of choices and weightings that are plausible and the differential actions that might be performed. Because authenticated domain names represent a collaborative sequence between signer and Assessor, actions can sometimes reasonably include contacting the signer.
署名識別子の評価は、潜在的に広範囲の異なる要因と重み付けに従って、ローカルポリシーによって定義されるハンドリングフィルターに与えられます。このセクションでは、もっともらしい選択と重み付けの種類のいくつか、および実行される可能性のある微分行動について説明します。認証されたドメイン名は、署名者と評価者の間の共同シーケンスを表しているため、行動には署名者への連絡が合理的に含まれる場合があります。
The discussion focuses on variations in Organizational Trust versus Message Stream Risk, that is, the degree of positive assessment of a DKIM-signing organization, and the potential danger present in the message stream signed by that organization. While it might seem that higher trust automatically means lower risk, the experience with real-world operations provides examples of every combination of the two factors, as shown in Figure 2. For each axis, only three levels of granularity are listed, in order to keep discussion manageable. In real-world filtering engines, finer-grained distinctions are typically needed, and there typically are more axes. For example, there are different types of risk, so that an engine might distinguish between spam risk versus virus risk and take different actions based on which type of problematic content is present. For spam, the potential damage from a false negative is small, whereas the damage from a false positive is high. For a virus, the potential danger from a false negative is extremely high, while the likelihood of a false positive when using modern detection tools is extremely low. However, for the discussion here, "risk" is taken as a single construct.
議論は、組織の信頼とメッセージストリームのリスクの変動、つまりDKIM署名組織の肯定的な評価の程度と、その組織が署名したメッセージストリームに存在する潜在的な危険に焦点を当てています。より高い信頼は自動的にリスクが低いことを意味するように思われるかもしれませんが、図2に示すように、実際の操作の経験は2つの要因のあらゆる組み合わせの例を提供します。ディスカッションを管理しやすいままにしてください。実際のフィルタリングエンジンでは、通常、より細かい粒子の区別が必要であり、通常はより多くの軸があります。たとえば、リスクにはさまざまな種類があります。そのため、エンジンはスパムリスクとウイルスリスクを区別し、問題のあるコンテンツのタイプに基づいて異なるアクションを実行する可能性があります。スパムの場合、偽陰性による潜在的な損傷は小さく、偽陽性による損傷は高いです。ウイルスの場合、偽陰性による潜在的な危険は非常に高いですが、最新の検出ツールを使用する場合の偽陽性の可能性は非常に低いです。ただし、ここでの議論では、「リスク」は単一の構成要素と見なされます。
The DKIM d= identifier is independent of any other identifier in a message and can be a subdomain of the name owned by the signer. This permits the use of fine-grained and stable distinctions between different types of message streams, such as between transactional messages and marketing messages from the same organization. Hence, the use of DKIM might permit a richer filtering model than has typically been possible for mail-receiving engines.
DKIM D =識別子は、メッセージ内の他の識別子から独立しており、署名者が所有する名前のサブドメインにすることができます。これにより、トランザクションメッセージや同じ組織からのマーケティングメッセージなど、さまざまなタイプのメッセージストリーム間の細かく安定した区別を使用できます。したがって、DKIMを使用すると、メール受信エンジンが通常可能であるよりも、より豊富なフィルタリングモデルが可能になる場合があります。
Note that the realities of today's public Internet Mail environment necessitate having a baseline handling model that is quite suspicious. Hence, "strong" filtering rules really are the starting point, as indicated for the UNKNOWN cell.
今日の公開インターネットメール環境の現実は、非常に疑わしいベースライン処理モデルを持つ必要があることに注意してください。したがって、未知のセルに示されているように、「強い」フィルタリングルールが実際に出発点です。
The table indicates differential handling for each combination, such as how aggressive or broad-based the filtering could be. Aggressiveness affects the types of incorrect assessments that are likely. So, the table distinguishes various characteristics, including: 1) whether an organization is unknown, known to be good actors, or known to be bad actors; and 2) the assessment of messages. It includes advice about the degree of filtering that might be done, and other message disposition. Perhaps unexpectedly, it also lists a case in which the receiving site might wish to deliver problematic mail, rather than redirecting or deleting it. The site might also wish to contact the signing organization and seek resolution of the problem.
このテーブルは、フィルタリングがどれだけ攻撃的または広範囲に基づいているかなど、各組み合わせの微分処理を示しています。攻撃性は、可能性のある誤った評価の種類に影響します。したがって、この表は、次のようなさまざまな特性を区別します。1）組織が不明であるか、良い俳優であることが知られているか、悪い俳優であることが知られているか。2）メッセージの評価。これには、行われる可能性のあるフィルタリングの程度やその他のメッセージ処分に関するアドバイスが含まれています。おそらく予想外に、それはまた、受信サイトがそれをリダイレクトまたは削除するのではなく、問題のあるメールの配信を希望するケースもリストしています。また、このサイトは、署名組織に連絡し、問題の解決を求めたい場合があります。
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
Figure 2: Trust versus Risk Handling Tradeoffs Example
図2：信頼とリスクの処理トレードオフの例
[LEGEND]
[伝説]
AXES
軸
Stream Risk: This is a measure of the recent history of a message stream and the severity of problems it has presented.
ストリームリスク：これは、メッセージストリームの最近の歴史と、それが提示した問題の重大度の尺度です。
Organizational Trust: This combines longer-term history about possible stream problems from that organization, and its responsiveness to problem handling.
組織の信頼：これは、その組織からの可能なストリームの問題に関する長期的な歴史と、問題の処理に対するその応答性を組み合わせています。
CELLS (indicating reasonable responses)
セル（合理的な応答を示す）
Labels for the cells are meant as a general assessment of an organization producing that type of mail stream under that circumstance.
セルのラベルは、その状況下でそのタイプのメールストリームを作成する組織の一般的な評価として意図されています。
Benign: There is some history of sending good messages, with very few harmful messages having been received. This stream warrants filtering that does not search for problems very aggressively, in order to reduce the likelihood of false positives.
良性：良いメッセージを送信する歴史がいくつかあり、有害なメッセージはほとんど受け取られていません。このストリームは、誤検知の可能性を減らすために、問題をあまり積極的に検索しないフィルタリングを保証します。
Diligent: The stream has had a limited degree of problems and the organization is consistently successful at controlling their abuse issues and in a timely manner.
勤勉：ストリームには限られた問題があり、組織は虐待の問題を制御し、タイムリーに成功しています。
Pristine: There is a history of a clean message stream with no problems, from an organization with an excellent reputation. So, the filter primarily needs to ensure that messages are delivered; catching stray problem messages is a lesser concern. In other words, the paramount concern, here, is false positives.
PRISTINE：評判の良い組織から、問題のないクリーンなメッセージストリームの歴史があります。したがって、フィルターは主にメッセージが配信されることを確認する必要があります。浮遊問題メッセージをキャッチすることは、それほど懸念されません。言い換えれば、ここでの最も重要な懸念は誤った肯定的です。
-----
Unknown: There is no history with the organization. Apply an aggressive level of "naive" filtering, given the nature of the public email environment.
不明：組織に歴史はありません。パブリックメール環境の性質を考慮して、「素朴な」フィルタリングの積極的なレベルを適用します。
Typical: The stream suffers significant abuse issues and the organization has demonstrated a record of having difficulties resolving them in a timely manner, in spite of legitimate efforts. Unfortunately, this is the typical case for service providers with an easy and open subscription policy.
典型的なもの：ストリームは重大な虐待の問題に苦しんでおり、組織は合法的な努力にもかかわらず、タイムリーにそれらを解決するのが難しいという記録を実証しています。残念ながら、これは簡単でオープンなサブスクリプションポリシーを備えたサービスプロバイダーの典型的なケースです。
Protected: An organization with a good history and/or providing an important message stream for the receiving site is subject to a local policy that messages are not allowed to be blocked, but the stream is producing a problematic stream. The receiver delivers messages, but works quickly with the organization to resolve the matter.
保護：優れた歴史を持つ組織、および/または受信サイトに重要なメッセージストリームを提供することは、メッセージのブロックを許可されていないが、ストリームが問題のあるストリームを生成しているというローカルポリシーの対象となります。受信機はメッセージを配信しますが、組織と迅速に連携して問題を解決します。
-----
Malicious: A persistently problematic message stream is coming from an organization that appears to contribute to the problem. The stream will be blocked, but the organization's role is sufficiently troubling to warrant following up with others in the anti-abuse or legal communities, to constrain or end their impact.
悪意のある：問題に貢献していると思われる組織から、持続的に問題のあるメッセージストリームが生まれています。ストリームはブロックされますが、組織の役割は、反乱用または合法的なコミュニティの他の人とのフォローアップを保証し、その影響を制約または終わらせるために十分に厄介です。
Negligent: A persistently problematic message stream is coming from an organization that does not appear to be contributing to the problem, but also does not appear to be working to eliminate it. At the least, the stream needs to be blocked.
過失：問題に貢献していないように見える組織からの持続的に問題のあるメッセージストリームは、それを排除するために取り組んでいないようです。少なくとも、ストリームをブロックする必要があります。
Compromised: An organization with a good history has a stream that changes and becomes too problematic to be delivered. The receiver blocks the stream and works quickly with the organization to resolve the matter.
妥協点：良い歴史を持つ組織には、変化し、問題が大きくなりすぎて配信されることができなくなります。レシーバーはストリームをブロックし、組織と迅速に動作して問題を解決します。
By itself, verification of a digital signature only allows the verifier to conclude with a very high degree of certainty that the signature was created by a party with access to the corresponding private signing key. It follows that a verifier requires means to (1) obtain the public key for the purpose of verification and (2) infer useful attributes of the key holder.
それ自体では、デジタル署名の検証により、検証者は、対応するプライベート署名キーにアクセスできる当事者によって署名が作成されたという非常に高い確実性で締めくくることができます。したがって、検証者は、（1）検証を目的として公開鍵を取得し、（2）キーホルダーの有用な属性を推測する手段を必要とすることになります。
In a traditional Public Key Infrastructure (PKI), the functions of key distribution and key accreditation are separated. In DKIM [RFC4871], these functions are both performed through the DNS.
従来の公開キーインフラストラクチャ（PKI）では、主要な分布と主要な認定の機能が分離されています。DKIM [RFC4871]では、これらの機能は両方ともDNSを介して実行されます。
In either case, the ability to infer semantics from a digital signature depends on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In a traditional PKI, a Trusted Third Party (TTP) vouches that the key holder has been validated with respect to a specified set of attributes. The range of attributes that can be attested in such a scheme is thus limited only to the type of attributes that a TTP can establish effective processes for validating. In DKIM, TTPs are not employed and the functions of key distribution and accreditation are combined.
どちらの場合でも、デジタル署名からセマンティクスを推測する能力は、対応する秘密鍵が特定の属性セットを持つ当事者がのみアクセスできるという仮定に依存します。従来のPKIでは、信頼できるサードパーティ（TTP）は、指定された属性セットに関してキーホルダーが検証されていることを保証します。したがって、このようなスキームで証明できる属性の範囲は、TTPが検証するための効果的なプロセスを確立できる属性のタイプにのみ制限されます。DKIMでは、TTPは採用されておらず、主要な分布と認定の機能が組み合わされています。
Consequently, there are only two types of inference that a signer can make from a key published in a DKIM key record:
その結果、DKIMキーレコードで公開されたキーから署名者が作成できる推論には2種類しかありません。
1. That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.
1. DNSゾーン内でDNSレコードを制御する機能を備えた当事者は、対応するプライベート署名キーを使用して署名されたメッセージの責任を請求することを意図していること。
2. That use of a specific key is restricted to the particular subset of messages identified by the selector.
2. 特定のキーの使用は、セレクターによって識別されたメッセージの特定のサブセットに制限されています。
The ability to draw any useful conclusion from verification of a digital signature relies on the assumption that the corresponding private key is only accessible to a party with a particular set of
デジタル署名の検証から有用な結論を引き出す能力は、対応する秘密鍵が特定のセットのある当事者がのみアクセスできるという仮定に依存しています。
attributes. In the case of DKIM, this means that the party that created the corresponding DKIM key record in the specific zone intended to claim responsibility for the signed message.
属性。DKIMの場合、これは、署名されたメッセージの責任を請求することを目的とした特定のゾーンで対応するDKIMキーレコードを作成した当事者が作成したことを意味します。
Ideally, we would like to draw a stronger conclusion, that if we obtain a DKIM key record from the DNS zone example.com, that the legitimate holder of the DNS zone example.com claims responsibility for the signed message. In order for this conclusion to be drawn, it is necessary for the verifier to assume that the operational security of the DNS zone and corresponding private key are adequate.
理想的には、DNS Zone example.comからDKIMキーレコードを取得すると、DNS Zone example.comの正当な所有者が署名されたメッセージの責任を主張するというより強力な結論を導き出したいと思います。この結論を引き出すためには、検証者がDNSゾーンと対応する秘密鍵の運用セキュリティが適切であると仮定する必要があります。
Access to signing keys needs to be carefully managed to prevent use by unauthorized parties and to minimize the consequences if a compromise were to occur.
署名キーへのアクセスは、許可されていない当事者による使用を防ぎ、妥協が発生した場合の結果を最小限に抑えるために慎重に管理する必要があります。
While a DKIM signing key is used to sign messages on behalf of many mail users, the signing key itself needs to be under direct control of as few key holders as possible. If a key holder were to leave the organization, all signing keys held by that key holder need to be withdrawn from service and, if appropriate, replaced.
DKIMの署名キーは、多くのメールユーザーに代わってメッセージに署名するために使用されますが、署名キー自体は、可能な限り少数のキー保有者を直接制御する必要があります。キーホルダーが組織を離れる場合、そのキーホルダーが保持しているすべての署名キーをサービスから撤回し、必要に応じて交換する必要があります。
If key management hardware support is available, it needs to be used. If keys are stored in software, appropriate file control protections need to be employed, and any location in which the private key is stored in plaintext form needs to be excluded from regular backup processes and is best not accessible through any form of network including private local area networks. Auditing software needs to be used periodically to verify that the permissions on the private key files remain secure.
主要な管理ハードウェアサポートが利用可能な場合は、使用する必要があります。キーがソフトウェアに保存されている場合、適切なファイル制御保護を採用する必要があり、プライベートキーがプレーンテキスト形式に保存されている場所は、通常のバックアッププロセスから除外する必要があり、プライベートローカルを含むどの形態のネットワークを介してアクセスできないのが最適ですエリアネットワーク。監査ソフトウェアを定期的に使用して、秘密キーファイルのアクセス許可が安全なままであることを確認する必要があります。
Wherever possible, a signature key needs to exist in exactly one location and be erased when no longer used. Ideally, a signature key pair needs to be generated as close to the signing point as possible, and only the public key component transferred to another party. If this is not possible, the private key needs to be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in plaintext form.
可能な限り、署名キーはちょうど1つの場所に存在し、使用されなくなったときに消去する必要があります。理想的には、署名キーペアを可能な限り署名ポイントに近づける必要があり、公開キーコンポーネントのみが別の当事者に転送される必要があります。これが不可能な場合、署名キーの機密性を保護する暗号化された形式で秘密鍵を輸送する必要があります。ローカルファイルシステムの共有ディレクトリは、プレーンテキストフォームで署名キーの配布に適切なセキュリティを提供しません。
Key escrow schemes are not necessary and are best not used. In the unlikely event of a signing key becoming lost, a new signature key pair can be generated as easily as recovery from a key escrow scheme.
キーエスクロースキームは必要ありませんし、使用しないのが最適です。署名キーが失われる可能性が低い場合、新しい署名キーペアをキーエスクロースキームからの回復と同じくらい簡単に生成できます。
To enable accountability and auditing:
説明責任と監査を可能にするには：
o Responsibility for the security of a signing key needs to ultimately vest in a single named individual.
o 署名キーのセキュリティに対する責任は、最終的に単一の名前の個人に付与する必要があります。
o Where multiple parties are authorized to sign messages, each signer needs to use a different key to enable accountability and auditing.
o 複数の関係者がメッセージに署名する権限がある場合、各署名者は、説明責任と監査を可能にするために異なるキーを使用する必要があります。
Best practices for management of cryptographic keying material require keying material to be refreshed at regular intervals, particularly where key management is achieved through software. While this practice is highly desirable, it is of considerably less importance than the requirement to maintain the secrecy of the corresponding private key. An operational practice in which the private key is stored in tamper-proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software.
暗号化キーイング素材の管理のためのベストプラクティスでは、特にソフトウェアを通じてキー管理が達成される場合、定期的にキーイング素材をリフレッシュする必要があります。このプラクティスは非常に望ましいものですが、対応する秘密鍵の秘密を維持するための要件よりもかなり重要ではありません。秘密キーが改ざん防止ハードウェアに保存され、年に1回変更される運用慣行は、署名キーが1時間ごとに変更されたがソフトウェアで維持されているものよりもかなり望ましいものです。
In order to use DKIM, a DNS domain holder requires (1) the ability to create the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of spurious DNS records by an attacker.
DKIMを使用するには、DNSドメインホルダーには（1）必要なDKIM DNSレコードを作成する機能と（2）攻撃者によるスプリアスDNSレコードの挿入を防ぐための十分な運用セキュリティ制御が必要です。
DNS record management is often operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. If the best practices for private key management described above are observed, such deployment is not a one-time event; DNS DKIM selectors will be changed over time as signing keys are terminated and replaced.
DNSレコード管理は、多くの場合、組織の電子メールサービスを運営している人とは異なる管理スタッフによって運営されています。DKIM DNSレコードが正確であることを確認するために、これは2つの操作グループ間で慎重に調整するための要件を課します。上記の秘密鍵管理のベストプラクティスが観察された場合、そのような展開は1回限りのイベントではありません。DNS DKIMセレクターは、署名キーが終了して交換されるため、時間の経過とともに変更されます。
At a minimum, a DNS server that handles queries for DKIM key records needs to allow the server administrators to add free-form TXT records. It would be better if the DKIM records could be entered using a structured form, supporting the DKIM-specific fields.
少なくとも、DKIMキーレコードのクエリを処理するDNSサーバーは、サーバー管理者がフリーフォームTXTレコードを追加できるようにする必要があります。DKIM固有のフィールドをサポートする構造化されたフォームを使用してDKIMレコードを入力できる場合は、より良いでしょう。
Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NextSECure version 3 (NSEC3) [RFC5155] records are employed to prevent insertion attack, the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for details.)
理想的には、DNSセキュリティ（DNSSEC）[RFC4034]は、レコード挿入攻撃とゾーン列挙に対する保護を提供する構成で使用する必要があります。NextSecureバージョン3（NSEC3）[RFC5155]レコードが挿入攻撃を防ぐために採用されている場合、オプトアウトフラグを明確にする必要があります。（詳細については、[RFC5155]セクション6を参照してください。）
Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for the delegation of the right to authenticate a portion of the namespace to a TTP. Examples include:
セレクターは、新しいキーにロールオーバーするため、または名前空間の一部をTTPに認証する権利の委任など、署名ドメインの管理ニーズに従って割り当てられます。例は次のとおりです。
jun2005.eng._domainkey.example.com
2005.Eng._DomainKey.example.com
widget.promotion._domainkey.example.com
Widget.promotion._domainkey.example.com
It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. While past practice of a signer can permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a change of signing software can cause such heuristics to fail at any time.
DKIM IDの評価はドメイン名に基づいており、セレクターを含めないことを意図しています。署名者の過去の実践は、検証者が構造DKIMキーセレクターから特定のメッセージの追加プロパティを推測することを許可しますが、署名ソフトウェアの変更などの未発表の管理変更により、そのようなヒューリスティックがいつでも失敗する可能性があります。
While a signer can establish business rules, such as the issue of individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out-of-band distribution of such business rules is outside the scope of DKIM. Consequently, there is no means by which external parties can make use of such keys to attribute messages with any greater granularity than a DNS domain.
署名者は、各エンドユーザーの個々の署名キーの問題などのビジネスルールを確立できますが、DKIMはこれらを他の関係者に伝えるための規定を行いません。このようなビジネスルールの帯域外分布は、DKIMの範囲外です。その結果、外部の当事者がそのようなキーを利用して、メッセージをDNSドメインよりも大きな粒度で属性することができる手段はありません。
If per-user signing keys are assigned for internal purposes (e.g., authenticating messages sent to an MTA (Mail Transfer Agent) for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:
ユーザーごとの署名キーが内部目的で割り当てられている場合（たとえば、配布のためにMTA（メール転送エージェント）に送信されるメッセージの認証）、アウトバウンドでの従来のエッジ署名の代替としてそのような署名を使用する前に、次の問題を考慮する必要がありますMTA：
External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to [RFC4871].
外部検証器は、[RFC4871]に関してバンドから渡された追加情報にアクセスすることなく、追加の署名の粒度を利用できません。
If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.
ユーザーキーの数が多い場合、検証器によるキーレコードのローカルキャッシュの効率が低くなります。
A large number of end users is be less likely to do an adequate job of managing private key data securely on their personal computers than is an administrator running an edge MTA.
多数のエンドユーザーは、エッジMTAを実行している管理者よりも、パーソナルコンピューターで秘密キーデータを安全に管理するのに適切な仕事をする可能性が低くなります。
A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under the corresponding key. In some applications, such as bulk mail delivery, it is desirable to delegate use of the key. That is, to allow a third party to sign on behalf of the domain holder. The trust relationship is still established between the domain holder and the verifier, but the private signature key is held by a third party.
DKIMキーレコードは、対応するドメイン名の所有者が対応するキーの下で署名されたメッセージの責任を主張することを主張しています。バルクメール配信などの一部のアプリケーションでは、キーの使用を委任することが望ましいです。つまり、サードパーティがドメインホルダーに代わってサインすることを許可します。信頼関係は依然としてドメインホルダーと検証者の間に確立されていますが、プライベート署名キーは第三者によって保持されています。
Signature keys used by a third-party signer need to be kept entirely separate from those used by the domain holder and other third-party signers. To limit potential exposure of the private key, the signature key pair needs to be generated by the third-party signer and the public component of the key transmitted to the domain holder, rather than have the domain holder generate the key pair and transmit the private component to the third-party signer.
サードパーティの署名者が使用する署名キーは、ドメインホルダーやその他のサードパーティの署名者が使用するものとは完全に分離する必要があります。秘密鍵の潜在的な露出を制限するには、署名キーペアを、ドメインホルダーがキーペアを生成してプライベートを送信するのではなく、ドメインホルダーに送信されたキーのパブリックコンポーネントによって生成する必要があります。サードパーティの署名者へのコンポーネント。
Domain holders needs to adopt a least-privilege approach and grant third-party signers the minimum access necessary to perform the desired function. Limiting the access granted to third-party signers serves to protect the interests of both parties. The domain holder minimizes its security risk and the TTP signer avoids unnecessary liability.
ドメインホルダーは、最小限のアプローチを採用し、サードパーティの署名者に目的の機能を実行するために必要な最小アクセスを付与する必要があります。サードパーティの署名者に付与されたアクセスを制限することは、両当事者の利益を保護するのに役立ちます。ドメインホルダーはセキュリティリスクを最小限に抑え、TTP署名者は不必要な責任を回避します。
In the most restrictive case, domain holders maintain full control over the creation of key records. They can employ appropriate key record restrictions to enforce limits on the messages for which the third-party signer is able to sign. If such restrictions are impractical, the domain holder needs to delegate a DNS subzone for publishing key records to the third-party signer. It is best that the domain holder NOT allow a third-party signer unrestricted access to its DNS service for the purpose of publishing key records.
最も制限的なケースでは、ドメインホルダーは主要なレコードの作成を完全に制御しています。彼らは、サードパーティの署名者が署名できるメッセージに制限を実施するために、適切な主要な記録制限を使用することができます。そのような制限が非現実的である場合、ドメインホルダーは、主要な記録をサードパーティの署名者に公開するためにDNSサブゾーンを委任する必要があります。ドメインホルダーが、キーレコードを公開する目的で、DNSサービスへのサードパーティの署名者の無制限のアクセスを許可しないことが最善です。
Deployments need to establish, document, and observe processes for managing the entire life cycle of an asymmetric key pair.
展開は、非対称キーペアのライフサイクル全体を管理するためのプロセスを確立、文書化、および観察する必要があります。
When it is determined that a new key pair is required:
新しいキーペアが必要であると判断された場合：
1. A Key Pair is generated by the signing device.
1. 署名デバイスによってキーペアが生成されます。
2. A proposed key selector record is generated and transmitted to the DNS administration infrastructure.
2. 提案されたキーセレクターレコードが生成され、DNS管理インフラストラクチャに送信されます。
3. The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted:
3. DNS管理インフラストラクチャは、キーセレクター登録要求の信頼性を検証します。受け入れられた場合：
1. A key selector is assigned.
1. キーセレクターが割り当てられます。
2. The corresponding key record is published in the DNS.
2. 対応するキーレコードはDNSに公開されています。
3. Wait for DNS updates to propagate (if necessary).
3. DNSの更新が伝播するのを待ちます（必要に応じて）。
4. Report assigned key selector to signing device.
4. 署名デバイスにキーセレクターを割り当てたレポート。
4. The signer verifies correct registration of the key record.
4. 署名者は、キーレコードの正しい登録を確認します。
5. The signer begins generating signatures using the new key pair.
5. 署名者は、新しいキーペアを使用して署名の生成を開始します。
6. The signer terminates any private keys that are no longer required due to issue of replacement.
6. 署名者は、交換の発行により不要になったプライベートキーを終了します。
When it is determined that a private signature key is no longer required:
プライベート署名キーが不要になったと判断された場合：
1. The signer stops using the private key for signature operations.
1. 署名者は、署名操作に秘密鍵を使用するのを停止します。
2. The signer deletes all records of the private key, including in-memory copies at the signing device.
2. 署名者は、署名デバイスでのメモリ内コピーを含む、秘密鍵のすべてのレコードを削除します。
3. The signer notifies the DNS administration infrastructure that the signing key is withdrawn from service and that the corresponding key records can be withdrawn from service at a specified future date.
3. 署名者は、DNS管理インフラストラクチャに、署名キーがサービスから撤回され、対応するキーレコードが指定された将来の日付でサービスから撤回できることを通知します。
4. The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted,
4. DNS管理インフラストラクチャは、キーセレクター終了要求の信頼性を検証します。受け入れられた場合、
1. The key selector is scheduled for deletion at a future time determined by site policy.
1. キーセレクターは、サイトポリシーによって決定される将来の時間に削除が予定されています。
2. Wait for deletion time to arrive.
2. 削除時間が到着するのを待ちます。
3. The signer either publishes a revocation key selector with an empty public-key data (p=) field, or deletes the key selector record entirely.
3. 署名者は、空のパブリックキーデータ（p =）フィールドを使用して取り消しキーセレクターを公開するか、キーセレクターレコードを完全に削除します。
5. As far as the verifier is concerned, there is no functional difference between verifying against a key selector with an empty p= field, and verifying against a missing key selector: both
5. 検証者に関する限り、空のp =フィールドを使用してキーセレクターに対して検証することと、欠落しているキーセレクターに対する検証との間には機能的な違いはありません。
result in a failed signature and the signature needs to be treated as if it had not been there. However, there is a minor semantic difference: with the empty p= field, the signer is explicitly stating that the key has been revoked. The empty p= record provides a gravestone for an old selector, making it less likely that the selector might be accidentally reused with a different public key.
署名に失敗し、署名はそこにいなかったかのように扱う必要があります。ただし、マイナーなセマンティックの違いがあります。空のp =フィールドを使用すると、署名者はキーが取り消されたことを明示的に述べています。空のp =レコードは、古いセレクターの墓石を提供し、セレクターが異なる公開キーで誤って再利用される可能性が低くなります。
Creating messages that have one or more DKIM signatures requires support in only two outbound email service components:
1つ以上のDKIM署名を持つメッセージを作成するには、2つのアウトバウンド電子メールサービスコンポーネントのみでサポートが必要です。
o A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with underscores -- and resource records (RR).
o アンダースコア付きの名前を含む関連するDNS名を作成および維持できるDNS管理インターフェイスとリソースレコード（RR）。
o A trusted module, called the signing module, which is within the organization's outbound email handling service and which creates and adds the DKIM-Signature: header field(s) to the message.
o 署名モジュールと呼ばれる信頼できるモジュールは、組織のアウトバウンド電子メール処理サービス内にあり、DKIM-Signature：Headerフィールドをメッセージに作成および追加します。
If the module creates more than one signature, there needs to be the appropriate means of telling it which one(s) to use. If a large number of names are used for signing, it will help to have the administrative tool support a batch-processing mode.
モジュールが複数の署名を作成する場合、使用するものを伝える適切な手段が必要です。署名に多数の名前が使用されている場合、管理ツールがバッチ処理モードをサポートするのに役立ちます。
A receiver attempting to verify a DKIM signature obtains the public key that is associated with the signature for that message. The DKIM-Signature: header in the message contains the d= tag with the basic domain name doing the signing and serving as output to the Identity Assessor and the s= tag with the selector that is added to the name, for finding the specific public key. Hence, the relevant <selector>._domainkey.<domain-name> DNS record needs to contain a DKIM-related RR that provides the public key information.
DKIMの署名を確認しようとする受信者は、そのメッセージの署名に関連付けられている公開鍵を取得します。dkim-signature：メッセージ内のヘッダーには、署名を行い、識別評価者への出力として出力として機能する基本ドメイン名を持つd =タグと、特定のパブリックを見つけるために、名前に追加されたセレクターのs =タグが含まれます鍵。したがって、関連する<selector> ._ domainkey。<domain-name> dnsレコードには、公開キー情報を提供するDKIM関連RRを含める必要があります。
The administrator of the zone containing the relevant domain name adds this information. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to support DKIM names, such as with underscores, and to add new types of DNS information.
関連するドメイン名を含むゾーンの管理者がこの情報を追加します。初期DKIM DNS情報は、TXT RRS内に含まれています。DNS管理ソフトウェアは、アンダースコアなどのDKIM名をサポートし、新しいタイプのDNS情報を追加する能力がかなり異なります。
The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); obvious choices include department-level posting agents, as well as
署名をしているモジュールは、組織の信頼できる管理管理ドメイン（ADMD）内に配置できます。明らかな選択肢には、部門レベルの投稿エージェントや
outbound boundary MTAs to the open Internet. However, any other module, including the author's MUA (Mail User Agent), is potentially acceptable, as long as the signature survives any remaining handling within the ADMD. Hence, the choice among the modules depends upon software development, administrative overhead, security exposures, and transit-handling tradeoffs. One perspective that helps to resolve this choice is the difference between the increased flexibility, from placement at (or close to) the MUA, versus the streamlined administration and operation that is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA.
オープンインターネットへのアウトバウンド境界MTA。ただし、著者のMUA（メールユーザーエージェント）を含む他のモジュールは、署名がADMD内の残りの取り扱いを生き延びている限り、潜在的に受け入れられる可能性があります。したがって、モジュールの選択は、ソフトウェア開発、管理オーバーヘッド、セキュリティエクスポージャー、およびトランジット処理トレードオフに依存します。この選択を解決するのに役立つ1つの視点は、MUAへの配置（または近く）と、組織の電子メールインフラストラクチャにメカニズムを「より深く」実装することでより簡単に取得できる合理化された管理と操作から、柔軟性の向上の違いです。、その境界MTAなど。
Note the discussion in Section 2.2 concerning the use of the i= tag.
i = tagの使用に関するセクション2.2の議論に注意してください。
The signing module uses the appropriate private key to create one or more signatures. (See Section 6.5 for a discussion of multiple signatures.) The means by which the signing module obtains the private key(s) is not specified by DKIM. Given that DKIM is intended for use during email transit, rather than for long-term storage, it is expected that keys will be changed regularly. For administrative convenience, it is best not to hard-code key information into software.
署名モジュールは、適切な秘密鍵を使用して1つ以上の署名を作成します。（複数の署名についての議論については、セクション6.5を参照してください。）署名モジュールが秘密鍵を取得する手段は、DKIMによって指定されていません。DKIMは、長期のストレージではなく、電子メールトランジット中に使用することを目的としているため、キーが定期的に変更されることが予想されます。管理上の利便性のために、ソフトウェアに重要な情報をハードコードしないことが最善です。
Every organization (ADMD) will have its own policies and practices for deciding when to sign messages (message stream) and with what domain name, selector, and key. Examples of particular message streams include all mail sent from the ADMD versus mail from particular types of user accounts versus mail having particular types of content. Given this variability, and the likelihood that signing practices will change over time, it will be useful to have these decisions represented through run-time configuration information, rather than being hard-coded into the signing software.
すべての組織（ADMD）には、メッセージ（メッセージストリーム）にいつ署名するかを決定するための独自のポリシーとプラクティスがあり、ドメイン名、セレクター、およびキーを使用します。特定のメッセージストリームの例には、特定のタイプのユーザーアカウントと特定のタイプのコンテンツを持つメールとメールからのメールから送信されたすべてのメールが含まれます。この変動性、および署名プラクティスが時間とともに変化する可能性を考えると、署名ソフトウェアにハードコーディングされるのではなく、ランタイム構成情報を通じてこれらの決定を表すことは有用です。
As noted in Section 2.3, the choice of signing name granularity requires balancing administrative convenience and utility for recipients. Too much granularity is higher administrative overhead and might well attempt to impose more differential analysis on the recipient than they wish to support. In such cases, they are likely to use only a super-name -- right-hand substring -- of the signing name. When this occurs, the signer will not know what portion is being used; this then moves DKIM back to the non-deterministic world of heuristics, rather than the mechanistic world of signer/recipient collaboration that DKIM seeks.
セクション2.3で述べたように、署名名のGranularityの選択には、受信者の管理上の利便性とユーティリティのバランスをとる必要があります。あまりにも多くの粒度性は、管理のオーバーヘッドが高く、レシピエントにサポートしたいよりも多くの差別的な分析を課そうとする可能性があります。そのような場合、彼らは署名名のスーパーネーム（右側のサブストリング）のみを使用する可能性があります。これが発生した場合、署名者はどの部分が使用されているのかわかりません。これにより、DKIMは、DKIMが求める署名者/受信者のコラボレーションの機械的な世界ではなく、ヒューリスティックの非決定的な世界に戻ります。
A message recipient can verify a DKIM signature to determine if a claim of responsibility has been made for the message by a trusted domain.
メッセージ受信者は、DKIMの署名を検証して、信頼できるドメインによってメッセージに対して責任の主張がなされたかどうかを判断できます。
Access control requires two components: authentication and authorization. By design, verification of a DKIM signature only provides the authentication component of an access control decision and needs to be combined with additional sources of information such as reputation data to arrive at an access control decision.
アクセス制御には、認証と承認の2つのコンポーネントが必要です。設計上、DKIM署名の検証は、アクセス制御決定の認証コンポーネントのみを提供し、アクセス制御決定に到達するために評判データなどの追加の情報源と組み合わせる必要があります。
DKIM requires that a message with a signature that is found to be invalid is to be treated as if the message had not been signed at all.
DKIMでは、無効であることが判明した署名を含むメッセージは、メッセージがまったく署名されていないかのように扱われることを要求しています。
If a DKIM signature fails to verify, it is entirely possible that the message is valid and that either there is a configuration error in the signer's system (e.g., a missing key record) or that the message was inadvertently modified in transit. It is thus undesirable for mail infrastructure to treat messages with invalid signatures less favorably than those with no signatures whatsoever. Contrariwise, creation of an invalid signature requires a trivial amount of effort on the part of an attacker. If messages with invalid signatures were to be treated preferentially to messages with no signatures whatsoever, attackers will simply add invalid signature blocks to gain the preferential treatment. It follows that messages with invalid signatures need to be treated no better and no worse than those with no signature at all.
DKIMの署名が確認に失敗した場合、メッセージが有効であり、署名者のシステムに構成エラーがある（例：キーレコードの欠落）、またはメッセージが誤って輸送中に変更されたことが完全に可能です。したがって、メールインフラストラクチャにとって、無効な署名でメッセージを署名のないものよりも好意的に扱うことは望ましくありません。反対に、無効な署名の作成には、攻撃者の側でささいな努力が必要です。無効な署名を持つメッセージが、署名なしのメッセージに対して優先的に扱われる場合、攻撃者は単に無効な署名ブロックを追加して優先治療を得ることができます。そのため、無効な署名を持つメッセージは、署名のないものよりも良く扱われず、悪く扱われる必要があります。
As with any other digital signature scheme, verifiers need to consider only the part of the message that is inside the scope of the message as being authenticated by the signature.
他のデジタル署名スキームと同様に、Verifiersは、メッセージの範囲内にあるメッセージの部分のみを署名によって認証されていると考える必要があります。
For example, if the l= option is employed to specify a content length for the scope of the signature, only the part of the message that is within the scope of the content signature would be considered authentic.
たとえば、L =オプションが署名の範囲のコンテンツ長を指定するために使用されている場合、コンテンツ署名の範囲内にあるメッセージの部分のみが本物と見なされます。
Public key cryptography provides an exceptionally high degree of assurance, bordering on absolute certainty, that the party that created a valid digital signature had access to the private key corresponding to the public key indicated in the signature.
公開キーの暗号化は、有効なデジタル署名を作成した当事者が署名に示されている公開鍵に対応する秘密鍵にアクセスできるという、絶対的な確実性に接する非常に高い保証を提供します。
In order to make useful conclusions from the verification of a valid digital signature, the verifier is obliged to make assumptions that fall far short of absolute certainty. Consequently, mere validation of a DKIM signature does not represent proof positive that a valid claim of responsibility was made for it by the indicated party, that the message is authentic, or that the message is not abusive. In particular:
有効なデジタル署名の検証から有用な結論を出すために、検証者は絶対的な確実性をはるかに下回る仮定を行う義務があります。その結果、DKIM署名の単なる検証は、指定された当事者によって責任の有効な主張が行われたこと、メッセージが本物である、またはメッセージが虐待的ではないという責任の有効な主張が行われたという証拠を表していません。特に：
o The legitimate private key holder might have lost control of its private key.
o 正当な秘密鍵所有者は、秘密鍵の制御を失った可能性があります。
o The legitimate domain holder might have lost control of the DNS server for the zone from which the key record was retrieved.
o 正当なドメインホルダーは、キーレコードが取得されたゾーンのDNSサーバーの制御を失った可能性があります。
o The key record might not have been delivered from the legitimate DNS server for the zone from which the key record was retrieved.
o キーレコードは、キーレコードが取得されたゾーンの正当なDNSサーバーから配信されなかった可能性があります。
o Ownership of the DNS zone might have changed.
o DNSゾーンの所有権が変更された可能性があります。
In practice, these limitations have little or no impact on the field of use for which DKIM is designed, but they can have a bearing if use is made of the DKIM message signature format or key retrieval mechanism in other specifications.
実際には、これらの制限は、DKIMが設計されている使用分野にほとんどまたはまったく影響を与えませんが、DKIMメッセージ署名形式または他の仕様の主要な検索メカニズムで使用されている場合、それらは関係を持つことができます。
In particular, the DKIM key retrieval mechanism is designed for ease of use and deployment rather than to provide a high assurance Public Key Infrastructure suitable for purposes that require robust non-repudiation such as establishing legally binding contracts. Developers seeking to extend DKIM beyond its design application need to consider replacing or supplementing the DNS key retrieval mechanism with one that is designed to meet the intended purposes.
特に、DKIMキー検索メカニズムは、法的拘束力のある契約を確立するなどの堅牢な非繰り返しを必要とする目的に適した高い保証公開キーインフラストラクチャを提供するのではなく、使いやすさと展開のために設計されています。DKIMを設計アプリケーションを超えて拡張しようとしている開発者は、DNSキー検索メカニズムの交換または補充を検討する必要があります。
DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message.
DKIMは、信頼できるソースから発信された電子メールでコンテンツ分析の実行を避けるために、メールフィルタリング戦略で頻繁に採用されています。信頼できるソースから有効なDKIM署名を運ぶメッセージは、計算を実行する必要性を回避し、したがってメッセージの処分を決定するためにエネルギー集約型コンテンツ分析を避けることができます。
Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services. The precise means by which this is accomplished is outside the scope of DKIM.
メールソースは、以前に観察された行動および/または外部評判または認定サービスへの参照によって信頼されると判断できます。これが達成される正確な手段は、DKIMの範囲外です。
Adaptive (or learning) spam filtering mechanisms that are not capable of verifying DKIM signatures need to, at minimum, be configured to ignore DKIM header data entirely.
DKIM署名を検証することができない適応（または学習）スパムフィルタリングメカニズムは、DKIMヘッダーデータを完全に無視するように構成する必要があります。
Intermediaries, such as mailing lists, pose a particular challenge for DKIM implementations, as the message processing steps performed by the intermediary can cause the message content to change in ways that prevent the signature passing verification.
メーリングリストなどの仲介者は、DKIMの実装に特定の課題を提起します。これは、中間によって実行されるメッセージ処理手順により、署名の合格確認を防ぐ方法でメッセージコンテンツを変更する可能性があるためです。
Such intermediaries are strongly encouraged to deploy DKIM signing so that a verifiable claim of responsibility remains available to parties attempting to verify the modified message.
このような仲介者は、DKIMの署名を展開することを強くお勧めします。これにより、修正されたメッセージを検証しようとする当事者が責任の検証可能な主張を引き続き利用できるようにします。
In many deployments, it is desirable to separate signature verification from the application relying on the verification. A system can choose to relay information indicating the results of its message authentication efforts using various means; adding a "results header" to the message is one such mechanism [RFC5451]. For example, consider the cases where:
多くの展開では、検証に依存するアプリケーションと署名検証を分離することが望ましいです。システムは、さまざまな手段を使用して、メッセージ認証努力の結果を示す情報を中継することを選択できます。メッセージに「結果ヘッダー」を追加することは、そのようなメカニズムの1つです[RFC5451]。たとえば、次の場合を検討してください。
o The application relying on DKIM signature verification is not capable of performing the verification.
o DKIMの署名検証に依存するアプリケーションは、検証を実行することはできません。
o The message can be modified after the signature verification is performed.
o メッセージは、署名検証が実行された後に変更できます。
o The signature key cannot be available by the time that the message is read.
o 署名キーは、メッセージが読み取られるまでに利用できません。
In such cases, it is important that the communication link between the signature verifier and the relying application be sufficiently secure to prevent insertion of a message that carries a bogus results header.
そのような場合、署名検証剤と頼るアプリケーション間の通信リンクを、偽の結果ヘッダーを運ぶメッセージの挿入を防ぐために十分に安全であることが重要です。
An intermediary that generates results headers need to ensure that relying applications are able to distinguish valid results headers issued by the intermediary from those introduced by an attacker. For
結果ヘッダーを生成する仲介者は、依存するアプリケーションが、仲介者が発行した有効な結果ヘッダーと攻撃者によって導入されたヘッダーを区別できるようにする必要があります。為に
example, this can be accomplished by signing the results header. At a minimum, results headers on incoming messages need to be removed if they purport to have been issued by the intermediary but cannot be verified as authentic.
たとえば、これは結果ヘッダーに署名することで実現できます。少なくとも、中間メッセージの結果ヘッダーは、仲介者によって発行されたが本物として検証できないと主張する場合は、削除する必要があります。
Further discussion on trusting the results as relayed from a verifier to something downstream can be found in [RFC5451].
検証剤から下流のものに中継された結果を信頼することに関するさらなる議論は、[RFC5451]に記載されています。
As described in Section 2.1, a DKIM signature tells the signature verifier that the owner of a particular domain name accepts some responsibility for the message. It does not, in and of itself, provide any information about the trustworthiness or behavior of that identity. What it does provide is a verified identity to which such behavioral information can be associated, so that those who collect and use such information can be assured that it truly pertains to the identity in question.
セクション2.1で説明されているように、DKIM署名は、特定のドメイン名の所有者がメッセージに対するある程度の責任を受け入れることを署名の検証者に伝えます。それ自体では、そのアイデンティティの信頼性や行動に関する情報を提供しません。それが提供するのは、そのような行動情報を関連付けることができる検証済みのアイデンティティであるため、そのような情報を収集して使用する人は、問題のアイデンティティに本当に関係していることを保証できます。
This section lays out a taxonomy of some of the different identities, or combinations of identities, that might usefully be represented by a DKIM signature.
このセクションでは、DKIMの署名で有用に表現される可能性のある、さまざまなアイデンティティまたはアイデンティティの組み合わせの分類法を定めています。
Perhaps the simplest case is when an organization signs its own outbound email using its own domain in the SDID [RFC5672] of the signature. For example, Company A would sign the outbound mail from its employees with d=companyA.example.
おそらく最も単純なケースは、組織が署名のSDID [RFC5672]に独自のドメインを使用して独自のアウトバウンドメールに署名する場合です。たとえば、会社Aは、d = companya.exampleで従業員からのアウトバウンドメールに署名します。
In the most straightforward configuration, the addresses in the RFC5322.From field would also be in the companyA.example domain, but that direct correlation is not required.
最も簡単な構成では、RFC5322のアドレスはCompany.exampleドメインにもありますが、その直接的な相関は必要ありません。
A special case of the single domain signature is an author signature as defined by the Author Domain Signing Practices specification [RFC5617]. Author signatures are signatures from an author's organization that have an SDID value that matches that of an RFC5322.From address of the signed message.
単一のドメイン署名の特殊なケースは、著者ドメイン署名プラクティス仕様[RFC5617]で定義されている著者署名です。著者の署名は、署名されたメッセージのアドレスからRFC5322のそれと一致するSDID値を持つ著者の組織からの署名です。
Although an author signature might, in some cases, be proof against spoofing the domain name of the RFC5322.From address, it is important to note that the DKIM and ADSP validation apply only to the exact address string and not to look-alike addresses or to the human-friendly "display-name" or names and addresses used within the body of the message. That is, it only protects against the misuse of a precise address string within the RFC5322.From field and nothing else. For example, a message from bob@domain.example with a valid
著者の署名は、場合によっては、rfc5322のドメイン名をスプーフィングすることに対して証拠である可能性がありますが、アドレスから、DKIMとADSPの検証は、正確なアドレス文字列にのみ適用され、見た目のようなアドレスまたは外観のアドレスまたは適用されることに注意することが重要です。人間に優しい「ディスプレイ名」またはメッセージの本体内で使用される名前と住所へ。つまり、RFC5322内の正確なアドレス文字列の誤用からのみを保護します。フィールドから他に何もありません。たとえば、有効なbob@domain.exampleからのメッセージ
signature where d=d0main.example would fail an ADSP check because the signature domain, however similar, is distinct; however, a message from bob@d0main.example with a valid signature where d=d0main.example would pass an ADSP check, even though to a human it might be obvious that d0main.example is likely a malicious attempt to spoof the domain domain.example. This example highlights that ADSP, like DKIM, is only able to validate a signing identifier: it still requires some external process to attach a meaningful reputation to that identifier.
d = d0main.exampleがADSPチェックに失敗する署名は、署名ドメインが類似していても明確であるためです。ただし、d = d0main.exampleがADSPチェックに渡す有効な署名を持つbob@d0main.exampleからのメッセージは、d0main.exampleがドメインドメインをスプーフィングする悪意のある試みであることは明らかかもしれません。例。この例は、DKIMのようにADSPが署名識別子のみを検証できることを強調しています。それは、その識別子に意味のある評判を添付するために何らかの外部プロセスが必要です。
Another approach that might be taken by an organization with multiple active subdomains is to apply the same (single) signature domain to mail from all subdomains. In this case, the signature chosen would usually be the signature of a parent domain common to all subdomains. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature where d=domain.example.
複数のアクティブサブドメインを持つ組織が取る可能性のある別のアプローチは、同じ（単一の）署名ドメインをすべてのサブドメインから郵送するために適用することです。この場合、選択された署名は通常、すべてのサブドメインに共通する親ドメインの署名です。たとえば、Marketing.domain.example、sales.domain.example、およびEngineering.domain.exampleからのメールはすべて、d = domain.exampleで署名を使用する場合があります。
This approach has the virtue of simplicity, but it is important to consider the implications of such a choice. As discussed in Section 2.3, if the type of mail sent from the different subdomains is significantly different or if there is reason to believe that the reputation of the subdomains would differ, then it can be a good idea to acknowledge this and provide distinct signatures for each of the subdomains (d=marketing.domain.example, sales.domain.example, etc.). However, if the mail and reputations are likely to be similar, then the simpler approach of using a single common parent domain in the signature can work well.
このアプローチにはシンプルさの美徳がありますが、そのような選択の意味を考慮することが重要です。セクション2.3で説明したように、異なるサブドメインから送信されたメールの種類が大幅に異なる場合、またはサブドメインの評判が異なると信じる理由がある場合、これを認め、明確な署名を提供することをお勧めします。各サブドメイン（d = marketing.domain.example、sales.domain.exampleなど）の各サブドメイン。ただし、メールと評判が類似している可能性が高い場合、署名で単一の一般的な親ドメインを使用するというより簡単なアプローチがうまく機能する可能性があります。
Another approach to distinguishing the streams using a single DKIM key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM signature to differentiate the mail streams. For example, marketing email would be signed with i=@marketing.domain.example and d=domain.example.
単一のDKIMキーを使用してストリームを区別する別のアプローチは、DKIM署名のAUID [RFC5672]（i = TAG）を活用してメールストリームを区別することです。たとえば、マーケティングメールはi =@marketing.domain.exampleとd = domain.exampleで署名されます。
It's important to remember, however, that under core DKIM semantics, the AUID is opaque to receivers. That means that it will only be an effective differentiator if there is an out-of-band agreement about the i= semantics.
ただし、コアDKIMセマンティクスの下では、AUIDは受信機に不透明であることを覚えておくことが重要です。つまり、i =セマンティクスに関する帯域外の合意がある場合にのみ、効果的な差別化要因になります。
A signature whose domain does not match the domain of the RFC5322.From address is sometimes referred to as a third-party signature. In certain cases, even the parent domain signature
ドメインがRFC5322のドメインと一致しない署名。アドレスから、サードパーティの署名と呼ばれることもあります。特定の場合、親ドメインの署名でさえ
described above would be considered a third-party signature because it would not be an exact match for the domain in the RFC5322.From address.
上記は、RFC5322のドメインに正確な一致ではないため、サードパーティの署名と見なされます。
Although there is often heated debate about the value of third party signatures, it is important to note that the DKIM specification attaches no particular significance to the identity in a DKIM signature ([RFC4871], [RFC5672]). The identity specified within the signature is the identity that is taking responsibility for the message, and it is only the interpretation of a given receiver that gives one identity more or less significance than another. In particular, most independent reputation services assign trust based on the specific identifier string, not its "role": in general they make no distinction between, for example, an author signature and a third-party signature.
サードパーティの署名の価値についてはしばしば激しい議論がありますが、DKIM仕様はDKIMの署名（[RFC4871]、[RFC5672]）のIDに特別な重要性を提出しないことに注意することが重要です。署名内で指定されているアイデンティティは、メッセージに対して責任を負っているIDであり、1つのアイデンティティが別のアイデンティティよりも多かれ少なかれ重要性を与えるのは、特定のレシーバーの解釈のみです。特に、ほとんどの独立した評判サービスは、その「役割」ではなく特定の識別子文字列に基づいて信頼を割り当てます。一般に、著者の署名とサードパーティの署名を区別しません。
For some, a signature unrelated to the author domain (the domain in the RFC5322.From address) is less valuable because there is an assumption that the presence of an author signature guarantees that the use of the address in the RFC5322.From header is authorized.
一部の人にとっては、著者ドメイン（rfc5322のドメイン）と関係のない署名は、著者の署名の存在がRFC5322でのアドレスの使用が保証されているという仮定があるため、あまり価値がありません。。
For others, that relevance is tied strictly to the recorded behavioral data assigned to the identity in question, i.e., its trust assessment or reputation. The reasoning here is that an identity with a good reputation is unlikely to maintain that good reputation if it is in the habit of vouching for messages that are unwanted or abusive; in fact, doing so will rapidly degrade its reputation so that future messages will no longer benefit from it. It is therefore low risk to facilitate the delivery of messages that contain a valid signature of a domain with a strong positive reputation, independent of whether or not that domain is associated with the address in the RFC5322.From header field of the message.
他の人にとっては、その関連性は、問題のIDに割り当てられた記録された行動データ、つまりその信頼評価または評判に厳密に結び付けられています。ここでの理由は、評判の良いアイデンティティが、望ましくない、または虐待的なメッセージを保証する習慣がある場合、その良い評判を維持することはまずないということです。実際、そうすることで、その評判は急速に低下し、将来のメッセージがもはや利益を得ることができなくなります。したがって、そのドメインがメッセージのRFC5322のアドレスに関連付けられているかどうかに関係なく、強い肯定的な評判を持つドメインの有効な署名を含むメッセージの配信を促進することは低リスクです。
Third-party signatures encompass a wide range of identities. Some of the more common are:
サードパーティの署名には、幅広いアイデンティティが含まれます。より一般的なもののいくつかは次のとおりです。
Service Provider: In cases where email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or other type of service provider, that service provider can choose to DKIM-sign outbound mail with either its own identifier -- relying on its own, aggregate reputation -- or with a subdomain of the provider that is unique to the message author but still part of the provider's aggregate reputation. Such service providers can also encompass delegated business functions such as benefit management, although these will more often be treated as trusted third-party senders (see below).
サービスプロバイダー：電子メールが電子メールサービスプロバイダー（ESP）、インターネットサービスプロバイダー（ISP）、またはその他の種類のサービスプロバイダーにアウトソーシングされている場合、サービスプロバイダーは、独自の識別子を使用してDKIM-Signのアウトバウンドメールを選択できます。それ自体に依存して、総合的な評判 - またはメッセージ著者に固有のプロバイダーのサブドメインを使用して、プロバイダーの総評判の一部です。このようなサービスプロバイダーは、利益管理などの委任されたビジネス機能を網羅することもできますが、これらはより多くの場合、信頼できるサードパーティの送信者として扱われます（以下を参照）。
Parent Domain: As discussed above, organizations choosing to apply a parent-domain signature to mail originating from subdomains can have their signatures treated as third party by some verifiers, depending on whether or not the "t=s" tag is used to constrain the parent signature to apply only to its own specific domain. The default is to consider a parent-domain signature valid for its subdomains.
親ドメイン：上記のように、サブドメインから発信されたメールに親ドメインの署名を適用することを選択した組織は、「t = s」タグが使用されるかどうかに応じて、いくつかの検証者によってサードパーティとして署名を扱うことができます。親の署名は、独自の特定のドメインにのみ適用されます。デフォルトは、そのサブドメインに対して有効な親ドメイン署名を考慮することです。
Reputation Provider: Another possible category of third-party signature would be the identity of a third-party reputation provider. Such a signature would indicate to receivers that the message was being vouched for by that third party.
評判プロバイダー：サードパーティの署名のもう1つのカテゴリは、サードパーティの評判プロバイダーのアイデンティティです。このような署名は、メッセージがその第三者によって保証されていることを受信者に示します。
For most of the cases described so far, there has been an assumption that the signing agent was responsible for creating and maintaining its own DKIM signing infrastructure, including its own keys, and signing with its own identity.
これまでに説明したほとんどのケースでは、署名エージェントが独自の鍵を含む独自のDKIM署名インフラストラクチャを作成および維持する責任があり、独自のアイデンティティを備えた署名を担当したという仮定がありました。
A different model arises when an organization uses a trusted third-party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation. In other words, the mail would come out of the trusted third party's mail servers, but the signature applied would be that of the controlling organization.
組織が特定の主要なビジネス機能に信頼できるサードパーティの送信者を使用している場合、別のモデルが発生しますが、それでもそのメールが組織自身のアイデンティティと評判から利益を得ることを望んでいます。言い換えれば、メールは信頼できるサードパーティのメールサーバーから出てきますが、適用される署名は管理組織の署名です。
This can be done by having the third party generate a key pair that is designated uniquely for use by that trusted third party and publishing the public key in the controlling organization's DNS domain, thus enabling the third party to sign mail using the signature of the controlling organization. For example, if Company A outsources its employee benefits to a third party, it can use a special key pair that enables the benefits company to sign mail as "companyA.example". Because the key pair is unique to that trusted third party, it is easy for Company A to revoke the authorization if necessary by simply removing the public key from the companyA.example DNS.
これは、その信頼できるサードパーティが使用するために一意に指定され、管理組織のDNSドメインで公開キーを公開するために一意に指定されたキーペアをサードパーティに生成することで実行できます。組織。たとえば、会社Aが従業員の福利厚生をサードパーティに外部委託する場合、特別なキーペアを使用して、福利厚生会社が「Companya.example」としてメールに署名できるようにすることができます。キーペアはその信頼できるサードパーティに固有のものであるため、会社Aが会社から公開キーを削除するだけで、必要に応じて承認を取り消すことは簡単です。
A more cautious approach would be to create a dedicated subdomain (e.g., benefits.companyA.example) to segment the outsourced mail stream, and to publish the public key there; the signature would then use d=benefits.companyA.example.
より慎重なアプローチは、専用のサブドメイン（例：benefity.companya.example）を作成して、外部委託されたメールストリームをセグメント化し、そこに公開キーを公開することです。署名は、d = benefitive.companya.exampleを使用します。
Another possibility for configuring trusted third-party access, as discussed in Section 3.4, is to have Company A use DNS delegation and have the designated subdomain managed directly by the trusted third party. In this case, Company A would create a subdomain benefits.companya.example, and delegate the DNS management of that subdomain to the benefits company so it could maintain its own key records. When revocation becomes necessary, Company A could simply remove the DNS delegation record.
セクション3.4で説明したように、信頼できるサードパーティアクセスを構成するもう1つの可能性は、会社A DNS委任を行い、信頼できる第三者によって指定されたサブドメインを直接管理することです。この場合、会社Aはサブドメインの福利厚生を作成し、そのサブドメインのDNS管理を福利厚生会社に委任し、独自の主要な記録を維持できます。取り消しが必要になると、会社AはDNS委任記録を単純に削除できます。
A simple configuration for DKIM-signed mail is to have a single signature on a given message. This works well for domains that manage and send all of their own email from single sources, or for cases where multiple email streams exist but each has its own unique key pair. It also represents the case in which only one of the participants in an email sequence is able to sign, no matter whether it represents the author or one of the operators.
DKIMに署名したメールの単純な構成は、特定のメッセージに単一の署名を持つことです。これは、単一のソースから独自の電子メールをすべて管理および送信するドメイン、または複数の電子メールストリームが存在するが、それぞれが独自のキーペアを持っている場合に適しています。また、著者であろうとオペレーターの1人を表すかどうかに関係なく、電子メールシーケンスの参加者の1人のみが署名できる場合も表します。
The examples thus far have considered the implications of using different identities in DKIM signatures, but have used only one such identity for any given message. In some cases, it can make sense to have more than one identity claiming responsibility for the same message.
これまでの例では、DKIM署名で異なるアイデンティティを使用することの意味を考慮していますが、特定のメッセージに対してそのようなアイデンティティは1つだけ使用しています。場合によっては、同じメッセージの責任を主張する複数のアイデンティティを持つことは理にかなっています。
There are a number of situations where applying more than one DKIM signature to the same message might make sense. A few examples are:
同じメッセージに複数のDKIM署名を適用することが理にかなっている場合がある場合、多くの状況があります。いくつかの例は次のとおりです。
Companies with multiple subdomain identities: A company that has multiple subdomains sending distinct categories of mail might choose to sign with distinct subdomain identities to enable each subdomain to manage its own identity. However, it might also want to provide a common identity that cuts across all of the distinct subdomains. For example, Company A can sign mail for its sales department with a signature where d=sales.companya.example and a second signature where d=companya.example
複数のサブドメインのアイデンティティを持つ企業：複数のサブドメインが異なるカテゴリのメールを送信している企業は、各サブドメインが独自のアイデンティティを管理できるようにするために、異なるサブドメインIDで署名することを選択できます。ただし、すべての異なるサブドメインをカットする共通のアイデンティティを提供したい場合もあります。たとえば、会社Aは販売部門のメールに署名して、d = sales.companya.exampleとd = companya.exampleの2番目の署名で署名を備えています
Service Providers: A service provider can, as described above, choose to sign outbound messages with either its own identity or an identity unique to each of its clients (possibly delegated). However, it can also do both: sign each outbound message with its own identity as well as with the identity of each individual client. For example, ESP A might sign mail for its client Company B with its service provider signature d=espa.example, and a second client-specific signature where d= either companyb.example or companyb.espa.example. The existence of the service provider
サービスプロバイダー：サービスプロバイダーは、上記のように、それぞれのクライアントに固有の独自のIDまたはアイデンティティ（おそらく委任）でアウトバウンドメッセージに署名することを選択できます。ただし、両方を行うこともできます。各アウトバウンドメッセージには、独自のアイデンティティと各個々のクライアントのIDとともに署名します。たとえば、ESP Aは、サービスプロバイダーの署名d = espa.example、およびd = companyb.exampleまたはcompanyb.espa.exampleのいずれかで2番目のクライアント固有の署名を備えたクライアント企業Bのメールに署名する場合があります。サービスプロバイダーの存在
signature could, for example, help cover a new client while it establishes its own reputation, or help a very small volume client who might never reach a volume threshold sufficient to establish an individual reputation.
たとえば、署名は、独自の評判を確立しながら新しいクライアントをカバーするのに役立ちます。また、個々の評判を確立するのに十分なボリュームしきい値に達することがない非常に少ないボリュームクライアントを支援することができます。
Forwarders: Forwarded mail poses a number of challenges to email authentication. DKIM is relatively robust in the presence of forwarders as long as the signature is designed to avoid message parts that are likely to be modified; however, some forwarders do make modifications that can invalidate a DKIM signature.
フォワーダー：転送されたメールは、認証を電子メールで送信するための多くの課題を提起します。DKIMは、署名が変更される可能性のあるメッセージ部品を避けるように設計されている限り、フォワーダーの存在下で比較的堅牢です。ただし、一部のフォワーダーは、DKIMの署名を無効にする可能性のある変更を行います。
Some forwarders such as mailing lists or "forward article to a friend" services might choose to add their own signatures to outbound messages to vouch for them having legitimately originated from the designated service. In this case, the signature would be added even in the presence of a preexisting signature, and both signatures would be relevant to the verifier.
メーリングリストや「フォワード記事」などの一部のフォワーダーは、指定されたサービスから合法的に発信された彼らを保証するために、独自の署名をアウトバウンドメッセージに追加することを選択する場合があります。この場合、既存の署名が存在する場合でも署名が追加され、両方の署名が検証剤に関連します。
Any forwarder that modifies messages in ways that will break preexisting DKIM signatures needs to sign its forwarded messages.
既存のDKIM署名を破る方法でメッセージを変更するフォワーダーは、転送されたメッセージに署名する必要があります。
Reputation Providers: Although third-party reputation providers today use a variety of protocols to communicate their information to receivers, it is possible that they, or other organizations willing to put their "seal of approval" on an email stream, might choose to use a DKIM signature to do it. In nearly all cases, this "reputation" signature would be in addition to the author or originator signature.
評判プロバイダー：サードパーティの評判プロバイダーは今日、さまざまなプロトコルを使用して情報を受信者に伝えますが、電子メールストリームに「承認の印章」を配置する意思がある他の組織は、を使用することを選択する可能性があります。それを行うためのdkim署名。ほとんどすべての場合、この「評判」の署名は、著者またはオリジネーターの署名に加えています。
One important caveat to the use of multiple signatures is that there is currently no clear consensus among receivers on how they plan to handle them. The opinions range from ignoring all but one signature (and the specification of which of them is verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identifier that represents the most positive trust assessment. It is likely that the industry will evolve to accept multiple signatures using either the second or third of these, but it can take some time before one approach becomes pervasive.
複数の署名を使用するための重要な注意事項の1つは、現在、受信者がそれらを処理する計画について明確なコンセンサスがないことです。意見は、1つの署名を除くすべての署名（およびそれらのどの仕様が受信機ごとに異なる）から、存在するすべての署名を検証し、それらの識別子の信頼評価の加重ブレンドを適用することまで、存在するすべての署名を検証することまで、最も肯定的な信頼評価を表す識別子を単に使用します。業界は、これらの2番目または3分の1を使用して複数の署名を受け入れるように進化する可能性がありますが、1つのアプローチが広範になるまでには時間がかかる場合があります。
Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or a different one, and so on.
署名は、さまざまなタイプの電子メールアクターによって作成されます。これは、アクターが著者から受信者へのシーケンスで動作する場所、同じ評判の下で異なるメッセージを評価するか、異なるメッセージなどを使用するかなど、さまざまな基準に基づいて作成されます。
This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive but to illustrate a set of key deployment considerations.
このセクションでは、DKIM展開の使用シナリオの例をいくつか示します。選択は網羅的ではなく、一連の重要な展開に関する考慮事項を説明することを目的としています。
The simplest DKIM configuration is to have some mail from a given organization (Company A) be signed with the same d= value (e.g., d=companya.example). If there is a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example.
最も単純なDKIM構成は、特定の組織（会社A）からのメールを同じd =値（例：d = companya.example）で署名することです。追加情報を関連付けたい場合、auid [rfc5672]値はuniqued @companya.example、または @siqued.companya.exampleになります。
In this scenario, Company A need only generate a single signing key and publish it under their top-level domain (companya.example); the signing module would then tailor the AUID value as needed at signing time.
このシナリオでは、会社は単一の署名キーを生成し、トップレベルのドメイン（Companya.example）の下で公開する必要があります。署名モジュールは、署名時に必要に応じてAUID値を調整します。
A slight variation of the one signature case is where Company A signs some of its mail, but it wants to differentiate among categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively, where each category is assigned a unique subdomain and unique signing keys.
1つの署名ケースのわずかなバリエーションは、会社がそのメールの一部に署名する場所ですが、異なる識別子を使用して、アウトバウンドメールのカテゴリ間で区別したいと考えています。たとえば、マーケティング、請求、トランザクション、および個々のコーポレートメールをMarketing.companya.example、billing.companya.example、およびcompanya.exampleにそれぞれ区別することを選択する場合があります。。
Some domains might decide to sign all of their outgoing mail. If all of the legitimate mail for a domain is signed, recipients can be more aggressive in their filtering of mail that uses the domain but does not have a valid signature from the domain; in such a configuration, the absence of a signature would be more significant than for the general case. It might be desirable for such domains to be able to advertise their intent to other receivers: this is the topic of Author Domain Signing Practices (ADSP).
一部のドメインは、すべての送信メールに署名することを決定する場合があります。ドメインの正当なメールがすべて署名されている場合、ドメインを使用しているがドメインからの有効な署名がないメールのフィルタリングで受信者がより積極的になる可能性があります。このような構成では、署名がないことは、一般的なケースよりも重要です。そのようなドメインが他のレシーバーに意図を宣伝できることが望ましい場合があります。これは、著者ドメイン署名プラクティス（ADSP）のトピックです。
Note that ADSP is not for everyone. Sending domains that do not control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to experience delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains needs to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.
ADSPはすべての人のためではないことに注意してください。ドメインからのものであると主張するすべての正当なアウトバウンドメールを制御しないドメインを送信する（つまり、RFC5322.のドメインの住所から）は、そのメールのある割合で配信の問題を経験する可能性があります。ドメインのADSPを評価する管理者は、未配達のメールの可能性に対するフィッシング攻撃のリスクを慎重に比較検討する必要があります。
This section covers some examples of ADSP usage. For the complete specification, see [RFC5617].
このセクションでは、ADSP使用の例について説明します。完全な仕様については、[RFC5617]を参照してください。
In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address.
ADSP仕様では、メッセージのヘッダーフィールドからRFC5322のアドレスが「著者アドレス」として定義され、「著者ドメイン」は、著者アドレスの「@」の右側にあるものとして定義されます。
An "Author Signature" is thus any valid signature where the value of the SDID matches an author domain in the message.
したがって、「著者署名」は、SDIDの値がメッセージ内の著者ドメインと一致する場合の有効な署名です。
It is important to note that unlike the DKIM specification, which makes no correlation between the signature domain and any message headers, the ADSP specification applies only to the author domain. In essence, under ADSP, any non-author signatures are ignored (treated as if they are not present).
署名ドメインとメッセージヘッダーとの間に相関関係がないDKIM仕様とは異なり、ADSP仕様は著者ドメインにのみ適用されることに注意することが重要です。本質的に、ADSPの下では、非著者の署名は無視されます（まるで存在しないかのように扱われます）。
Signers wishing to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will thus want to include an author signature on their outbound mail to avoid ADSP verification failures.
したがって、署名プラクティスを説明する著者ドメイン署名プラクティス（ADSP）[RFC5617]レコードを公開したい署名者は、ADSP検証の障害を回避するために、著者の署名をアウトバウンドメールに含めることを望んでいます。
An organization (Company A) can specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP, Company A needs to first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain.
組織（会社A）は、「dkim = all」または「dkim =廃棄可能」でADSPレコードを公開することにより、署名プラクティスを指定できます。ADSPを検証しているレシーバーでのメールの誤配信を回避するために、会社Aは最初に徹底的な分析を行って、そのドメイン（Companya.example）からのアウトバウンドメールのすべてのソースを決定し、すべてが有効な著者署名を持っていることを確認する必要があります。そのドメイン。
For example, email with an RFC5322.From address of bob@ companyA.example needs to have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation.
たとえば、rfc5322を含むメールbob@ companya.exampleのアドレスから電子メールでは、sdid値が「companya.example」であるか、ADSP検証に失敗する著者署名が必要です。
Note that once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published that does not have a valid author signature is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check because the signature would not be considered a valid author signature.
組織がdkim = allまたはdkim = disdardableを使用してADSPレコードを公開したら、rfc5322を含む任意の電子メールが、有効な著者の署名がないADSPレコードが公開されているドメインを使用するアドレスから、誤った紛失のリスクがあることに注意してください。または破棄されます。たとえば、rfc5322を含むメッセージがnewsletter@companya.exampleのアドレスからd = marketing.companya.exampleの署名がある場合、そのメッセージは署名が有効な著者署名とは見なされないため、ADSPチェックに失敗します。
Because the semantics of an ADSP author signature are more constrained than the semantics of a "pure" DKIM signature, it is important to make sure the nuances are well understood before deploying an ADSP record. The ADSP specification [RFC5617] provides some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B).
ADSP Authorの署名のセマンティクスは、「純粋な」DKIM署名のセマンティクスよりも制約されているため、ADSPレコードを展開する前にニュアンスがよく理解されていることを確認することが重要です。ADSP仕様[RFC5617]は、いくつかのかなり広範な検索例（付録Aの）および使用例（付録Bの）を提供します。
In particular, in order to prevent mail from being negatively impacted or even discarded at the receiver, it is essential to perform a thorough survey of outbound mail from a domain before publishing an ADSP policy of anything stronger than "unknown". This includes mail that might be sent from external sources that might not be authorized to use the domain signature, as well as mail that risks modification in transit that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body).
特に、電子メールがマイナスの影響を受けたり、受信機で廃棄されたりするのを防ぐためには、「不明」よりも強いもののADSPポリシーを公開する前に、ドメインからのアウトバウンドメールの徹底的な調査を実行することが不可欠です。これには、ドメインの署名を使用することを許可されていない外部ソースから送信される可能性のあるメール、およびそれ以外の有効な著者の署名を無効にする可能性のある輸送中の変更をリスクするメール（例：メーリングリスト、提供：他のパス、その他のパスこれにより、ヘッダーを追加または変更したり、メッセージ本文を変更したりできます）。
An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email.
組織は、特定の主要サービスを独立企業に外注することを選択する場合があります。たとえば、会社Aは利益管理を外部委託する可能性があり、組織Bはマーケティングメールを外部委託する可能性があります。
If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4, it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain.
Company Aが、セクション6.4で説明したように、福利厚生プロバイダーに代わって送信されたすべてのメールがベネフィットプロバイダーを通じて送信されることを保証したい場合、Companya.exampleに基づいて福利厚生プロバイダーの使用に指定されたキーを公開することができます。（できればcompanya.exampleの指定されたサブドメインの下）、またはサブドメイン（たとえば、benefition.companya.example）をプロバイダーに委任し、プロバイダーがキーを生成し、指定されたサブドメインのDNSを管理できるようにすることができます。
In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address is not constrained: it could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain.
これらの両方のケースでは、メールは、d = benefitive.companya.exampleの署名を備えた福利厚生プロバイダーのメールサーバーから物理的に出て行きます。rfc5322.fromアドレスが制約されていないことに注意してください。それは、福利厚生会社（heention-admin@benefitprovider.example、またはbeantion-provider@benefits.companya.example）または会社ドメインのいずれかに関連する可能性があることに注意してください。
Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios.
セクション3.4で説明したように、上記の両方のシナリオで、セキュリティの懸念は、秘密鍵を転送する必要がないように、署名を行うことを計画している組織によってキーが生成されることを決定することに注意してください。つまり、福利厚生プロバイダーは、上記の両方のシナリオのキーを生成します。
Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client, Company A, with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and might sign all outgoing mail from its clients with its own d= domain (e.g., d=espa.example).
サービスプロバイダーの構成を管理するもう1つの方法は、サービスプロバイダーに、クライアントA Company Aを独自の（プロバイダー）識別子とともに送信メールに署名させることです。たとえば、電子メールサービスプロバイダー（ESP A）は、クライアントと独自の郵送の評判を共有したい場合があり、独自のD =ドメイン（d = espa.exampleなど）でクライアントからのすべての送信メールに署名する場合があります。
When the ESP wants to distinguish among its clients, it has two options:
ESPがクライアントを区別したい場合、2つのオプションがあります。
o Share the SDID domain and use the AUID value to distinguish among the clients, e.g., a signature on behalf of client A would have d=espa.example and i=@clienta.espa.example (or i=clienta@espa.example).
o SDIDドメインを共有し、AUID値を使用してクライアントを区別します。たとえば、クライアントAに代わって署名がD = espa.exampleとi =@clienta.espa.example（またはi = clienta@espa.example）があります。。
o Extend the SDID domain, so there is a unique value (and subdomain) for each client, e.g., a signature on behalf of client A would have d=clienta.espa.example.
o SDIDドメインを拡張するため、各クライアントに一意の値（およびサブドメイン）があります。たとえば、クライアントAに代わって署名がd = clienta.espa.exampleを持っています。
Note that this scenario and the delegation scenario are not mutually exclusive. In some cases, it can be desirable to sign the same message with both the ESP and the ESP client identities.
このシナリオと委任シナリオは相互に排他的ではないことに注意してください。場合によっては、ESPとESPクライアントのIDの両方で同じメッセージに署名することが望ましい場合があります。
An ISP (ISP A) might want to assign signatures to outbound mail from its users according to each user's past sending behavior (reputation). In other words, the ISP would segment its outbound traffic according to its own assessment of message quality, to aid recipients in differentiating among these different streams. Since the semantics of behavioral assessments are not valid AUID values, ISP A (ispa.example) can configure subdomains corresponding to the assessment categories (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these subdomains in the d= value of the signature.
ISP（ISP A）は、各ユーザーの過去の送信行動（評判）に従って、ユーザーからのアウトバウンドメールに署名を割り当てたい場合があります。言い換えれば、ISPは、メッセージ品質の独自の評価に従ってアウトバウンドトラフィックをセグメント化し、受信者がこれらの異なるストリームを区別するのを支援します。行動評価のセマンティクスは有効なAUID値ではないため、ISP A（ISPA.example）は、評価カテゴリに対応するサブドメインを構成できます（例：good.ispa.example、neutral.ispa.example、bad.ispa.example）、および署名のd =値でこれらのサブドメインを使用します。
The signing module can also set the AUID value to have a unique user ID (distinct from the local-part of the user's email address), for example, user3456@neutral.domain.example. Using a user ID that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases.
署名モジュールは、auid値を設定して、user3456@neutral.domain.exampleなど、一意のユーザーID（ユーザーのメールアドレスのローカルパートとは異なる）を持つこともできます。特定の電子メールエイリアスとは異なるユーザーIDを使用すると、単一のユーザーが複数の電子メールエイリアスを登録する環境で役立ちます。
Note that in this case, the AUID values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that
この場合、AUID値は部分的に安定していることに注意してください。与えられたi =値は常に同じアイデンティティを表すという意味で安定していますが、その意味では不安定です
a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple AUID values over the lifetime of a single account).
特定のユーザーは、送信動作に応じて評価サブドメイン間で移行できます（つまり、同じユーザーが単一のアカウントの寿命にわたって複数のAUID値を持つ場合があります）。
In this scenario, ISP A can generate as many keys as there are assessment subdomains (SDID values), so that each assessment subdomain has its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired, include the user ID in the AUID of the signature. As discussed earlier, the per-user granularity of the AUID can be ignored by verifiers; so organizations choosing to use it ought not rely on its use for receiver side filtering results. However, some organizations might also find the information useful for their own purposes in processing bounces or abuse reports.
このシナリオでは、ISP Aは評価サブドメイン（SDID値）と同じくらい多くのキーを生成することができるため、各評価サブドメインに独自のキーがあります。署名モジュールは、メールが署名されているユーザーの評価に基づいて署名キーを選択し、必要に応じて署名のAUIDにユーザーIDを含めます。前述のように、AUIDのユーザーごとの粒度は検証剤によって無視できます。したがって、それを使用することを選択した組織は、受信機側のフィルタリング結果に使用することに依存してはなりません。ただし、一部の組織は、バウンスまたは乱用レポートの処理において独自の目的に役立つ情報も見つける場合があります。
Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. In general, if the service is configured in such a way that its forwarding would break existing DKIM signatures, it needs to always add its own signature.
別のシナリオは、エージェント、通常は何らかのリメイラーであり、それが代表するサービスまたは組織に代わってサインするものです。エージェントの例のいくつかは、メーリングリストマネージャー、または多くのオンライン出版物が提供する「友人へのフォワード記事」サービスです。これらのほとんどの場合、署名は、メッセージが責任を主張するサービスによって発生した、または中継されたと主張しています。一般に、サービスが既存のDKIM署名を破壊するようにサービスが構成されている場合、常に独自の署名を追加する必要があります。
The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and other paths that could add or modify headers, or modify the message body.
DKIMの検証メカニズムの堅牢性は、承認された署名モジュールのみが指定された秘密鍵にアクセスできるという事実に基づいています。これには、承認された署名モジュールのドメインの外部からメッセージを発信またはリレーする電子メールの送信および配信シナリオが、その保護された秘密キーにアクセスできないため、予想されるドメイン署名をそれらのメッセージに添付できないという副作用があります。このようなシナリオには、メーリングリスト、礼儀フォワーダー、ホテルのMTA、旅行ユーザーが使用するホットスポットネットワーク、およびヘッダーを追加または変更したり、メッセージ本文を変更したりできる他のパスが含まれます。
For example, assume Joe works for Company A and has an email address joe@companya.example. Joe also has an ISP-1 account joe@isp1.example.com, and he uses ISP-1's multiple address feature to attach his work email address, joe@companya.example, to email from his ISP-1 account. When Joe sends email from his ISP-1 account and uses joe@companya.example as his designated RFC5322.From address,
たとえば、JoeがA Company Aで働いており、メールアドレスjoe@companya.exampleを持っていると仮定します。JoeにはISP-1アカウントjoe@isp1.example.comもあり、ISP-1の複数のアドレス機能を使用して、ISP-1アカウントからメールのメールアドレスjoe@companya.exampleを添付しています。JoeがISP-1アカウントから電子メールを送信し、joe@companya.exampleを指定されたrfc5322.fromアドレスとして使用するとき、
that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case, it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there might be no signature at all on the message.
ISP-1サーバーが会社Aのプライベートキーにアクセスできないため、そのメールはd = companya.exampleを使用して署名を持つことはできません。ISP-1の場合、ISP-1の署名がありますが、同じ複数のアドレス機能を提供する他のメールクライアントの場合、メッセージにはまったく署名がない場合があります。
Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC5322.From to their designated recipient. If Joe used either of his two addresses (joe@companya.example or joe@isp1.example.com), the forwarder would be equally unable to sign with a corresponding domain. As in the mail client case, the forwarder can either sign as its own domain or put no signature on the message.
別の例は、友人サービスへのフォワード記事を使用することかもしれません。今日のこれらのサービスのほとんどのインスタンスにより、誰かがRFC5322にメールアドレスを含む記事を指定された受信者から送信することができます。Joeが2つのアドレス（joe@companya.exampleまたはjoe@isp1.example.com）のいずれかを使用した場合、フォワーダーは対応するドメインで署名することもできません。メールクライアントの場合のように、フォワーダーは独自のドメインとして署名するか、メッセージに署名を入れることができません。
A third example is the use of privately configured forwarding. Assume that Joe has another account at ISP-2, joe@isp-2.example.com, but he'd prefer to read his ISP-2 mail from his ISP-1 account. He sets up his ISP-2 account to forward all incoming mail to joe@isp1.example.com. Assume alice@companyb.example sends joe@isp-2.example.com an email. Depending on how companyb.example configured its signature, and depending on whether or not ISP-2 modifies messages that it forwards, it is possible that when Alice's message is received in Joe's ISP-1 account, the original signature will fail verification.
3番目の例は、個人構成の転送の使用です。JoeがISP-2、joe@isp-2.example.comに別のアカウントを持っていると仮定しますが、彼はISP-1アカウントからISP-2メールを読むことを好みます。彼はISP-2アカウントを設定して、すべての着信メールをjoe@isp1.example.comに転送します。alice@companyb.exampleをjee@isp-2.example.comにメールを送信します。CompanyB.exampleがその署名を構成する方法、およびISP-2が転送するメッセージを変更するかどうかに応じて、AliceのメッセージがJoeのISP-1アカウントで受信されると、元の署名が検証に失敗する可能性があります。
One identity is particularly amenable to easy and accurate assessment: the organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However, Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization that does not contain a verifiable signature.
1つのアイデンティティは、特に簡単で正確な評価に適しています。組織自身のアイデンティティです。組織のメンバーは、その組織内から出身すると主張するメッセージを信頼する傾向があります。ただし、インターネットメールは、そのようなメールが実際に組織内からであるかどうかを判断する簡単な手段を提供しません。DKIMは、この曝露を改善するために使用できます。組織がすべてのメールに署名した場合、その境界MTAは、検証可能な署名を含まない組織からのものであると主張するメールを探すことができます。
Such mail can, in most cases, be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices.
そのようなメールは、ほとんどの場合、偽物であると推定される可能性があります。ただし、ドメインマネージャーは、メール処理が既存のDKIM署名を無効にする方法でメッセージを変更できる方法を検討することをお勧めします：メーリングリスト、礼儀フォワーダー、およびヘッダーを追加または変更したり、メッセージ本文を変更したりできる他のパス（例：MTAS、MTASホテルでは、旅行ユーザーが使用するホットスポットネットワーク、および前のセクションで説明したその他のシナリオ）。このような破損は、著者ドメイン署名慣行の存在下で特に関連しています。
Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer subdomains or otherwise adjust signatures in a way that supports per-user identification. This user-level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity or by creating and signing with unique per-user keys.
DKIMのドメイン名の使用は、組織レベルの署名の範囲に最適化されていますが、サブドメインを管理するか、ユーザーごとの識別をサポートする方法で署名を調整することができます。このユーザーレベルの粒度は、2つの方法で指定できます。署名IDを共有し、ユーザーごとの粒度を持つi =値の拡張機能を指定するか、ユニークなユーザーごとのキーを作成および署名することにより。
A subdomain or local part in the i= tag needs to be treated as an opaque identifier and thus need not correspond directly to a DNS subdomain or be a specific user address.
i =タグのサブドメインまたはローカル部分は不透明な識別子として扱う必要があるため、DNSサブドメインに直接対応する必要はないか、特定のユーザーアドレスである必要はありません。
The primary way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (It is possible, although not advised, to publish the same key in more than one distinct domain.)
ユーザーごとのキーで署名する主要な方法では、各ユーザーが個別のDNS（SUB）ドメインを持つ必要があります。各d =値にキーが公開されています。（推奨されていませんが、同じキーを複数の異なるドメインで公開することは可能です。）
It is technically possible to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not advised and is unlikely to be treated uniquely by Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identities.
技術的には、異なるセレクター値を使用して、単一のドメインまたはサブドメイン内でユーザーごとのキーを公開することができます。これはアドバイスされておらず、評価者によって独自に扱われる可能性は低いです。セレクターの主な目的は主要な管理を促進することであり、DKIM仕様はアイデンティティの決定または評価にそれらを使用することを推奨しています。
In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be
ほとんどの場合、ユーザーごとの粒度に電子メールに署名することは非現実的です。そのようなアプローチはそうでしょう
likely to be ignored: In most cases today, if receivers are verifying DKIM signatures, they are in general taking the simplest possible approach. In many cases, maintaining reputation information at a per-user granularity is not interesting to them, in large part because the per-user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per-user signatures, receivers are unlikely to retain anything more than the base domain reputation.
無視される可能性が高い：今日のほとんどの場合、受信者がDKIM署名を検証している場合、一般的に可能な限り単純なアプローチを取っています。多くの場合、ユーザーごとの粒度で評判情報を維持することは、それらにとって興味深いものではありません。これは、ユーザーごとのボリュームが小さすぎて便利または興味深いものであるためです。したがって、送信者がユーザーごとの署名をサポートするために必要な複雑さを引き受けたとしても、レシーバーは基本ドメインの評判以上のものを保持する可能性は低いです。
difficult to manage: Any scheme that involves maintenance of a significant number of public keys might require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary management complexity. It is also important to note
管理が困難：かなりの数のパブリックキーのメンテナンスを伴うスキームには、インフラストラクチャの強化または広範な管理の専門知識が必要になる場合があります。あらゆるサイズのドメインの場合、有効なユーザーごとのキーペアを維持し、ユーザーの消耗またはオンボーディングのためにキーを取り消す必要があるか、追加する必要があることを知ることができ、署名エンジンが常にキーを交換するオーバーヘッドは、かなりのかつ不要な管理の複雑さを生み出すことができます。また、注意することも重要です
that there is no way within the scope of the DKIM specification for a receiver to infer that a sender intends a per-user granularity.
送信者がユーザーごとの粒度を意図することを推測するためのDKIM仕様の範囲内にはないこと。
As mentioned before, what might make sense, however, is to use the infrastructure that enables finer granularity in signatures to identify segments smaller than a domain but much larger than a per-user segmentation. For example, a university might want to segment student, staff, and faculty mail into three distinct streams with differing reputations. This can be done by creating separate subdomains for the desired segments, and either specifying the subdomains in the i= tag of the DKIM Signature or by adding subdomains to the d= tag and assigning and signing with different keys for each subdomain.
前述のように、理にかなっているかもしれないのは、署名のより細かい粒度を可能にするインフラストラクチャを使用して、ドメインよりも小さいがユーザーごとのセグメンテーションよりもはるかに大きいセグメントを識別することです。たとえば、大学は、学生、スタッフ、および教員のメールを、異なる評判のある3つの異なるストリームに分割したい場合があります。これは、目的のセグメントに個別のサブドメインを作成し、DKIM署名のi =タグのサブドメインを指定するか、d = tagにサブドメインを追加し、各サブドメインの異なるキーを割り当てて署名することによって実行できます。
For those who choose to represent user-level granularity in signatures, the performance and management considerations above suggest that it would be more effective to do so by specifying a local part or subdomain extension in the i= tag rather than by extending the d= domain and publishing individual keys.
署名でユーザーレベルの粒度を表すことを選択した人のために、上記のパフォーマンスと管理の考慮事項は、d =ドメインを拡張するのではなく、i =タグのローカル部分またはサブドメイン拡張を指定することにより、より効果的であることを示唆しています。個々の鍵を公開します。
It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service, such as a department or a boundary MTA. What follows are some general recommendations for the Email Infrastructure.
DKIM実装の最も一般的な会場は、部門や境界MTAなどの組織の電子メールサービスのインフラストラクチャ内にあることが期待されています。以下は、電子メールインフラストラクチャに関する一般的な推奨事項です。
Outbound: An MSA (Mail Submission Agent) or an outbound MTA used for mail submission needs to ensure that the message sent is in compliance with the advertised email sending policy. It needs to also be able to generate an operator alert if it determines that the email messages do not comply with the published DKIM sending policy.
アウトバウンド：MSA（メール提出エージェント）またはメールの提出に使用されるアウトバウンドMTAは、送信されたメッセージが広告された電子メール送信ポリシーに準拠していることを確認する必要があります。また、電子メールメッセージが公開されたDKIM送信ポリシーに準拠していないと判断した場合、オペレーターアラートを生成できる必要があります。
An MSA needs to be aware that some MUAs might add their own signatures. If the MSA needs to perform operations on a message to make it comply with its email sending policy, if at all possible, it needs to do so in a way that would not break those signatures.
MSAは、一部のMUAが独自の署名を追加する可能性があることに注意する必要があります。MSAがメッセージの操作を実行して電子メール送信ポリシーを順守する必要がある場合、可能な場合は、これらの署名を破らない方法でそうする必要があります。
MUAs equipped with the ability to sign ought not to be encouraged. In terms of security, MUAs are generally not under the direct control of those in responsible roles within an organization and are thus more vulnerable to attack and compromise, which would expose private signing keys to intruders and thus jeopardize the integrity and reputation of the organization.
署名する能力を備えたMUASは奨励されるべきではありません。セキュリティに関しては、MUAは一般に組織内の責任ある役割にある人々の直接的な管理下にあるわけではなく、したがって攻撃や妥協に対してより脆弱であり、侵入者にプライベート署名キーをさらし、組織の完全性と評判を危険にさらすでしょう。
Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification.
インバウンド：組織がDKIMを展開する場合、DKIMハンドリングの主要な役割を持たない電子メールインフラストラクチャコンポーネントが、その後の検証を防ぐ方法でメッセージを変更しないことを確認する必要があります。
An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
インバウンドMTAまたはMDAは、認証結果のヘッダーフィールド[RFC5451]を使用するなど、検証結果の表示をメッセージに組み込むことができます。
Intermediaries: An email intermediary is both an inbound and outbound MTA. Each of the requirements outlined in the sections relating to MTAs apply. If the intermediary modifies a message in a way that breaks the signature, the intermediary.
仲介者：電子メール仲介者は、インバウンドとアウトバウンドMTAの両方です。MTAに関連するセクションで概説されている各要件が適用されます。仲介者が署名を破る方法でメッセージを変更する場合、仲介者。
+ needs to deploy abuse filtering measures on the inbound mail, and
+ インバウンドメールに乱用フィルタリング測定を展開する必要があり、
+ probably also needs to remove all signatures that will be broken.
+ また、おそらく破損するすべての署名を削除する必要があります。
In addition, the intermediary can:
さらに、仲介者は以下を行うことができます。
+ verify the message signature prior to modification.
+ 変更前にメッセージ署名を確認します。
+ incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
+ 認証結果のヘッダーフィールドを使用するなど、検証結果の表示をメッセージに組み込みます[RFC5451]。
+ sign the modified message including the verification results (e.g., the Authentication-Results header field).
+ 検証結果を含む修正されたメッセージに署名します（例：認証と結果のヘッダーフィールド）。
The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs. However, there is nothing in DKIM that is specific to those venues. In particular, MUAs can also support DKIM signing and verifying directly.
DKIM仕様は、主に境界MTA、または発信および受信のADMDの他のインフラストラクチャコンポーネントの間で使用されると予想されます。ただし、DKIMにはそれらの会場に固有のものは何もありません。特に、MUASはDKIMの署名と検証を直接サポートすることもできます。
Outbound: An MUA can support signing even if mail is to be relayed through an outbound MSA. In this case, the signature applied by the MUA will be in addition to any signature added by the MSA. However, the warnings in the previous section need to be taken into consideration.
アウトバウンド：MUAは、メールがアウトバウンドMSAを介して中継する場合でも、署名をサポートできます。この場合、MUAによって適用される署名は、MSAによって追加された署名に追加されます。ただし、前のセクションの警告を考慮する必要があります。
Some user software goes beyond simple user functionality and also performs MSA and MTA functions. When this is employed for sending directly to a receiving ADMD, the user software needs to be considered an outbound MTA.
一部のユーザーソフトウェアは、単純なユーザー機能を超えており、MSAおよびMTA関数も実行します。これが受信admdに直接送信するために使用される場合、ユーザーソフトウェアはアウトバウンドMTAと見なされる必要があります。
Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path; if a signature fails, the message is to be treated the same as a message that does not have a signature.
インバウンド：MUAは、インバウンドMTA/ MDAパスのある時点で行われたDKIM署名検証のレポートに依存することができます（例：認証結果ヘッダーフィールド）、またはMUAはDKIM署名検証を直接実行できます。検証MUAは、インバウンドMTAパスでメールが変更された場合を許可する必要があります。署名が失敗した場合、メッセージは署名がないメッセージと同じように扱われることです。
An MUA that looks for an Authentication-Results header field needs to be configurable to choose which Authentication-Results header fields are considered trustable. The MUA developer is encouraged to re-read the Security Considerations of [RFC5451].
認証結果を探すMUAは、どの認証結果ヘッダーフィールドが信頼できると見なされるかを選択するために設定可能である必要があります。MUA開発者は、[RFC5451]のセキュリティ上の考慮事項を読み直すことをお勧めします。
DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned.
DKIMでは、すべての検証者が、署名されていないかのように確認しない署名でメッセージを扱うことを要求します。
If verification in the client is to be acceptable to users, it is essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. The mere presence of a verified DKIM signature cannot be used by itself by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified can be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators.
クライアントの検証がユーザーに受け入れられる場合、署名の検証を成功させると、メッセージが署名されていないままになるのと比較して、満足のいくユーザーエクスペリエンスが発生しないことが不可欠です。検証済みのDKIM署名の単なる存在は、MUAによって単独で使用することはできません。これは、検証済みのDKIM署名なしでメッセージがメッセージよりも優れて扱われることを示すことはできません。ただし、DKIM署名が確認されたという事実は、そのような指標を提示するために、評判システム（つまり、ドメインとユーザーのホワイトリスト）への入力として使用できます。
It is common for components of an ADMD's email infrastructure to do violence to a message, such that a DKIM signature might be rendered invalid. Hence, users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature.
ADMDの電子メールインフラストラクチャのコンポーネントがメッセージに対して暴力を行うことが一般的であり、DKIMの署名が無効になる可能性があります。したがって、DKIMの署名および/または確認をサポートするMUASのユーザーは、関連する電子メールインフラストラクチャが署名を破らないことを知るための基礎が必要です。
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871].
DKIMプロトコルのセキュリティ上の考慮事項は、DKIMベース仕様[RFC4871]で説明されています。
The effort of the DKIM Working Group is gratefully acknowledged.
DKIMワーキンググループの努力は感謝されています。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[RFC5585] Hansen、T.、Crocker、D。、およびP. Hallam-Baker、「Domainkeys Idified Mail（DKIM）サービスの概要」、RFC 5585、2009年7月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「Domainkeys Idified Mail（DKIM）著者ドメイン署名プラクティス（ADSP）」、RFC 5617、2009年8月。
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.
[RFC5672] Crocker、D。、「RFC 4871 Domainkeys Idefied Mail（DKIM）署名 - 更新」、RFC 5672、2009年8月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC4870] Delany、M。、「DNS（domainkeys）で宣伝されているパブリックキーを使用したドメインベースの電子メール認証」、RFC 4870、2007年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）は認証された存在拒否」、RFC 5155、2008年3月。
There are three migration occasions worth noting in particular for DKIM:
特にDKIMで注目に値する3つの移行機会があります。
1. Migrating from DomainKeys to DKIM.
1. ドメインキーからDKIMへの移行。
2. Migrating from a current hash algorithm to a new standardized hash algorithm.
2. 現在のハッシュアルゴリズムから新しい標準化されたハッシュアルゴリズムに移行します。
3. Migrating from a current signing algorithm to a new standardized signing algorithm.
3. 現在の署名アルゴリズムから新しい標準化された署名アルゴリズムに移行します。
The case of deploying a new key selector record is described elsewhere (Section 3.5).
新しいキーセレクターレコードを展開する場合は、他の場所で説明されています（セクション3.5）。
As with any migration, the steps required will be determined by who is doing the migration and their assessment of:
他の移行と同様に、必要な手順は、誰が移行を行っているか、次の評価によって決定されます。
o the users of what they are generating, or
o 彼らが生成しているもののユーザー、または
o the providers of what they are consuming.
o 彼らが消費しているもののプロバイダー。
Signers and verifiers have different considerations.
署名者と検証者にはさまざまな考慮事項があります。
DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications.
DKIMは、以前のドメインキー（DK）仕様を置き換えます。セレクターファイルは、2つの仕様の間でほとんど互換性があります。
A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are:
現在DKと署名する署名者は、すべての署名者に必要なすべてではなく、DKIMの使用に移行する際にさまざまな段階を経ます。署名者が尋ねる必要がある本当の質問は次のとおりです。
1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, and
1. DKIM署名ではなく、DKの署名を見ているのは *のレシーバーの数またはレシーバーの種類のみが *のみです。
2. how much does the signer care about those receivers?
2. 署名者はそれらのレシーバーをどれだけ気にしていますか？
If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK.
DK署名をもう見ない場合、DKで署名する必要はなくなります。または、すべての「大手プレーヤー」がDKに加えてまたはDKIMに加えてDKIMを見ている場合、署名者はDKとの署名を停止することを選択できます。
With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way that DomainKeys signatures are already being used. In particular, the same selectors and DNS key records can be used for both, after verifying that they are compatible as discussed below.
署名ポリシーに関しては、妥当な最初のアプローチは、DomainKeys署名がすでに使用されているのと同じ方法でDKIM署名を使用することです。特に、以下で説明するように互換性があることを確認した後、同じセレクターとDNSキーレコードを両方に使用できます。
Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue".
次のすべてのシナリオの各セカンダリステップは、ゲーティングファクター「テストをテストし、以前のステップの結果に満足している場合は続行」を備えています。
One migration strategy is to:
移行戦略の1つは次のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 現在のセレクターDNSキーレコードがDKとDKIMの両方と互換性があることを確認してください
o sign messages with both DK and DKIM signatures
o DKとDKIMの両方の署名で署名メッセージ
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o DK署名が不要になることが決定されたら、DKでの署名を停止します
Another migration strategy is to:
別の移行戦略は次のとおりです。
o add a new selector DNS key record only for DKIM signatures
o dkim署名のためだけに新しいセレクターDNSキーレコードを追加する
o sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record)
o DK（古いDNSキーレコードを使用）とDKIM署名（新しいDNSキーレコードを使用）の両方で署名するメッセージ
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o DK署名が不要になることが決定されたら、DKでの署名を停止します
o eventually remove the old DK selector DNS record
o 最終的に古いDKセレクターDNSレコードを削除します
A combined migration strategy is to:
複合移行戦略は次のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 現在のセレクターDNSキーレコードがDKとDKIMの両方と互換性があることを確認してください
o start signing messages with both DK and DKIM signatures
o DKとDKIMの両方の署名を使用してメッセージの署名を開始します
o add a new selector DNS key record for DKIM signatures
o DKIM署名の新しいセレクターDNSキーレコードを追加する
o switch the DKIM signatures to use the new selector
o DKIM署名を切り替えて、新しいセレクターを使用します
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o DK署名が不要になることが決定されたら、DKでの署名を停止します
o eventually remove the old DK selector DNS record
o 最終的に古いDKセレクターDNSレコードを削除します
Another migration strategy is to:
別の移行戦略は次のとおりです。
o add a new selector DNS key record for DKIM signatures
o DKIM署名の新しいセレクターDNSキーレコードを追加する
o do a flash cut and replace the DK signatures with DKIM signatures
o フラッシュカットを行い、DK署名をDKIM署名に置き換えます
o eventually remove the old DK selector DNS record
o 最終的に古いDKセレクターDNSレコードを削除します
Another migration strategy is to:
別の移行戦略は次のとおりです。
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 現在のセレクターDNSキーレコードがDKとDKIMの両方と互換性があることを確認してください
o do a flash cut and replace the DK signatures with DKIM signatures
o フラッシュカットを行い、DK署名をDKIM署名に置き換えます
Note that when you have separate key records for DK and DKIM, you can use the same public key for both.
DKとDKIMの個別のキーレコードがある場合、両方に同じ公開キーを使用できることに注意してください。
The first step in some of the above scenarios is ensuring that the selector DNS key records are compatible for both DK and DKIM. The format of the DNS key record was intentionally meant to be backwardly compatible between the two systems, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one critical difference between DK and DKIM DNS key records. The definitions of the "g" fields:
上記のシナリオのいくつかの最初のステップは、セレクターDNSキーレコードがDKとDKIMの両方に互換性があることを保証することです。DNSキーレコードの形式は、意図的に2つのシステム間で逆方向に互換性があることを意図的に意図していましたが、必ずしも上向きに互換性がありません。DKIMは、DKを無視する必要があるいくつかのオプションパラメーターを追加することにより、DK DNSキーレコード形式を強化しました。ただし、DKとDKIM DNSキーレコードには1つの重大な違いがあります。「G」フィールドの定義：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and "g=*;" mean to allow any sending address.
G =キーの粒度：DKとDKIMの両方で、これは、送信アドレスを制約するために使用されるオプションのフィールドであり、このセレクターを合法的に使用できるかどうか。残念ながら、空のフィールド（ "g =;"）の扱いは異なります。DKIMは、DKがそうでないワイルドカードを許可します。DKの場合、空のフィールドは欠損値と同じであり、送信アドレスを許可すると扱われます。DKIMの場合、空のフィールドは空のローカル部品のみに一致します。DKIMでは、欠損値と「g =*;」の両方が送信アドレスを許可することを意味します。
Also, in DomainKeys, the "g" field is required to match the address in "From:"/"Sender:", while in DKIM, it is required to match i=. This might or might not affect transition.
また、DomainKeysでは、「g」フィールドは、 "/" sender： "のアドレスを一致させる必要があります。DKIMでは、i =を一致させる必要があります。これは、移行に影響を与える可能性があります。
If your DK DNS key record has an empty "g" field in it ("g=;"), your best course of action is to modify the record to remove the empty field. In that way, the DK semantics will remain the same, and the DKIM semantics will match.
DK DNSキーレコードに空の「G」フィールド（ "g =;"）がある場合、あなたの最善の行動方針は、レコードを変更して空のフィールドを削除することです。そのようにして、DKセマンティクスは同じままであり、DKIMセマンティクスは一致します。
If your DNS key record does not have an empty "g" field in it ("g=;"), it's probable that the record can be left alone. But the best course of action would still be to make sure that it has a "v" field. When the decision is made to stop supporting DomainKeys and to only support DKIM, it is important to verify that the "g" field is compatible with DKIM, and typically having "v=DKIM1;" in it. It is strongly encouraged that if use of an empty "g" field in the DKIM selector, include the "v" field.
DNSキーレコードに空の「G」フィールド（ "g =;"）がない場合、レコードを放置する可能性があります。しかし、最善の行動は、「V」フィールドがあることを確認することです。ドメインキーのサポートを停止し、DKIMのみをサポートすることが決定された場合、「G」フィールドがDKIMと互換性があり、通常は「V = DKIM1;」を持っていることを確認することが重要です。初期化。DKIMセレクターで空の「G」フィールドを使用する場合、「V」フィールドを含めることが強く推奨されています。
The principal use of DomainKeys is at boundary MTAs. Because no operational transition is ever instantaneous, it is advisable to continue performing DomainKeys signing until it is determined that DomainKeys receive-side support is no longer used, or is sufficiently reduced. That is, a signer needs to add a DKIM signature to a message that also has a DomainKeys signature and keep it there until they decide it is deemed no longer useful. The signer can do its transitions in a straightforward manner, or more gradually. Note that because digital signatures are not free, there is a cost to performing both signing algorithms, so signing with both algorithms ought not be needlessly prolonged.
ドメインキーの主要な使用は、境界MTAにあります。運用上の移行は瞬間的ではないため、ドメインキーが受信側のサポートが使用されなくなったか、十分に削減されると判断されるまで、ドメインキーの署名を継続することをお勧めします。つまり、署名者は、ドメインキーの署名を持つメッセージにDKIM署名を追加し、もはや有用ではないと判断されるまでそこに保管する必要があります。署名者は、簡単な方法で、またはより徐々に移行することができます。デジタル署名は無料ではないため、両方の署名アルゴリズムを実行するにはコストがかかるため、両方のアルゴリズムに署名することは不必要に延長されるべきではないことに注意してください。
The tricky part is deciding when DK signatures are no longer necessary. The real questions are: how many DomainKeys verifiers are there that do *not* also do DKIM verification, which of those are important, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it can choose to verify both signatures, or just one or the other.
トリッキーな部分は、DK署名がいつ必要でないかを決定することです。本当の質問は次のとおりです。DKIM検証を実行しない *ドメインキーの検証剤がいくつありますか、それらのどれが重要であり、どのようにそれらの使用を追跡できますか？DK検証の早期採用者のほとんどはDKIM検証を追加しましたが、まだすべてではありません。VerifierがDKとDKIMの両方でメッセージを見つけた場合、両方の署名を検証するか、どちらか一方のみを検証することを選択できます。
Many DNS services offer tracking statistics so it can be determined how often a DNS record has been accessed. By using separate DNS selector key records for your signatures, you can chart the use of your records over time, and watch the trends. An additional distinguishing factor to track would take into account the verifiers that verify both the DK and DKIM signatures, and discount those from counts of DK selector usage. When the number for DK selector access reaches a low-enough level, that's the time to consider discontinuing signing with DK.
多くのDNSサービスは追跡統計を提供するため、DNSレコードがアクセスされる頻度を決定できます。署名に個別のDNSセレクターキーレコードを使用することにより、レコードの使用を長期にわたってチャートして、トレンドを視聴できます。追跡するための追加の際立った要因は、DKとDKIMの両方の署名を検証し、DKセレクターの使用量からそれらを割引する検証剤を考慮に入れます。DKセレクターアクセスの数が少ないレベルに達すると、DKとの署名を中止することを検討する時が来ました。
Note, this level of rigor is not required. It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above.
このレベルの厳密さは必要ありません。DK署名者が上記の「フラッシュカット」シナリオに従うことを決定することは完全に合理的です。
As a verifier, several issues need to be considered:
検証者として、いくつかの問題を考慮する必要があります：
At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it might take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures.
執筆時点では、DK署名のみを生成しているサイトがまだかなりあります。時間が経つにつれて、この数はゼロになると予想されますが、数年かかる場合があります。したがって、VerifierがDKIMとDKの両方の署名を探して検証することは、近い将来に賢明です。
A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?
A.1.2.2. DKとDKIMの両方の署名を単一のメッセージで評価する必要がありますか？
For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures can verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails.
しばらくの間、DKとDKIMの両方で署名するサイトがあります。両方のタイプの署名を持つメッセージを受信する検証器は、両方の署名または1つだけを確認できます。両方の署名を検証することの欠点の1つは、署名者がまだDKセレクターを使用している検証剤の数を決定するのがより困難になることです。1つの遷移戦略は、DKIM署名を検証し、DKIM検証が失敗した場合にのみDK署名を検証することです。
The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one key difference between DK and DKIM DNS key records. The definitions of the g fields:
DNSキーレコードの形式は、意図的にDKとDKIMの間で逆方向に互換性があることを意図していましたが、必ずしも上向きに互換性がありません。DKIMは、DKを無視する必要があるいくつかのオプションパラメーターを追加することにより、DK DNSキーレコード形式を強化しました。ただし、DKとDKIM DNSキーレコードには重要な違いが1つあります。Gフィールドの定義：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part.
G =キーの粒度：DKとDKIMの両方で、これは、送信アドレスを制約するために使用されるオプションのフィールドであり、このセレクターを合法的に使用できるかどうか。残念ながら、空のフィールド（ "g =;"）の扱いは異なります。DKの場合、空のフィールドは欠損値と同じであり、送信アドレスを許可すると扱われます。DKIMの場合、空のフィールドは空のローカル部品のみに一致します。
v= version of the selector It is advised that a DKIM selector have "v=DKIM1;" at its beginning, but it is not required.
v =セレクターのバージョンDKIMセレクターには「v = dkim1;」があることをお勧めします。最初は必要ありませんが、必要ありません。
If a DKIM verifier finds a selector record that has an empty "g" field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was:
DKIM検証剤が空の「G」フィールド（「G =;」）を持つセレクターレコードを見つけ、最初に「V」フィールド（ "V = dkim1;"）がない場合、決定に直面しますこのレコードが次の場合：
1. from a DK signer that transitioned to supporting DKIM but forgot to remove the "g" field (so that it could be used by both DK and DKIM verifiers); or
1. DKIMのサポートに移行したが、「G」フィールドを削除するのを忘れたDK署名者から（DKとDKIMの両方の検証者が使用できるように）。また
2. from a DKIM signer that truly meant to use the empty "g" field but forgot to put in the "v" field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a "g" field in the record.
2. 空の「G」フィールドを本当に使用することを意味したが、「V」フィールドに入れるのを忘れたDKIM署名者から。そのようなレコードを最初の解釈を使用して扱い、署名者がレコードに「G」フィールドを持っていないかのような記録を扱うことをお勧めします。
[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256. The security of all hash algorithms is constantly under attack, and SHA-1 has already shown weaknesses as of this writing. Migrating from SHA-1 to SHA-256 is not an issue, because all verifiers are already required to support SHA-256. But when it becomes necessary to replace SHA-256 with a more secure algorithm, there will be a migratory period. In the following, "NEWHASH" is used to represent a new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this scenario.
[RFC4871] 2つのハッシュアルゴリズムの使用を定義します：SHA-1とSHA-256。すべてのハッシュアルゴリズムのセキュリティは絶えず攻撃を受けており、SHA-1はこの執筆時点ですでに弱点を示しています。SHA-1からSHA-256への移行は問題ではありません。なぜなら、すべての検証はSHA-256をサポートするためにすでに必要であるためです。しかし、SHA-256をより安全なアルゴリズムに置き換える必要がある場合、移動期間があります。以下では、新しいハッシュアルゴリズムを表すために「NewHash」を使用しています。[RFC4871]のセクション4.1は、このシナリオについて簡単に説明します。
As with migrating from DK to DKIM, migrating hash algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing hash algorithms are considered and how important that is to the signers.
DKからDKIMへの移行と同様に、ハッシュアルゴリズムの移行は、古いアルゴリズムとの署名を継続し、検証官による新しいアルゴリズムの予想されるサポートの実用性に関する署名者の最良の推測に依存します。古いアルゴリズムで署名を継続するという有用性は、既存のハッシュアルゴリズムがどれほど壊れているか、署名者にとってどれほど重要かに基づいています。
One strategy is to wait until it's determined that there is a large enough base of verifiers available that support NEWHASH, and then flash cut to the new algorithm.
1つの戦略は、NewHashをサポートする十分な大きさの検証剤が利用可能であると判断されるまで待つことです。その後、新しいアルゴリズムにフラッシュカットがあります。
Another strategy is to sign with both the old and new hash algorithms for a period of time. This is particularly useful for testing the new code to support the new hash algorithm, as verifiers will continue to accept the signature for the older hash algorithm and ought to ignore any signature that fails because the code is slightly wrong. Once the signer has determined that the new code is correct AND it's determined that there is a large enough base of verifiers available that support NEWHASH, the signer can flash cut to the new algorithm.
別の戦略は、長い間、古いハッシュアルゴリズムと新しいハッシュアルゴリズムの両方に署名することです。これは、新しいコードをテストして新しいハッシュアルゴリズムをサポートするのに特に役立ちます。検証剤は、古いハッシュアルゴリズムの署名を引き続き受け入れ、コードがわずかに間違っているために失敗する署名を無視する必要があるためです。署名者が新しいコードが正しいと判断し、NewHashをサポートする十分な大きさの検証剤が利用可能であると判断されると、署名者は新しいアルゴリズムにカットすることができます。
One advantage migrating hash algorithms has is that the selector can be completely compatible for all hash algorithms. The key selector has an optional "h=" field that can be used to list the hash algorithms being used; it also is used to limit the algorithms that a
ハッシュアルゴリズムを移行する利点の1つは、すべてのハッシュアルゴリズムにセレクターが完全に互換性があることです。キーセレクターには、使用されているハッシュアルゴリズムをリストするために使用できるオプションの「H =」フィールドがあります。また、アルゴリズムを制限するためにも使用されます。
verifier will accept. If the signer is not currently using the key selector "h=" field, no change is required. If the signer is currently using the key selector "h=" field, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the "h=" list.)
検証者は受け入れます。署名者が現在キーセレクター「H =」フィールドを使用していない場合、変更は不要です。署名者が現在キーセレクター「H =」フィールドを使用している場合、「H = SHA256：NewHash;」のように、NewHashをリストに追加する必要があります。（署名者がSHA-256を使用しなくなった場合、「h =」リストから削除できます。）
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
新しいハッシュアルゴリズムが標準化されると、検証者ができるだけ早くサポートを開始するのが最適です。
[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.
[RFC4871]は、RSA署名アルゴリズムの使用を定義します。ハッシュと同様に、署名アルゴリズムは常に攻撃を受けており、RSAを新しい署名アルゴリズムに置き換えることが必要になると、移動期間があります。以下では、「Newalg」が新しい署名アルゴリズムを表すために使用されます。
As with the other migration issues discussed above, migrating signing algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing signing algorithms are considered and how important that is to the signers.
上記の他の移行問題と同様に、移行の署名アルゴリズムは、古いアルゴリズムとの署名を継続するという有用性に関する署名者の最良の推測と、検証剤による新しいアルゴリズムの予想されるサポートに依存しています。古いアルゴリズムで署名を継続するという有用性は、既存の署名アルゴリズムがどれほど壊れているか、署名者にとってどれほど重要かに基づいています。
As before, the two basic strategies are to 1) wait until there is sufficient base of verifiers available that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm.
前と同様に、2つの基本的な戦略は、1）Newalgをサポートし、Newalgにフラッシュカットを行う検証剤の十分なベースが利用できるまで待つことです。古いアルゴリズムのサポート。
It is unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out. Therefore, in order to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different "k=" value to reflect the use of NEWALG.
新しいアルゴリズムが「RSA」と同じ公開キーを使用できる可能性は低いため、両方のアルゴリズムのキーに同じセレクターDNSレコードを使用することが除外されます。したがって、新しいアルゴリズムを使用するには、既存のアルゴリズムの既存のDNSセレクターレコードと並行して新しいDNSセレクターレコードを展開する必要があります。新しいDNSセレクターレコードは、Newalgの使用を反映するために異なる「k =」値を指定します。
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
新しいハッシュアルゴリズムが標準化されると、検証者ができるだけ早くサポートを開始するのが最適です。
NOTE: This section could possibly be changed into a reference to something else, such as another RFC.
注：このセクションは、別のRFCなどの他の何かへの参照に変更される可能性があります。
Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications.
暗号化アルゴリズムの正しい実装は、暗号化アプリケーションのコーディングには必要ですが、十分な条件ではありません。暗号化ライブラリのコーディングには、暗号化アプリケーションに固有のセキュリティに関する考慮事項に細心の注意が必要です。
In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers need to pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of.
バッファや整数のオーバーフローやアンダーフローの回避などの通常のセキュリティコーディングの考慮事項に加えて、実装者は暗号化のプライベートキーとセッションキーの管理に細心の注意を払う必要があり、これらが正しく初期化され、処分されるようにします。
Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes ought to be used when available. In particular, great care needs to be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes.
プライベートキーの機密性を他のプロセスから保護することを可能にするオペレーティングシステムメカニズムは、利用可能な場合に使用する必要があります。特に、メモリページをオペレーティングシステムにリリースする際には、秘密のキー情報が他のプロセスに開示されないようにする際には、細心の注意を払う必要があります。
Certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack.
RSAなどの公開キーアルゴリズムの特定の実装は、タイミング分析攻撃に対して脆弱です。
Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys.
主要な管理機能を提供する暗号化ハードウェアのサポートが強く奨励されています。パフォーマンスの利点を提供することに加えて、多くの暗号化ハードウェアデバイスは、プライベートキーの堅牢で検証可能な管理を提供します。
Fortunately, appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware.
幸いなことに、適切に設計およびコーディングされた暗号化ライブラリは、商用、オープンソース、フリーソフトウェアライセンスの条件に互換性のあるライセンス条件の下で、ほとんどのオペレーティングシステムプラットフォームで利用できます。標準の暗号化ライブラリの使用が強く奨励されています。これらは広くテストされており、開発時間を短縮し、幅広い暗号化ハードウェアをサポートしています。
Authors' Addresses
著者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA
トニーハンセンAT＆Tラボラトリーズ200ローレルアベニューサウスミドルタウン、ニュージャージー07748 USA
EMail: tony+dkimov@maillennium.att.com
Ellen Siegel Consultant
エレン・シーゲルコンサルタント
EMail: dkim@esiegel.net
Phillip Hallam-Baker Default Deny Security, Inc.
Phillip Hallam-BakerデフォルトDeny Security、Inc。
EMail: phillip@hallambaker.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale、CA 94086 USA
EMail: dcrocker@bbiw.net