Page 19

　
An MTA adding this header field must take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content.  One required process to do so is described in Section 5.  Further measures may be required in some environments. Some possible solutions are enumerated in Section 7.1. This memo does not mandate any specific solution to this issue as each environment has its own facilities and limitations.

本ヘッダフィールドを追加するMTAは、最終的にその内容を使用するMUAまたは下流フィルタに対して段階をふんで自らの正当性を示さなければならない。そのために必要な処理の1つを5章で説明している。環境によってはさらに対策が必要かもしれない。可能な解決策が7.1節にいくつか列挙されている。それぞれの環境には独自の設備や制約があるので、本文書はこの問題にいかなる特定の解決方法も指定しない。

For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is particularly important. Moreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend.  This allows easy detection of header fields that can be trusted.

このヘッダフィールドを追加するMTAにとって、[MAIL]の3.6節ごとに順番に（先頭に）ヘッダフィールドを追加することは特に重要である。さらに、このヘッダフィールドは、MTAがメッセージの前に付加するような他のどの追跡ヘッダフィールドよりも上に挿入すべきである(SHOULD)。これによって、信頼できるヘッダフィールドの検出を容易にできる。

End users making direct use of this header field may inadvertently trust information that has not been properly vetted.  If, for example, a basic [SPF] result were to be relayed that claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated.  Thus, an MTA adding this header field SHOULD NOT include any data that has not been authenticated by the method(s) being applied.  Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it.

本ヘッダフィールドを直接使用するエンドユーザは、十分に吟味されていない情報を不用意に信頼してしまうかもしれない。たとえば、addr-specが認証済みであると主張する基本[SPF]結果が中継される場合、そのaddr-specのlocal-partは実際には認証されていないことになる。それゆえ、このヘッダフィールドを追加するMTAは、適用されている方式で認証されていないいかなるデータも含むべきではない(SHOULD NOT)。さらに、ある情報の認証用として知られていない方式によって提示されている情報については、MUAはその情報をユーザに表示すべきではない(SHOULD NOT)。

4.1.  Header Field Position and Interpretation

In order to ensure non-ambiguous results and avoid the impact of false header fields, MUAs and downstream filters SHOULD NOT interpret this header field unless specifically instructed to do so by the user or administrator.  That is, this interpretation should not be “on by default”.  Naturally then, users or administrators should not activate such a feature unless they are certain the header field will be added by the border MTA that accepts the mail that is ultimately read by the MUA, and instances of the header field appearing to be from within the ADMD but actually added by foreign MTAs will be removed before delivery.

4.1.  ヘッダフィールドの位置と解釈

明確な結果を保証し、偽のヘッダフィールドの弊害を回避するため、ユーザまたは管理者によって解釈するように特に指示されていない限り、MUAおよび下流フィルタはこのヘッダフィールドを解釈すべきではない。つまり、この解釈を「指示のない場合は行うように設定」すべきではない。そして当然、最終的にあるMUAによって読まれるメールを受け入れる境界MTAがヘッダフィールドを追加することが確実であり、かつADMD内で追加されたように見えるが実際には外部のMTAによって追加されたヘッダフィールドは配送前に削除されることが確実でない限り、そのMUAのユーザまたは管理者はこの機能を有効化すべきではない。

Furthermore, MUAs and downstream filters SHOULD NOT interpret this header field unless the authentication identifier it bears appears to be one used within its own ADMD as configured by the user or administrator.

さらに、MUAおよび下流フィルタは本ヘッダフィールドに含まれる認証識別子がユーザまたは管理者によって設定された自身のADMD内で使われているものでない限り、本ヘッダフィールドを解釈すべきではない(SHOULD NOT)。

MUAs and downstream filters MUST ignore any result reported using a “result” not specified in the result code registry, or a “ptype” not listed in the corresponding registry for such values as defined in Section 6.  Moreover, such agents MUST ignore a result indicated for any “method” they do not specifically support.

MUAおよび下流フィルタは、結果コードレジストリで定義されていない“result”または6章で定義されている値に対応するレジストリに挙げられていない“ptype”を使っていると報告された結果はすべて無視しなければならない(MUST)。さらに、このようなエージェントは、自身が特に取り扱っていない“method”に対して示されている結果を無視しなければならない(MUST)。

　
 [Page 19]