Page 11

　
The authentication identifier field provides a unique identifier that refers to the authenticating service within a given ADMD.  The uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and must pertain to exactly that one ADMD.  This identifier is intended to be machine-readable and not necessarily meaningful to users.  MUAs or downstream filters SHOULD use this identifier to determine whether or not the data contained in an Authentication-Results header field should be used.

認証識別子フィールドは、あるADMD内の認証サービスを参照する一意の識別子を提供する。識別子の一意性は、その識別子を生成するADMDによって保証されなければならない(MUST)。また、その単一のADMDに正確に結びついていなければならない。この識別子は機械可読用であり、必ずしもユーザに意味が分かる必要はない。MUAまたは下流フィルタはこの識別子を使用して、Authentication-Resultsヘッダフィールドに含まれるデータを使うべきかどうかを決定すべきである(SHOULD)。

For simplicity and scalability, the authentication identifier SHOULD be a common token used throughout the ADMD, such as the DNS domain name used by or within that ADMD.

簡潔性と拡張性を得るため、認証識別子は、そのADMDによって、またはそのADMD内で使われるDNSドメイン名などの、そのADMDを通して使われる一般トークンであるべきである(SHOULD)。

For tracing and debugging purposes, the authentication identifier MAY instead be the hostname of the MTA performing the authentication check whose result is being reported.  This is also useful for another purpose, as described in Section 4.  Moreover, some implementations have considered appending a delimiter such as “/” and following it with useful transport tracing data such as the [SMTP] queue ID or a timestamp.

追跡やデバッグといった目的のためには、認証識別子の代わりに、結果が報告されている認証検査を行ったMTAのホスト名を使用してもよい(MAY)。このやり方は、4章で説明するように別の目的にも利用できる。さらに、実装によっては“/”などの区切り文字を追加して、それに続けて[SMTP]待ち行列IDやタイムスタンプなどの便利な伝送追跡データを使っているものもある。

It should be noted, however, that using a local, relative identifier like a single hostname, rather than a hierarchical and globally unique ADMD identifier like a DNS domain name, makes configuration more difficult for large sites.  The hierarchical identifier permits aggregating related, trusted systems together under a single, parent identifier, which in turn permits assessing the trust relationship with a single reference.  The alternative is a flat namespace requiring individually listing each trusted system.  Since consumers must use the identifier to determine whether to use the contents of the header field:

しかし、DNSドメイン名のような階層化されたグローバルに一意のADMD識別子の代わりに単一のホスト名などのローカルで相対的な識別子を使うと、大規模サイトでは設定の難しさが増してしまうことには注意すべきである。階層化された識別子を使うことで、関連し信頼されているシステムを単一の親識別子にまとめて集約できるので、信頼の関係を単一の参照先との間で評価できるようになる。階層化されていない識別子を使う方法では平面的な名前空間となり、信頼されているシステムそれぞれを個別に列挙する必要がある。使用者は識別子を使ってヘッダフィールドの内容を使用すべきかを判断しなければならないので、以下のような論点が生じる。 

・ Changes to the identifier impose a large, centralizedadministrative burden.

・ 識別子の変更には大規模で中央集約的な管理コストがかかる。

・ Ongoing administrative changes require constantly updating this centralized table, making it difficult to ensure that an MUA or downstream filter will have access to accurate information for assessing the usability of the header field’s content.  In particular, consumers of the header field will need to know not only the current identifier(s) in use, but previous ones as well to account for delivery latency or later re-assessment of the header field’s contents.

・ 管理的変更を続ける限りこの中央集約化された一覧を常に更新する必要があり、MUAや下流フィルタがヘッダフィールドの内容の有用性を評価するための正確な情報を入手できると保証することが難しくなる。具体的に言えば、ヘッダフィールドの使用者は、配送遅延やヘッダフィールドの内容の後での再評価に対応するため、現在使用中の識別子だけでなく以前の識別子も知る必要があるだろう。

Examples of valid authentication identifiers are “example.com”, “mail.example.org”, “ms1.newyork.example.com”, and “example-auth”.

有効な認証識別子の例としては、“example.com”“mail.example.org”“ms1.newyork.example.com”“example-auth”などがある。

[Page 11]