Network Working Group T. Showalter
Request for Comments: 5230
Category: Standards Track N. Freed, Ed.
Sun Microsystems
January 2008
Network Working Group T. Showalter
Request for Comments: 5230
Category: Standards Track N. Freed, Ed.
Sun Microsystems
January 2008
Sieve Email Filtering: Vacation 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 describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops.
本文档描述了用于自动应答器的Sieve电子邮件过滤语言的扩展，类似于用于回复消息的Unix“vacation”命令。包括各种安全功能，以防止出现诸如消息循环之类的问题。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Response Message Generation . . . . . . . . . . . . . . . . . 9
5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
6. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
7. Internationalization Considerations . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Response Message Generation . . . . . . . . . . . . . . . . . 9
5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
6. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
7. Internationalization Considerations . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
This document defines an extension to the Sieve language defined in [RFC5228] for notification that messages to a particular recipient will not be answered immediately.
本文档定义了[RFC5228]中定义的筛语言的扩展，用于通知发送给特定收件人的邮件不会立即回复。
Conventions for notations are as in [RFC5228] section 1.1.
符号惯例如[RFC5228]第1.1节所述。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED", and "MAY" in this document are to be interpreted as defined in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”、“必需”和“可能”应按照[RFC2119]中的定义进行解释。
Sieve implementations that implement vacation have an identifier of "vacation" for use with the capability mechanism.
实现休假的筛选实现具有“休假”标识符，用于能力机制。
Usage: vacation [":days" number] [":subject" string]
[":from" string] [":addresses" string-list]
[":mime"] [":handle" string] <reason: string>
Usage: vacation [":days" number] [":subject" string]
[":from" string] [":addresses" string-list]
[":mime"] [":handle" string] <reason: string>
The "vacation" action implements a vacation autoresponder similar to the vacation command available under many versions of Unix. Its purpose is to provide correspondents with notification that the user is away for an extended period of time and that they should not expect quick responses.
“休假”操作实现休假自动响应程序，类似于许多Unix版本下可用的休假命令。其目的是向通讯员提供通知，告知用户已离开一段较长的时间，并且他们不应期望得到快速响应。
"Vacation" is used to respond to a message with another message. Vacation's messages are always addressed to the Return-Path address (that is, the envelope from address) of the message being responded to.
“假期”用于用另一条消息响应消息。假期的消息总是发送到被响应消息的返回路径地址（即信封发件人地址）。
The ":days" argument is used to specify the period in which addresses are kept and are not responded to, and is always specified in days. The minimum value used for this parameter is normally 1. Sites MAY define a different minimum value as long as the minimum is greater than 0. Sites MAY also define a maximum days value, which MUST be greater than 7, and SHOULD be greater than 30.
“：days”参数用于指定保存地址和不响应地址的时间段，并且始终以天为单位指定。此参数使用的最小值通常为1。只要最小值大于0，站点可以定义不同的最小值。站点还可以定义最大天数值，该值必须大于7，并且应大于30。
If ":days" is omitted, the default value is either 7 or the minimum value (as defined above), whichever is greater.
如果省略“：days”，则默认值为7或最小值（如上所述），以较大者为准。
If the parameter given to ":days" is less than the minimum value, then the minimum value is used instead.
如果给“：days”的参数小于最小值，则使用最小值。
If ":days" exceeds the site-defined maximum, the site-defined maximum is used instead.
如果“：天”超过现场定义的最大值，则使用现场定义的最大值。
"Vacation" keeps track of all the responses it has sent to each address in some period (as specified by the :days optional argument). If vacation has not previously sent the response to this address within the given time period, it sends the "reason" argument to the SMTP MAIL FROM address [RFC2821] of the message that is being responded to. (The SMTP MAIL FROM address should be available in the Return-path: header field if Sieve processing occurs after final delivery.)
“假期”跟踪它在某段时间内发送到每个地址的所有响应（由：days可选参数指定）。如果假期之前在给定的时间段内没有向该地址发送响应，则它将“reason”参数从被响应邮件的地址[RFC2821]发送到SMTP邮件。（如果在最终传递后进行筛选处理，则“返回路径：标头”字段中应提供SMTP邮件发件人地址。）
Tracking is not just per address, but must also take the vacation response itself into account. A script writer might, for example, have a vacation action that will send a general notice only once in any two-week period. However, even if a sender has received this general notice, it may be important to send a specific notice when a message about something timely or something specific has been detected.
跟踪不仅仅是每个地址，还必须考虑假期响应本身。例如，脚本编写者可能有一个假期动作，在任何两周内只发送一次一般通知。但是，即使发送者已收到此一般通知，当检测到关于某个及时或特定内容的消息时，发送特定通知也可能很重要。
A particular vacation response can be identified in one of two ways. The first way is via an explicit :handle argument, which attaches a name to the response. All vacation statements that use the same handle will be considered the same response for tracking purposes.
可以通过以下两种方式之一确定特定的假期响应。第一种方法是通过显式：handle参数，它将名称附加到响应。出于跟踪目的，所有使用相同句柄的休假语句都将被视为相同的响应。
The second way is via a synthesis of the :subject, :from, :mime, and reason vacation command arguments. All vacation actions that do not contain an explicit handle and that use an identical combination of these arguments are considered the same for tracking purposes.
第二种方法是：subject、：from、：mime和reason命令参数的合成。所有不包含显式句柄且使用这些参数的相同组合的休假操作都被视为相同的跟踪操作。
For instance, if coyote@desert.example.org sends mail to roadrunner@acme.example.com twice, once with the subject "Cyrus bug" and once with the subject "come over for dinner", and roadrunner@acme.example.com has the script shown below, coyote@desert.example.org would receive two responses, one with the first message, one with the second.
例如，如果coyote@desert.example.org发送邮件到roadrunner@acme.example.com两次，一次主题是“塞勒斯虫”，一次主题是“过来吃晚饭”，以及roadrunner@acme.example.com脚本如下所示，coyote@desert.example.org将收到两个响应，一个包含第一条消息，一个包含第二条消息。
require "vacation";
if header :contains "subject" "cyrus" {
vacation "I'm out -- send mail to cyrus-bugs";
} else {
vacation "I'm out -- call me at +1 304 555 0123";
}
require "vacation";
if header :contains "subject" "cyrus" {
vacation "I'm out -- send mail to cyrus-bugs";
} else {
vacation "I'm out -- call me at +1 304 555 0123";
}
In the above example, coyote@desert.example.org gets the second message despite having gotten the first one because separate vacation responses have been triggered. This behavior is REQUIRED.
在上面的例子中，coyote@desert.example.org获取第二条消息，尽管已获取第一条消息，因为已触发单独的休假响应。这种行为是必需的。
There is one important exception to this rule, however. If the Sieve variables extension [RFC5229] is used, the arguments MUST NOT have undergone variable expansion prior to their use in response tracking. This is so that examples like the following script will only generate a single response to each incoming message with a different subject line.
然而，这条规则有一个重要的例外。如果使用筛变量扩展[RFC5229]，则参数在用于响应跟踪之前不得进行变量扩展。这样，像下面的脚本这样的示例只会对每个具有不同主题行的传入消息生成一个响应。
require ["vacation", "variables"];
if header :matches "subject" "*" {
vacation :subject "Automatic response to: ${1}"
"I'm away -- send mail to foo in my absence";
}
require ["vacation", "variables"];
if header :matches "subject" "*" {
vacation :subject "Automatic response to: ${1}"
"I'm away -- send mail to foo in my absence";
}
As noted above, the optional ":handle" parameter can be used to tell the Sieve interpreter to treat two vacation actions with different arguments as the same command for purposes of response tracking. The argument to ":handle" is a string that identifies the type of response being sent. For instance, if tweety@cage.example.org sends mail to spike@doghouse.example.com twice, one with the subject "lunch?" and once with the subject "dinner?", and spike@doghouse.example.com has the script shown below, tweety@cage.example.org will only receive a single response. (Which response is sent depends on the order in which the messages are processed.)
如上所述，可选的“：handle”参数可用于告诉Sieve解释器将具有不同参数的两个休假操作视为同一个命令，以便进行响应跟踪。“：handle”的参数是一个字符串，用于标识正在发送的响应类型。例如，如果tweety@cage.example.org发送邮件到spike@doghouse.example.com两次，一次主题为“午餐”，一次主题为“晚餐”，以及spike@doghouse.example.com脚本如下所示，tweety@cage.example.org将只收到一个响应。（发送哪个响应取决于消息的处理顺序。）
require "vacation";
if header :contains "subject" "lunch" {
vacation :handle "ran-away" "I'm out and can't meet for lunch";
} else {
vacation :handle "ran-away" "I'm out";
}
require "vacation";
if header :contains "subject" "lunch" {
vacation :handle "ran-away" "I'm out and can't meet for lunch";
} else {
vacation :handle "ran-away" "I'm out";
}
NOTE: One way to implement the necessary mechanism here is to store a hash of either the current handle and the recipient address or, if no handle is provided, a hash of the vacation action parameters specifying the message content and the recipient address. If a script is changed, implementations MAY reset the records of who has been responded to and when they have been responded to.
注意：这里实现必要机制的一种方法是存储当前句柄和收件人地址的散列，如果没有提供句柄，则存储指定消息内容和收件人地址的休假操作参数的散列。如果更改了脚本，实现可能会重置响应对象和响应时间的记录。
IMPLEMENTATION NOTE: Care must be taken in constructing a hash of vacation action parameters. In particular, since most parameters are optional, it is important not to let the same string used as the value for different parameters produce the same hash value. One
实现说明：在构造休假操作参数的散列时必须小心。特别是，由于大多数参数都是可选的，因此重要的是不要让用作不同参数值的相同字符串产生相同的哈希值。一
possible way to accomplish this is to apply the hash to a series of counted or null terminated strings, one for each possible parameter in particular order.
实现这一点的可能方法是将哈希应用于一系列已计数或以null结尾的字符串，每个可能的参数按特定顺序对应一个。
Implementations are free to limit the number of remembered responses; however, the limit MUST NOT be less than 1000. When limiting the number of tracked responses, implementations SHOULD discard the oldest ones first.
实现可以自由限制记忆响应的数量；但是，限制不得小于1000。在限制跟踪响应的数量时，实现应首先丢弃最旧的响应。
The ":subject" parameter specifies a subject line to attach to any vacation response that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST generate an appropriate default subject line as specified below if no :subject parameter is specified.
“：subject”参数指定要附加到生成的任何休假响应的主题行。字符串参数中可以使用UTF-8字符；当且仅当存在非ASCII字符时，实现必须将字符串转换为[RFC2047]编码字。如果未指定：subject参数，则实现必须生成下面指定的适当的默认主题行。
A ":from" parameter may be used to specify an alternate address to use in the From field of vacation messages. The string must specify a valid [RFC2822] mailbox-list. Implementations SHOULD check the syntax and generate an error when a syntactically invalid ":from" parameter is specified. Implementations MAY also impose restrictions on what addresses can specified in a ":from" parameter; it is suggested that values that fail such a validity check simply be ignored rather than cause the vacation action to fail.
“：from”参数可用于指定假期消息的发件人字段中使用的备用地址。字符串必须指定有效的[RFC2822]邮箱列表。当指定语法无效的“：from”参数时，实现应该检查语法并生成错误。实现还可能对在“：from”参数中指定的地址施加限制；建议忽略未通过有效性检查的值，而不是导致休假操作失败。
The ":mime" parameter, if supplied, specifies that the reason string is, in fact, a MIME entity as defined in [RFC2045] section 2.4, including both MIME headers and content.
“：mime”参数（如果提供）指定原因字符串实际上是[RFC2045]第2.4节中定义的mime实体，包括mime头和内容。
If the optional :mime parameter is not supplied, the reason string is considered a UTF-8 string.
如果未提供可选的：mime参数，则原因字符串被视为UTF-8字符串。
require "vacation";
vacation :mime text:
Content-Type: multipart/alternative; boundary=foo
require "vacation";
vacation :mime text:
Content-Type: multipart/alternative; boundary=foo
--foo
--福
I'm at the beach relaxing. Mmmm, surf...
我在海滩上放松。嗯，冲浪。。。
--foo
Content-Type: text/html; charset=us-ascii
--foo
Content-Type: text/html; charset=us-ascii
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML><HEAD><TITLE>How to relax</TITLE>
<BASE HREF="http://home.example.com/pictures/"></HEAD>
<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
Mmmm, <A HREF="ocean.gif">surf</A>...
</BODY></HTML>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML><HEAD><TITLE>How to relax</TITLE>
<BASE HREF="http://home.example.com/pictures/"></HEAD>
<BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
Mmmm, <A HREF="ocean.gif">surf</A>...
</BODY></HTML>
--foo-- .
--福--。
"Vacation" MUST NOT respond to a message unless the recipient user's email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or "Resent-Bcc" line of the original message. An email address is considered to belong to the recipient if it is one of:
“休假”不得回复邮件，除非收件人用户的电子邮件地址位于原始邮件的“收件人”、“抄送”、“密件抄送”、“重新发送至”、“重新发送抄送”或“重新发送密件抄送”行。如果电子邮件地址是下列地址之一，则视为属于收件人：
1. an email address known by the implementation to be associated with the recipient,
1. 实现已知的与收件人关联的电子邮件地址，
2. the final envelope recipient address if it's available to the implementation, or
2. 最终信封收件人地址（如果可供实施使用），或
3. an address specified by the script writer via the ":addresses" argument described in the next paragraph.
3. 脚本编写器通过下一段中描述的“：addresses”参数指定的地址。
Users can supply additional mail addresses that are theirs with the ":addresses" argument, which takes a string-list listing additional addresses that a user might have. These addresses are considered to belong to the recipient user in addition to the addresses known to the implementation.
用户可以使用“：addresses”参数提供属于他们的其他邮件地址，该参数采用一个字符串列表，列出用户可能拥有的其他地址。除了实现已知的地址之外，这些地址还被认为属于接收方用户。
Implementations MAY refuse to send a vacation response to a message that contains any header or content that makes it appear that a response would not be appropriate.
实现可能会拒绝向包含任何标题或内容的消息发送休假响应，这些标题或内容会使响应看起来不合适。
Implementations MUST have a list of addresses that "vacation" MUST NOT send mail to. However, the contents of this list are implementation defined. The purpose of this list is to stop mail from going to addresses used by system daemons that would not care if the user is actually reading her mail.
实现必须有一个“假期”不能向其发送邮件的地址列表。但是，此列表的内容是由实现定义的。此列表的目的是阻止邮件发送到系统守护进程使用的地址，这些系统守护进程不关心用户是否正在阅读她的邮件。
Implementations are encouraged, however, to include well-known addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other addresses typically used only by automated systems. Additionally, addresses ending in "-request" or beginning in "owner-", i.e., reserved for mailing list software, are also suggested.
但是，鼓励实现包括众所周知的地址，如“MAILER-DAEMON”、“LISTSERV”、“majordomo”，以及通常仅由自动化系统使用的其他地址。此外，还建议使用以“-request”结尾或以“owner-”开头的地址，即为邮件列表软件保留的地址。
Implementors may take guidance from [RFC2142], but should be careful. Some addresses, like "POSTMASTER", are generally actually managed by people, and people do care if the user is going to be unavailable.
实施者可以从[RFC2142]获得指导，但应小心。有些地址，比如“邮政局长”，实际上是由人管理的，人们确实关心用户是否不可用。
Implementations SHOULD NOT respond to any message that contains a "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369] header field.
实现不应响应包含“列表Id”[RFC2919]、“列表帮助”、“列表订阅”、“列表取消订阅”、“列表发布”、“列表所有者”或“列表存档”[RFC2369]标题字段的任何消息。
Implementations SHOULD NOT respond to any message that has an "Auto-submitted" header field with a value other than "no". This header field is described in [RFC3834].
实现不应响应任何具有“Auto submitted”头字段且值不是“no”的消息。[RFC3834]中描述了此标题字段。
Vacation does not affect Sieve's implicit keep action.
假期不会影响Sieve的隐式keep动作。
Vacation can only be executed once per script. A script MUST fail with an appropriate error if it attempts to execute two or more vacation actions.
每个脚本只能执行一次休假。如果脚本试图执行两个或多个休假操作，则脚本必须失败并出现相应错误。
Implementations MUST NOT consider vacation used with discard, keep, fileinto, or redirect an error. The vacation action is incompatible with the Sieve reject and refuse actions [REJECT].
实现不能考虑使用丢弃、保持、文件插入或重定向错误的休假。休假操作与筛拒绝和拒绝操作[拒绝]不兼容。
Here is a simple use of vacation.
下面是假期的一个简单用法。
require "vacation";
vacation :days 23 :addresses ["tjs@example.edu",
"ts4z@landru.example.edu"]
"I'm away until October 19.
If it's an emergency, call 911, I guess." ;
require "vacation";
vacation :days 23 :addresses ["tjs@example.edu",
"ts4z@landru.example.edu"]
"I'm away until October 19.
If it's an emergency, call 911, I guess." ;
By mingling vacation with other rules, users can do something more selective.
通过将假期与其他规则相结合，用户可以做一些更有选择性的事情。
require "vacation";
if header :contains "from" "boss@example.edu" {
redirect "pleeb@isp.example.org";
} else {
vacation "Sorry, I'm away, I'll read your
message when I get around to it.";
}
require "vacation";
if header :contains "from" "boss@example.edu" {
redirect "pleeb@isp.example.org";
} else {
vacation "Sorry, I'm away, I'll read your
message when I get around to it.";
}
This section details the requirements for the generated response message.
本节详细说明了生成的响应消息的要求。
It is worth noting that the input message and arguments may be in UTF-8, and that implementations MUST deal with UTF-8 input, although implementations MAY transcode to other character sets as regional taste dictates. When :mime is used, the reason argument also contains MIME header information. The headers must conform to MIME conventions; in particular, 8bit text is not allowed. Implementations SHOULD reject vacation :mime actions containing 8bit header material.
值得注意的是，输入消息和参数可能在UTF-8中，并且实现必须处理UTF-8输入，尽管实现可能根据区域口味转换为其他字符集。使用：mime时，reason参数还包含mime头信息。标头必须符合MIME约定；特别是，不允许使用8位文本。实现应该拒绝包含8位头材料的休假：mime操作。
The SMTP MAIL FROM address of the message envelope SHOULD be set to <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.
邮件信封的SMTP邮件发件人地址应设置为<>。如果公证人SMTP扩展名[RFC3461]可用，则在SMTP事务期间，还应在RCPT TO行中设置NOTIFY=NEVER。
The Date field SHOULD be set to the date and time when the vacation response was generated. Note that this may not be the same as the time the message was delivered to the user.
日期字段应设置为生成假期响应的日期和时间。请注意，这可能与消息交付给用户的时间不同。
Users can specify the Subject of the reply with the ":subject" parameter. If the :subject parameter is not supplied, then the subject is generated as follows: The subject is set to the characters "Auto: " followed by the original subject. An appropriate fixed Subject, such as "Automated reply", SHOULD be used in the event that :subject isn't specified and the original message doesn't contain a Subject field.
用户可以使用“：Subject”参数指定回复的主题。如果未提供：subject参数，则按如下方式生成主题：主题设置为字符“Auto:”，后跟原始主题。如果：Subject未指定且原始邮件不包含Subject字段，则应使用适当的固定主题，如“自动回复”。
Unless explicitly overridden with a :from parameter, the From field SHOULD be set to the address of the owner of the Sieve script.
除非使用：from参数显式重写，否则from字段应设置为Sieve脚本所有者的地址。
The To field SHOULD be set to the address of the recipient of the response.
“收件人”字段应设置为响应收件人的地址。
An Auto-Submitted field with a value of "auto-replied" SHOULD be included in the message header of any vacation message sent.
值为“自动回复”的自动提交字段应包含在发送的任何假期邮件的邮件头中。
The body of the message is taken from the reason string in the vacation command.
消息正文取自休假命令中的原因字符串。
Replies MUST have the In-Reply-To field set to the Message-ID of the original message, and the References field SHOULD be updated with the Message-ID of the original message.
回复必须将In Reply To字段设置为原始邮件的邮件ID，并且应使用原始邮件的邮件ID更新References字段。
If the original message lacks a Message-ID, an In-Reply-To need not be generated, and References need not be changed.
如果原始消息缺少消息ID，则不需要生成回复，也不需要更改引用。
Section 3.6.4 of [RFC2822] provides a complete description of how References fields should be generated.
[RFC2822]第3.6.4节提供了如何生成引用字段的完整说明。
6. Relationship to Recommendations for Automatic Responses to Electronic Mail
6. 与自动回复电子邮件建议的关系
The vacation extension implements a "Personal Responder" in the terminology defined in [RFC3834]. Care has been taken in this specification to comply with the recommendations of [RFC3834] regarding how personal responders should behave.
假期扩展实现了[RFC3834]中定义的术语中的“个人响应者”。本规范中已注意遵守[RFC3834]关于个人响应者行为的建议。
Internationalization capabilities provided by the base Sieve language are discussed in [RFC5228]. However, the vacation extension is the first Sieve extension to be defined that is capable of creating entirely new messages. This section deals with internationalization issues raised by the use of the vacation extension.
[RFC5228]中讨论了基本筛选语言提供的国际化功能。但是，假期扩展是第一个定义的能够创建全新消息的筛选扩展。本节讨论使用假期延长引起的国际化问题。
Vacation messages are normally written using the UTF-8 charset, allowing text to be written in most of the world's languages. Additionally, the :mime parameter allows specification of arbitrary MIME content. In particular, this makes it possible to use multipart/alternative objects to specify vacation responses in multiple languages simultaneously.
假期消息通常使用UTF-8字符集编写，允许用世界上大多数语言编写文本。此外，：mime参数允许指定任意mime内容。特别是，这使得可以使用多部分/可选对象同时以多种语言指定假期响应。
The Sieve language itself allows a vacation response to be selected based on the content of the original message. For example, the Accept-Language or Content-Language header fields [RFC3282] could be checked and used to select appropriate text:
Sieve语言本身允许根据原始消息的内容选择休假响应。例如，可以检查接受语言或内容语言标题字段[RFC3282]，并使用其选择适当的文本：
require "vacation";
if header :contains ["accept-language", "content-language"] "en"
{
vacation "I am away this week.";
} else {
vacation "Estoy ausente esta semana.";
}
require "vacation";
if header :contains ["accept-language", "content-language"] "en"
{
vacation "I am away this week.";
} else {
vacation "Estoy ausente esta semana.";
}
Note that this rather simplistic test of the field values fails to take the structure of the fields into account and hence could be fooled by some more complex field values. A more elaborate test could be used to deal with this problem.
请注意，对字段值的这种相当简单的测试没有考虑字段的结构，因此可能会被一些更复杂的字段值所愚弄。可以使用更复杂的测试来处理此问题。
The approach of explicitly coding language selection criteria in scripts is preferred because in many cases language selection issues are conflated with other selection issues. For example, it may be appropriate to use informal text in one language for vacation responses sent to a fellow employee while using more formal text in a different language in a response sent to a total stranger outside the company:
首选在脚本中显式编码语言选择标准的方法，因为在许多情况下，语言选择问题与其他选择问题相混淆。例如，对于发送给同事的假期回复，可以使用一种语言的非正式文本，而对于发送给公司以外完全陌生的人的回复，可以使用另一种语言的正式文本：
require "vacation";
if address :matches "from" "*@ourdivision.example.com"
{
vacation :subject "Gone fishing"
"Having lots of fun! Back in a day or two!";
} else {
vacation :subject "Je suis parti cette semaine"
"Je lirai votre message quand je retourne.";
}
require "vacation";
if address :matches "from" "*@ourdivision.example.com"
{
vacation :subject "Gone fishing"
"Having lots of fun! Back in a day or two!";
} else {
vacation :subject "Je suis parti cette semaine"
"Je lirai votre message quand je retourne.";
}
IMPLEMENTATION NOTE: A graphical Sieve generation interface could in principle be used to hide the complexity of specifying response selection criteria from end users. Figuring out the right set of options to present in a graphical interface is likely a nontrivial proposition, but this is more because of the need to employ a variety of criteria to select different sorts of responses to send to different classes of people than because of the issues involved in selecting a response in an appropriate language.
实施说明：原则上可以使用图形筛选生成界面来隐藏向最终用户指定响应选择标准的复杂性。找出在图形界面中显示的正确选项集可能是一个不平凡的命题，但这更多的是因为需要使用各种标准来选择不同类型的响应发送给不同类别的人，而不是因为选择适当语言的响应所涉及的问题。
It is critical that implementations correctly implement the behavior and restrictions described throughout this document. Replies MUST NOT be sent out in response to messages not sent directly to the user, and replies MUST NOT be sent out more often than the :days argument states unless the script changes.
实现正确实现本文档中描述的行为和限制至关重要。对于未直接发送给用户的消息，不得发送回复，除非脚本发生更改，否则发送回复的频率不得超过：days参数的状态。
If mail is forwarded from a site that uses subaddressing, it may be impossible to list all recipient addresses with ":addresses".
如果邮件是从使用子地址的站点转发的，则可能无法列出所有带有“：addresses”的收件人地址。
Security issues associated with mail auto-responders are fully discussed in the security considerations section of [RFC3834]. This document is believed not to introduce any additional security considerations in this general area.
[RFC3834]的安全注意事项部分详细讨论了与邮件自动应答器相关的安全问题。相信本文件不会在这一一般领域引入任何额外的安全注意事项。
The following template specifies the IANA registration of the vacation Sieve extension specified in this document:
以下模板指定了本文档中指定的假期筛选扩展的IANA注册：
To: iana@iana.org Subject: Registration of new Sieve extension
致：iana@iana.org主题：新筛网扩展的注册
Capability name: vacation Description: adds an action for generating an auto-reply saying that the original message will not be read or answered immediately RFC number: RFC 5230
功能名称：假期描述：添加一个生成自动回复的操作，表示原始消息不会立即被读取或回复RFC编号：RFC 5230
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
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.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[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月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 38342004年8月。
[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月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229]Homme，K.，“筛选电子邮件过滤：变量扩展”，RFC5292008年1月。
[REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email Filtering: Reject Extension", Work in Progress, October 2007.
[拒绝]Stone，A.，Elvey，M.，和A.Melnikov，“筛选电子邮件过滤：拒绝扩展”，正在进行的工作，2007年10月。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，1997年5月。
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[RFC2369]Neufeld，G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，1998年7月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[RFC2919]Chandhok，R.和G.Wenger，“列表Id：用于识别邮件列表的结构化字段和名称空间”，RFC 2919，2001年3月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282]Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
This extension is obviously inspired by Eric Allman's vacation program under Unix. The authors owe a great deal to Carnegie Mellon University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, Jeffrey Hutzelman, Philip Guenther, and many others whose names have been lost during the inexcusably long gestation period of this document.
这个扩展显然受到了Eric Allman在Unix下的假期计划的启发。作者在很大程度上要归功于卡内基梅隆大学、塞勒斯·达布、劳伦斯·格林菲尔德、迈克尔·哈尔德、克杰蒂尔·托格里姆·霍姆、阿恩特·古尔布兰森、马克·马利特、阿列克谢·梅尔尼科夫、杰弗里·哈泽尔曼、菲利普·根瑟，以及许多其他人，他们的名字在这份文件漫长的酝酿过程中丢失了。
Authors' Addresses
作者地址
Tim Showalter
蒂姆·肖沃尔特
EMail: tjs@psaux.com
EMail: tjs@psaux.com
Ned Freed (editor) Sun Microsystems 3401 Centrelake Drive, Suite 410 Ontario, CA 92761-1205 USA
Ned Freed（编辑）美国加利福尼亚州安大略省410号套房太阳微系统3401 Centrelake Drive 92761-1205
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.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.