Network Working Group J. Degener
Request for Comments: 5173 P. Guenther
Updates: 5229 Sendmail, Inc.
Category: Standards Track April 2008
Network Working Group J. Degener
Request for Comments: 5173 P. Guenther
Updates: 5229 Sendmail, Inc.
Category: Standards Track April 2008
Sieve Email Filtering: Body 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
摘要
This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message.
本文档为“筛选”电子邮件过滤语言定义了一个新命令，用于测试电子邮件正文中是否出现一个或多个字符串。
The "body" test checks for the occurrence of one or more strings in the body of an email message. Such a test was initially discussed for the [SIEVE] base document, but was subsequently removed because it was thought to be too costly to implement.
“body”测试检查电子邮件正文中是否出现一个或多个字符串。这种测试最初是针对[SIEVE]基础文档讨论的，但后来被删除，因为它被认为实施起来成本太高。
Nevertheless, several server vendors have implemented some form of the "body" test.
然而，一些服务器供应商已经实现了某种形式的“body”测试。
This document reintroduces the "body" test as an extension, and specifies its syntax and semantics.
本文档将“body”测试作为扩展重新引入，并指定其语法和语义。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Conventions for notations are as in [SIEVE] Section 1.1, including the use of the "Usage:" label for the definition of text and tagged argument syntax.
注释惯例如[SIEVE]第1.1节所述，包括使用“用法：”标签定义文本和标记参数语法。
The rules for interpreting the grammar are defined in [SIEVE] and inherited by this specification. In particular, readers of this document are reminded that according to [SIEVE] Sections 2.6.2 and 2.6.3, optional arguments such as COMPARATOR and MATCH-TYPE can appear in any order.
解释语法的规则在[SIEVE]中定义，并由本规范继承。特别提醒本文件的读者，根据[SIFE]第2.6.2节和第2.6.3节，比较器和匹配类型等可选参数可以以任何顺序出现。
The capability string associated with the extension defined in this document is "body".
与本文档中定义的扩展相关联的功能字符串为“body”。
Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
<key-list: string-list>
Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
<key-list: string-list>
The body test matches content in the body of an email message, that is, anything following the first empty line after the header. (The empty line itself, if present, is not considered to be part of the body.)
正文测试匹配电子邮件正文中的内容，即标题后第一个空行后面的任何内容。（空行本身（如果存在）不被视为主体的一部分。）
The COMPARATOR and MATCH-TYPE keyword parameters are defined in [SIEVE]. As specified in Sections 2.7.1 and 2.7.3 of [SIEVE], the default COMPARATOR is "i;ascii-casemap" and the default MATCH-TYPE is ":is".
比较器和匹配类型关键字参数在[SIEVE]中定义。如[SIVE]第2.7.1节和第2.7.3节所述，默认比较器为“i；ascii casemap”，默认匹配类型为“：is”。
The BODY-TRANSFORM is a keyword parameter that governs how a set of strings to be matched against are extracted from the body of the message. If a message consists of a header only, not followed by an empty line, then that set is empty and all "body" tests return false, including those that test for an empty string. (This is similar to how the "header" test always fails when the named header fields aren't present.) Otherwise, the transform must be followed as defined below in Section 5.
BODY-TRANSFORM是一个关键字参数，用于控制如何从消息体中提取一组要匹配的字符串。如果消息只包含一个标题，后面没有空行，那么该集合为空，所有“body”测试返回false，包括测试空字符串的测试。（这类似于当命名的头字段不存在时，“头”测试总是失败的方式。）否则，必须按照下面第5节中的定义进行转换。
Note that the transformations defined here do *not* match against each line of the message independently, so the strings will usually contain CRLFs. How these can be matched is governed by the comparator and match-type. For example, with the default comparator of "i;ascii-casemap", they can be included literally in the key strings, or be matched with the "*" or "?" wildcards of the :matches match-type, or be skipped with :contains.
请注意，此处定义的转换*不*独立地与消息的每一行匹配，因此字符串通常包含CRLF。如何匹配这些参数取决于比较器和匹配类型。例如，使用默认的比较器“i；ascii casemap”，可以将它们逐字包含在键字符串中，或者与“*”或“？”通配符匹配：matches match类型，或者使用：contains跳过。
Prior to matching content in a message body, "transformations" can be applied that filter and decode certain parts of the body. These transformations are selected by a "BODY-TRANSFORM" keyword parameter.
在匹配消息正文中的内容之前，可以应用“转换”，对正文的某些部分进行过滤和解码。这些转换由“BODY-TRANSFORM”关键字参数选择。
Usage: ":raw"
/ ":content" <content-types: string-list>
/ ":text"
Usage: ":raw"
/ ":content" <content-types: string-list>
/ ":text"
The default transformation is :text.
默认转换为：text。
The ":raw" transform matches against the entire undecoded body of a message as a single item.
“：raw”转换将消息的整个未编码正文作为单个项进行匹配。
If the specified body-transform is ":raw", the [MIME] structure of the body is irrelevant. The implementation MUST NOT remove any transfer encoding from the message, MUST NOT refuse to filter messages with syntactic errors (unless the environment it is part of rejects them outright), and MUST treat multipart boundaries or the MIME headers of enclosed body parts as part of the content being matched against, instead of MIME structures to interpret.
如果指定的主体转换为“：raw”，则主体的[MIME]结构不相关。实现不得从消息中删除任何传输编码，不得拒绝过滤有语法错误的消息（除非它所属的环境完全拒绝），并且必须将多部分边界或封闭正文部分的MIME头视为匹配内容的一部分，而不是解释MIME结构。
Example:
例子：
require "body";
需要“身体”；
# This will match a message containing the literal text # "MAKE MONEY FAST" in body parts (ignoring any # content-transfer-encodings) or MIME headers other than # the outermost RFC 2822 header.
#这将匹配正文部分中包含文字文本#“快速赚钱”（忽略任何#内容传输编码）或MIME头（最外层的RFC 2822头除外）的消息。
if body :raw :contains "MAKE MONEY FAST" {
discard;
}
if body :raw :contains "MAKE MONEY FAST" {
discard;
}
If the body transform is ":content", the MIME parts that have the specified content types are matched against independently.
如果主体转换为“：content”，则具有指定内容类型的MIME部分将独立匹配。
If an individual content type begins or ends with a '/' (slash) or contains multiple slashes, then it matches no content types. Otherwise, if it contains a slash, then it specifies a full <type>/<subtype> pair, and matches only that specific content type. If it is the empty string, all MIME content types are matched. Otherwise, it specifies a <type> only, and any subtype of that type matches it.
如果单个内容类型以“/”开头或结尾（斜杠），或包含多个斜杠，则它不匹配任何内容类型。否则，如果它包含斜杠，则它指定一个完整的<type>/<subtype>对，并且只匹配该特定的内容类型。如果是空字符串，则匹配所有MIME内容类型。否则，它只指定一个<type>，并且该类型的任何子类型都与之匹配。
The search for MIME parts matching the :content specification is recursive and automatically descends into multipart and message/rfc822 MIME parts. All MIME parts with matching types are searched for the key strings. The test returns true if any combination of a searched MIME part and key-list argument match.
对匹配：content规范的MIME部分的搜索是递归的，并自动下降到multipart和message/rfc822 MIME部分。将搜索所有具有匹配类型的MIME部件以查找键字符串。如果搜索到的MIME部分和键列表参数的任何组合匹配，则测试返回true。
If the :content specification matches a multipart MIME part, only the prologue and epilogue sections of the part will be searched for the key strings, treating the entire prologue and the entire epilogue as separate strings; the contents of nested parts are only searched if their respective types match the :content specification.
如果：content规范与多部分MIME部分匹配，则仅搜索该部分的序言和尾声部分以查找键字符串，将整个序言和尾声视为单独的字符串；仅当嵌套零件的各自类型与：内容规范匹配时，才会搜索嵌套零件的内容。
If the :content specification matches a message/rfc822 MIME part, only the header of the nested message will be searched for the key strings, treating the header as a single string; the contents of the nested message body parts are only searched if their content type matches the :content specification.
如果：content规范与message/rfc822 MIME部分匹配，则只会在嵌套消息的头中搜索键字符串，将头视为单个字符串；仅当嵌套消息正文部分的内容类型与：content规范匹配时，才会搜索其内容。
For other MIME types, the entire part will be searched as a single string.
对于其他MIME类型，整个部分将作为单个字符串进行搜索。
(Matches against container types with an empty match string can be useful as tests for the existence of such parts.)
（与具有空匹配字符串的容器类型的匹配可用于测试是否存在此类部件。）
Example:
例子：
From: Whomever
To: Someone
Date: Whenever
Subject: whatever
Content-Type: multipart/mixed; boundary=outer
From: Whomever
To: Someone
Date: Whenever
Subject: whatever
Content-Type: multipart/mixed; boundary=outer
& This is a multi-part message in MIME format. & --outer Content-Type: multipart/alternative; boundary=inner
&这是MIME格式的多部分消息--外部内容类型：多部分/可选；边界=内部
& This is a nested multi-part message in MIME format. & --inner Content-Type: text/plain; charset="us-ascii"
&这是MIME格式的嵌套多部分消息--内部内容类型：文本/普通；charset=“us ascii”
$ Hello $ --inner Content-Type: text/html; charset="us-ascii"
$ Hello$--内部内容类型：text/html；charset=“us ascii”
% <html><body>Hello</body></html>
%
--inner--
&
& This is the end of the inner MIME multipart.
&
--outer
Content-Type: message/rfc822
% <html><body>Hello</body></html>
%
--inner--
&
& This is the end of the inner MIME multipart.
&
--outer
Content-Type: message/rfc822
! From: Someone Else
! Subject: hello request
! From: Someone Else
! Subject: hello request
$ Please say Hello $ --outer-- & & This is the end of the outer MIME multipart.
$ 请说Hello$--outer--&&这是外部MIME多部分的结尾。
In the above example, the '&', '$', '%', and '!' characters at the start of a line are used to illustrate what portions of the example message are used in tests:
在上面的示例中，“&'、“$”、“%”和“！”行首的字符用于说明示例消息的哪些部分在测试中使用：
- the lines starting with '&' are the ones that are tested when a 'body :content "multipart" :contains "MIME"' test is executed.
- 以“&”开头的行是在执行“body:content“multipart”：contains“MIME”测试时测试的行。
- the lines starting with '$' are the ones that are tested when a 'body :content "text/plain" :contains "Hello"' test is executed.
- 以“$”开头的行是在执行“body:content“text/plain”：contains“Hello”测试时测试的行。
- the lines starting with '%' are the ones that are tested when a 'body :content "text/html" :contains "Hello"' test is executed.
- 以“%”开头的行是在执行“body:content“text/html”：contains“Hello”测试时测试的行。
- the lines starting with '$' or '%' are the ones that are tested when a 'body :content "text" :contains "Hello"' test is executed.
- 以“$”或“%”开头的行是在执行“body:content“text”：contains“Hello”测试时测试的行。
- the lines starting with '!' are the ones that are tested when a 'body :content "message/rfc822" :contains "Hello"' test is executed.
- 以“！”开头的行是在执行“body:content”message/rfc822:contains“Hello”测试时测试的。
Comparisons are performed on octets. Implementations decode the content-transfer-encoding and convert text to [UTF-8] as input to the comparator. MIME parts that cannot be decoded and converted MAY be treated as plain US-ASCII, omitted, or processed according to local conventions. A NUL octet (character zero) SHOULD NOT cause early termination of the content being compared against. Implementations MUST support the "quoted-printable", "base64", "7bit", "8bit", and "binary" content transfer encodings. Implementations MUST be capable of converting to UTF-8 the US-ASCII, ISO-8859-1, and the US-ASCII subset of ISO-8859-* character sets.
比较是在八位字节上进行的。实现对内容传输编码进行解码，并将文本转换为[UTF-8]作为比较器的输入。无法解码和转换的MIME部分可能被视为纯US-ASCII、省略或根据本地约定进行处理。NUL八位字节（零字符）不应导致所比较的内容提前终止。实现必须支持“引用的可打印”、“base64”、“7bit”、“8bit”和“二进制”内容传输编码。实现必须能够将ISO-8859-*字符集的US-ASCII、ISO-8859-1和US-ASCII子集转换为UTF-8。
Each matched part is matched against independently: search expressions MUST NOT match across MIME part boundaries. MIME headers of the containing part MUST NOT be included in the data.
每个匹配的部分都是独立匹配的：搜索表达式不能跨MIME部分边界匹配。数据中不得包含包含部分的MIME头。
Example:
例子：
require ["body", "fileinto"];
要求[“body”，“fileinto”]；
# Save any message with any text MIME part that contains the # words "missile" or "coordinates" in the "secrets" folder.
#使用包含“机密”文件夹中的#单词“导弹”或“坐标”的任何文本MIME部分保存任何消息。
if body :content "text" :contains ["missile", "coordinates"] {
fileinto "secrets";
}
if body :content "text" :contains ["missile", "coordinates"] {
fileinto "secrets";
}
# Save any message with an audio/mp3 MIME part in # the "jukebox" folder.
#将任何带有音频/mp3 MIME部件的邮件保存在#jukebox文件夹中。
if body :content "audio/mp3" :contains "" {
fileinto "jukebox";
}
if body :content "audio/mp3" :contains "" {
fileinto "jukebox";
}
The ":text" body transform matches against the results of an implementation's best effort at extracting UTF-8 encoded text from a message.
“：text”正文转换与实现从消息中提取UTF-8编码文本的最大努力的结果相匹配。
It is unspecified whether this transformation results in a single string or multiple strings being matched against. All the text extracted from a given non-container MIME part MUST be in the same string.
未指定此转换是导致匹配单个字符串还是多个字符串。从给定的非容器MIME部分提取的所有文本必须在同一字符串中。
In simple implementations, :text MAY be treated the same as :content "text".
在简单的实现中，：text可以被视为与：content“text”相同。
Sophisticated implementations MAY strip mark-up from the text prior to matching, and MAY convert media types other than text to text prior to matching.
复杂的实现可能会在匹配之前从文本中去除标记，并且可能会在匹配之前将文本以外的媒体类型转换为文本。
(For example, they may be able to convert proprietary text editor formats to text or apply optical character recognition algorithms to image data.)
（例如，他们可能能够将专有文本编辑器格式转换为文本，或将光学字符识别算法应用于图像数据。）
Example: require ["body", "fileinto"];
示例：require[“body”，“fileinto”]；
# Save messages mentioning the project schedule in the
# project/schedule folder.
if body :text :contains "project schedule" {
fileinto "project/schedule";
}
# Save messages mentioning the project schedule in the
# project/schedule folder.
if body :text :contains "project schedule" {
fileinto "project/schedule";
}
Any extension that extends the grammar for the COMPARATOR or MATCH-TYPE nonterminals will also affect the implementation of "body".
任何扩展比较器或匹配类型非终结符语法的扩展也将影响“body”的实现。
Wildcard expressions used with "body" are exempt from the side effects described in [VARIABLES]. That is, they MUST NOT set match variables (${1}, ${2}...) to the input values corresponding to wildcard sequences in the matched pattern. However, if the extension is present, variable references in the key strings or content type strings are evaluated as described in this document.
与“body”一起使用的通配符表达式不受[VARIABLES]中描述的副作用的影响。也就是说，它们不能将匹配变量（${1}，${2}…）设置为与匹配模式中的通配符序列对应的输入值。但是，如果存在扩展名，则键字符串或内容类型字符串中的变量引用将按照本文档中的说明进行计算。
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: body Description: Provides a test for matching against the body of the message being processed RFC number: RFC 5173 Contact Address: The Sieve discussion list <ietf-mta-filters@imc.org>
功能名称：正文描述：提供与正在处理的邮件正文匹配的测试RFC编号：RFC 5173联系地址：筛选讨论列表<ietf mta-filters@imc.org>
The system MUST be sized and restricted in such a manner that even malicious use of body matching does not deny service to other users of the host system.
系统的大小和限制方式必须确保即使恶意使用主体匹配也不会拒绝向主机系统的其他用户提供服务。
Filters relying on string matches in the raw body of an email message may be more general than intended. Text matches are no replacement for a spam, virus, or other security related filtering system.
依赖电子邮件原始正文中字符串匹配的筛选器可能比预期的更通用。文本匹配不能替代垃圾邮件、病毒或其他与安全相关的过滤系统。
This document has been revised in part based on comments and discussions that took place on and off the SIEVE mailing list. Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson, Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, Greg Shapiro, Tim Showalter, Nigel Swinson, Dowson Tong, and Christian Vogt for reviews and suggestions.
本文件的修订部分基于在筛选邮件列表内外进行的评论和讨论。感谢赛勒斯·达布、内德·弗里德、鲍勃·约翰森、西蒙·约瑟夫森、马克·E·马列特、克里斯·马克尔、阿列克谢·梅尔尼科夫、肯·穆奇森、格雷格·夏皮罗、蒂姆·肖沃尔特、奈杰尔·斯温森、道森·唐和克里斯蒂安·沃格特的评论和建议。
[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月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]Guenther，P.，Ed.，和T.Showalter，Ed.，“SIEVE:电子邮件过滤语言”，RFC 5228，2008年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[VARIABLES]Homme，K.，“筛选电子邮件过滤：变量扩展”，RFC 52292008年1月。
Authors' Addresses
作者地址
Jutta Degener 5245 College Ave, Suite #127 Oakland, CA 94618
加利福尼亚州奥克兰127号学院大道5245号朱塔·德詹，邮编94618
EMail: jutta@pobox.com
EMail: jutta@pobox.com
Philip Guenther Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608
Philip Guenther Sendmail，Inc.加利福尼亚州埃默里维尔克里斯蒂大道6425号4楼，邮编94608
EMail: guenther@sendmail.com
EMail: guenther@sendmail.com
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.