Page 18

　
There is some contention regarding the wisdom and reliability of this test.  For example, in some regions it can be difficult for this test ever to pass because the practice of arranging to match the forward and reverse DNS is infrequently observed.  Therefore, the actual implementation details of how a verifier performs an “iprev” test are not specified here.  The verifier MAY report a successful or failed “iprev” test at its discretion having done some kind of check of the validity of the connection’s identity using DNS.  It is incumbent upon an agent making use of the reported “iprev” result to understand what exactly that particular verifier is attempting to report.

この試験の堅実性と信頼性に関しては異論もある。たとえば、正引きDNSと逆引きDNSを合致させるような構成は実際にはあまり見られないものであり、そのような領域ではこの試験に合格することが難しいこともあり得る。それゆえ、検証器が“iprev”試験を行う方法の実際の実装の詳細はここでは定義しない。検証器は、DNSを使った接続のアイデンティティ有効性の検査を、自己の判断で“iprev”試験の合格または不合格として報告してもよい(MAY)。報告された結果コード“iprev”を利用して、ある検証器が正確に何を報告しようとしているのかを理解することは、エージェント自らの責任である。

Extensive discussion of reverse DNS mapping and its implications can be found in [DNSOP-REVERSE].  In particular, it recommends that applications avoid using this test as a means of authentication or security.  Its presence in this memo is not an endorsement, but is merely acknowledgement that the method remains common and provides the means to relay the results of that test.

逆引きDNSマッピングとその実装に関するこれ以上の議論は[DNSOP-REVERSE]で参照できる。[DNSOP-REVERSE]は特に、アプリケーションが認証やセキュリティの手段としてこの試験を使用しないよう推奨している。本文書でそれについて記載しているのはこの試験を支持しているからではなく、この方式がいまだに一般的であるため、その試験の結果を中継する手段を提供していることを単に知らせているだけである。

　
4.  Adding the Header Field to A Message

This specification makes no attempt to evaluate the relative strengths of various message authentication methods that may become available.  As such, the order of the presented authentication methods and results MUST NOT be used either to imply or infer the importance or strength of any given method over another.  Instead, the MUA or downstream filter consuming this header field must interpret the result of each method based on its own knowledge of what that method evaluates.

4.  メッセージへのヘッダフィールドの追加

本仕様では、利用可能になるかもしれない様々なメッセージ認証方式の相対的強度の評価は行わない。そのため、提示される認証方式と結果の順序を、ある方式が他の方式と比べて重要性や強度が高いことを暗示するために利用してはならない(MUST NOT)。その代わり、このヘッダフィールドを使用するMUAまたは下流フィルタは、各方式の結果をその方式が評価する対象に関する自身の知識に基づいて解釈しなければならない。

Each “method” MUST refer to an authentication method declared in the IANA registry, or an extension method as defined in Section 2.5.2, and each “result” MUST refer to a result code declared in the IANA registry, or an extension result code as defined in Section 2.4.5. See Section 6 for further information about the registered methods and result codes.

各“method”はIANAレジストリで宣言された認証方式、または2.5.2節で定義した拡張方式を参照しなければならない(MUST)。また各“result”はIANAレジストリで宣言された結果コード、または2.4.5節で定義した結果コードを参照しなければならない(MUST)。登録された方式および結果コードに関するこれ以上の情報については6章を参照のこと。

An MTA compliant with this specification MUST add this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test got applied and what the result was.  If an MTA applies more than one such test, it MUST add this header field either once per test, or once indicating all of the results.  An MTA MUST NOT add a result to an existing header field.

本仕様に準拠するMTAは、（1つ以上のメッセージ認証試験を行った後に）どのMTAまたはADMDが試験を行ったか、どの試験が適用され、結果はどうだったかをこのヘッダフィールドに追加しなければならない(MUST)。MTAが複数の試験を適用した場合は、試験の回数分ヘッダフィールドを追加するか、結果をまとめて示すヘッダフィールドを1回追加しなければならない(MUST)。MTAは結果を既存のヘッダフィールドに追加してはならない(MUST NOT)。

An MTA MAY add this header field containing only the authentication identifier portion to indicate explicitly that no message authentication schemes were applied prior to delivery of this message.

MTAは、このメッセージの配送前にメッセージ認証機構が適用されなかったことを明示的に示すために認証識別子の部分だけを含んでいる本ヘッダフィールドを追加してもよい(MAY)。

　
 [Page 18]