Network Working Group K. Murchison
Request for Comments: 3598 Oceana Matrix Ltd.
Category: Standards Track September 2003
Network Working Group K. Murchison
Request for Comments: 3598 Oceana Matrix Ltd.
Category: Standards Track September 2003
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 mail filtering language that allows users to compare against the user and detail parts of an address.
在允许“子地址”或“详细地址”的电子邮件系统上（例如，“ken+sieve@example.org例如，有时需要与地址的这些子部分进行比较。本文档定义了对Sieve邮件过滤语言的扩展，允许用户与地址的用户和细节部分进行比较。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 2
3. Subaddress Comparisons. . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References. . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Intellectual Property Statement . . . . . . . . . . . . . . . 5
9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 5
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 6
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 2
3. Subaddress Comparisons. . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References. . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. Intellectual Property Statement . . . . . . . . . . . . . . . 5
9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 5
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 6
Subaddressing is the practice of appending some "detail" information to the local-part of an [IMAIL] address to indicate that the message should be delivered to the mailbox specified by the "detail" information. The "detail" information is prefixed with a special "separator character" (typically "+") which forms the boundary between the "user" (original local-part) and the "detail" sub-parts of the address, much like the "@" character forms the boundary between the local-part and domain.
子地址是在[IMAIL]地址的本地部分附加一些“详细信息”的做法，以指示邮件应发送到“详细信息”信息指定的邮箱。“详细信息”的前缀是一个特殊的“分隔符”（通常为“+”），它构成“用户”（原始本地部分）和地址的“详细信息”子部分之间的边界，就像“@”字符构成本地部分和域之间的边界一样。
Typical uses of subaddressing might be:
子地址的典型用途可能是：
- A message addressed to "ken+sieve@example.org" is delivered into a mailbox called "sieve" belonging to the user "ken".
- 一封写给“肯”的信+sieve@example.org“发送到一个名为“sieve”的邮箱中，该邮箱属于用户“ken”。
- A message addressed to "5551212#123@example.org" is delivered to the voice mailbox number "123" at phone number "5551212".
- 致“5551212”的信息#123@example.org传送至电话号码“5551212”处的语音信箱号码“123”。
This document describes an extension to the Sieve language defined by [SIEVE] for comparing against the "user" and "detail" sub-parts of an address.
本文档描述了[Sieve]定义的Sieve语言的扩展，用于与地址的“用户”和“详细信息”子部分进行比较。
Conventions for notations are as in [SIEVE] section 1.1, including use of [KEYWORDS].
符号惯例如[SIFE]第1.1节所述，包括使用[关键词]。
The capability string associated with the extension defined in this document is "subaddress".
与本文档中定义的扩展相关联的功能字符串是“子地址”。
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.
注意：在大多数情况下，信封“收件人”地址是检查子地址信息的首选地址，因为需要根据邮件的地址对邮件进行排序，以便到达特定的收件人。毕竟，信封地址是给定用户的给定筛选脚本处理给定消息的原因。当涉及邮件列表、别名和“虚拟域”时尤其如此，因为信封可能是特定收件人详细信息的唯一来源。
The ":user" argument specifies that sub-part of the local-part which lies to the left of the separator character (e.g., "ken" in "ken+sieve@example.org"). If no separator character exists, then ":user" specifies the entire left-side of the address (equivalent to ":localpart").
“：user”参数指定位于分隔符左侧的本地部分的子部分（例如，“ken”中的“ken”）+sieve@example.org"). 如果不存在分隔符，则“：user”指定地址的整个左侧（相当于“：localpart”）。
The ":detail" argument specifies that sub-part of the local-part which lies to the right of the separator character (e.g., "sieve" in "ken+sieve@example.org"). If no separator character exists, the test evaluates to false. If nothing lies to the right of the separator character, then ":detail" ":is" the null key (""). Otherwise, the ":detail" sub-part contains the null key.
“：detail”参数指定位于分隔符右侧的局部部分的子部分（例如，“ken”中的“sieve”）+sieve@example.org"). 如果不存在分隔符，则测试的计算结果为false。如果分隔符右侧没有任何内容，则“：detail”“：是”空键（“”）。否则，“：detail”子部分包含空键。
Implementations MUST make sure that the separator character matches that which is used and/or allowed by the encompassing mail system, otherwise unexpected results might occur. Implementations SHOULD allow the separator character to be configurable so that they may be used with a variety of mail systems. Note that the mechanisms used to define and/or query the separator character 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 [SIEVE]. For convenience, the "ADDRESS-PART" syntax element defined in [SIEVE] is augmented here as follows:
“：user”和“：detail”地址部分受与[SIEVE]中定义的标准地址部分相同的规则和限制。为方便起见，[SIEVE]中定义的“ADDRESS-PART”语法元素在此处扩充如下：
ADDRESS-PART =/ ":user" / ":detail"
ADDRESS-PART =/ ":user" / ":detail"
A diagram showing the ADDRESS-PARTs of a email address utilizing a separator character of '+' is shown below:
下图显示了使用“+”分隔符的电子邮件地址的地址部分：
:user "+" :detail "@" :domain
`-----------------'
:local-part
:user "+" :detail "@" :domain
`-----------------'
:local-part
Example:
例子：
require "subaddress";
需要“子地址”；
# 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";
}
# If a message is not to me (ignoring +detail), junk it.
if not allof (address :user ["to", "cc", "bcc"] "ken",
address :domain ["to", "cc", "bcc"] "example.org") {
discard;
# If a message is not to me (ignoring +detail), junk it.
if not allof (address :user ["to", "cc", "bcc"] "ken",
address :domain ["to", "cc", "bcc"] "example.org") {
discard;
}
}
# Redirect all mail sent to +foo.
if envelope :detail ["to", "cc", "bcc"] "foo" {
redirect "ken@example.edu";
}
# Redirect all mail sent to +foo.
if envelope :detail ["to", "cc", "bcc"] "foo" {
redirect "ken@example.edu";
}
Security considerations are discussed in [SIEVE]. It is believed that this extension does not introduce any additional security concerns.
[SIFE]中讨论了安全注意事项。据信，这一扩展不会带来任何额外的安全问题。
The following template specifies the IANA registration of the Sieve extension specified in this document:
以下模板规定了本文件中规定的筛网扩展的IANA注册：
To: iana@iana.org Subject: Registration of new Sieve extension
致：iana@iana.org主题：新筛网扩展的注册
Capability name: subaddress Capability keyword: subaddress Capability arguments: N/A Standards Track/RFC 3598 Person and email address to contact for further information:
功能名称：子地址功能关键字：子地址功能参数：N/A Standards Track/RFC 3598联系人和电子邮件地址以获取更多信息：
Kenneth Murchison ken@oceana.com
肯尼斯·默奇森ken@oceana.com
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.
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[IMAIL]Resnick，P.，Ed.“互联网信息格式”，RFC 2822，2001年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[SIEVE]Showalter，T.，“SIEVE:邮件过滤语言”，RFC30281001年1月。
Thanks to Tim Showalter, Alexey Melnikov, Michael Salmon, Randall Gellens, Philip Guenther and Jutta Degener for their help with this document.
感谢Tim Showalter、Alexey Melnikov、Michael Salmon、Randall Gellens、Philip Guenther和Jutta Degener对本文档的帮助。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Kenneth Murchison Oceana Matrix Ltd. 21 Princeton Place Orchard Park, NY 14127
肯尼斯·默奇森海洋矩阵有限公司，纽约州乌节公园普林斯顿广场21号，邮编14127
EMail: ken@oceana.com
EMail: ken@oceana.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。