Page 20

　
An MUA SHOULD NOT reveal these results to end users unless the results are accompanied by, at a minimum, some associated reputation data about the authenticated origin identifiers within the message. For example, an attacker could register examp1e.com (note the digit “one”) and send signed mail to intended victims; a verifier would detect that the signature was valid and report a “pass” even though it’s clear the DNS domain name was intended to mislead.  See Section 7.2 for further discussion.

これらの結果については、最低でもメッセージ中の認証済み送信元アイデンティティについて何らかの関連評価データが添付されていない限り、MUAはエンドユーザに表示すべきではない(SHOULD NOT)。たとえば、攻撃者がexamp1e.com（数字の「1」に注意）を登録して被害者に署名付きのメールを送ることもあり得る。検証器は、その署名が有効であることを検出して、DNSドメイン名が誤読を誘っていることは明らかであるにもかかわらず“pass”と報告してしまうかもしれない。これ以上の議論については、7.2節を参照のこと。

As stated in Section 2.1, this header field SHOULD be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL], and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done.

2.1節で述べたように、このヘッダフィールドは、[MAIL]の3.6.7節で定義されている追跡ヘッダフィールドであるかのように扱うべきであり(SHOULD)、それゆえ、処理を行うMTAのチェーン中での配送においてメッセージ認証が行われた何らかの徴候が残るように、ヘッダフィールドの順序を変えてはならず(MUST NOT)、メッセージの先頭に置かなければならない(MUST)。

MUAs SHOULD ignore instances of this header field discovered within message/rfc822 [MIME] attachments.

MUAはmessage/rfc822 [MIME]添付データ内で見つかった本ヘッダフィールドを無視すべきである(SHOULD)。

Further discussion of this can be found in Section 7 below.

これについてのこれ以上の議論は、後の7章を参照のこと。

4.2.  Local Policy Enforcement

If a site’s local policy is to consider a non-recoverable failure result (e.g., “fail” for DKIM, “hardfail” for SPF) for any particular authentication method as justification to reject the message completely, the border MTA SHOULD issue an [SMTP] rejection response to the message rather than adding this header field with the failure result and allowing it to proceed toward delivery.  This is more desirable than allowing the message to reach an internal host’s MTA or spam filter, thus possibly generating a local rejection such as a [DSN] to a forged originator.

4.2.  ローカルポリシの強制

サイトのローカルポリシが、何らかの特定の認証方式に対する回復不可能な不合格という結果（たとえば、DKIMでは“fail”、SPFでは“hardfail”）をメッセージを完全に拒絶する正当な理由と考えるなら、境界MTAは不合格という結果のついた本ヘッダフィールドをメッセージに追加して配送を進めることを許すよりも、そのメッセージに対して[SMTP]拒絶応答を発行すべきである(SHOULD)。この方法は、メッセージが内部ホストのMTAやスパムフィルタまで到達するのを許して偽装発信者に対して[DNS]などのローカルの拒絶を生成するよりも望ましい。

The same MAY also be done for local policy decisions overriding the results of the authentication methods (e.g., the “policy” result codes described in Section 2.4).

ローカルポリシの決定を認証方式の結果（たとえば、2.4節で説明した結果コード“policy”）に優先させるためにも、同様の方法をとってもよい(MAY)。

Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA.  Unfortunately, this may be a common scenario.

SMTPプロトコルレベルでのこのような拒絶は、ローカルポリシがMTAではなくMUAで強制される場合には不可能である。残念ながら、こちらの方が一般的かもしれない。

　
5.  Removing the Header Field

For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims to have been added within its trust boundary and that did not come from another trusted MTA.  For example, an MTA (border or otherwise) for example.com receiving a message MUST delete any instance of this header field bearing an authentication identifier indicating the header field was added within example.com prior to adding its own header fields.  This may mean each MTA will have to be equipped with a list of internal MTAs known to be compliant (and hence trustworthy).

5.  ヘッダフィールドの削除

セキュリティ上の理由のため、本仕様に準拠するMTAは、自身の信頼の境界内で追加されたと主張する本ヘッダフィールドが見つかり、それが別の信頼されるMTAから届いたものではない場合は、すべて削除しなければならない(MUST)。たとえば、example.comのMTA（境界MTAその他のMTA）がメッセージを受信した場合、自分自身のヘッダフィールドを追加する前に、example.com内で追加されたことを示す認証識別子のついた本ヘッダフィールドがあったらそれを削除しなければならない(MUST)。これはすなわち、各MTAが、本仕様に準拠していることが分かっている（それゆえ信頼できる）内部MTAの一覧を用意していなければならないということになるだろう。

[Page 20]