Network Working Group K. Murchison
Request for Comments: 5233 Carnegie Mellon University
Obsoletes: 3598 January 2008
Category: Standards Track
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例如，有时需要与地址的这些子部分进行比较。本文档定义了对Sieve电子邮件过滤语言的扩展，允许用户与地址的用户和详细信息子部分进行比较。
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
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]地址的本地部分增加一些“细节”信息，以赋予该地址一些额外的含义。将“细节”信息编码到本地部分的一种常见方法是添加“分隔符序列”，如“+”，以在地址的“用户”（原始本地部分）和“细节”子部分之间形成边界，就像“@”字符形成本地部分和域之间的边界一样。
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 一封写给“肯”的信+sieve@example.org“发送到一个名为“sieve”的邮箱中，该邮箱属于用户“ken”。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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”和“：detail”，以指定将作用于地址本地部分的哪个子部分。
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").
“：user”参数指定地址本地部分的用户子部分。如果地址未编码为包含详细信息子部分，则“：user”指定地址的整个左侧（相当于“：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”参数指定地址本地部分的详细信息子部分。如果地址未编码为包含详细信息子部分，则该地址无法匹配任何指定键。如果将长度为零的字符串编码为细节子部分，则“：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.
“：user”和“：detail”地址部分受与[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”语法元素在此扩充如下：
ADDRESS-PART =/ ":user" / ":detail"
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
: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
:detail "--" :user "@" :domain
\------------------/
:local-part
Example (where the detail information follows "+"):
示例（详细信息如下“+”）：
require ["envelope", "subaddress", "fileinto"];
要求[“信封”、“子地址”、“文件插入”]；
# In this example the same user account receives mail for both
# "ken@example.com" and "postmaster@example.com"
# 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 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";
}
# 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";
}
# 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>
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.，“筛选：电子邮件过滤语言”，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 添加了说明，详细说明此扩展对外部地址（信封“发件人”或发起者标题字段）不太有用。
o Fixed envelope test example to only use "to" address.
o 固定信封测试示例仅使用“收件人”地址。
o Replaced ":user" example with one that doesn't produce unexpected behavior.
o 将“：user”示例替换为不会产生意外行为的示例。
o Refer to the zero-length string ("") as "empty" instead of "null" (per RFC 5228).
o 将零长度字符串（“”）称为“空”而不是“空”（根据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
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Phone: +1 412 268 2638
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.