Page 17

　
Experimental method identifiers MUST only be used within ADMDs that have explicitly consented to use them.  These method identifiers and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use.  Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental method identifier.

実験的方式識別子は、それらの使用を明示的に承認したADMD内でのみ使用しなければならない(MUST)。これらの方式識別子とそれに関連するパラメータはRFCに記載されない。それゆえ、いつでも変更の対象となり、製品での使用には適していない。製品として使われるMTA、MUAまたは下流フィルタは実験的方式識別子を含むAuthentication-Resultsヘッダフィールドを無視または削除すべきである(SHOULD)。

　
3.  The “iprev” Authentication Method

This section defines an additional authentication method called “iprev”.

3.  認証方式“iprev”

本章では、“iprev”と呼ばれる追加認証方式を定義する。

In general, “iprev” is an attempt to verify that a client appears to be valid based on some DNS queries.  Upon receiving a session initiation of some kind from a client, the IP address of the client peer is queried for matching names (i.e., a number-to-name translation, also known as a “reverse lookup” or a “PTR” record query).  Once that result is acquired, a lookup of each of the names (i.e., a name-to-number translation, or an “A” or “AAAA” record query) thus retrieved is done.  The response to this second check should result in at least one mapping back to the client’s IP address.

概して、“iprev”は何らかのDNS問い合わせに基づいてクライアントが友好だと考えられることを検証する認証方式である。クライアントからの何らかの種類のセッション初期化の受信に際して、クライアント側のIPアドレスに合致する名前があるかが問い合わせられる（たとえば、アドレスから名前への変換、またの名「逆引き（reverse lookup）」または“PTR”レコード問い合わせ）。結果が取得されたら、取得された名前それぞれについての検索（たとえば、アドレスから名前への変換［「逆引き（reverse lookup）」または“PTR”レコード問い合わせとも呼ばれる］）が行われる。この第2段階の検査への応答では、クライアントIPアドレスへのマッピングが少なくとも1つ返されるべきである。

More algorithmically: if the client peer’s IP address is I, the list of names to which I maps (after a “PTR” query) is the set N, and the union of IP addresses to which each member of N maps (after corresponding “A” and “AAAA” queries) is L, then this test is successful if I is an element of L.

よりアルゴリズム的に言えば、クライアント側のIPアドレスがI、Iが（“PTR”問い合わせ後に）マッピングする名前のリストがN、Nの各エントリが（対応する“A”および“AAAA”問い合わせ後に）マッピングするIPアドレスの集合がLとすれば、IがLの要素の1つになっていればこの試験に合格したことになる。

The response to a PTR query could contain multiple names.  To prevent heavy DNS loads, agents performing these queries MUST be implemented such that the number of names evaluated by generation of corresponding A or AAAA queries is finite, though it MAY be configurable by an administrator.  As an example, Section 5.5 of [SPF] chose a limit of 10 for its implementation of this algorithm.

PTR問い合わせへの応答には複数の名前を含むことも可能である。DNSの負荷を重くしないため、これらの問い合わせを行うエージェントは、対応するAまたはAAAA問い合わせの生成によって評価を行う名前の数を限定するような形で実装されなければならない(MUST)。ただし、管理者が設定できるようにしてもよい(MAY)。例として、[SPF]の5.5節はこのアルゴリズムの実装に対して制限を10個としている。

[DNS-IP6] discusses the query formats for the IPv6 case.

IPv6の場合の問い合わせの書式については[DNS-IP6]で論じている。

A successful test using this algorithm constitutes a result of “pass” since the ADMD in which the client’s PTR claims it belongs has confirmed that claim by including corresponding data in its DNS domain.  A failure to match constitutes a “fail”.  There is no case in which a “neutral” result can be returned.  The remaining “temperror” and “permerror” cases refer, respectively, to temporary and permanent DNS query errors.

クライアントのPTRがあるADMDに属していると主張する場合、そのADMDがそのDNSドメイン内の対応するデータを含んでいればその主張が検査されるため、このアルゴリズムを使った試験に合格すると“pass”という結果が構成される。合致が失敗すると“fail”が構成される。“neutral”という結果が返される場合はない。残りの“temperror”および“permerror”という場合はそれぞれ、一時的DNS問い合わせエラーと永続的DNS問い合わせエラーを示している。

 [Page 17]