[要約] RFC 5585は、DKIMサービスの概要を提供するものであり、DKIMの目的は、電子メールの送信者の認証とメッセージの改ざんの検出を可能にすることです。
Network Working Group T. Hansen
Request for Comments: 5585 AT&T Laboratories
Category: Informational D. Crocker
Brandenburg InternetWorking
P. Hallam-Baker
Default Deny Security, Inc.
July 2009
DomainKeys Identified Mail (DKIM) Service Overview
DomainKeysは、メール（DKIM）サービスの概要を識別しました
Abstract
概要
This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified 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, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables 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".
このドキュメントは、ドメインキー識別されたメール（DKIM）サービスの概要を提供し、メッセージングサービスにどのように適合するかについて説明します。また、DKIMが他のIETFメッセージ署名テクノロジーとどのように関係するかについても説明しています。これは、DKIMを採用、開発、展開している人を対象としています。DKIMでは、組織が受信者が検証できる方法で、メッセージを送信する責任を負うことを許可します。組織は、著者の著者、起源の送信サイト、仲介者、またはそのエージェントの1人です。メッセージには、メッセージに関係する同じまたは異なる組織からの複数の署名を含めることができます。DKIMは、パブリックキー暗号化を使用して、ドメイン名を使用して、ドメイン名サービスを主要なサーバーテクノロジー（RFC 4871）として使用して、電子メールのドメインレベルのデジタル署名認証フレームワークを定義しています。これにより、責任ある組織の検証、およびメッセージコンテンツの完全性が可能になります。DKIMは、潜在的な電子メール署名者が電子メールの署名プラクティスに関する情報を公開できるメカニズムも可能にします。これにより、電子メール受信者はメッセージに関する追加の評価を行うことができます。DKIMの電子メールIDの認証は、「スパム」と「フィッシング」のグローバルな制御を支援できます。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. DKIM's Scope ...............................................4
1.2. Prior Work .................................................5
1.3. Internet Mail Background ...................................6
2. The DKIM Value Proposition ......................................6
2.1. Identity Verification ......................................7
2.2. Enabling Trust Assessments .................................7
2.3. Establishing Message Validity ..............................8
3. DKIM Goals ......................................................8
3.1. Functional Goals ...........................................9
3.2. Operational Goals .........................................10
4. DKIM Function ..................................................12
4.1. Basic Signing .............................................12
4.2. Characteristics of a DKIM Signature .......................12
4.3. The Selector Construct ....................................13
4.4. Verification ..............................................13
4.5. Sub-Domain Assessment .....................................13
5. Service Architecture ...........................................14
5.1. Administration and Maintenance ............................15
5.2. Signing ...................................................16
5.3. Verifying .................................................16
5.4. Unverified or Unsigned Mail ...............................16
5.5. Assessing .................................................17
5.6. DKIM Processing within an ADMD ............................17
6. Considerations .................................................17
6.1. Security Considerations ...................................17
6.2. Acknowledgements ..........................................17
7. Informative References .........................................18
Appendix A. Internet Mail Background .............................20
A.1. Core Model ................................................20
A.2. Trust Boundaries ..........................................20
Index .............................................................22
This document provides a description of the architecture and functionality for DomainKeys Identified Mail (DKIM), that is, the core mechanism for signing and verifying messages. It is intended for those who are adopting, developing, or deploying DKIM. It will also be helpful for those who are considering extending DKIM, either into other areas of use or to support additional features. This overview does not provide information on threats to DKIM or email or details on the protocol specifics, which can be found in [RFC4686] and [RFC4871], respectively. Because the scope of this overview is restricted to the technical details of signing and verifying using DKIM, it does not explore operational issues, the details of services that DKIM uses, or those that, in turn, use DKIM. Nor does it discuss services that build upon DKIM for enforcement of policies or assessments. The document assumes a background in basic email and network security technology and services.
このドキュメントは、ドメインキー識別されたメール（DKIM）のアーキテクチャと機能の説明、つまりメッセージの署名と検証のコアメカニズムです。これは、DKIMを採用、開発、展開している人を対象としています。また、DKIMを他の使用領域に拡張することを検討している人にとっても役立ちます。この概要では、それぞれ[RFC4686]と[RFC4871]に記載されているプロトコルの詳細に関するDKIMまたは電子メールまたは詳細に関する脅威に関する情報は提供されません。この概要の範囲は、DKIMを使用した署名と検証の技術的な詳細に限定されているため、運用上の問題、DKIMが使用するサービスの詳細、またはDKIMを使用するサービスの詳細については検討しません。また、ポリシーや評価の実施のためにDKIMに基づいて構築されるサービスについても議論していません。このドキュメントは、基本的な電子メールおよびネットワークセキュリティテクノロジーとサービスの背景を想定しています。
DKIM allows an organization to take responsibility for a message in a way that can be verified by a recipient. The organization can be a direct handler of the message, such as the author's, the originating sending site's, or an intermediary's along the transit path. However, it can also be an indirect handler, such as an independent service that is providing assistance to a direct handler. DKIM defines a domain-level digital signature authentication framework for email through the use of public-key cryptography and using the domain name service as its key server technology [RFC4871]. It permits verification of the signer of a message, as well as the integrity of its contents. 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 of unsigned messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing".
DKIMは、組織が受信者が検証できる方法でメッセージの責任を負うことを許可します。組織は、著者のもの、発信する送信サイト、または通過パスに沿った仲介者など、メッセージの直接のハンドラーになることができます。ただし、直接ハンドラーに支援を提供している独立したサービスなど、間接的なハンドラーでもあります。DKIMは、パブリックキー暗号化とドメイン名サービスを主要なサーバーテクノロジーとして使用することにより、電子メールのドメインレベルのデジタル署名認証フレームワークを定義します[RFC4871]。メッセージの署名者の検証と、その内容の完全性を許可します。DKIMは、潜在的な電子メール署名者が電子メールの署名慣行に関する情報を公開できるメカニズムも提供します。これにより、電子メール受信者が署名されていないメッセージの追加評価を行うことができます。DKIMの電子メールIDの認証は、「スパム」と「フィッシング」のグローバルな制御を支援できます。
Neither this document nor DKIM attempts to provide solutions to the world's problems with spam, phishing, viruses, worms, joe jobs, etc. DKIM provides one basic tool, in what needs to be a large arsenal, for improving basic trust in the Internet mail service. However, by itself, DKIM is not sufficient to that task and this overview does not pursue the issues of integrating DKIM into these larger efforts, beyond a simple reference within a system diagram. Rather, it is a basic introduction to the technology and its use.
この文書もDKIMも、スパム、フィッシング、ウイルス、ワーム、ジョージョブなどの世界の問題に対する解決策を提供しようとしません。サービス。ただし、それ自体では、DKIMはそのタスクに対して十分ではなく、この概要は、システム図内の単純な参照を超えて、DKIMをこれらのより大きな取り組みに統合する問題を追求していません。むしろ、それはテクノロジーとその使用に関する基本的な紹介です。
A person or organization has an "identity" -- that is, a constellation of characteristics that distinguish them from any other identity. Associated with this abstraction can be a label used as a reference, or "identifier". This is the distinction between a thing and the name of the thing. DKIM uses a domain name as an identifier, to refer to the identity of a responsible person or organization. In DKIM, this identifier is called the Signing Domain IDentifier (SDID) and is contained in the DKIM-Signature header fields "d=" tag. Note that the same identity can have multiple identifiers.
個人または組織には、「アイデンティティ」、つまり他のアイデンティティと区別する特性の星座があります。この抽象化に関連付けられているのは、参照として使用されるラベル、または「識別子」です。これは、物と物の名前の区別です。DKIMは、識別子としてドメイン名を使用して、責任者または組織の身元を指します。DKIMでは、この識別子は署名ドメイン識別子（SDID）と呼ばれ、dkim-signatureヘッダーフィールド "d ="タグに含まれています。同じIDには複数の識別子があることに注意してください。
A DKIM signature can be created by a direct handler of a message, such as the message's author or by an intermediary. A signature also can be created by an independent service that is providing assistance to a handler of the message. Whoever does the signing chooses the SDID to be used as the basis for later assessments. Hence, the reputation associated with that domain name might be an additional basis for evaluating whether to trust the message for delivery. The owner of the SDID is declaring that they accept responsibility for the message and can thus be held accountable for it.
DKIMの署名は、メッセージの著者や仲介者など、メッセージの直接ハンドラーによって作成できます。署名は、メッセージのハンドラーに支援を提供している独立したサービスによって作成することもできます。署名をする人は誰でも、後の評価の基礎として使用されるSDIDを選択します。したがって、そのドメイン名に関連する評判は、配信のためのメッセージを信頼するかどうかを評価するための追加の基礎となる可能性があります。SDIDの所有者は、メッセージに対する責任を受け入れることを宣言しているため、責任を負うことができます。
DKIM is intended as a value-added feature for email. Mail that is not signed by DKIM is handled in the same way as it was before DKIM was defined. The message will be evaluated by established analysis and filtering techniques. (A signing policy can provide additional information for that analysis and filtering.) Over time, widespread DKIM adoption could permit stricter handling of messages that are not signed. However, early benefits do not require this and probably do not warrant this.
DKIMは、電子メールの付加価値機能として意図されています。DKIMによって署名されていないメールは、DKIMが定義される前と同じように処理されます。メッセージは、確立された分析とフィルタリング手法によって評価されます。（署名ポリシーは、その分析とフィルタリングの追加情報を提供できます。）時間の経過とともに、DKIMの採用が広く採用されると、署名されていないメッセージのより厳格な処理が可能になります。ただし、初期の利益はこれを必要とせず、おそらくこれを保証しないでしょう。
DKIM has a narrow scope. It is an enabling technology, intended for use in the larger context of determining message legitimacy. This larger context is complex, so it is easy to assume that a component like DKIM, which actually provides only a limited service, instead satisfies the broader set of requirements.
DKIMには狭い範囲があります。これは、メッセージの正当性を決定するというより大きなコンテキストで使用することを目的とした有効化テクノロジーです。この大きなコンテキストは複雑であるため、実際に限られたサービスのみを提供するDKIMのようなコンポーネントが、より広範な要件を満たす代わりに、簡単に想定するのは簡単です。
By itself, a DKIM signature:
それ自体、DKIM署名：
o Does not authenticate or verify the contents of the message header or body, such as the author From field, beyond certifying data integrity between the time of signing and the time of verifying.
o 署名時と検証の時間の間のデータの整合性を認証するだけでなく、フィールドからの著者など、メッセージヘッダーまたはボディの内容を認証または検証しません。
o Does not offer any assertions about the behaviors of the signer.
o 署名者の行動に関する主張は提供しません。
o Does not prescribe any specific actions for receivers to take upon successful signature verification.
o 受信者が署名検証を成功させるための特定のアクションを規定していません。
o Does not provide protection after signature verification.
o 署名検証後に保護を提供しません。
o Does not protect against re-sending (replay of) a message that already has a verified signature; therefore, a transit intermediary or a recipient can re-post the message -- that is, post it as a new message -- with the original signature remaining verifiable, even though the new recipient(s) might be different from those who were originally specified by the author.
o 既に検証済みの署名があるメッセージを再送信（リプレイ）から保護しません。したがって、トランジット仲介者または受信者は、新しい受信者が元々だった人とは異なる場合がありますが、元の署名が検証可能なままであるため、メッセージを再投稿すること、つまり新しいメッセージとして投稿することができます。著者によって指定されています。
Historically, the IP Address of the system that directly sent the message -- that is, the previous email "hop" -- has been treated as an identity to use for making assessments. For example, see [RFC4408], [RFC4406], and [RFC4407] for some current uses of the sending system's IP Address. The IP Address is obtained via underlying Internet information mechanisms and is therefore trusted to be accurate. Besides having some known security weaknesses, the use of addresses presents a number of functional and operational problems. Consequently, there is a widespread desire to use an identifier that has better correspondence to organizational boundaries. Domain names can satisfy this need.
歴史的に、メッセージを直接送信したシステムのIPアドレス、つまり以前の電子メール「ホップ」は、評価を行うために使用するアイデンティティとして扱われてきました。たとえば、送信システムのIPアドレスの現在の使用については、[RFC4408]、[RFC4406]、および[RFC4407]を参照してください。IPアドレスは、基礎となるインターネット情報メカニズムを介して取得されるため、正確であると信頼されています。セキュリティの弱点がいくつかあることに加えて、アドレスの使用は、多くの機能的および運用上の問題を提示します。したがって、組織の境界により良い対応を持つ識別子を使用したいという広範な欲求があります。ドメイン名はこのニーズを満たすことができます。
There have been four previous IETF Internet Mail signature standards. Their goals have differed from those of DKIM. PEM and MOSS are only of historical interest.
以前に4つのIETFインターネットメールの署名標準がありました。彼らの目標はDKIMの目標とは異なりました。ペムとモスは歴史的な関心のみです。
o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989].
o プライバシー拡張メール（PEM）が1987年に最初に公開されました[RFC0989]。
o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first released in 1991. A later version was standardized as OpenPGP [RFC1991] [RFC2440] [RFC3156] [RFC4880].
o Prety Good Privacy（PGP）はPhil Zimmermannによって開発され、1991年に最初にリリースされました。後のバージョンは、OpenPGP [RFC1991] [RFC2440] [RFC3156] [RFC4880]として標準化されました。
o PEM eventually transformed into MIME Object Security Services (MOSS) in 1995 [RFC1848].
o PEMは、1995年に最終的にMIMEオブジェクトセキュリティサービス（MOSS）に変身しました[RFC1848]。
o RSA Security independently developed Secure MIME (S/MIME) to transport a Public Key Cryptographic System (PKCS) #7 data object. It was standardized as [RFC3851].
o RSAセキュリティは、公開キーの暗号システム（PKCS）＃7データオブジェクトを輸送するために、安全なMIME（S/MIME）を独立して開発しました。[RFC3851]として標準化されました。
Development of both S/MIME and OpenPGP has continued. While each has achieved a significant user base, neither one has achieved ubiquity in deployment or use.
S/MIMEとOpenPGPの両方の開発が継続しています。それぞれが重要なユーザーベースを達成していますが、どちらも展開や使用の遍在性を達成していません。
To the extent that other message-signing services might have been adapted to do the job that DKIM is designed to perform, it was felt that repurposing any of those would be more problematic than creating a separate service. That said, DKIM only uses cryptographic components that have a long history, including use within some of those other messaging security services.
他のメッセージ署名サービスがDKIMが実行するように設計されている仕事をするために適応した限り、それらのいずれかを再利用することは、別のサービスを作成するよりも問題があると感じられました。とはいえ、DKIMは、他のメッセージングセキュリティサービスの一部での使用を含む、長い歴史を持つ暗号化コンポーネントのみを使用しています。
DKIM is differentiated by its reliance on an identifier that is specific to DKIM use.
DKIMは、DKIMの使用に固有の識別子への依存によって区別されます。
DKIM also has a distinctive approach for distributing and vouching for keys. It uses a key-centric, public-key management scheme, rather than the more typical approaches based on a certificate in the styles of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust) [WebofTrust]. For DKIM, the owner of the SDID asserts the validity of a key, rather than having the validity of the key attested to by a trusted third party, often including other assertions, such as a quality assessment of the key's owner. DKIM treats quality assessment as an independent, value-added service, beyond the initial work of deploying a signature verification service.
DKIMには、キーを配布して保証するための独特のアプローチもあります。Kohnfelder（X.509）[Kohnfelder]またはZimmermann（Web of Trust）[Weboftrust]のスタイルの証明書に基づいたより典型的なアプローチではなく、重要な中心のパブリックキー管理スキームを使用します。DKIMの場合、SDIDの所有者は、キーの所有者の品質評価など、他の主張を含む、信頼できる第三者によって証明されたキーの有効性を持つのではなく、キーの有効性を主張します。DKIMは、署名検証サービスを展開する最初の作業を超えて、品質評価を独立した付加価値サービスとして扱います。
Further, DKIM's key management is provided by adding information records to the existing Domain Name System (DNS) [RFC1034], rather than requiring deployment of a new query infrastructure. This approach has significant operational advantages. First, it avoids the considerable barrier of creating a new global infrastructure; hence, it leverages a global base of administrative experience and highly reliable distributed operation. Second, the technical aspect of the DNS is already known to be efficient. Any new service would have to undergo a period of gradual maturation, with potentially problematic early-stage behaviors. By (re-)using the DNS, DKIM avoids these growing pains.
さらに、DKIMの主要な管理は、新しいクエリインフラストラクチャの展開を要求するのではなく、既存のドメイン名システム（DNS）[RFC1034]に情報レコードを追加することにより提供されます。このアプローチには、運用上の大きな利点があります。まず、新しいグローバルインフラストラクチャを作成するかなりの障壁を回避します。したがって、管理経験と信頼性の高い分散操作のグローバルな基盤を活用します。第二に、DNSの技術的側面は、既に効率的であることが知られています。新しいサービスは、潜在的に問題のある初期段階の動作を伴う段階的な成熟を受ける必要があります。DNSを使用することにより、DKIMはこれらの成長する痛みを回避します。
The basic Internet email service has evolved extensively over its several decades of continuous operation. Its modern architecture comprises a number of specialized components. A discussion about Mail User Agents (MUAs), Mail Handling Services (MHSs), Mail Transfer Agents (MTAs), Mail Submission Agents (MSAs), Mail Delivery Agents (MDAs), Mail Service Providers (MSPs), Administrative Management Domains (ADMDs), Mediators, and their relationships can be found in Appendix A.
基本的なインターネットメールサービスは、数十年の継続的な運用にわたって広く進化してきました。その近代的なアーキテクチャは、多くの特殊なコンポーネントで構成されています。メールユーザーエージェント（MUAS）、メールハンドリングサービス（MHSS）、メール転送エージェント（MTA）、メール提出エージェント（MSA）、メール配信エージェント（MDA）、メールサービスプロバイダー（MSPS）、管理管理ドメイン（ADMDS）、調停者、およびその関係は付録Aにあります。
The nature and origins of a message often are falsely stated. Such misrepresentations may be employed for legitimate or nefarious reasons. DKIM provides a foundation for distinguishing legitimate mail, and thus a means of associating a verifiable identifier with a message. Given the presence of that identifier, a receiver can make decisions about further handling of the message, based upon assessments of the identity that is associated with the identifier.
メッセージの性質と起源はしばしば誤って述べられています。このような不実表示は、正当なまたは不正な理由で採用される場合があります。DKIMは、正当なメールを区別するための基盤を提供し、したがって、検証可能な識別子をメッセージに関連付ける手段を提供します。その識別子の存在を考えると、受信者は、識別子に関連付けられているアイデンティティの評価に基づいて、メッセージのさらなる処理について決定を下すことができます。
Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors. DKIM does not, itself, prescribe any specific actions by the recipient; rather, it is an enabling technology for services that do.
署名を正常に確認するレシーバーは、スパム、スプーフィング、フィッシング、またはその他の望ましくない行動を制限するプログラムの一部として署名者に関する情報を使用できます。DKIMは、それ自体が受信者による特定のアクションを処方しません。むしろ、それはサービスのための有効化テクノロジーです。
These services will typically:
これらのサービスは通常：
1. Determine a verified identity as taking responsibility for the message, if possible.
1. 可能であれば、メッセージの責任を負うと検証されたアイデンティティを決定します。
2. Evaluate the trustworthiness of this/these identities.
2. この/これらのアイデンティティの信頼性を評価します。
The role of DKIM is to perform the first of these; DKIM is an enabler for the second.
DKIMの役割は、これらの最初を実行することです。DKIMは2番目のイネーブラーです。
Consider an attack made against an organization or against customers of an organization. The name of the organization is linked to particular Internet domain names (identifiers). Attackers can leverage using either a legitimate domain name, one without authorization, or a "cousin" name that is similar to one that is legitimate, but is not controlled by the target organization. An assessment service that uses DKIM can differentiate between a domain (SDID) used by a known organization and a domain used by others. As such, DKIM performs the positive step of identifying messages associated with verifiable identities, rather than the negative step of identifying messages with problematic use of identities. Whether a verified identity belongs to a Good Actor or a Bad Actor is a question for later stages of assessment.
組織または組織の顧客に対して行われた攻撃を検討してください。組織の名前は、特定のインターネットドメイン名（識別子）にリンクされています。攻撃者は、正当なドメイン名、許可なしのドメイン名、または合法的なものと似ているが、ターゲット組織によって制御されていない「いとこ」名を使用して活用できます。DKIMを使用する評価サービスは、既知の組織が使用するドメイン（SDID）と他の組織が使用するドメインを区別できます。そのため、DKIMは、IDの問題のある使用でメッセージを識別するという否定的なステップではなく、検証可能なアイデンティティに関連付けられたメッセージを識別する肯定的なステップを実行します。検証済みのアイデンティティが良い俳優に属しているのか悪い俳優に属しているのかは、評価の後の段階の質問です。
Email receiving services are faced with a basic decision: whether to accept and deliver a newly arrived message to the indicated recipient? That is, does the receiving service trust that the message is sufficiently "safe" to be viewed? For the modern Internet, most receiving services have an elaborate engine that formulates this quality assessment. These engines take a variety of information as input to the decision, such as from reputation lists and accreditation services. As the engine processes information, it raises or lowers its trust assessment for the message.
電子メール受信サービスは、基本的な決定に直面しています。つまり、受信サービスは、メッセージが表示されるのに十分な「安全」であると信じていますか？最新のインターネットの場合、ほとんどの受信サービスには、この品質評価を策定する精巧なエンジンがあります。これらのエンジンは、評判リストや認定サービスなど、意思決定への入力としてさまざまな情報を取得します。エンジンが情報を処理するにつれて、メッセージの信頼評価を提起または下げます。
In order to formulate reputation information, an accurate, stable identifier is needed. Otherwise, the information might not pertain to the identified organization's own actions. When using an IP Address, accuracy is based on the belief that the underlying Internet infrastructure supplies an accurate address. When using domain-based reputation data, some other form of verification is needed, since it is not supplied independently by the infrastructure.
評判情報を策定するには、正確で安定した識別子が必要です。それ以外の場合、情報は特定された組織自身の行動に関係していない可能性があります。IPアドレスを使用する場合、正確さは、基礎となるインターネットインフラストラクチャが正確なアドレスを提供するという信念に基づいています。ドメインベースの評判データを使用する場合、インフラストラクチャによって独立して提供されていないため、他の形式の検証が必要です。
DKIM satisfies this requirement by declaring a valid "responsible" identity -- referenced through the SDID -- about which the engine can make quality assessments and by using a digital signature to ensure that use of the identifier is authorized. However, by itself, a valid DKIM signature neither lowers nor raises the level of trust associated with the message, but it enables other mechanisms to be used for doing so.
DKIMは、SDIDを介して参照される有効な「責任ある」IDを宣言することにより、この要件を満たします。エンジンは品質評価を行うことができ、デジタル署名を使用して識別子の使用が許可されるようにします。ただし、それ自体では、有効なDKIM署名はメッセージに関連する信頼のレベルを下げたり引き上げたりすることはありませんが、他のメカニズムを使用することができます。
An organization might build upon its use of DKIM by publishing information about its Signing Practices (SP). This could permit detecting some messages that purport to be associated with a domain, but which are not. As such, an SP can cause the trust assessment to be reduced, or leave it unchanged.
組織は、署名慣行（SP）に関する情報を公開することにより、DKIMの使用に基づいて構築される場合があります。これにより、ドメインに関連付けられていると主張するいくつかのメッセージを検出することができますが、そうではありません。そのため、SPは信頼評価を減らすか、変化しないままにすることがあります。
Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM.
中間の攻撃は歴史的に電子メールではまれですが、それでも輸送中にメッセージを変更することは理論的に可能です。DKIMで使用される暗号化方法の興味深い副作用は、署名されたメッセージ（L =を使用する場合、メッセージの署名部分）が署名時と署名時と検証の時間。それが何らかの方法で変更された場合、メッセージはDKIMで正常に検証されません。
As described above, this validity neither lowers nor raises the level of trust associated with the message. If it was an untrustworthy message when initially sent, the verifier can be certain that the message will be equally untrustworthy upon receipt and successful verification.
上記のように、この有効性は、メッセージに関連する信頼のレベルを下げたり引き上げたりしません。最初に送信されたときに信頼できないメッセージであった場合、検証者は、メッセージが受領と成功した検証時に等しく信頼できないことを確認できます。
DKIM adds an end-to-end authentication capability to the existing email transfer infrastructure. That is, there can be multiple email relaying hops between signing and verifying. Hence, it defines a mechanism that only needs to be supported by the signer and the verifier, rather than any of the functional components along the handling path. This motivates functional goals about the authentication itself and operational goals about its integration with the rest of the Internet email service.
DKIMは、既存の電子メール転送インフラストラクチャにエンドツーエンドの認証機能を追加します。つまり、署名と検証の間にホップを中継する複数の電子メールがあります。したがって、ハンドリングパスに沿った機能コンポーネントのいずれでも、署名者と検証者によってのみサポートされる必要があるメカニズムを定義します。これにより、認証自体に関する機能的な目標と、他のインターネットメールサービスとの統合に関する運用目標が動機付けられます。
DKIM provides accountability at the coarse granularity of an organization or, perhaps, a department. An existing construct that enables this granularity is the Domain Name [RFC1034]. DKIM binds a signing key record to a Domain Name as the SDID. Further benefits of using domain names include simplifying key management, enabling signing by the infrastructure as opposed to the MUA, and reducing privacy concerns.
DKIMは、組織またはおそらく部門の粗い粒度で説明責任を提供します。この粒度性を可能にする既存の構造は、ドメイン名[RFC1034]です。DKIMは、署名キーレコードをSDIDとしてドメイン名にバインドします。ドメイン名を使用することのさらなる利点には、主要な管理の簡素化、MUAとは対照的にインフラストラクチャによる署名を可能にすること、プライバシーの懸念の削減が含まれます。
Contrast this with OpenPGP and S/MIME, which associate verification with individual authors, using their full email addresses.
これをOpenPGPおよびS/MIMEとは対照的に、完全な電子メールアドレスを使用して、個々の著者と関連付けます。
Any party, anywhere along the transit path, can implement DKIM signing. Its use is not confined to particular systems, such as the author's MUA or the inbound boundary MTA, and there can be more than one signature per message.
輸送パスに沿ったどこでも、DKIMの署名を実装できます。その使用は、著者のMUAやインバウンド境界MTAなどの特定のシステムに限定されておらず、メッセージごとに複数の署名がある場合があります。
Different parties have different roles in the process of email exchange. Some are easily visible to end users and others are primarily visible to operators of the service. DKIM was designed to support signing by any of these different parties and to permit them to sign with any domain name that they deem appropriate (and for which they hold authorized signing keys). As an example, an organization that creates email content often delegates portions of its processing or transmission to an outsourced group. DKIM supports this mode of activity, in a manner that is not normally visible to end users. Similarly, a reputation provider can delegate a signing key for a domain under the control of the provider, to be used by an organization for which the provider is prepared to vouch.
さまざまな当事者は、電子メール交換の過程で異なる役割を持っています。エンドユーザーに簡単に見えるものもあれば、主にサービスのオペレーターに見えるものもあります。DKIMは、これらのさまざまな関係者のいずれかによる署名をサポートし、適切だと思われるドメイン名（および承認された署名キーを保持している）に署名できるように設計されました。例として、電子メールコンテンツを作成する組織は、多くの場合、その処理または送信の一部をアウトソーシンググループに委任します。DKIMは、通常、エンドユーザーには表示されない方法で、このアクティビティモードをサポートしています。同様に、評判プロバイダーは、プロバイダーの制御下にあるドメインの署名キーを委任し、プロバイダーが保証する準備ができている組織が使用することができます。
An authenticated identity can be subject to a variety of assessment policies, either ad hoc or standardized. DKIM separates basic authentication from assessment. The only semantics inherent to a DKIM signature are that the signer is asserting some kind of responsibility for the message. Any interpretation of this kind of responsibility is the job of services building on DKIM, but the details are beyond the scope of that core. One such mechanism might assert a relationship between the SDID and the author, as specified in the rfc5322.From: header field's domain identity. Another might specify how to treat an unsigned message with that rfc5322.From: field domain.
認証されたアイデンティティは、アドホックまたは標準化されたさまざまな評価ポリシーの対象となります。DKIMは、基本認証を評価と分離します。DKIMの署名に固有の唯一のセマンティクスは、署名者がメッセージに対する何らかの責任を主張していることです。この種の責任の解釈は、DKIMに基づいてサービスを構築するサービスの仕事ですが、詳細はそのコアの範囲を超えています。そのようなメカニズムの1つは、RFC5322で指定されているように、SDIDと著者の関係を主張する可能性があります。別の人は、そのrfc5322.from：フィールドドメインを使用して、署名のないメッセージを扱う方法を指定する場合があります。
The ability to send a message that does not identify its author is considered to be a valuable quality of the current email service that needs to be retained. DKIM is compatible with this goal since it permits authentication of the email system operator, rather than the content author. If it is possible to obtain effectively anonymous accounts at example.com, knowing that a message definitely came from example.com does not threaten the anonymity of the user who authored it.
著者を識別しないメッセージを送信する機能は、保持する必要がある現在の電子メールサービスの貴重な品質であると考えられています。DKIMは、コンテンツ作者ではなく、電子メールシステムオペレーターの認証を許可するため、この目標と互換性があります。example.comで効果的に匿名アカウントを取得できる場合、example.comからのメッセージが間違いなく送信されることを知っていても、それを執筆したユーザーの匿名性を脅かすことはありません。
In order to facilitate incremental adoption, DKIM is designed to be transparent to recipients that do not support it. A DKIM signature does not "get in the way" for such recipients.
漸進的な採用を促進するために、DKIMはそれをサポートしていない受信者に透明性を持つように設計されています。DKIMの署名は、そのような受信者にとって「邪魔になりません」。
Contrast this with S/MIME and OpenPGP, which modify the message body. Hence, their presence is potentially visible to email recipients, whose user software needs to process the associated constructs.
これをS/MIMEおよびOpenPGPとは対照的に、メッセージ本文を変更します。したがって、それらの存在は、電子メール受信者に潜在的に表示されます。受信者のユーザーソフトウェアは、関連するコンストラクトを処理する必要があります。
DKIM must also be transparent to existing assessment mechanisms. Consequently, a DKIM signature verifier is to treat messages with signatures that fail as if they were unsigned. Hence, the message will revert to normal handling, through the receiver's existing filtering mechanisms. Thus, DKIM specifies that an assessing site is not to take a message that has a broken signature and treat it any differently than if the signature weren't there.
DKIMは、既存の評価メカニズムに対しても透過的でなければなりません。したがって、DKIM署名検証者は、まるで署名されていないかのように失敗する署名でメッセージを扱うことです。したがって、メッセージは、受信者の既存のフィルタリングメカニズムを介して、通常の取り扱いに戻ります。したがって、DKIMは、評価サイトは、署名が壊れているメッセージを受け取り、署名がそこになかった場合とは異なる方法で扱われないことを指定します。
Contrast this with OpenPGP and S/MIME, which were designed for strong cryptographic protection. This included treating verification failure as message failure.
これを強力な暗号化保護のために設計されたOpenPGPおよびS/MIMEとは対照的です。これには、検証障害をメッセージの障害として扱うことが含まれていました。
DKIM can be used by any two organizations that exchange email and implement DKIM; it does not require adoption within the open Internet's email infrastructure. In the usual manner of "network effects", the benefits of DKIM increase as its adoption increases. Although this mechanism can be used in association with independent assessment services, such services are not essential in order to obtain initial benefit. For example, DKIM allows (possibly large) pairwise sets of email providers and spam filtering companies to distinguish mail that is associated with a known organization, versus mail that might deceptively purport to have the affiliation. This in turn allows the development of "whitelist" schemes whereby authenticated mail from a known source with good reputation is allowed to bypass some anti-abuse filters.
DKIMは、電子メールを交換してDKIMを実装する2つの組織で使用できます。Open Internetの電子メールインフラストラクチャ内での採用は必要ありません。「ネットワーク効果」の通常の方法では、DKIMの採用が増加するにつれてDKIMの利点が増加します。このメカニズムは独立した評価サービスに関連して使用できますが、そのようなサービスは初期利益を得るために不可欠ではありません。たとえば、DKIMは、（おそらく大規模な）電子メールプロバイダーとスパムフィルタリング会社のペアワイズセットを許可して、既知の組織に関連付けられているメールを区別します。これにより、「ホワイトリスト」スキームの開発により、評判の高いソースからの郵便物を認証することで、いくつかの乱用防止フィルターがバイパスされます。
In effect, the email receiver can use their set of known relationships to generate their own reputation data. This works particularly well for traffic between large sending providers and large receiving providers. However, it also works well for any operator, public or private, that has mail traffic dominated by exchanges among a stable set of organizations.
実際、電子メール受信者は、既知の関係のセットを使用して、独自の評判データを生成できます。これは、大規模な送信プロバイダーと大規模な受信プロバイダー間のトラフィックに特に適しています。ただし、パブリックまたはプライベートのオペレーターにも適しています。これは、安定した一連の組織間の交換によって郵便トラフィックが支配されています。
Management of email delivery problems currently represents a significant pain point for email administrators at every point on the mail transit path. Administrators who have deployed DKIM verification have an incentive to encourage senders (who might subsequently complain that their email is not being delivered) to use DKIM signatures.
電子メール配信の問題の管理は、現在、メールトランジットパス上のすべてのポイントで電子メール管理者にとって重要な問題点を表しています。DKIM検証を展開した管理者は、DKIMの署名を使用するよう送信者（その後、電子メールが配信されていないことを訴える可能性がある）を奨励するインセンティブを持っています。
In order to allow early adopters to gain early benefit, DKIM makes no changes to the core Internet Mail service and, instead, can provide a useful benefit for any individual pair of signers and verifiers who are exchanging mail. Similarly, DKIM's reliance on the Domain Name System greatly reduces the amount of new administrative infrastructure that is needed across the open Internet.
早期採用者が早期の利益を得ることができるように、DKIMはコアインターネットメールサービスに変更を加えず、代わりに、メールを交換している個々の署名者と検証者に有用な利益を提供できます。同様に、DKIMのドメイン名システムへの依存は、オープンインターネット全体で必要な新しい管理インフラストラクチャの量を大幅に削減します。
DKIM can be deployed at a variety of places within an organization's email service. This affords flexibility in terms of who administers its use, as well as what traffic carries a DKIM signature. For example, employing DKIM at an outbound boundary MTA will mean that it is administered by the organization's central IT department and that internal messages are not signed.
DKIMは、組織の電子メールサービス内のさまざまな場所に展開できます。これにより、誰がその使用を管理するか、およびDKIMの署名があるトラフィックの点で柔軟性が得られます。たとえば、DKIMをアウトバウンド境界MTAで採用すると、組織の中央IT部門によって管理され、内部メッセージが署名されていないことを意味します。
DKIM has a very constrained set of capabilities, primarily targeting email while it is in transit from an author to a set of recipients. It associates verifiable information with a message, especially a responsible identity. When a message does not have a valid signature associated with the author, a DKIM SP will permit the domain name of the author to be used for obtaining information about their signing practices.
DKIMには非常に制約された機能セットがあり、主に著者から一連の受信者への輸送中に電子メールをターゲットにしています。検証可能な情報をメッセージ、特に責任あるアイデンティティに関連付けます。メッセージに著者に関連付けられた有効な署名がない場合、DKIM SPは、署名慣行に関する情報を取得するために著者のドメイン名を使用することを許可します。
With the DKIM signature mechanism, a signer chooses an SDID, performs digital signing on the message, and adds the signature information using a DKIM header field. A verifier obtains the domain name and the "selector" from the DKIM header field, obtains the public key associated with the name, and verifies the signature.
DKIMの署名メカニズムにより、署名者はSDIDを選択し、メッセージにデジタル署名を実行し、DKIMヘッダーフィールドを使用して署名情報を追加します。Verifierは、DKIMヘッダーフィールドからドメイン名と「セレクター」を取得し、名前に関連付けられた公開キーを取得し、署名を検証します。
DKIM permits any domain name to be used as the SDID, and supports extensible choices for various algorithms. As is typical for Internet standards, there is a core set of algorithms that all implementations are required to support, in order to guarantee basic interoperability.
DKIMは、任意のドメイン名をSDIDとして使用することを許可し、さまざまなアルゴリズムの拡張可能な選択をサポートします。インターネット標準に典型的なものであるように、基本的な相互運用性を保証するために、すべての実装がサポートするために必要であるアルゴリズムのコアセットがあります。
DKIM permits restricting the use of a signature key to signing messages for particular types of services, such as only for a single source of email. This is intended to be helpful when delegating signing authority, such as to a particular department or to a third-party outsourcing service.
DKIMは、単一の電子メールのみの場合のみなど、特定の種類のサービスにメッセージに署名するための署名キーの使用を制限することを許可します。これは、特定の部門やサードパーティのアウトソーシングサービスなど、署名当局を委任するときに役立つことを目的としています。
With DKIM, the signer explicitly lists the headers that are signed, such as From:, Date:, and Subject:. By choosing the minimal set of headers needed, the signature is likely to be considerably more robust against the handling vagaries of intermediary MTAs.
dkimを使用すると、署名者は、from：、date：、and subject：。など、署名されたヘッダーを明示的にリストします。必要な最小限のヘッダーセットを選択することにより、署名は、中間MTAのハンドリングの気まぐれに対してかなり堅牢になる可能性があります。
A DKIM signature applies to the message body and selected header fields. The signer computes a hash of the selected header fields and another hash of the body. The signer then uses a private key to cryptographically encode this information, along with other signing parameters. Signature information is placed into DKIM-Signature:, a new [RFC5322] message header field.
dkim署名は、メッセージ本文と選択されたヘッダーフィールドに適用されます。署名者は、選択したヘッダーフィールドのハッシュとボディの別のハッシュを計算します。その後、署名者は秘密鍵を使用して、他の署名パラメーターとともに、この情報を暗号化してエンコードします。署名情報は、DKIM-Signature：、新しい[RFC5322]メッセージヘッダーフィールドに配置されます。
The key for a signature is associated with an SDID. That domain name provides the complete identity used for making assessments about the signer. (The DKIM specification does not give any guidance on how to do an assessment.) However, this name is not sufficient for making a DNS query to obtain the key needed to verify the signature.
署名の鍵はSDIDに関連付けられています。そのドメイン名は、署名者に関する評価を行うために使用される完全なIDを提供します。（DKIMの仕様では、評価の実行方法に関するガイダンスは提供されません。）しかし、この名前は、署名を検証するために必要なキーを取得するためにDNSクエリを作成するのに十分ではありません。
A single SDID can have multiple signing keys and/or multiple potential signers. To support this, DKIM identifies a particular signature as using a combination of the SDID and an added field, called the "selector", specified in a separate DKIM-Signature: header field parameter.
単一のSDIDには、複数の署名キーおよび/または複数の潜在的な署名者を持つことができます。これをサポートするために、DKIMは特定の署名を、別のDKIMシグネチャーで指定された「セレクター」と呼ばれるSDIDと追加されたフィールドの組み合わせを使用して識別します：ヘッダーフィールドパラメーター。
NOTE: The semantics of the selector (if any) are strictly reserved to the signer and is to be treated as an opaque string by all other parties. 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.
注：セレクターのセマンティクス（もしあれば）は、署名者に厳密に留保され、他のすべての関係者によって不透明な文字列として扱われます。検証剤が評価メカニズムの一部としてセレクターを採用した場合、古い、または妥協した鍵から新しいものへの移行を行うための残りのメカニズムはありません。
After a message has been signed, any agent in the message transit path can verify the signature to determine that the owner of the SDID took responsibility for the message. Message recipients can verify the signature by querying the DNS for the signer's domain directly, to retrieve the appropriate public key, and thereby confirm that the message was signed by a party in possession of the private key for the SDID. Typically, verification will be done by an agent in the Administrative Management Domain (ADMD) of the message recipient.
メッセージが署名された後、メッセージトランジットパスのエージェントは署名を検証して、SDIDの所有者がメッセージに対して責任を負ったことを判断できます。メッセージ受信者は、署名者のドメインのDNSを直接照会して署名を検証して、適切な公開キーを取得し、それによりメッセージがSDIDの秘密鍵を所有している当事者によって署名されたことを確認できます。通常、検証は、メッセージ受信者の管理管理ドメイン（ADMD）のエージェントによって行われます。
Signers often need to support multiple assessments about their organization, such as to distinguish one type of message from another, or one portion of the organization from another. To permit assessments that are independent, one method is for an organization to use different sub-domains as the SDID tag, such as "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com". These can be entirely separate from the rfc5322.From header field domain.
多くの場合、署名者は、あるタイプのメッセージを別のタイプから、または組織の一部を別のメッセージと区別するなど、組織に関する複数の評価をサポートする必要があります。独立した評価を許可するために、1つの方法は、「transaction.example.com」と「newsletter.example.com」、または「producta.example.com」など、sdidタグとして異なるサブドメインを使用することです。versus "productb.example.com"。これらは、ヘッダーフィールドドメインからRFC5322.から完全に分離できます。
DKIM uses external service components, such as for key retrieval and
relaying email. This specification defines an initial set, using DNS
and SMTP, for basic interoperability.
|
|- RFC5322 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +...>| Sign Message with SDID |
| Store | +---------------+----------------+
+--------+ |
(paired) [Internet]
+--------+ | +-----------+
| Public | +--------------------------------+ | Remote |
| Key | | RELAYING OR DELIVERING ADMD | | Sender |
| Store | | Message Signed? | | Practices |
+----+---+ +-----+--------------------+-----+ +-----+-----+
. |yes |no .
. V | .
. +-------------+ | .
+.......>| Verify +--------+ | .
| Signature | | | .
+------+------+ | | .
pass| fail| | .
V | | .
+-------------+ | | .
| | | | .
+.......>| Assessments | | | .
. | | V V .
. +-----+--+----+ +-------+ .
. | | / Check \<............+
. | +-------->/ Signing \
. | / Practices \<..........+
. | +-------+-------+ .
. | | .
. | V .
+----+--------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info |
|Accreditation| +----------->| Filtering | | on Sender |
|Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+
Figure 1: DKIM Service Architecture
図1：DKIMサービスアーキテクチャ
As shown in Figure 1, basic message processing is divided between a signing Administrative Management Domain (ADMD) and a verifying ADMD. At its simplest, this is between the originating ADMD and the delivering ADMD, but can involve other ADMDs in the handling path.
図1に示すように、基本的なメッセージ処理は、署名管理管理ドメイン（ADMD）と検証ADMDの間で分割されています。最も簡単に言えば、これは起源のADMDと配信のADMDの間にありますが、取り扱いパスに他のADMDが関与する可能性があります。
signing: Signing is performed by an authorized module within the signing ADMD and uses private information from the Key Store, as discussed below. Within the originating ADMD, this might be performed by the MUA, MSA, or an MTA.
署名：署名は、署名admd内の承認されたモジュールによって実行され、以下で説明するように、キーストアからの個人情報を使用します。起源のADMD内では、これはMUA、MSA、またはMTAによって実行される場合があります。
verifying: verifying is performed by an authorized module within the verifying ADMD. Within a delivering ADMD, verifying might be performed by an MTA, MDA, or MUA. The module verifies the signature or determines whether a particular signature was required. Verifying the signature uses public information from the Key Store. If the signature passes, reputation information is used to assess the signer and that information is passed to the message filtering system. If the signature fails or there is no signature using the author's domain, information about signing practices related to the author can be retrieved remotely and/or locally, and that information is passed to the message filtering system.
確認：検証は、検証admd内の承認されたモジュールによって実行されます。配信中のADMD内で、MTA、MDA、またはMUAによって検証が実行される場合があります。モジュールは署名を検証するか、特定の署名が必要かどうかを判断します。署名の確認は、キーストアからの公開情報を使用します。署名が合格した場合、評判情報は署名者を評価するために使用され、その情報はメッセージフィルタリングシステムに渡されます。署名が失敗した場合、または著者のドメインを使用して署名がない場合、著者に関連する署名慣行に関する情報は、リモートおよび/またはローカルで取得でき、その情報はメッセージフィルタリングシステムに渡されます。
If a message has more than one valid signature, the order in which the signers are assessed and the interactions among the assessments are not defined by the DKIM specification.
メッセージに複数の有効な署名がある場合、署名者が評価される順序と評価間の相互作用は、DKIM仕様によって定義されません。
A number of tables and services are used to provide external information. Each of these introduces administration and maintenance requirements.
多くのテーブルとサービスが使用され、外部情報を提供します。これらのそれぞれは、管理および保守要件を導入します。
Key Store: DKIM uses public-/private-key (asymmetric) cryptography. The signer users a private key and the verifier uses the corresponding public key. The current DKIM Signing specification provides for querying the Domain Names Service (DNS), to permit a verifier to obtain the public key. The signing organization therefore needs to have a means of adding a key to the DNS, for every selector/SDID combination. Further, the signing organization needs policies for distributing and revising keys.
キーストア：DKIMは、パブリック/プライベートキー（非対称）暗号化を使用しています。署名者は秘密鍵を使用し、検証者は対応する公開キーを使用します。現在のDKIM署名仕様は、Verifierが公開キーを取得できるようにするために、ドメイン名サービス（DNS）をクエリすることを規定しています。したがって、署名組織には、すべてのセレクター/SDIDの組み合わせに対して、DNSにキーを追加する手段が必要です。さらに、署名組織には、キーを配布および修正するためのポリシーが必要です。
Reputation/Accreditation: If a message contains a valid signature, then the verifier can evaluate the associated domain name's reputation, in order to determine appropriate delivery or display options for that message. Quality assessment information, which is associated with a domain name, comes in many forms and from many sources. DKIM does not define assessment services. Its relevance to them is to provide a verified domain name, upon which assessments can be made.
評判/認定：メッセージに有効な署名が含まれている場合、Verifierは、そのメッセージの適切な配信または表示オプションを決定するために、関連するドメイン名の評判を評価できます。ドメイン名に関連付けられている品質評価情報は、多くの形式で多くの情報源から来ています。DKIMは評価サービスを定義していません。彼らとの関連性は、評価を行うことができる検証済みのドメイン名を提供することです。
Signing Practices (SP): Separate from determining the validity of a signature, and separate from assessing the reputation of the organization that is associated with the signed identity, there is an opportunity to determine any organizational practices concerning a domain name. Practices can range widely. They can be published by the owner of the domain or they can be maintained by the evaluating site. They can pertain to the use of the domain name, such as whether it is used for signing messages, whether all mail having that domain name in the author rfc5322.From: header field is signed, or even whether the domain owner recommends discarding messages in the absence of an appropriate signature. The statements of practice are made at the level of a domain name, and are distinct from assessments made about particular messages, as occur in a Message Filtering Engine. Such assessments of practices can provide useful input for the Message Filtering Engine's determination of message handling. As practices are defined, each domain name owner needs to consider what information to publish. The nature and degree of checking practices, if any are performed, is optional to the evaluating site and is strictly a matter of local policy.
署名プラクティス（SP）：署名の有効性を判断することとは別に、署名されたアイデンティティに関連付けられている組織の評判を評価することとは別に、ドメイン名に関する組織の慣行を決定する機会があります。慣行は広く範囲になります。ドメインの所有者によって公開されるか、評価サイトによって維持されることもあります。メッセージの署名に使用されるかどうか、著者RFC5322にそのドメイン名を持っているすべてのメールが署名されているかどうかなど、ドメイン名の使用に関係することができます。適切な署名がない。実践文はドメイン名のレベルで行われ、メッセージフィルタリングエンジンで発生するように、特定のメッセージについて行われた評価とは異なります。このようなプラクティスの評価は、メッセージフィルタリングエンジンのメッセージ処理の決定に有用な入力を提供できます。プラクティスが定義されているため、各ドメイン名の所有者は、公開する情報を検討する必要があります。実行された場合、チェックプラクティスの性質と程度は、評価サイトにオプションであり、厳密にはローカルポリシーの問題です。
Signing can be performed by a component of the ADMD that creates the message, and/or within any ADMD along the relay path. The signer uses the appropriate private key that is associated with the SDID.
署名は、メッセージを作成するADMDのコンポーネント、および/またはリレーパスに沿ったADMD内で実行できます。署名者は、SDIDに関連付けられている適切な秘密鍵を使用します。
Verification can be performed by any functional component along the relay and delivery path. Verifiers retrieve the public key based upon the parameters stored in the message.
検証は、リレーと配信パスに沿った任意の機能成分によって実行できます。Verifiersは、メッセージに保存されているパラメーターに基づいて公開キーを取得します。
Messages lacking a valid author signature (a signature associated with the author of the message as opposed to a signature associated with an intermediary) can prompt a query for any published "signing practices" information, as an aid in determining whether the author information has been used without authorization.
有効な著者の署名がないメッセージ（仲介者に関連付けられた署名とは対照的に、メッセージの著者に関連付けられた署名）は、著者情報があるかどうかを判断するための支援として、公開された「署名慣行」情報の質問を促すことができます。許可なしに使用されます。
Figure 1 shows the verified identity as being used to assess an associated reputation, but it could be applied to other tasks, such as management tracking of mail. Local policy guidelines may cause signing practices to be checked or the message may be sent directly to the message Filtering Engine.
図1は、関連する評判を評価するために使用されていると確認されたアイデンティティを示していますが、メールの管理追跡など、他のタスクに適用できます。ローカルポリシーガイドラインにより、署名慣行がチェックされるか、メッセージがメッセージフィルタリングエンジンに直接送信される場合があります。
A popular use of reputation information is as input to a Filtering Engine that decides whether to deliver -- and possibly whether to specially mark -- a message. Filtering Engines have become complex and sophisticated. Their details are outside of the scope of DKIM, other than the expectation that the verified identity produced by DKIM can accumulate its own reputation, and will be added to the varied soup of rules used by the engines. The rules can cover signed messages and can deal with unsigned messages from a domain, if the domain has published information about its practices.
評判情報の一般的な使用は、メッセージを配信するかどうかを決定するフィルタリングエンジンへの入力として、そしてメッセージがメッセージです。フィルタリングエンジンは複雑で洗練されています。彼らの詳細は、DKIMによって生成された検証されたアイデンティティが独自の評判を蓄積する可能性があり、エンジンが使用するルールのさまざまなスープに追加されるという期待以外のDKIMの範囲外です。ルールは署名されたメッセージをカバーでき、ドメインがそのプラクティスに関する情報を公開している場合、ドメインからの署名されていないメッセージを処理できます。
It is expected that the most common venue for a DKIM implementation will be within the infrastructures of the authoring organization's outbound service and the receiving organization's inbound service, such as a department or a boundary MTA. DKIM can be implemented in an author's or recipient's MUA, but this is expected to be less typical, since it has higher administration and support costs.
DKIM実装の最も一般的な会場は、オーサリング組織のアウトバウンドサービスのインフラストラクチャと、部門や境界MTAなどの受信組織のインバウンドサービス内にあることが期待されています。DKIMは著者または受信者のMUAに実装できますが、これはより高い管理コストとサポートコストがあるため、典型的ではないと予想されます。
A Mediator is an MUA that receives a message and can repost a modified version of it, such as to a mailing list. A DKIM signature can survive some types of modifications through this process. Furthermore, the Mediator can add its own signature. This can be added by the Mediator software itself, or by any outbound component in the Mediator's ADMD.
メディエーターは、メッセージを受信し、メーリングリストなどの変更されたバージョンを再投稿できるMUAです。DKIMの署名は、このプロセスを通じていくつかのタイプの変更に耐えることができます。さらに、メディエーターは独自の署名を追加できます。これは、メディエーターソフトウェア自体、またはメディエーターのADMDの任意のアウトバウンドコンポーネントによって追加できます。
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871], with [RFC4686] as their basis.
DKIMプロトコルのセキュリティ上の考慮事項は、[RFC4871]をDKIMベース仕様[RFC4871]に基づいて説明しています。
Many people contributed to the development of the DomainKeys Identified Mail and the effort of the DKIM Working Group is gratefully acknowledged. In particular, we would like to thank Jim Fenton for his extensive feedback diligently provided on every version of this document.
多くの人々がドメインキーの開発に貢献し、郵便物を特定し、DKIMワーキンググループの努力に感謝します。特に、このドキュメントのすべてのバージョンで熱心に提供された広範なフィードバックについて、ジムフェントンに感謝します。
[Kohnfelder] Kohnfelder, L., "Towards a Practical Public-key Cryptosystem", May 1978.
[Kohnfelder] Kohnfelder、L。、「実用的な公開暗号システムに向けて」、1978年5月。
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 989, February 1987.
[RFC0989] Linn、J。およびIABプライバシータスクフォース、「インターネット電子メールのプライバシー強化：パートI：メッセージのエンカイファメントと認証手順」、RFC 989、1987年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1113] Linn, J., "Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures", RFC 1113, August 1989.
[RFC1113] Linn、J。、「インターネット電子メールのプライバシー強化：パートI-メッセージのエンカイファメントと認証手順」、RFC 1113、1989年8月。
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME Object Security Services", RFC 1848, October 1995.
[RFC1848] Crocker、S.、Galvin、J.、Murphy、S。、およびN. Freed、「Mime Object Security Services」、RFC 1848、1995年10月。
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991] Atkins、D.、Stallings、W。、およびP. Zimmermann、「PGPメッセージ交換形式」、RFC 1991、1996年8月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPを使用したMime Security」、RFC 3156、2001年8月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406] Lyon、J。およびM. Wong、「送信者ID：認証電子メール」、RFC 4406、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407] Lyon、J。、「電子メールメッセージの責任ある住所」、RFC 4407、2006年4月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC4408] Wong、M。およびW. Schlitt、「送信者ポリシーフレームワーク（SPF）電子メールでのドメインの使用を承認するための、バージョン1」、RFC 4408、2006年4月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686] Fenton、J。、「ドメインキーを動機付けた脅威の分析（DKIM）」、RFC 4686、2006年9月。
[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月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[WebofTrust] Network Associates, Inc. and its Affiliated Companies, "How PGP works, in Introduction to Cryptography", 1999, <http://www.pgpi.org/doc/pgpintro/>.
[Weboftrust] Network Associates、Inc。およびその関連会社、「Cryptographyの紹介におけるPGPの仕組み」、1999年、<http://www.pgpi.org/doc/pgpintro/>。
Internet Mail is split between the user world, in the form of Mail User Agents (MUA), and the transmission world, in the form of the Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). The MHS is responsible for accepting a message from one user, the author, and delivering it to one or more other users, the recipients. This creates a virtual MUA-to-MUA exchange environment. The first component of the MHS is called the Mail Submission Agent (MSA) and the last is called the Mail Delivery Agent (MDA).
インターネットメールは、メール転送エージェント（MTA）で構成されるメールハンドリングサービス（MHS）の形で、メールユーザーエージェント（MUA）の形でユーザーの世界と伝送の世界に分割されます。MHSは、著者である1人のユーザーからのメッセージを受け入れ、1人以上の他のユーザー、受信者に配信する責任があります。これにより、仮想MUAからMUAへの交換環境が作成されます。MHSの最初のコンポーネントはメール提出エージェント（MSA）と呼ばれ、最後のコンポーネントはメール配信エージェント（MDA）と呼ばれます。
An email Mediator is both an inbound MDA and outbound MSA. It takes delivery of a message, makes changes appropriate to its service, and then reposts it for further distribution. Typically, the new message will retain the original rfc5322.From: header field. A mailing list is a common example of a Mediator.
電子メールメディエーターは、インバウンドMDAとアウトバウンドMSAの両方です。メッセージの配信が必要であり、サービスに適切な変更を加え、さらに配信するために再投稿します。通常、新しいメッセージは、元のRFC5322を保持します：ヘッダーフィールド。メーリングリストは、調停者の一般的な例です。
The modern Internet Mail service is marked by many independent operators, many different components for providing users with service and many other components for performing message transfer. Consequently, it is necessary to distinguish administrative boundaries that surround sets of functional components, which are subject to coherent operational policies.
最新のインターネットメールサービスは、多くの独立したオペレーター、ユーザーにサービスを提供するための多くの異なるコンポーネント、およびメッセージ転送を実行するための他の多くのコンポーネントによってマークされています。その結果、一貫した運用ポリシーの対象となる機能コンポーネントのセットを取り巻く管理境界を区別する必要があります。
As elaborated on below, every MSA is a candidate for signing using DKIM, and every MDA is a candidate for doing DKIM verification.
以下で詳しく説明されているように、すべてのMSAはDKIMを使用して署名する候補者であり、すべてのMDAはDKIM検証を行う候補者です。
Operation of Internet Mail services is apportioned to different providers (or operators). Each can be composed of an independent ADministrative Management Domain (ADMD). An ADMD operates with an independent set of policies and interacts with other ADMDs according to differing types and amounts of trust. Examples include an end user operating a desktop client that connects to an independent email service, a department operating a submission agent or a local Relay, an organization's IT group that operates enterprise Relays, and an ISP operating a public shared email service.
インターネットメールサービスの運用は、さまざまなプロバイダー（またはオペレーター）に配分されます。それぞれは、独立した管理管理ドメイン（ADMD）で構成できます。ADMDは、独立した一連のポリシーで動作し、異なるタイプと量の信頼量に従って他のADMDと対話します。例には、独立した電子メールサービスに接続するデスクトップクライアントを操作するエンドユーザー、提出エージェントまたはローカルリレーを操作する部門、エンタープライズリレーを運営する組織のITグループ、およびISPが公開共有電子メールサービスを運営しています。
Each of these can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 2 depicts the relationships among ADMDs. Perhaps the most salient aspect of an ADMD is the differential trust that determines its policies for activities within the ADMD, versus those involving interactions with other ADMDs.
これらはそれぞれ、管理関係と運用上の関係の多くの組み合わせに構成でき、それぞれが潜在的に機能成分の複雑な配置を持っている可能性があります。図2は、ADMDS間の関係を示しています。おそらく、ADMDの最も顕著な側面は、他のADMDとの相互作用を伴うものに対して、ADMD内の活動のポリシーを決定する差別的な信頼です。
Basic types of ADMDs include:
ADMDの基本的なタイプは次のとおりです。
Edge: Independent transfer services, in networks at the edge of the Internet Mail service.
Edge：インターネットメールサービスのEdgeにあるネットワーク内の独立転送サービス。
User: End-user services. These might be subsumed under an Edge service, such as is common for web-based email access.
ユーザー：エンドユーザーサービス。これらは、Webベースの電子メールアクセスに一般的であるようなエッジサービスの下に包まれている可能性があります。
Transit: These are Mail Service Providers (MSP) offering value-added capabilities for Edge ADMDs, such as aggregation and filtering.
トランジット：これらは、集約やフィルタリングなど、エッジアドバンスの付加価値機能を提供するメールサービスプロバイダー（MSP）です。
Note that Transit services are quite different from packet-level transit operation. Whereas end-to-end packet transfers usually go through intermediate routers, email exchange across the open Internet often is directly between the Edge ADMDs, at the email level.
トランジットサービスは、パケットレベルのトランジット操作とはまったく異なることに注意してください。通常、エンドツーエンドのパケット転送は中間ルーターを通過しますが、オープンインターネット全体での電子メール交換は、電子メールレベルでのエッジADMDSの間に直接行われることがよくあります。
+--------+ +--------+ +--------+
| ADMD#1 | | ADMD#3 | | ADMD#4 |
| ------ | | ------ | | ------ |
| | +----------------------->| | | |
| User | | |--Edge--+--->|--User |
| | | | +--->| | | |
| V | | | +--------+ +--------+
| Edge---+---+ |
| | | +----------+ |
+--------+ | | ADMD#2 | |
| | ------ | |
| | | |
+--->|-Transit--+---+
| |
+----------+
Figure 2: ADministrative Management Domains (ADMD) Example
図2：管理管理ドメイン（ADMD）の例
In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM signing, and ADMD numbers 2, 3, and 4 are candidates for doing DKIM verification.
図2では、ADMD番号1と2はDKIMの署名を行う候補者であり、ADMD番号2、3、および4はDKIM検証を行う候補者です。
The distinction between Transit network and Edge network transfer services is primarily significant because it highlights the need for concern over interaction and protection between independent administrations. The interactions between functional components within a single ADMD are subject to the policies of that domain. Although any pair of ADMDs can arrange for whatever policies they wish, Internet Mail is designed to permit inter-operation without prior arrangement.
トランジットネットワークとエッジネットワーク転送サービスの区別は、独立した管理間の相互作用と保護に対する懸念の必要性を強調するため、主に重要です。単一のADMD内の機能成分間の相互作用は、そのドメインのポリシーの対象となります。ADMDのペアは、希望するポリシーを何でも手配できますが、インターネットメールは、事前の取り決めなしに相互操作を可能にするように設計されています。
Common ADMD examples are:
一般的なADMDの例は次のとおりです。
Enterprise Service Providers:
エンタープライズサービスプロバイダー：
Operators of an organization's internal data and/or mail services.
組織の内部データおよび/またはメールサービスのオペレーター。
Internet Service Providers:
インターネットサービスプロバイダー：
Operators of underlying data communication services that, in turn, are used by one or more Relays and Users. It is not necessarily their job to perform email functions, but they can, instead, provide an environment in which those functions can be performed.
基礎となるデータ通信サービスのオペレーターは、1つ以上のリレーとユーザーによって使用されます。メール関数を実行することは必ずしも彼らの仕事ではありませんが、代わりに、それらの機能を実行できる環境を提供できます。
Mail Service Providers:
メールサービスプロバイダー：
Operators of email services, such as for end users, or mailing lists.
エンドユーザーやメーリングリストなどの電子メールサービスのオペレーター。
Index
索引
A ADMD 6 Administrative Management Domain 6 assessment 7
ADMD 6管理管理ドメイン6評価7
D DKIM-Signature 12-13 DNS 6, 13-15
d dkim-signature 12-13 DNS 6、13-15
I identifier 4-8 identity 3-7, 9, 12 infrastructure 5-6, 8-11, 17
I識別子4-8 ID 3-7、9、12インフラストラクチャ5-6、8-11、17
M Mail Delivery Agent 6 Mail Handling Service 6 Mail Service Provider 6 Mail Submission Agent 6 Mail Transfer Agent 6 Mail User Agent 6 MDA 6 MHS 6 MIME Object Security Services 5 MOSS 5 MSA 6 MSP 6 MTA 6 MUA 6
Mメールデリバリーエージェント6メールハンドリングサービス6メールサービスプロバイダー6メール提出エージェント6メール転送エージェント6メールユーザーエージェント6 MDA 6 MHS 6 MIMEオブジェクトセキュリティサービス5 MOSS 5 MSA 6 MSP 6 MTA 6 MUA 6
O OpenPGP 5
o openPGP 5
P PEM 5 PGP 5 Pretty Good Privacy 5 Privacy Enhanced Mail 5
PEM 5 PGP 5かなり良いプライバシー5プライバシー強化メール5
S S/MIME 5
s/mime 5
T trust 3, 7-8, 20
T Trust 3、7-8、20
V verification 4, 7-8, 10-11, 13, 16, 20-21
v検証4、7-8、10-11、13、16、20-21
W Web of Trust 6
W Web of Trust 6
X X.509 6
x x.509 6
Authors' Addresses
著者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
トニー・ハンセンAT＆Tラボトリーズ200ローレルアベニュー、ミドルタウン、ニュージャージー07748 USA
EMail: tony+dkimov@maillennium.att.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
Phillip Hallam-Baker Default Deny Security, Inc.
Phillip Hallam-Baker Default Deny Security、Inc。
EMail: phillip@hallambaker.com