[要約] RFC 7410は、Authentication-Resultsヘッダーフィールドのためのプロパティタイプレジストリに関するものであり、目的は、ヘッダーフィールドのプロパティタイプを一元管理し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7410 December 2014
Updates: 7001
Category: Standards Track
ISSN: 2070-1721
A Property Types Registry for the Authentication-Results Header Field
Authentication-Resultsヘッダーフィールドのプロパティタイプレジストリ
Abstract
概要
This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.
このドキュメントは、参加者を元の小さな固定値のセットの使用に制限するのではなく、Authentication-Resultsヘッダーフィールドにプロパティタイプのレジストリを作成して、RFC 7001を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7410.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7410で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Updated "ptype" Definition . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
[RFC7001] defines the email Authentication-Results header field that presents the results of an authentication effort in a machine-readable format. The header field creates a place to collect the output from authentication processes that are disjoint from later processes that might use the output, such as analysis, filtering, or sorting mechanisms.
[RFC7001]は、認証作業の結果を機械可読形式で表示する電子メールのAuthentication-Resultsヘッダーフィールドを定義します。ヘッダーフィールドは、分析、フィルタリング、並べ替えメカニズムなど、出力を使用する可能性のある後のプロセスから切り離された認証プロセスからの出力を収集する場所を作成します。
The specification in that document enumerated a small set of types of properties that can be reported using this mechanism. There has emerged a desire to report types of properties about a message through this mechanism. Accordingly, this document updates the specification to allow for additional property types ("ptypes") beyond the original set and creates a registry where new ones can be listed and their defining documents referenced.
そのドキュメントの仕様では、このメカニズムを使用してレポートできるプロパティの小さなセットが列挙されています。このメカニズムを通じて、メッセージに関するプロパティのタイプを報告したいという要望が出てきました。したがって、このドキュメントは仕様を更新して、元のセットを超える追加のプロパティタイプ（「ptypes」）を許可し、新しいプロパティリストとそれらの定義ドキュメントを参照できるレジストリを作成します。
Advanced Backus Naur Form (ABNF) is defined in [RFC5234].
Advanced Backus Naur Form（ABNF）は[RFC5234]で定義されています。
The ABNF in Section 2.2 of [RFC7001] is updated as follows:
[RFC7001]のセクション2.2のABNFは次のように更新されます。
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving Message Transfer Agent (MTA)
The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321].
ABNFトークン「キーワード」は、[RFC5321]のセクション4.1.2で定義されています。
Legal values of "ptype" are as defined in the IANA "Email Authentication Property Types" registry (see Section 3). The initial values are as follows, matching those defined in [RFC7001]:
「ptype」の有効な値は、IANAの「Email Authentication Property Types」レジストリで定義されているとおりです（セクション3を参照）。初期値は次のとおりであり、[RFC7001]で定義されているものと一致します。
body: Indicates information that was extracted from the body of the message. This might be an arbitrary string of bytes, a hash of a string of bytes, a Uniform Resource Identifier, or some other content of interest.
body：メッセージの本文から抽出された情報を示します。これは、任意のバイト文字列、バイト文字列のハッシュ、Uniform Resource Identifier、またはその他の関心のあるコンテンツです。
header: Indicates information that was extracted from the header of the message. This might be the value of a header field or some portion of a header field.
header：メッセージのヘッダーから抽出された情報を示します。これは、ヘッダーフィールドの値またはヘッダーフィールドの一部である可能性があります。
policy: A local policy mechanism was applied that augments or overrides the result returned by the authentication mechanism. See Section 2.3 of [RFC7001].
ポリシー：認証メカニズムによって返された結果を拡張またはオーバーライドするローカルポリシーメカニズムが適用されました。 [RFC7001]のセクション2.3をご覧ください。
smtp: Indicates information that was extracted from an SMTP command that was used to relay the message.
smtp：メッセージの中継に使用されたSMTPコマンドから抽出された情報を示します。
When a consumer of this header field encounters a "ptype" that it does not understand, it ignores the result reported with that "ptype".
このヘッダーフィールドのコンシューマーは、理解できない「ptype」を検出すると、その「ptype」で報告された結果を無視します。
IANA has created the "Email Authentication Property Types" sub-registry within the existing "Email Authentication Parameters" registry. Entries in this registry are subject to the Expert Review rules as described in [RFC5226]. Each entry in the registry requires the following values:
IANAは、既存の「Email Authentication Parameters」レジストリ内に「Email Authentication Property Types」サブレジストリを作成しました。このレジストリのエントリは、[RFC5226]で説明されているように、エキスパートレビュールールの対象となります。レジストリの各エントリには、次の値が必要です。
o The "ptype" token to be registered, which must fit within the ABNF described in Section 2.
o 登録する「ptype」トークン。セクション2で説明したABNFに適合している必要があります。
o A brief description of what sort of information this "ptype" is meant to cover.
o この「ptype」がカバーする情報の種類の簡単な説明。
o An optional reference to the defining document. This is recommended, but not required.
o 定義ドキュメントへのオプションの参照。これは推奨されますが、必須ではありません。
The initial entries in this table are as follows, taken from [RFC7001]:
このテーブルの最初のエントリは、[RFC7001]から取得した次のとおりです。
+--------+-------------+----------------------------------------+
| ptype | Definition | Description |
+--------+-------------+----------------------------------------+
| body | RFC 7001 | The property being reported was found |
| | Section 2.2 | in the body of the message. |
+--------+-------------+----------------------------------------+
| header | RFC 7001 | The property being reported was found |
| | Section 2.2 | in a header field of the message. |
+--------+-------------+----------------------------------------+
| policy | RFC 7001 | The property being reported relates to |
| | Section 2.3 | a locally defined policy. |
+--------+-------------+----------------------------------------+
| smtp | RFC 7001 | The property being reported is a |
| | Section 2.2 | parameter to an SMTP command used to |
| | | relay the message. |
+--------+-------------+----------------------------------------+
For new entries, the Designated Expert needs to assure that the description provided for the new entry adequately describes the intended use. An example would be helpful to include in the entry's defining document, if any, although entries in the "Email Authentication Methods" registry or the "Email Authentication Result Names" registry might also serve as examples of intended use.
新しいエントリの場合、指定された専門家は、新しいエントリに提供された説明が意図された用途を適切に説明していることを確認する必要があります。 「メール認証方式」レジストリーまたは「メール認証結果名」レジストリー内のエントリーも、意図された使用例として役立つ場合がありますが、エントリーの定義文書がある場合は、その例を含めると役立ちます。
It is unknown how legacy code, which expects one of a fixed set of "ptype" tokens, will handle new tokens as they begin to appear. There are typically two options: prevent delivery of the message, or ignore those portions of the field that use unknown "ptype" tokens and allow processing of the message to continue.
「ptype」トークンの固定セットの1つを期待するレガシーコードが、新しいトークンが出現し始めるときにどのように処理するかは不明です。通常、2つのオプションがあります。メッセージの配信を防止するか、不明な「ptype」トークンを使用するフィールドの部分を無視して、メッセージの処理を続行できるようにします。
The choice comes down to whether the consumer considers it a threat when there are unknown "ptypes" present. The semantics of the report are unknown; the report might be indicating the message is authentic, fraudulent, or that a test failed to complete. The report itself is not actionable because it cannot be understood, and only its presence is certain.
選択は、存在する「ptype」が不明な場合に、消費者がそれを脅威と見なすかどうかによって決まります。レポートのセマンティクスは不明です。レポートは、メッセージが本物であるか、不正であるか、テストが完了しなかったことを示している可能性があります。レポート自体は理解できないため、実行可能ではなく、その存在のみが確実です。
Generally, the advice in this situation is to ignore unknown "ptypes". It is anticipated that a new property type evaluated by earlier handling agents would also result in the filtering of messages by those agents until consumers can be updated to interpret them.
一般に、この状況でのアドバイスは、不明な「ptypes」を無視することです。以前の処理エージェントによって評価された新しいプロパティタイプも、コンシューマを更新してメッセージを解釈できるようになるまで、それらのエージェントによるメッセージのフィルタリングにつながることが予想されます。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.
[RFC7001] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7001、2013年9月、<http://www.rfc-editor.org/info/rfc7001>。
Acknowledgements
謝辞
The author wishes to acknowledge the following for their review and constructive criticism of this update: Dave Crocker, Tim Draegen, Scott Kitterman, and Franck Martin.
著者は、この更新のレビューと建設的な批評のために、Dave Crocker、Tim Draegen、Scott Kitterman、Franck Martinを認めたいと思います。
Author's Address
著者のアドレス
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States
Murray S.Kucherawiy 270 Upland Driveサンフランシスコ、CA 94127アメリカ合衆国
EMail: superuser@gmail.com