Page 27

　
4.  Extensions to [IMAP], [SMTP], and [POP3] could be defined to allow an MUA or filtering agent to acquire the “authserv-id” in use within an ADMD, thus allowing it to identify which Authentication-Results header fields it can trust.

4.　[IMAP]、[SMTP]、[POP3]への拡張を定義することで、MUAまたはフィルタリングエージェントがADMD内で使われる“authserv-id”を取得できるようになり、どのAuthentication-Resultsヘッダフィールドを信頼できるかの判断を行えるかもしれない。

5.  On the presumption that internal MTAs are fully compliant with Section 3.6 of [MAIL], and the compliant internal MTAs are using their own host names or the ADMD’s DNS domain name as the “authserv-id” token, the header field proposed here should always appear above a Received: header added by a trusted MTA. This can be used as a test for header field validity.

5.　内部MTAが[MAIL]の3.6節に完全に準拠しており、自分自身のホスト名またはADMDのDNSドメイン名を“authserv-id”トークンとして使っているという前提で、本文書で提案するヘッダフィールドは必ず、信頼されるMTAが追加するReceived:ヘッダの上に置かれているべきである。これをヘッダフィールドの有効性の試験として利用できる。

Support for some of these is planned for future work.

今後の作業では上記のいずれかを取り扱う計画になっている。

In any case, a mechanism needs to exist for an MUA or filter to verify that the host that appears to have added the header field (a) actually did so, and (b) is legitimately adding that header field for this delivery.  Given the variety of messaging environments deployed today, consensus appears to be that specifying a particular mechanism for doing so is not appropriate for this memo.

どの場合でも、ヘッダフィールドを追加したように見えるホストがこの配送のために（a） 実際に追加を行ったか、（b）ヘッダフィールドが正しく追加されているかについてMUAまたはフィルタが検証するための機構が存在しなければならない。現在配備されているメッセージ処理環境の多様性を考えると、検証を行うための特定の機構を本文書で定義することは適切ではないだろうと思われる。

Mitigation of the forged header field attack can also be accomplished by moving the authentication results data into meta-data associated with the message.  In particular, an [SMTP] extension could be established which is used to communicate authentication results from the border MTA to intermediate and delivery MTAs; the latter of these could arrange to store the authentication results as meta-data retrieved and rendered along with the message by an [IMAP] client aware of a similar extension in that protocol.  The delivery MTA would be told to trust data via this extension only from MTAs it trusts, and border MTAs would not accept data via this extension from any source.  There is no vector in such an arrangement for forgery of authentication data by an outside agent.

偽ヘッダフィールド攻撃はまた、認証結果データをメッセージに関連するメタデータに移動することでも軽減できる。具体的に言えば、認証結果を境界MTAから中間および配送MTAに通信するために使われる[SMTP]拡張機能を策定できるだろう。その場合、認証結果を受け取った中間および配送MTAは、そのプロトコルの類似拡張機能を理解する[IMAP]クライアントによってメッセージと共に取得され表示されるメタデータとして、認証結果を格納することが可能だろう。配送MTAはこの拡張機能を通した信頼するMTAからの信頼データのみに対応し、境界MTAはこの拡張機能を通したいかなる送信元からのデータも受け入れないようにする。このようなやり方をとれば、外部エージェントによる認証データの偽装にはいかなる侵入路もなくなる。

7.2.  Misleading Results

Until some form of service for querying the reputation of a sending agent is widely deployed, the existence of this header field indicating a “pass” does not render the message trustworthy.  It is possible for an arriving piece of spam or other undesirable mail to pass checks by several of the methods enumerated above (e.g., a piece of spam signed using [DKIM] by the originator of the spam, which might be a spammer or a compromised system).  In particular, this issue is not resolved by forged header field removal discussed above.

7.2.  誤解を導く結果データ

送信エージェントの評価を問い合わせる何らかの形のサービスが広く配備されるまで、“pass”を示す本ヘッダフィールドがあっても、メッセージの信頼性が示されることにはならない。スパムその他の望まれないメールが届く際に、上記に挙げた方式のいくつかによる検査に合格してしまう可能性がある（たとえば、スパムの送信元（スパム送信者自身またはサイバー攻撃などのために信頼できなくなったシステム）で[DKIM]を使って署名されたスパムメール）。特に、この問題は上記で論じた偽ヘッダフィールドを削除する方法では解決されない。

 [Page 27]