[要約] RFC 5233は、Sieveメールフィルタリングのサブアドレス拡張に関する仕様です。このRFCの目的は、メールアドレスのサブアドレス機能を利用して、メールのフィルタリングとルーティングをより柔軟に行うことです。
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」）では、これらのアドレスのサブパートと比較することが望ましい場合があります。このドキュメントでは、ユーザーがユーザーと比較し、アドレスのサブパートを詳細に比較できるようにするSIVEメールのフィルタリング言語の拡張機能を定義します。
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]アドレスのローカルパートを、そのアドレスに追加の意味を与えるために、いくつかの「詳細」情報を拡張する慣行です。「詳細」情報をローカルパートにエンコードする1つの一般的な方法は、「ユーザー」（元のローカルパート）と「ディテール」サブサブの境界を形成して、「セパレーター文字シーケンス」を追加して「セパレーター文字シーケンス」を追加することです。アドレスの一部は、「@」文字がローカルパートとドメインの境界を形成します。
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」に宛てられたメッセージは、ユーザー「Ken」に属する「Sieve」と呼ばれるメールボックスに配信されます。
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]によって定義されたふるい言語の拡張機能について説明します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
アドレスのみで行動するテストコマンドは、オプションのタグ付けされた引数「：user」と「詳細」を取得して、アドレスのローカルパートのサブパートを指定することができます。
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.
注：ほとんどの場合、エンベロープ「To」アドレスは、特定の受信者に到達するためにそれらがどのように対処されたかに基づいてメッセージを並べ替えたい場合に、サブアドレス情報を調べるための優先アドレスです。エンベロープアドレスは、結局のところ、特定のユーザーの特定のふるいスクリプトによって与えられたメッセージが処理されている理由です。これは、メーリングリスト、エイリアス、および「仮想ドメイン」が関与する場合に特に当てはまります。これは、封筒が特定の受信者の唯一の詳細情報のソースである可能性があるためです。
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").
「：ユーザー」引数は、アドレスのローカルパートのユーザーサブパートを指定します。アドレスが詳細サブパートを含むようにエンコードされていない場合、「：ユーザー」はアドレスの左側全体を指定します（「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 ("").
「：詳細」引数は、アドレスのローカルパートの詳細なサブパートを指定します。アドレスが詳細なサブパートを含むようにエンコードされていない場合、アドレスは指定されたキーのいずれでも一致しません。ゼロ長さの文字列が詳細サブパートとしてエンコードされている場合、 "：detail"は空の値（ ""）に解決します。
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]で定義されている「アドレスパート」構文要素、セクション2.7.4は、次のようにここで補強されています。
ADDRESS-PART =/ ":user" / ":detail"
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"];
["envelope"、 "subaddress"、 "fileinto"]が必要です。
# In this example the same user account receives mail for both
# "ken@example.com" and "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";
}
# Redirect all mail sent to "ken+foo".
if envelope :detail "to" "foo" {
redirect "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
宛先：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>
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC5228] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228] Guenther、P.、ed。、およびT. Showalter、ed。、「Sive：An Email Filtering Language」、RFC 5228、2008年1月。
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.
Tim Showalter、Alexey Melnikov、Michael Salmon、Randall Gellens、Philip Guenther、Jutta Degener、Michael Haardt、Ned Freed、Mark Mallett、およびBarry Leibaのおかげで、この文書を支援してくれたことに感謝します。
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 この拡張機能は、外国の住所（envelope "from"またはOriginator Headerフィールド）であまり役に立たないことを詳述したメモを追加しました。
o Fixed envelope test example to only use "to" address.
o 「To」アドレスのみを使用するためのエンベロープテストの例を修正しました。
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 ゼロ長文字列（ ""）を「null」の代わりに「空」として参照してください（RFC 5228ごと）。
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フォーブスアベニューサイエートホール285ピッツバーグ、ペンシルバニア州15213 USA
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。