Page 2

　
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

　
目次

1.  はじめに　　2
2.  RFC 4871、本文書の概要　　4
3.  RFC 4871、1章、はじめに　　4
4.  RFC 4871、2.7節、アイデンティティ　　4
5.  RFC 4871、2.8節、アイデンティティ　　5
6.  RFC 4871、2.9章、署名ドメイン識別子(SDID)　　5
7.  RFC 4871、2.10節、エージェントまたはユーザ識別子(AUID)　　5
8.  RFC 4871、2.11節、アイデンティティ評価者　　6
9.  RFC 4871、3.5節、DKIM-Signatureヘッダフィールド　　6
10. RFC 4871、3.5節、DKIM-Signatureヘッダフィールド　　7
11. RFC 4871、3.8節、親ドメインによる署名　　9
12. RFC 4871、3.9節、SDIDとAUIDの関係　　10
13. RFC 4871、6.3節、解釈の結果/適用に関するローカルポリシ　　11
14. RFC 4871、6.3節、解釈の結果/適用に関するローカルポリシ　　11
15. RFC 4871、付録D、MUAに関する考察　　12
16. セキュリティに関する考察　　12
17. インターネット標準にかかわる参照資料　　12
付録A.  ABNFフラグメント　　13
付録B.  謝辞　　14
　

1.  Introduction

About the purpose for DKIM, [RFC4871] states:

The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity…

1. はじめに

DKIMの目的に関して[RFC4871]は以下のように述べている：

本フレームワークの最終目標は、署名を行うドメインがメッセージに対する責任を主張できるようにしてメッセージ署名者のアイデンティティを保護することである……

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の目的を単純に説明すれば、受信側判定モジュールに識別子を伝えることとなる。この識別子は責任を持つアイデンティティを参照するドメイン名の形をとる。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.

しかし、RFC4871仕様はDKIM-Signature: ヘッダフィールドで伝えられる2種類の潜在的に異なる識別子、d=とi=を定義している。このどちらかが検証済みペイロードを利用する受信側処理モジュールに届けられる可能性がある。DKIM仕様における定義では、どちらの識別子が利用するモジュールに配送されるべきものであり、どちらが内部的な存在で単に到着ペイロード配送を支援するためのものであるのかについて明確になっていない。

　
 [Page 2]