Page 3

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の内部における署名および検証処理が、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.

本更新の焦点はDKIMの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.

本更新は、DKIMライブラリ出力に検証のYES/NO結果と”d=”値を含めることを定義する。言いかえれば、署名者による使用のためどんな識別子が公式に定義されたか、またその識別子の使用が検証されているかである。特定のライブラリについては、評価者の開発者(DKIMライブラリの利用者)が標準的な2つの情報以上を欲する可能性があるため、ライブラリ開発者の裁量によって他の情報を提供することもできる。しかし、そのライブラリがDKIMに準拠していると主張するためには、最低限上記の標準情報を利用モジュールに提供する必要がある。

This does not state what the implicit value of “i=” is, relative to “d=”.  In this context, that fact is irrelevant.

本文書は”d=”に対して値のない”i=”の示す意味を定めていない。この文脈では値のない”i=”は重要ではない。

[Page 3]