Network Working Group K. Murchison
Request for Comments: 5233 Carnegie Mellon University
Obsoletes: 3598 January 2008
Category: Standards Track
Sieve Email Filtering: Subaddress Extension
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address.
「サブアドレス」または「アドレッシング詳細」（例えば、「ken+sieve@example.org」）を可能にする電子メールシステムでは、アドレスのこれらのサブ部分に対して比較を行うことが望ましい場合があります。この文書は、ユーザがアドレスのユーザと詳細サブ部分と比較することを可能にするふるいのメールフィルタリング言語への拡張を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Capability Identifier ...........................................2
4. Subaddress Comparisons ..........................................2
5. IANA Considerations .............................................5
6. Security Considerations .........................................5
7. Normative References ............................................5
Appendix A. Acknowledgments ........................................6
Appendix B. Changes since RFC 3598 .................................6
Subaddressing is the practice of augmenting the local-part of an [RFC2822] address with some 'detail' information in order to give some extra meaning to that address. One common way of encoding 'detail' information into the local-part is to add a 'separator character sequence', such as "+", to form a boundary between the 'user' (original local-part) and 'detail' sub-parts of the address, much like the "@" character forms the boundary between the local-part and domain.
サブアドレスは、そのアドレスにいくつかの余分な意味を与えるために、いくつかの「詳細」情報と[RFC2822]アドレスのローカル部分を補強する練習です。ローカル部分に符号「詳細」情報の一つの一般的な方法は、「ユーザ」（元のローカル部分）と「詳細」サブ間の境界を形成するために、そのような「+」と、「区切り文字列」を追加することです多くの「@」文字のようなアドレスの-partsは、ローカル部分とドメイン間の境界を形成します。
Typical uses of subaddressing might be:
サブアドレスの典型的な用途は次のようになります。
o A message addressed to "ken+sieve@example.org" is delivered into a mailbox called "sieve" belonging to the user "ken".
Oメッセージは「ken+sieve@example.org」「ふるい」ユーザー「ケン」に属すると呼ばれるメールボックスに配信されるために取り組みました。
o A message addressed to "5551212#123@example.com" is delivered to the voice mailbox number "123" at phone number "5551212".
Oメッセージは「5551212#123@example.com」電話番号「5551212」でボイスメールボックス番号「123」に配信されるために取り組みました。
This document describes an extension to the Sieve language defined by [RFC5228] for comparing against the 'user' and 'detail' sub-parts of an address.
この文書では、「ユーザ」とアドレスの「詳細」のサブ部分と比較するために[RFC5228]で定義されたSieve言語への拡張を記述しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The capability string associated with the extension defined in this document is "subaddress".
この文書で定義された拡張子に関連付けられた機能文字列は「サブアドレス」です。
Test commands that act exclusively on addresses may take the optional tagged arguments ":user" and ":detail" to specify what sub-part of the local-part of the address will be acted upon.
アドレスのローカル部分のサブ部分が作用されるかを指定するには、「詳細を」：「ユーザー」のアドレスにのみ動作するテストコマンドは、オプションのタグ付き引数を取ることがあります。
NOTE: In most cases, the envelope "to" address is the preferred address to examine for subaddress information when the desire is to sort messages based on how they were addressed so as to get to a specific recipient. The envelope address is, after all, the reason a given message is being processed by a given sieve script for a given user. This is particularly true when mailing lists, aliases, and 'virtual domains' are involved since the envelope may be the only source of detail information for the specific recipient.
注：ほとんどの場合、アドレス「に」エンベロープは、欲求が特定の受信者に到達するようにそれらが対処された方法に基づいてメッセージをソートするときにサブアドレス情報について検討するための好ましいアドレスです。エンベロープアドレスは、結局、与えられたメッセージは、特定のユーザーのために与えられたふるいスクリプトによって処理されている理由です。メーリングリスト、エイリアス、および「仮想ドメイン」が関与しているとき、エンベロープが特定の受信者のための詳細な情報の唯一の源であってもよいので、これは特にそうです。
NOTE: Because the encoding of detailed addresses are site and/or implementation specific, using the subaddress extension on foreign addresses (such as the envelope "from" address or originator header fields) may lead to inconsistent or incorrect results.
注：詳細なアドレスの符号化部位および/または実装固有であるため、（アドレスまたは発信元のヘッダフィールド「から」は、封筒など）の外来アドレスにサブアドレス拡張を使用すると、一貫性のない、または誤った結果をもたらし得ます。
The ":user" argument specifies the user sub-part of the local-part of an address. If the address is not encoded to contain a detail sub-part, then ":user" specifies the entire left side of the address (equivalent to ":localpart").
「ユーザ」引数は、アドレスのローカル部分のユーザーのサブ部分を指定します。アドレスは、その後、詳細サブ部分を含むように符号化されていない場合「：ユーザーが」アドレス（「：ローカル部分」に相当）の全体の左側を指定します。
The ":detail" argument specifies the detail sub-part of the local-part of an address. If the address is not encoded to contain a detail sub-part, then the address fails to match any of the specified keys. If a zero-length string is encoded as the detail sub-part, then ":detail" resolves to the empty value ("").
「：詳細」引数は、アドレスのローカル部分の詳細なサブ部分を指定します。アドレスが詳細サブ部分を含むように符号化されていない場合は、アドレスが指定されたキーのいずれかと一致しません。長さゼロの文字列が詳細サブ一部として符号化される場合は、「：詳細は、」空の値（「」）に解決されます。
NOTE: If the encoding method used for detailed addresses utilizes a separator character sequence, and the separator character sequence occurs more than once in the local-part, then the logic used to split the address is implementation-defined and is usually dependent on the format used by the encompassing mail system.
注：詳細なアドレスに使用される符号化方式は、区切り文字列を利用し、区切り文字列を一度ローカル部分でより多く発生した場合、アドレスを分割するために使用されるロジックは、実装定義され、通常の形式に依存しています包括的なメールシステムで使用されます。
Implementations MUST make sure that the encoding method used for detailed addresses matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur. Note that the mechanisms used to define and/or query the encoding method used by the mail system are outside the scope of this document.
実装は、詳細なアドレスのために使用される符号化方式は、そうでない場合、予期しない結果が発生する可能性があり、使用および/または包括的なメールシステムによって許可されているものと一致することを確認する必要があります。メールシステムによって使用される符号化方式を定義および/またはクエリするために使用されるメカニズムはこの文書の範囲外であることに留意されたいです。
The ":user" and ":detail" address parts are subject to the same rules and restrictions as the standard address parts defined in [RFC5228], Section 2.7.4.
「ユーザ」と「詳細」アドレス部は[RFC5228]で定義された標準的なアドレス部分、セクション2.7.4と同じ規則および制限の対象となっています。
For convenience, the "ADDRESS-PART" syntax element defined in [RFC5228], Section 2.7.4, is augmented here as follows:
次のように便宜上、[RFC5228]で定義された「ADDRESS-PART」のシンタックス要素は、セクション2.7.4は、ここに拡大されます。
ADDRESS-PART =/ ":user" / ":detail"
ADDRESS-PART = / "：ユーザー" / "：詳細"
A diagram showing the ADDRESS-PARTs of an email address where the detail information follows a separator character sequence of "+" is shown below:
詳細情報は、「+」の区切り文字列を次のメールアドレスのアドレス部分を示す図を以下に示します。
:user "+" :detail "@" :domain
\-----------------/
:local-part
A diagram showing the ADDRESS-PARTs of a email address where the detail information precedes a separator character sequence of "--" is shown below:
「 - 」詳細情報は、の区切り文字列の前にメールアドレスのアドレス部分を示す図を以下に示します。
:detail "--" :user "@" :domain
\------------------/
:local-part
Example (where the detail information follows "+"):
（詳細情報は、「+」以下）例：
require ["envelope", "subaddress", "fileinto"];
[ "封筒"、 "サブアドレス"、 "のfileinto"]が必要です。
# In this example the same user account receives mail for both # "ken@example.com" and "postmaster@example.com"
＃この例では、同じユーザーアカウントが＃「ken@example.com」と「postmaster@example.com」の両方のためにメールを受信します
# File all messages to postmaster into a single mailbox,
# ignoring the :detail part.
if envelope :user "to" "postmaster" {
fileinto "inbox.postmaster";
stop;
}
# File mailing list messages (subscribed as "ken+mta-filters"). if envelope :detail "to" "mta-filters" { fileinto "inbox.ietf-mta-filters"; }
（「県+のMTA-フィルタ」として加入）＃ファイルメーリングリストのメッセージ。封筒の場合： "inbox.ietf-MTA-フィルタ "{のfileinto"" MTA-フィルタ "を" 詳細; }
# Redirect all mail sent to "ken+foo". if envelope :detail "to" "foo" { redirect "ken@example.net"; }
＃「県+ fooという」に送信されたすべてのメールをリダイレクトします。封筒の場合：「foo「というの」詳細」ken@example.netを「{リダイレクト」。 }
The following template specifies the IANA registration of the subaddress Sieve extension specified in this document. This registration replaces that from RFC 3598:
次のテンプレートは、この文書で指定されたサブアドレスふるい拡張のIANA登録を指定します。この登録は、RFC 3598からそれを置き換えます。
To: iana@iana.org Subject: Registration of new Sieve extension
To：iana@iana.org件名：新しいふるい拡張の登録
Capability name: subaddress Description: Adds the ':user' and ':detail' address parts for use with the address and envelope tests RFC number: RFC 5233 Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名：サブアドレス説明：「：ユーザー」と追加します「：詳細」アドレスの部分をアドレスとエンベロープのテストのRFC番号で使用するために：RFC 5233連絡先アドレス：ふるいディスカッションリスト<ietf-mta-filters@imc.org>
This information has been added to the list of Sieve extensions given on http://www.iana.org/assignments/sieve-extensions.
この情報はhttp://www.iana.org/assignments/sieve-extensionsに与えられたふるい拡張子のリストに追加されました。
Security considerations are discussed in [RFC5228]. It is believed that this extension does not introduce any additional security concerns.
セキュリティの考慮事項は、[RFC5228]で議論されています。この拡張は、追加のセキュリティ上の懸念を導入しないと考えられています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]ギュンター、P.、エド、およびT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"。。、RFC 5228、2008年1月。
Appendix A. Acknowledgments
付録A.謝辞
Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Gellens, Philip Guenther, Jutta Degener, Michael Haardt, Ned Freed, Mark Mallett, and Barry Leiba for their help with this document.
この文書で彼らの助けのためのティム・ショーウォルター監督、アレクセイ・メルニコフ、マイケルサーモン、ランドールGellens、フィリップ・ギュンター、ユッタ・デッジナー、マイケルHaardt、ネッドフリード、マーク・マレット、そしてバリー・レイバに感謝します。
Appendix B. Changes since
付録B.からの変更点
o Discussion of how the user and detail information is encoded now uses generic language.
Oユーザーと詳細情報がエンコードされているかの議論は今、一般的な言語を使用しています。
o Added note detailing that this extension is most useful when used on the envelope "to" address.
Oアドレス「を」封筒に使用された場合、この拡張子が最も有用であることを詳述ノートを追加しました。
o Added note detailing that this extension isn't very useful on foreign addresses (envelope "from" or originator header fields).
Oこの拡張は、外国のアドレス（「から」エンベロープや発信元のヘッダフィールド）に非常に便利ではないことを詳述ノートを追加しました。
o Fixed envelope test example to only use "to" address.
Oアドレス「を」使用のみに封筒の試験例を修正しました。
o Replaced ":user" example with one that doesn't produce unexpected behavior.
O置き換え「：ユーザー」予期しない動作を生成しないものと例。
o Refer to the zero-length string ("") as "empty" instead of "null" (per RFC 5228).
O（RFC 5228あたり）「空「の代わりに」NULL「として長さゼロの文字列（」）」を参照してください。
o Use only RFC 2606 domains in examples.
Oの例でのみRFC 2606個のドメインを使用してください。
o Miscellaneous editorial changes.
Oその他の編集上の変更。
Author's Address
著者のアドレス
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネス・マーチソンカーネギーメロン大学5000フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213 USA
Phone: +1 412 268 2638 EMail: murch@andrew.cmu.edu
電話：+1 412 268 2638 Eメール：murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。