[要約] RFC 5672は、RFC 4871で定義されたDomainKeys Identified Mail（DKIM）署名の更新を提供します。この更新は、DKIM署名のセキュリティと信頼性を向上させるために行われました。目的は、電子メールの送信者の認証とメッセージの改ざんの検出を容易にすることです。
Network Working Group D. Crocker, Ed.
Request for Comments: 5672 Brandenburg InternetWorking
Updates: 4871 August 2009
Category: Standards Track
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
RFC 4871 DomainKeys Identified Mail（DKIM）署名-更新
Abstract
概要
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one.
このドキュメントは、RFC 4871「DomainKeys Identified Mail（DKIM）Signatures」を更新します。具体的には、このドキュメントでは、受信処理モジュールへのペイロード配信の候補である2つのDKIM識別子タグ値の性質、役割、および関係を明らかにしています。更新はかなり長いものですが、Errataエントリのスタイルで行われます。
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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トラストの法的規定に従うものとします。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RFC 4871, Abstract . . . . . . . . . . . . . . . . . . . . . . 4
3. RFC 4871, Section 1, Introduction . . . . . . . . . . . . . . 4
4. RFC 4871, Section 2.7, Identity . . . . . . . . . . . . . . . 4
5. RFC 4871, Section 2.8, Identifier . . . . . . . . . . . . . . 5
6. RFC 4871, Section 2.9, Signing Domain Identifier (SDID) . . . 5
7. RFC 4871, Section 2.10, Agent or User Identifier (AUID) . . . 5
8. RFC 4871, Section 2.11, Identity Assessor . . . . . . . . . . 6
9. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 6
10. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 7
11. RFC 4871, Section 3.8, Signing by Parent Domains . . . . . . . 9
12. RFC 4871, Section 3.9, Relationship between SDID and AUID . . 10
13. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
14. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
15. RFC 4871, Appendix D, MUA Considerations . . . . . . . . . . . 12
16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
17. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. ABNF Fragments . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
About the purpose for DKIM, [RFC4871] states:
DKIMの目的について、[RFC4871]は次のように述べています。
The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity...
このフレームワークの最終的な目標は、署名ドメインがメッセージに対する責任を主張できるようにすることであり、それによりメッセージ署名者のアイデンティティを保護します...
Hence, DKIM has a signer that produces a signed message, a verifier that confirms the signature, and an assessor that consumes the validated signing domain. So, the simple purpose of DKIM is to communicate an identifier to a receive-side assessor module. The identifier is in the form of a domain name that refers to a responsible identity. For DKIM to be interoperable and useful, the signer and assessor must share the same understanding of the details about the identifier.
したがって、DKIMには、署名付きメッセージを生成する署名者、署名を確認する検証者、および検証済みの署名ドメインを使用する評価者がいます。したがって、DKIMの単純な目的は、受信側の査定者モジュールに識別子を伝達することです。識別子は、責任あるIDを参照するドメイン名の形式です。 DKIMが相互運用可能で有用であるためには、署名者と評価者は、識別子に関する詳細について同じ理解を共有する必要があります。
However, the RFC 4871 specification defines two, potentially different, identifiers that are carried in the DKIM-Signature: header field, d= and i=. Either might be delivered to a receiving processing module that consumes validated payload. The DKIM specification fails to clearly define which is the "payload" to be delivered to a consuming module, versus what is internal and merely in support of achieving payload delivery.
ただし、RFC 4871仕様では、DKIM-Signatureで運ばれる2つの（場合によっては異なる）識別子が定義されています：ヘッダーフィールド、d =およびi =。どちらも、検証済みのペイロードを使用する受信処理モジュールに配信される可能性があります。 DKIM仕様では、内部で何がペイロード配信の実現を単にサポートしているのかに対して、消費モジュールに配信される「ペイロード」が明確に定義されていません。
This currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a different intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment.
これは現在、署名者と評価者に2つの識別子間で異なる解釈を行う可能性を残しており、相互運用性の問題につながる可能性があります。署名者は、一方を評価に使用することを意図し、もう一方に値を設定する意図が異なる場合があります。ただし、検証者が誤った値を選択して評価者に提供し、意図しない（および不正確な）評価を生成する場合があります。
This Update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature, and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a whitelist -- is the value of the "d=" tag. However, this does not prohibit message filtering engines from using the "i=" tag, or any other information in the message's header, for filtering decisions.
このアップデートはその混乱を解決します。 2つの値の追加のセマンティックラベルを定義し、それらの性質を明確にし、それらの関係を指定します。より具体的には、評価者への配信を目的とした識別子（ホワイトリストを参照するものなど）が「d =」タグの値であることを明確にします。ただし、これはメッセージフィルタリングエンジンが "i ="タグ、またはメッセージのヘッダーにあるその他の情報をフィルタリングの決定に使用することを禁止しません。
For signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended.
評価者に配信される主要な値としてi =タグを使用していた署名者と検証者の場合、d =タグを使用するためのソフトウェアの変更が意図されています。
So, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface.
したがって、この更新では、署名の検証が実行された後のDKIMへの正式なインターフェースが明確になります。これは、DKIMの内部署名および検証アクティビティを、そのインターフェースへのデータの標準化された配信と区別します。
The focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message.
アップデートの焦点は、API定義によく似たDKIMの部分にあります。 DKIMが他のユーザーが使用するソフトウェアライブラリとして実装されている場合、提供される出力、つまり、ライブラリを使用するアプリケーション開発者がメッセージでDKIMを呼び出した結果として取得できると期待できるデータを定義する必要があります。
This Update defines the output of that library to include the yes/no result of the verification and the "d=" value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However, that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant.
このアップデートは、検証のyes / no結果と「d =」値を含むようにそのライブラリの出力を定義します。つまり、署名者が使用するために正式に指定された識別子（1つ）、およびその識別子の使用が検証されているかどうかを示します。特定のライブラリについては、ライブラリ開発者の裁量で他の情報を提供できます。評価者の開発者（これらはDKIMライブラリのコンシューマです）は、標準化された2つの情報よりも多くの情報を必要とする場合があるためです。ただし、その標準化されたセットは、ライブラリがDKIMに準拠していると主張できるようにするために、消費モジュールに提供する必要がある最低限のものです。
This does not state what the implicit value of "i=" is, relative to "d=". In this context, that fact is irrelevant.
これは、「i =」の暗黙の値が「d =」と比較して何であるかを述べていません。この文脈では、その事実は無関係です。
Another example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used.
別の例は、TCPへのソケットインターフェイスとTCPプロトコル自体の違いです。プロトコルスタック内にアクティビティがあり、実際に使用されるソフトウェアライブラリ内にアクティビティがあります。
NOTE: The text provided here updates [RFC4871]. Text appearing in the "Corrected Text:" replaces text in RFC 4871. Hence, references that appear in the "Original Text:" can be found in RFC 4871, and are not duplicated in this document.
注：ここで提供されるテキストは[RFC4871]を更新します。 「Corrected Text：」に表示されるテキストは、RFC 4871のテキストを置き換えます。したがって、「Original Text：」に表示される参照はRFC 4871にあり、このドキュメントでは複製されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Original Text:
元のテキスト：
The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message,
このフレームワークの最終的な目的は、署名ドメインがメッセージに対する責任を主張できるようにすることです。
Corrected Text:
修正されたテキスト：
The ultimate goal of this framework is to permit a person, role or organization that owns the signing domain to assert responsibility for a message,
このフレームワークの最終的な目的は、署名ドメインを所有する個人、役割、または組織がメッセージの責任を主張できるようにすることです。
Original Text:
元のテキスト：
...permitting a signing domain to claim responsibility
...署名ドメインに責任を主張することを許可する
Corrected Text:
修正されたテキスト：
permitting a person, role, or organization that owns the signing domain to claim responsibility
署名ドメインを所有する個人、役割、または組織が責任を主張することを許可する
Original Text:
元のテキスト：
(None. New section. Additional text.)
（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
A person, role, or organization. In the context of DKIM, examples include author, author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator.
人、役割、または組織。 DKIMのコンテキストでは、例には、作成者、作成者の組織、処理経路に沿ったISP、独立した信頼評価サービス、およびメーリングリストオペレーターが含まれます。
Original Text:
元のテキスト：
(None. New section. Additional text.)
（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
A label that refers to an identity.
IDを参照するラベル。
Original Text:
元のテキスト：
(None. New section. Additional text.)
（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming responsibility for introduction of a message into the mail stream. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.
DKIMの必須ペイロード出力であり、メールストリームへのメッセージの導入の責任を主張するIDを参照する単一のドメイン名。 DKIM処理の場合、名前には基本的なドメイン名のセマンティクスしかありません。考えられる所有者固有のセマンティクスは、DKIMの範囲外です。セクション3.5で指定されています。
Original Text:
元のテキスト：
(None. New section. Additional text.)
（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional <Local-part>. The domain name is the same as that used for the SDID or is a sub-domain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.
署名ドメイン識別子（SDID）が担当したエージェントまたはユーザーを表す単一の識別子。 AUIDはドメイン名とオプションの<Local-part>で構成されます。ドメイン名は、SDIDに使用されるものと同じか、そのサブドメインです。 DKIM処理の場合、AUIDのドメイン名部分には、基本的なドメイン名のセマンティクスしかありません。考えられる所有者固有のセマンティクスは、DKIMの範囲外です。セクション3.5で指定されています。
Original Text:
元のテキスト：
(None. New section. Additional text.)
（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification.
責任のある署名ドメイン識別子（SDID）であるDKIMの必須ペイロードを使用するモジュール。モジュールは、配信された識別子の評価専用です。他のDKIM（および非DKIM）値も、このモジュールおよびより一般的なメッセージ評価フィルタリングエンジンに配信できます。ただし、この追加アクティビティはDKIM署名仕様の範囲外です。
Original Text:
元のテキスト：
d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid.
d =署名エンティティのドメイン（プレーンテキスト、必須）。これは、公開鍵を照会するドメインです。このドメインは、「i =」タグ（以下で説明するように、署名ID）と同じであるか、親ドメインである必要があります。または、セクション3.8で説明されている親ドメイン署名の要件を満たす必要があります。これらの要件を満たさない署名が提示された場合、検証者は署名を無効と見なさなければなりません（MUST）。
Internationalized domain names MUST be encoded as described in [RFC3490].
国際化ドメイン名は、[RFC3490]で説明されているようにエンコードする必要があります。
ABNF:
ABNF：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain,
but excluding address-literal
Corrected Text:
修正されたテキスト：
d=
d =
Specifies the SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED). Hence, the SDID value is used to form the query for the public key. The SDID MUST correspond to a valid DNS name under which the DKIM key record is published. The conventions and semantics used by a signer to create and use a specific SDID are outside the scope of the DKIM Signing specification, as is any use of those conventions and semantics. When presented with a signature that does not meet these requirements, verifiers MUST consider the signature invalid.
メールストリームへのメッセージの導入の責任を主張するSDIDを指定します（プレーンテキスト、必須）。したがって、SDID値を使用して、公開キーのクエリが形成されます。 SDIDは、DKIMキーレコードが公開される有効なDNS名に対応している必要があります。特定のSDIDを作成して使用するために署名者が使用する規則とセマンティクスは、それらの規則とセマンティクスの使用と同様に、DKIM署名仕様の範囲外です。これらの要件を満たさない署名が提示された場合、検証者は署名を無効と見なさなければなりません（MUST）。
Internationalized domain names MUST be encoded as described in [RFC3490].
国際化ドメイン名は、[RFC3490]で説明されているようにエンコードする必要があります。
ABNF:
ABNF：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
Original Text:
元のテキスト：
i= Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag). The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as or a subdomain of the value of the "d=" tag.
i =このメッセージに署名するユーザーまたはエージェント（メーリングリストマネージャーなど）のID（dkim-quoted-printable;オプション、デフォルトは空のローカルパーツの後に「@」とドメインが続く「d =」タグから）。構文は、ローカル部分が省略される場合がある標準の電子メールアドレスです。アドレスのドメイン部分は、「d =」タグの値と同じか、そのサブドメインである必要があります。
Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function.
国際化ドメイン名は、[ToASCII]関数を使用して、[RFC3490]のセクション4に記載されている手順に従って変換する必要があります。
ABNF:
ABNF：
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional because in some cases a signer may not be able to establish a verified individual identity. In such cases, the signer may wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity.
有益な注意：「i =」タグのローカル部分はオプションです。これは、署名者が検証済みの個人のアイデンティティを確立できない場合があるためです。そのような場合、署名者は、ドメインへの署名までは進んでいますが、ドメイン内の個々のユーザー名にコミットすることはできない、または望まないことを主張したい場合があります。 IDのドメイン部分は含めるがローカル部分は含めないことで可能になります。
INFORMATIVE DISCUSSION: This document does not require the value of the "i=" tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the "i=" tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options.
有益なディスカッション：このドキュメントでは、「i =」タグの値がメッセージヘッダーフィールドのIDと一致する必要はありません。これは検証者ポリシーの問題と見なされます。 「i =」タグの値と他のヘッダーフィールドの他のIDの間の制約は、コンテンツ作成者などのロールに関連付けられた信頼のセマンティクスに基本認証を適用しようとします。信頼は広く複雑なトピックであり、信頼メカニズムは非常に独創的な攻撃の影響を受けます。 "i ="値と他のID間のバインディングの実際の有効性は十分に確立されておらず、攻撃者による転覆に対する脆弱性も確立されていません。したがって、これらのオプションの使用への依存は厳しく制限されるべきです。特に、典型的なエンドユーザーの受信者が「i =」オプションの使用が成功することによって行われる可能性がある保証にどの程度依存できるかは、まったく明確ではありません。
Corrected Text:
修正されたテキスト：
i=
i =
The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag).
SDIDが責任を負う代理人またはユーザーID（AUID）（dkim-quoted-printable;オプション、デフォルトは空のローカルパーツの後に「@」が続き、その後に「d =」タグのドメインが続く）。
The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of the value of, the "d=" tag.
構文は、ローカル部分が省略される場合がある標準の電子メールアドレスです。アドレスのドメイン部分は、「d =」タグと同じか、その値のサブドメインである必要があります。
Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function.
国際化ドメイン名は、[ToASCII]関数を使用して、[RFC3490]のセクション4に記載されている手順に従って変換する必要があります。
ABNF:
ABNF：
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
The AUID is specified as having the same syntax as an email address, but is not required to have the same semantics. Notably, the domain name is not required to be registered in the DNS -- so it might not resolve in a query -- and the Local-part MAY be drawn from a namespace that does not contain the user's mailbox. The details of the structure and semantics for the namespace are determined by the Signer. Any knowledge or use of those details by verifiers or assessors is outside the scope of the DKIM Signing specification. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.
AUIDは、メールアドレスと同じ構文を持つものとして指定されますが、同じセマンティクスを持つ必要はありません。特に、ドメイン名はDNSに登録する必要がないため、クエリで解決されない可能性があります。ローカルパーツは、ユーザーのメールボックスを含まない名前空間から取得される場合があります。名前空間の構造とセマンティクスの詳細は、署名者が決定します。検証者または評価者によるこれらの詳細の知識または使用は、DKIM署名仕様の範囲外です。署名者は、ユーザーの電子メールアドレスと同じ名前空間をAUIDに使用することを選択してもよいし、ユーザーを表す他の方法を選択してもよい（MAY）。ただし、署名者は、SDIDよりも細かい安定した識別子としてAUIDを使用するオプションを受信者に提供したい場合、同じ責任範囲内であると評価されることを意図した各メッセージに同じAUIDを使用する必要があります。
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional because, in some cases, a signer may not be able to establish a verified individual identity. In such cases, the signer might wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity.
有益な注意：場合によっては、署名者が検証済みの個人IDを確立できないことがあるため、「i =」タグのローカル部分はオプションです。このような場合、署名者は、ドメインへの署名までは進んでいますが、ドメイン内の個々のユーザー名にコミットすることはできない、または望まないことを主張したい場合があります。 IDのドメイン部分は含めるがローカル部分は含めないことで可能になります。
Original Text:
元のテキスト：
e.g., a key record for the domain example.com can be used to verify messages where the signing identity ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag may be set in the "t=" tag of the key record to constrain the validity of the record to exactly the domain of the signing identity. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the signing identity ("i=" flag) MUST be the same as that of the d= domain. If this flag is absent, the domain of the signing identity MUST be the same as, or a subdomain of, the d= domain.
たとえば、ドメインexample.comのキーレコードを使用して、署名ID（署名の「i =」タグ）がsub.example.com、さらにはsub1.sub2.example.comであるメッセージを検証できます。これが意図されていない場合にこのようなキーの機能を制限するには、キーレコードの「t =」タグに「s」フラグを設定して、レコードの有効性を署名IDのドメインに限定します。参照されるキーレコードに「t =」タグの一部として「s」フラグが含まれている場合、署名IDのドメイン（「i =」フラグ）は、d =ドメインのドメインと同じである必要があります。このフラグが存在しない場合、署名IDのドメインは、d =ドメインと同じか、そのサブドメインでなければなりません（MUST）。
Corrected Text:
修正されたテキスト：
...for example, a key record for the domain example.com can be used to verify messages where the AUID ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain. If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.
...たとえば、ドメインexample.comのキーレコードを使用して、AUID（署名の「i =」タグ）がsub.example.com、さらにはsub1.sub2.example.comであるメッセージを検証できます。 。これが意図されていないときにそのようなキーの機能を制限するために、キーレコードの「t =」タグに「s」フラグを設定して、AUIDのドメインの有効性を制約してもよい（MAY）。参照されたキーレコードに "t ="タグの一部として "s"フラグが含まれている場合、AUIDのドメイン（ "i ="フラグ）はSDID（d =）ドメインのドメインと同じである必要があります。このフラグが存在しない場合、AUIDのドメインはSDIDと同じであるか、またはそのサブドメインである必要があります。
Original Text: (None. New section. Additional text.)
元のテキスト：（なし。新しいセクション。追加のテキスト。）
Corrected Text:
修正されたテキスト：
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).
DKIMの主なタスクは、署名者から受信者側のIDアセッサに、責任のあるIDを参照する単一の署名ドメインID（SDID）を通信することです。 DKIMはオプションで、単一の担当エージェントまたはユーザー識別子（AUID）を提供する場合があります。
Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name. Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. That is, within its role as a DKIM identifier, additional semantics cannot be assumed by an Identity Assessor.
したがって、受信側のIDアセッサへのDKIMの必須出力は単一のドメイン名です。 DKIM出力としての使用の範囲内で、名前には基本的なドメイン名のセマンティクスしかありません。考えられる所有者固有のセマンティクスは、DKIMの範囲外です。つまり、DKIM識別子としての役割内では、IDアセッサは追加のセマンティクスを想定できません。
A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.
受信側のDKIMベリファイアは、署名ドメイン識別子（d =）を消費IDアセッサモジュールに通信しなければならず、存在する場合はエージェントまたはユーザー識別子（i =）を通信してもよい（MAY）。
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. Hence, it is relegated to a higher-level service, such as a delivery handling filter that integrates a variety of inputs and performs heuristic analysis of them.
受信者がいずれかの識別子の構造化セマンティクスを直感しようとする限り、これはDKIMの仕様とセマンティクスの範囲外のヒューリスティック関数です。したがって、さまざまな入力を統合し、それらのヒューリスティック分析を実行する配信処理フィルターなど、より高レベルのサービスに追いやられます。
INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identifier in any other message header field. This requirement is, instead, an assessor policy issue. The purpose of such a linkage would be to authenticate the value in that other header field. This, in turn, is the basis for applying a trust assessment based on the identifier value. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence, reliance on the use of such bindings should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.
有益なディスカッション：このドキュメントでは、SDIDまたはAUIDの値が他のメッセージヘッダーフィールドの識別子と一致する必要はありません。代わりに、この要件は評価者のポリシーの問題です。このようなリンケージの目的は、他のヘッダーフィールドの値を認証することです。これは、識別子の値に基づいて信頼評価を適用するための基礎となります。信頼は広く複雑なトピックであり、信頼メカニズムは非常に独創的な攻撃の影響を受けます。 SDIDまたはAUIDと他のIDの間の最も基本的なバインディング以外の実際の有効性は十分に確立されておらず、攻撃者による転覆に対する脆弱性もありません。したがって、そのようなバインディングの使用への依存は厳しく制限されるべきです。特に、一般的なエンドユーザーの受信者が、SDIDまたはAUIDを正常に使用することによって行われる保証にどの程度依存できるかは、まったく明確ではありません。
Original Text:
元のテキスト：
It is beyond the scope of this specification to describe what actions a verifier system should make, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation.
検証システムが行うべきアクションを説明することはこの仕様の範囲を超えていますが、認証された電子メールは、認証されていない電子メールではできない受信システムに機会を提供します。具体的には、認証された電子メールは予測可能な識別子を作成し、それによって信頼や評判などの他の決定を確実に管理できます。逆に、認証されていない電子メールには、信頼と評判を割り当てるために使用できる信頼できる識別子がありません。
Corrected Text:
修正されたテキスト：
It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation.
Identity Assessorが実行できるアクションを説明することはこの仕様の範囲を超えていますが、検証済みのSDIDを含むメールは、認証されていない電子メールではできない機会をIdentity Assessorに提供します。具体的には、認証された電子メールは予測可能な識別子を作成し、それによって信頼や評判などの他の決定を確実に管理できます。
Original Text:
元のテキスト：
Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/ whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader.
署名が検証されたら、その情報を上位レベルのシステム（明示的な許可/ホワイトリストやレピュテーションシステムなど）および/またはエンドユーザーに伝達する必要があります。メッセージがFrom：ヘッダーフィールドのアドレス以外のアドレスに代わって署名されている場合、メールシステムは実際の署名IDが読者に明確であることを確認するために苦労する必要があります。
Corrected Text:
修正されたテキスト：
Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.
署名が検証されたら、その情報をIDアセッサ（明示的な許可/ホワイトリストやレピュテーションシステムなど）やエンドユーザーに伝達する必要があります。 SDIDがFrom：ヘッダーフィールドのアドレスと同じでない場合、メールシステムは実際のSDIDが読者に明確であることを確認するために苦労する必要があります。
Original Text:
元のテキスト：
The tendency is to have the MUA highlight the address associated with this signing identity in some way, in an attempt to show the user the address from which the mail was sent.
メールの送信元のアドレスをユーザーに表示するために、MUAがこの署名IDに関連付けられたアドレスを何らかの方法で強調表示する傾向があります。
Corrected Text:
修正されたテキスト：
The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message.
MUAがSDIDを強調表示する傾向があり、メッセージの責任を主張しているIDをユーザーに表示しようとします。
This Update clarifies core details about DKIM's payload. As such, it affects interoperability, semantic characterization, and the expectations for the identifiers carried with a DKIM signature. Clarification of these details is likely to limit misinterpretation of DKIM's semantics. Since DKIM is fundamentally a security protocol, this should improve its security characteristics.
このアップデートは、DKIMのペイロードに関するコアの詳細を明確にします。そのため、相互運用性、セマンティックの特性、およびDKIM署名とともに保持される識別子の期待に影響を与えます。これらの詳細の明確化は、DKIMのセマンティクスの誤解を制限する可能性があります。 DKIMは基本的にセキュリティプロトコルであるため、これによりセキュリティ特性が向上するはずです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、2003年3月。
[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 Identified Mail（DKIM）Signatures」、RFC 4871、2007年5月。
This appendix contains the full set of corrected ABNF fragments defined in this document.
この付録には、このドキュメントで定義されている修正済みABNFフラグメントの完全なセットが含まれています。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
以下の条件が満たされている場合に限り、変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用が許可されます。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布では、上記の著作権表示、この条件のリスト、および次の免責事項を保持する必要があります。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式で再配布する場合は、上記の著作権表示、この条件のリスト、および次の免責事項を、配布物とともに提供されるドキュメントやその他の資料に複製する必要があります。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- Internet Society、IETFまたはIETF Trustの名前、または特定の寄稿者の名前は、事前の書面による事前の許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは著作権者および寄稿者によって「現状のまま」提供され、商品性および特定の目的への適合性の黙示の保証を含むがこれに限定されない明示または黙示の保証は否認されます。いかなる場合も、著作権者または寄稿者は、直接的、間接的、偶発的、特別、例示的、または派生的な損害（代替商品またはサービスの購入、使用、データ、または利益の損失を含みますが、これらに限定されません）に対して責任を負わないものとします。またはビジネスの中断）責任の理論にかかわらず、契約、厳格責任、または不法行為（過失またはその他の場合を含む）にかかわらず、このソフトウェアの使用にかかわらず、このソフトウェアの使用を問わず
This version of this MIB module is part of RFC 5672; see the RFC itself for full legal notices.
このMIBモジュールのこのバージョンはRFC 5672の一部です。完全な法的通知については、RFC自体を参照してください。
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
This document was initially formulated by an ad hoc design team, comprising: Jon Callas, D. Crocker, J. D. Falk, Michael Hammer, Tony Hansen, Murray Kucherawy, John Levine, Jeff Macdonald, Ellen Siegel, and Wietse Venema. The final version of the document was developed through vigorous discussion in the IETF DKIM working group.
このドキュメントは当初、Jon Callas、D。Crocker、J。D. Falk、Michael Hammer、Tony Hansen、Murray Kucherawy、John Levine、Jeff Macdonald、Ellen Siegel、およびWietse Venemaを含む特別な設計チームによって作成されました。ドキュメントの最終版は、IETF DKIMワーキンググループでの活発な議論を通じて開発されました。
Author's Address
著者のアドレス
D. Crocker (editor) Brandenburg InternetWorking
D.クロッカー（編集者）ブランデンブルクインターネットワーキング
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net