Page 36

　
B.4.  Service Provided, Several Authentications Done, Single MTA

A message that was relayed inbound via a single MTA that conforms to this specification and applied three different message authentication checks:

        Authentication-Results: example.com;
                  auth=pass (cram-md5) smtp.auth=sender@example.com;
                  spf=pass smtp.mailfrom=example.com
        Authentication-Results: example.com;
                  sender-id=pass header.from=example.com
        Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by mail-router.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.net
        From: sender@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

　
B.4.  サービスが提供されており、単一MTAで複数の認証が行われた

本仕様に準拠している単一のMTAを通して内部に中継され、3種類の異なったメッセージ認証検査を適用されたメッセージ：

        Authentication-Results: example.com;
                  auth=pass (cram-md5) smtp.auth=sender@example.com;
                  spf=pass smtp.mailfrom=example.com
        Authentication-Results: example.com;
                  sender-id=pass header.from=example.com
        Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
                      (dialup-1-2-3-4.example.net [192.0.2.200])
                  by mail-router.example.com (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.net
        From: sender@example.com
        Message-Id: <12345.abc@example.com>
        Subject: here's a sample

        Hello!  Goodbye!

　
Example 4: Headers reporting results from one MTA

The “Authentication-Results” header field is present, indicating the delivering MTA conforms to this specification.  Once again, the receiving DNS domain name is used as the authserv-id.  Furthermore, the sender authenticated herself/himself to the MTA via a method specified in [AUTH], and both [SPF] and [SENDERID] checks were done and passed.  The MUA could extract and relay this extra information if desired.

例4： 1つのMTAからの結果を報告しているヘッダ

“Authentication-Results”ヘッダフィールドが存在し、配送MTAが本仕様に準拠していることを示している。ここでも、受信DNSドメイン名がauthserv-idとして使われている。さらに、送信者が[AUTH]で定義されている方式を通してMTAに自分自身を認証し、[SPF]検査および[SENDERID]検査が行われて合格した。MUAは必要な場合この追加情報を抽出および中継できるだろう。

Two “Authentication-Results” header fields are not required since the same host did all of the checking.  The authenticating agent could have consolidated all the results into one header field.

同一のホストがすべての検査を行ったので、2つの“Authentication-Results”ヘッダフィールドは必要ない。認証エージェントはすべての結果を1つのヘッダフィールドに統合できた。

This example illustrates a scenario in which a remote user on a dialup connection (example.net) sends mail to a border MTA (example.com) using SMTP authentication to prove identity.  The dialup provider has been explicitly authorized to relay mail as “example.com” resulting in passes by the SPF and SenderID checks.

この例では、ダイアルアップ接続上の遠隔ユーザ（example.net）がアイデンティティを証明するためにSMTP認証を用いて境界MTA（example.com）にメールを送信する筋書きを解説している。ダイアルアッププロバイダが“example.com”としてのメール中継を明示的に委任されており、その結果メールがSPFとSenderIDによる検査に合格している。 

[Page 36]