Page 40

　
The message was sent to a mailing list service provider called example.net, which is used by example.com.  There, meetings@example.net is expanded to a long list of recipients, one of that is at the Chicago office.  In this example, we will assume that the trust boundary for chicago.example.com includes the mailing list server at example.net.

メッセージは、example.comが使っているexample.netというメーリングリストサービスプロバイダに送られた。そこで、meetings@example.netは長い受信者一覧に展開される。受信者の1つはシカゴオフィスである。この例では、chicago.example.comの信頼の境界はexample.netにあるメーリングリストサーバを含んでいると仮定しよう。

The mailing list server there first authenticated the message and affixed an Authentication-Results header field indicating such using its DNS domain name for the authserv-id.  It then altered the message by affixing some footer text to the body, including some administrivia such as unsubscription instructions.  Finally, the mailing list server affixes a second [DKIM] signature and begins distribution of the message.

メーリングリストサーバではまずメッセージを認証し、authserv-idにDNSドメイン名を使っていることを示すAuthentication-Resultsヘッダフィールドを追加した。続いて本体に何らかの補足テキスト（購読停止の方法などの管理情報を含む）を追加するメッセージ変更を行った。最後に、メーリングリストサーバは第2の[DKIM]署名を追加してメッセージの配布を開始する。

The border MTA for chicago.example.com explicitly trusts results from mail-router.example.net so that header field is not removed.  It performs evaluation of both signatures and determines that the first (most recent) is a “pass” but, because of the aforementioned modifications, the second is a “fail”.  However, the first signature included the Authentication-Results header added at mail-router.example.net that validated the second signature.  Thus, indirectly, it can be determined that the authentications claimed by both signatures are indeed valid.

chicago.example.comの境界MTAはmail-router.example.netからの結果を明示的に信頼しているので、ヘッダフィールドが削除されない。境界MTAは両方の署名の評価を実行し、第1の（最近の）方を“pass”（合格）と判断するが、前述の変更のため第2の署名を“fail”（不合格）と判断する。しかし第1の署名は、第2の署名を検証したmail-router.example.netで追加されたAuthentication-Resultsヘッダを含んでいた。それゆえ間接的に、両方の署名が主張する認証は実際には有効だと判断できる。

 [Page 40]