Network Working Group J. Degener
Request for Comments: 5293 P. Guenther
Category: Standards Track Sendmail, Inc.
August 2008
Network Working Group J. Degener
Request for Comments: 5293 P. Guenther
Category: Standards Track Sendmail, Inc.
August 2008
Sieve Email Filtering: Editheader Extension
筛选电子邮件筛选：Editheader扩展
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 two new actions for the "Sieve" email filtering language that add and delete email header fields.
本文档为“筛选”电子邮件过滤语言定义了两个新操作，用于添加和删除电子邮件标题字段。
Email header fields are a flexible and easy-to-understand means of communication between email processors. This extension enables sieve scripts to interact with other components that consume or produce header fields by allowing the script to delete and add header fields.
电子邮件标题字段是电子邮件处理者之间灵活且易于理解的通信方式。此扩展允许脚本删除和添加标题字段，从而使筛选脚本能够与使用或生成标题字段的其他组件交互。
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 Section 1.1 of [SIEVE], including use of the "Usage:" label for the definition of action and tagged arguments syntax.
符号惯例如[SIFE]第1.1节所述，包括使用“用法：”标签定义动作和标记参数语法。
The term "header field" is used here as in [IMAIL] to mean a logical line of an email message header.
术语“header field”在这里与[IMAIL]中一样用于表示电子邮件消息头的逻辑行。
The capability string associated with the extension defined in this document is "editheader".
与本文档中定义的扩展相关联的功能字符串为“editheader”。
Usage: "addheader" [":last"] <field-name: string> <value: string>
Usage: "addheader" [":last"] <field-name: string> <value: string>
The addheader action adds a header field to the existing message header. If the field-name is not a valid 7-bit US-ASCII header field name, as described by the [IMAIL] "field-name" nonterminal syntax element, the implementation MUST flag an error. The addheader action does not affect Sieve's implicit keep.
addheader操作将头字段添加到现有消息头。如果字段名不是有效的7位US-ASCII头字段名（如[IMAIL]“field name”非终端语法元素所述），则实现必须标记错误。addheader操作不会影响Sieve的隐式保留。
If the specified field value does not match the [IMAIL] "unstructured" nonterminal syntax element or exceeds a length limit set by the implementation, the implementation MUST either flag an error or encode the field using folding white space and the encodings described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].
如果指定的字段值与[IMAIL]“非结构化”非终端语法元素不匹配或超出了实现设置的长度限制，则实现必须标记错误或使用折叠空格对字段进行编码，[MIME3]或[MIMEPARM]中描述的编码符合[IMAIL]。
An implementation MAY impose a length limit onto the size of the encoded header field; such a limit MUST NOT be less than 998 characters, not including the terminating CRLF supplied by the implementation.
一种实现可以对编码的报头字段的大小施加长度限制；该限制不得少于998个字符，不包括实现提供的终止CRLF。
By default, the header field is inserted at the beginning of the existing message header. If the optional flag ":last" is specified, it is appended at the end.
默认情况下，标题字段插入到现有消息标题的开头。如果指定了可选标志“：last”，则会将其附加在末尾。
Example:
例子：
/* Don't redirect if we already redirected */
if not header :contains "X-Sieve-Filtered"
["<kim@job.example.com>", "<kim@home.example.com>"]
{
addheader "X-Sieve-Filtered" "<kim@job.example.com>";
redirect "kim@home.example.com";
}
/* Don't redirect if we already redirected */
if not header :contains "X-Sieve-Filtered"
["<kim@job.example.com>", "<kim@home.example.com>"]
{
addheader "X-Sieve-Filtered" "<kim@job.example.com>";
redirect "kim@home.example.com";
}
Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
[COMPARATOR] [MATCH-TYPE]
<field-name: string>
[<value-patterns: string-list>]
Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
[COMPARATOR] [MATCH-TYPE]
<field-name: string>
[<value-patterns: string-list>]
By default, the deleteheader action deletes all occurrences of the named header field. The deleteheader action does not affect Sieve's implicit keep.
默认情况下，deleteheader操作删除所有出现的命名标题字段。deleteheader操作不会影响Sieve的隐式保留。
The field-name is mandatory and always matched as a case-insensitive US-ASCII string. If the field-name is not a valid 7-bit header field name as described by the [IMAIL] "field-name" nonterminal syntax element, the implementation MUST flag an error.
字段名是必需的，并且始终作为不区分大小写的US-ASCII字符串匹配。如果字段名不是[IMAIL]“field name”非终结语法元素描述的有效7位标头字段名，则实现必须标记错误。
The value-patterns, if specified, restrict which occurrences of the header field are deleted to those whose values match any of the specified value-patterns, the matching being according to the match-type and comparator and performed as if by the "header" test. In particular, leading and trailing whitespace in the field values is ignored. If no value-patterns are specified, then the comparator and match-type options are silently ignored.
值模式（如果指定）将删除标题字段的次数限制为其值与任何指定值模式匹配的次数，匹配根据匹配类型和比较器进行，并像通过“标题”测试一样执行。特别是，字段值中的前导空格和尾随空格将被忽略。如果未指定值模式，则会自动忽略比较器和匹配类型选项。
If :index <fieldno> is specified, the attempts to match a value are limited to the <fieldno> occurrence of the named header field, beginning at 1, the first named header field. If :last is specified, the count is backwards; 1 denotes the last named header field, 2 the second to last, and so on. The counting happens before the <value-patterns> match, if any. For example:
如果指定了：index<fieldno>，则匹配值的尝试仅限于命名标头字段的<fieldno>出现，从第一个命名标头字段1开始。如果指定：last，则计数向后；1表示最后命名的头字段，2表示倒数第二个，依此类推。计数发生在<value patterns>匹配之前（如果有）。例如：
deleteheader :index 1 :contains "Delivered-To"
"bob@example.com";
deleteheader :index 1 :contains "Delivered-To"
"bob@example.com";
deletes the first "Delivered-To" header field if it contains the string "bob@example.com" (not the first "Delivered-To" field that contains "bob@example.com").
删除第一个“传递到”标题字段（如果它包含字符串）bob@example.com（不是包含的第一个“交付到”字段）bob@example.com").
It is not an error if no header fields match the conditions in the deleteheader action or if the :index argument is greater than the number of named header fields.
如果没有标题字段与deleteheader操作中的条件匹配，或者：index参数大于命名标题字段的数量，则不是错误。
The implementation MUST flag an error if :last is specified without also specifying :index.
如果指定了：last而未同时指定：index，则实现必须标记错误。
As a matter of local policy, implementations MAY limit which header fields may be deleted and which header fields may be added. However, implementations MUST NOT permit attempts to delete "Received" and "Auto-Submitted" header fields and MUST permit both addition and deletion of the "Subject" header field.
根据本地策略，实现可能会限制哪些标头字段可以删除，哪些标头字段可以添加。但是，实现必须不允许尝试删除“已接收”和“自动提交”标题字段，并且必须允许添加和删除“主题”标题字段。
If a script tries to make a change that isn't permitted, the attempt MUST be silently ignored.
如果脚本试图进行不允许的更改，则必须忽略该尝试。
Actions that generate [MDN], [DSN], or similar disposition messages MUST do so using the original, unmodified message header. Similarly, if an error terminates processing of the script, the original message header MUST be used when doing the implicit keep required by Section 2.10.6 of [SIEVE].
生成[MDN]、[DSN]或类似处置消息的操作必须使用原始的、未修改的消息头。类似地，如果错误终止了脚本的处理，则在执行[SIEVE]第2.10.6节要求的隐式保留时，必须使用原始消息头。
All other actions that store, send, or alter the message MUST do so with the current set of header fields. This includes the addheader and deleteheader actions themselves. For example, the following leaves the message unchanged:
存储、发送或更改消息的所有其他操作都必须使用当前的头字段集执行。这包括addheader和deleteheader操作本身。例如，以下内容使消息保持不变：
addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello";
addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello";
Similarly, given a message with three or more "X-Hello" header fields, the following example deletes the first and third of them, not the first and second:
类似地，对于包含三个或更多“X-Hello”头字段的消息，以下示例将删除其中的第一个和第三个，而不是第一个和第二个：
deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello";
deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello";
Tests and actions such as "exists", "header", or "vacation" [VACATION] that examine header fields MUST examine the current state of a header as modified by any actions that have taken place so far.
检查报头字段的测试和操作（如“存在”、“报头”或“休假”[休假]）必须检查报头的当前状态，该状态由迄今为止已发生的任何操作修改。
As an example, the "header" test in the following fragment will always evaluate to true, regardless of whether or not the incoming message contained an "X-Hello" header field:
例如，以下片段中的“header”测试将始终计算为true，而不管传入消息是否包含“X-Hello”头字段：
addheader "X-Hello" "World";
if header :contains "X-Hello" "World"
{
fileinto "international";
}
addheader "X-Hello" "World";
if header :contains "X-Hello" "World"
{
fileinto "international";
}
However, if the presence or value of a header field affects how the implementation parses or decodes other parts of the message, then, for the purposes of that parsing or decoding, the implementation MAY ignore some or all changes made to those header fields. For example, in an implementation that supports the [BODY] extension, "body" tests may be unaffected by deleting or adding "Content-Type" or "Content-Transfer-Encoding" header fields. This does not rescind the requirement that changes to those header fields affect direct tests; only the semantic side effects of changes to the fields may be ignored.
然而，如果报头字段的存在或值影响实现如何解析或解码消息的其他部分，则出于解析或解码的目的，实现可以忽略对那些报头字段所做的一些或所有更改。例如，在支持[BODY]扩展的实现中，删除或添加“Content-Type”或“Content-Transfer-Encoding”头字段可能不影响“BODY”测试。这并没有取消对这些标题字段的更改会影响直接测试的要求；只有字段更改的语义副作用可以忽略。
For the purpose of weeding out duplicates, a message modified by addheader or deleteheader MUST be considered the same as the original message. For example, in an implementation that obeys the constraint in Section 2.10.3 of [SIEVE] and does not deliver the same message to a folder more than once, the following code fragment
为了剔除重复的消息，必须将由addheader或deleteheader修改的消息视为与原始消息相同。例如，在遵守[SIEVE]第2.10.3节中的约束且不会将同一消息多次传递到文件夹的实现中，以下代码片段
keep;
addheader "X-Flavor" "vanilla";
keep;
keep;
addheader "X-Flavor" "vanilla";
keep;
MUST only file one message. It is up to the implementation to pick which of the redundant "fileinto" or "keep" actions is executed, and which ones are ignored.
只能提交一封邮件。由实现选择执行哪些冗余的“fileinto”或“keep”操作，以及忽略哪些操作。
The "implicit keep" is thought to be executed at the end of the script, after the headers have been modified. (However, a canceled "implicit keep" remains canceled.)
“隐式保留”被认为是在修改了头之后，在脚本末尾执行的。（但是，取消的“隐式保留”仍将被取消。）
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: editheader Description: Adds actions 'addheader' and 'deleteheader' that modify the header of the message being processed RFC number: RFC 5293 Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>
功能名称：editheader描述：添加操作“addheader”和“deleteheader”，以修改正在处理的邮件的标题RFC编号：RFC 5293联系地址：筛讨论列表<ietf mta filters&imc.org>
Someone with write access to a user's script storage may use this extension to generate headers that a user would otherwise be shielded from (e.g., by a gateway Mail Transport Agent (MTA) that removes them).
对用户的脚本存储具有写访问权限的人可以使用此扩展生成头，否则用户将被屏蔽（例如，由删除它们的网关邮件传输代理（MTA））的头。
This is the first Sieve extension to be standardized that allows alteration of messages being processed by Sieve engines. A Sieve script that uses Sieve tests defined in [SIEVE], the editheader extension, and the redirect action back to the same user can keep some state between different invocations of the same script for the same message. But note that it would not be possible to introduce an infinite loop using any such script, because each iteration adds a new Received header field, so email loop prevention described in [SMTP] will eventually non deliver the message, and because the
这是第一个标准化的Sieve扩展，允许对Sieve引擎处理的消息进行更改。使用[Sieve]中定义的Sieve测试、editheader扩展和重定向操作返回给同一用户的Sieve脚本可以在同一消息的同一脚本的不同调用之间保持某种状态。但请注意，使用任何此类脚本都不可能引入无限循环，因为每次迭代都会添加一个新的接收头字段，因此[SMTP]中描述的电子邮件循环预防最终将无法传递消息，并且
editheader extension is explicitly prohibited to alter or delete Received header fields (i.e., it can't interfere with loop prevention).
editheader扩展明确禁止更改或删除收到的头字段（即，它不能干扰循环预防）。
A sieve filter that removes header fields may unwisely destroy evidence about the path a message has taken.
删除标头字段的筛选筛选器可能会不明智地销毁有关消息所采用路径的证据。
Any change in message content may interfere with digital signature mechanisms that include the header in the signed material. For example, changes to (or deletion/addition of) header fields included in the "SHOULD be included in the signature" list in Section 5.5 of [DKIM] can invalidate DKIM signatures. This also includes DKIM signatures that guarantee a header field absence.
消息内容的任何更改都可能会干扰数字签名机制，其中包括签名材料中的标题。例如，对[DKIM]第5.5节“应包括在签名中”列表中的标题字段的更改（或删除/添加）可能会使DKIM签名无效。这还包括DKIM签名，这些签名保证不存在头字段。
The editheader extension doesn't directly affect [IMAIL] header field signatures generated using [SMIME] or [OPENPGP], because these signature schemes include a separate copy of the header fields inside the signed message/rfc822 body part. However, software written to detect differences between the inner (signed) copy of header fields and the outer (modified by editheader) header fields might be affected by changes made by editheader.
editheader扩展不会直接影响使用[SMIME]或[OPENPGP]生成的[IMAIL]头字段签名，因为这些签名方案包括签名消息/rfc822正文部分中头字段的单独副本。但是，为检测头字段的内部（签名）副本和外部（由editheader修改）头字段之间的差异而编写的软件可能会受到editheader所做更改的影响。
Since normal message delivery adds "Received" header fields and other trace fields to the beginning of a message, many such digital signature mechanisms are impervious to headers prefixed to a message, and will work with "addheader" unless :last is used.
由于正常的消息传递会在消息的开头添加“Received”标头字段和其他跟踪字段，因此许多此类数字签名机制对消息前缀的标头不敏感，并且将使用“addheader”，除非使用：last。
Any decision mechanism in a user's filter that is based on headers is vulnerable to header spoofing. For example, if the user adds an APPROVED header or tag, a malicious sender may add that tag or header themselves. One way to guard against this is to delete or rename any such headers or stamps prior to processing the message.
用户筛选器中基于头的任何决策机制都容易受到头欺骗的攻击。例如，如果用户添加批准的标题或标签，恶意发件人可能会自行添加该标签或标题。防止这种情况的一种方法是在处理消息之前删除或重命名任何此类标题或戳记。
Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive corrections and suggestions.
感谢Eric Allman、Cyrus Daboo、Matthew Elvey、Ned Freed、Arnt Gulbrandsen、Kjetil Torgrim Homme、Simon Josefsson、Will Lee、William Leibzon、Mark E.Mallett、Chris Markle、Alexey Melnikov、Randall Schwartz、Aaron Stone、Nigel Swinson和Rand Wacker的广泛更正和建议。
[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月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME3]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[MIMEPARAM] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[MIMEPARAM]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年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月。
[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: Body Extension", RFC 5173, April 2008.
[正文]Degener，J.和P.Guenther，“筛选电子邮件过滤：正文扩展”，RFC 51732008年4月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN]Hansen，T.，Ed.，和G.Vaudreuil，Ed.，“消息处置通知”，RFC 3798，2004年5月。
[OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[OPENPGP]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OPENPGP的MIME安全性”，RFC 3156，2001年8月。
[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIME]Ramsdell，B.，Ed.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
[VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[假期]Showalter，T.和N.Freed，Ed.，“筛选电子邮件过滤：假期延长”，RFC 5230，2008年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. 6475 Christie Ave., Ste 350 Emeryville, CA 94608
Philip Guenther Sendmail，Inc.地址：加利福尼亚州埃默里维尔市克里斯蒂大道6475号，圣350号，邮编：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.