Page 38

　
The second MTA, “auth-checker.example.com”, reports that it did a [SENDERID] test (which failed) and a [DKIM] test (which passed). Again, additional data about one of the tests is provided as a comment, which the MUA may choose to render.

第2のMTAである“auth-checker.example.com”は、[SENDERID]試験（不合格）と[DKIM]試験（合格）を行ったことを報告している。ここでも、試験の一方に関する追加データがコメントとして提供されており、MUAが示すことができる。

Since different hosts did the two sets of authentication checks, the header fields cannot be consolidated in this example.

異なるホストが2群の認証検査を行ったため、この例ではヘッダフィールドを統合できない。

This example illustrates more typical transmission of mail into “example.com” from a user on a dialup connection “example.net”.  The user appears to be legitimate as he/she had a valid password allowing authentication at the border MTA using [AUTH].  The [SPF] and [SENDERID] tests failed since “example.com” has not granted “example.net” authority to relay mail on its behalf.  However, the [DKIM] test passed because the sending user had a private key matching one of “example.com”‘s published public keys and used it to sign the message.

この例では、ダイアルアップ接続“example.net”上のユーザから“example.com”へのメールのより典型的な送信を説明している。このユーザは、[AUTH]を使って境界MTAで認証できる有効なパスワードを持っている正当なユーザであるように見える。[SPF]試験と[SENDERID]試験には、“example.com”が自分へのメール中継を“example.net”に委任していないため合格しなかった。しかし、送信ユーザが“example.com”から公開された公開鍵の1つに合致する秘密鍵を持っており、その鍵をメッセージの署名に使ったため、[DKIM]試験には合格した。

[Page 38]