Page 21

　
For simplicity and maximum security, a border MTA MAY remove all instances of this header field on mail crossing into its trust boundary.  However, this may conflict with the desire to access authentication results performed by trusted external service providers.  It may also invalidate signed messages whose signatures cover external instances of this header field.  A more robust border MTA could allow a specific list of authenticating MTAs whose information should be let in, removing all others.

簡潔性と最大限のセキュリティを得るため、境界MTAは自身の信頼の境界を越えて入ってくるメールに含まれる本ヘッダフィールドをすべて削除してもよい(MAY)。しかし、この処理は、信頼される外部のサービスプロバイダによって行われた認証結果を参照したいという要望と矛盾するかもしれない。また、本ヘッダフィールドを利用している署名付きメッセージのうち、署名が外部で追加されたものを無効化してもよい。さらに堅牢な境界MTAの場合は、認証を行うMTAのうち情報を受け入れるべきMTAの一覧を用意して、それ以外はすべて削除することも可能だろう。

As stated in Section 1.2, a formal definition of “trust boundary” is deliberately not made here.  It is entirely possible that a border MTA for example.com might explicitly trust authentication results asserted by upstream host example.net even though they exist in completely disjoint administrative boundaries.  In that case, the border MTA MAY elect not to delete those results; moreover, the upstream host doing some authentication work could apply a signing technology such as [DKIM] on its own results to assure downstream hosts of their authenticity.  An example of this is provided in Appendix B.

1.2節で説明したように、ここでは「信頼の境界」の正式な定義を意図的に行っていない。example.comの上流ホストexample.netが全然関連のない管理境界内にあるとしても、example.netが主張する認証結果をexample.comの境界MTAが明示的に信頼するようなこともまったく可能である。その場合、境界MTAはそれらの結果を削除しないという選択をしてもよい(MAY)。さらに、何らかの認証処理を行う上流ホストは、下流ホストに自らの信頼性を主張するために自らの認証結果について[DKIM]などの署名技術を適用することもできる。付録Bでこの一例を紹介している。

Similarly, in the case of messages signed using [DKIM] or other message signing methods that sign header fields, this may invalidate one or more signatures on the message if they covered the header field to be removed at the time of signing.  This behavior can be desirable since there’s little value in validating the signature on a message with forged headers.  However, signing agents MAY therefore elect to omit these header fields from signing to avoid this situation.

同様に、[DKIM]その他のヘッダフィールドに署名するメッセージ署名方式を使って署名したメッセージの場合、もしそのメッセージの署名がこのヘッダフィールド削除規則によって削除されてしまうヘッダフィールドを署名時点で利用していたら、この規則を適用することで1つ以上の署名が無効化されてしまうかもしれない。偽ヘッダのついたメッセージ上の署名を有効化しても価値がないので、この挙動が望ましいこともあるだろう。しかし、署名を行うエージェントはそれゆえに、このような状況を避けるため署名の対象からこれらのヘッダフィールドを除外することを選択してもよい(MAY)。

An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support.  However, an MTA MUST remove such a header if the [SMTP] connection relaying the message is not from a trusted internal MTA.

MTAは、自分が取り扱っていない版を(明示的または暗黙的に)採用している本ヘッダフィールドを削除すべきである(SHOULD)。しかし、メッセージを中継する[SMTP]接続が信頼される内部MTAからのものでない場合、MTAはこのようなヘッダを削除しなければならない(MUST)。

[Page 21]