Page 29

　
7.8.  Intentionally Malformed Header Fields

It is possible for an attacker to add an Authentication-Results header field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in header field parsing code.  Implementors must thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed header fields.

7.8.  意図的な不正ヘッダフィールド

攻撃者が、ヘッダフィールド分析コードの弱点を発見または悪用しようとして異常に大きいなどの不正なAuthentication-Resultsヘッダフィールドを追加する可能性がある。実装者はMTAから受信するそのようなヘッダフィールドをすべて完全に検証し、意図的または非意図的な不正ヘッダフィールドに対して堅牢でなければならない。

7.9.  Compromised Internal Hosts

An internal MUA or MTA that has been compromised could generate mail with a forged From header field and a forged Authentication-Results header field that endorses it.  Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this header field, this risk can be mitigated by arranging that internal MTAs will remove this header field if it claims to have been added by a trusted border MTA (as described above), yet the [SMTP] connection is not coming from an internal machine known to be running an authorized MTA.  However, in such a configuration, legitimate MTAs will have to add this header field when legitimate internal-only messages are generated.  This is also covered in Section 5.

7.9.  サイバー攻撃などのために信頼できなくなった内部ホスト

サイバー攻撃などのために信頼できなくなった内部MUAまたはMTAが、メール生成の際に偽のFromヘッダフィールドや、そのメールを保証する偽のAuthentication-Resultsヘッダフィールドを付ける可能性がある。サイバー攻撃などのために信頼できなくなった内部機器がある方が、このヘッダフィールドの値を検証しなければならないことよりも明らかに大きな問題ではあるけれども、このヘッダフィールドでは（上記で説明したように）信頼される境界MTAによって追加されたと主張しているが、権限のあるMTAに運用されていることが分かっている内部機器からの[SMTP]接続ではない場合、内部MTAがこのヘッダフィールドを削除するように設定することでこのリスクを軽減できる。しかし、このような設定では、正当なMTAが内部向けのメッセージを生成するときでもこのヘッダフィールドを追加しなければならない。この問題についても5章で論じている。

7.10.  Encapsulated Instances

[MIME] messages may contain attachments of type “message/rfc822”, which contain other [MAIL] messages.  Such an encapsulated message may also contain an Authentication-Results header field.  Although the processing of these is outside of the intended scope of this document (see Section 1.3), some early guidance to MUA developers is appropriate here.

7.10.  ヘッダフィールドのカプセル化

[MIME]メッセージは他の[MAIL]メッセージを含む“message/rfc822”というタイプの添付データを含むことがある。このようなカプセル化メッセージには、Authentication-Resultsヘッダフィールドが含まれることもある。これらのメッセージの処理は本文書の本来の範囲外であるが（1.3節を参照）、MUA開発者への基本的なアドバイスについてここで触れておくべきだろう。

Since MTAs are unlikely to strip Authentication-Results header fields after mailbox delivery, MUAs are advised in Section 4.1 to ignore such instances within [MIME] attachments.  Moreover, when extracting a message digest to separate mail store messages or other media, such header fields should be removed so that they will never be interpreted improperly by MUAs that might later consume them.

MTAがmailboxへの配送後にAuthentication-Resultsヘッダフィールドを削除することは稀なため、4.1節においてMUAは[MIME]添付データ内のこのようなヘッダフィールドを無視するよう推奨されている。さらに、メール格納メッセージその他のメディアを分離するためにメッセージダイジェストを抽出する際には後で抽出したデータを使用するMUAが適切に解釈できないため、このようなヘッダフィールドは削除されるべきである。

7.11.  Reverse Mapping

Although Section 3 of this memo includes explicit support for the “iprev” method, its value as an authentication mechanism is limited. Implementors of both this proposal and agents that use the data it relays are encouraged to become familiar with the issues raised by [DNSOP-REVERSE] when deciding whether or not to include support for “iprev”.

7.11.  逆引きマッピング

本文書の3章には“iprev”方式を取り扱うことが明記されているが、“iprev”方式の認証機構としての価値は限られたものである。本提案とその機構が中継するデータを使用するエージェントを実装する場合、“iprev”を取り扱うかどうかを決める際に[DNSOP-REVERSE]の提起する問題をよく知っておくことが推奨される。

[Page 29]