draft-ietf-sieve-vacation-07.txt   rfc5230.txt 
SIEVE Email Filtering Working T. Showalter Network Working Group T. Showalter
Group Request for Comments: 5230
Internet-Draft N. Freed, Ed. Category: Standards Track N. Freed, Ed.
Expires: September 4, 2007 Sun Microsystems Sun Microsystems
March 3, 2007 January 2008
Sieve Email Filtering: Vacation Extension Sieve Email Filtering: Vacation Extension
draft-ietf-sieve-vacation-07
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007). 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.
Abstract Abstract
This document describes an extension to the Sieve email filtering This document describes an extension to the Sieve email filtering
language for an autoresponder similar to that of the Unix "vacation" language for an autoresponder similar to that of the Unix "vacation"
command for replying to messages. Various safety features are command for replying to messages. Various safety features are
included to prevent problems such as message loops. included to prevent problems such as message loops.
Change History (to be removed prior to publication as an RFC)
Changes from draft-showalter-sieve-vacation-06.txt:
1. Updated to XML source.
2. Added :from parameter.
3. Added :handle parameter.
4. Added more detailed description of :subject parameter
5. Clarified some discussion text.
6. Fixed various minor typos.
7. Refinement of duplicate response suppression semantics
8. Added a statement that vacation is incompatible with reject
9. Prohibited the use of 8bit material in MIME headers specified
when :mime is in effect.
10. Use "Auto:" instead of "Re:" in automatically generated subject
lines
11. Added an explicit list of registered "List-*" header fields to
check for
12. Switched Syntax: label to Usage:
13. Updated draft to refer to RFC 3028bis instead of RFC 3028.
14. Removed reference to section 2.4.2.4 of RFC 3028 since the
section no longer exists in the revised version.
15. Updated reference for Sieve reject, added text about refuse.
16. Added reference to RFC 2822 section 3.6.4 - explains how to
construct references fields.
17. The minimum of 1000 remembered responses and the requirement
that scripts fail when two or more vacation actions are executed
are now normative.
18. Added text making it explicit that it is OK to have additional
implementation-specific checks to see if a vacation response
should be sent. (This just reiterates the advice in RFC 3834.)
19. Added an implementation note about how to construct a hash of
vacation action parameters.
20. Clarified what to do when :subject isn't used and the original
message also doesn't contain a Subject field.
21. Corrected typos, added Internationalization Considerations
section.
22. Updated IANA Considerations with new registrtion form
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
4.3. Subject and From Parameters . . . . . . . . . . . . . . . 7 4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Address Parameter and Limiting Replies to Personal 4.5. Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Restricting Replies to Automated Processes and Mailing 4.6. Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 9 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Response Message Generation . . . . . . . . . . . . . . . . . 10 5. Response Message Generation . . . . . . . . . . . . . . . . . 9
5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
6. Relationship to Recommendations for Automatic Responses to 6. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
7. Internationalization Considerations . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
This document defines an extension to the Sieve language defined in This document defines an extension to the Sieve language defined in
[I-D.ietf-sieve-3028bis] for notification that messages to a [RFC5228] for notification that messages to a particular recipient
particular recipient will not be answered immediately. will not be answered immediately.
2. Conventions used in this document 2. Conventions Used in This Document
Conventions for notations are as in [I-D.ietf-sieve-3028bis] section Conventions for notations are as in [RFC5228] section 1.1.
1.1.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED",
and "MAY" in this document are to be interpreted as defined in and "MAY" in this document are to be interpreted as defined in
[RFC2119]. [RFC2119].
3. Capability Identifier 3. Capability Identifier
Sieve implementations that implement vacation have an identifier of Sieve implementations that implement vacation have an identifier of
"vacation" for use with the capability mechanism. "vacation" for use with the capability mechanism.
4. Vacation Action 4. Vacation Action
skipping to change at page 5, line 16 skipping to change at page 4, line 13
value (as defined above), whichever is greater. value (as defined above), whichever is greater.
If the parameter given to ":days" is less than the minimum value, If the parameter given to ":days" is less than the minimum value,
then the minimum value is used instead. then the minimum value is used instead.
If ":days" exceeds the site-defined maximum, the site-defined maximum If ":days" exceeds the site-defined maximum, the site-defined maximum
is used instead. is used instead.
4.2. Previous Response Tracking 4.2. Previous Response Tracking
"Vacation" keeps track of all of the responses it has sent to each "Vacation" keeps track of all the responses it has sent to each
address in some period (as specified by the :days optional argument). address in some period (as specified by the :days optional argument).
If vacation has not previously sent the response to this address If vacation has not previously sent the response to this address
within the given time period, it sends the "reason" argument to the within the given time period, it sends the "reason" argument to the
SMTP MAIL FROM address [RFC2821] of the message that is being SMTP MAIL FROM address [RFC2821] of the message that is being
responded to. (The SMTP MAIL FROM address should be available in the responded to. (The SMTP MAIL FROM address should be available in the
Return-path: header field if Sieve processing occurs after final Return-path: header field if Sieve processing occurs after final
delivery.) delivery.)
Tracking is not just per address, but must also take the vacation Tracking is not just per address, but must also take the vacation
response itself into account. A script writer might, for example, response itself into account. A script writer might, for example,
have a vacation action that will send a general notice only once in 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 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 general notice, it may be important to send a specific notice when a
message about something timely or something specific has been message about something timely or something specific has been
detected. detected.
A particular vacation response can be identified in one of two ways. A particular vacation response can be identified in one of two ways.
The first way is via an explicit :handle argument, which attaches a The first way is via an explicit :handle argument, which attaches a
name to the response. All vacation statements that use the same name to the response. All vacation statements that use the same
handle will be considered to be the same response for tracking handle will be considered the same response for tracking purposes.
purposes.
The second way is via a synthesis of the :subject, :from, :mime, and The second way is via a synthesis of the :subject, :from, :mime, and
reason vacation command arguments. All vacation actions that do not reason vacation command arguments. All vacation actions that do not
contain an explicit handle and which use an identical combination of contain an explicit handle and that use an identical combination of
these arguments are considered to be the same for tracking purposes. these arguments are considered the same for tracking purposes.
For instance, If coyote@desert.example.org sends mail to For instance, if coyote@desert.example.org sends mail to
roadrunner@acme.example.com twice, once with the subject "Cyrus bug" roadrunner@acme.example.com twice, once with the subject "Cyrus bug"
and once with the subject "come over for dinner", and and once with the subject "come over for dinner", and
roadrunner@acme.example.com has the script shown below, roadrunner@acme.example.com has the script shown below,
coyote@desert.example.org would receive two responses, once with the coyote@desert.example.org would receive two responses, one with the
first message, once with the second. first message, one with the second.
require "vacation"; require "vacation";
if header :contains "subject" "cyrus" { if header :contains "subject" "cyrus" {
vacation "I'm out -- send mail to cyrus-bugs"; vacation "I'm out -- send mail to cyrus-bugs";
} else { } else {
vacation "I'm out -- call me at +1 304 555 0123"; vacation "I'm out -- call me at +1 304 555 0123";
} }
In the above example, coyote@desert.example.org gets the second In the above example, coyote@desert.example.org gets the second
message despite having gotten the first one because separate vacation message despite having gotten the first one because separate vacation
responses have been triggered. This behavior is REQUIRED. responses have been triggered. This behavior is REQUIRED.
There is one important exception to this rule, however. If the Sieve There is one important exception to this rule, however. If the Sieve
variables extension [I-D.ietf-sieve-variables] is used, the arguments variables extension [RFC5229] is used, the arguments MUST NOT have
MUST NOT have undergone variable expansion prior to their use in undergone variable expansion prior to their use in response tracking.
response tracking. This is so that examples like the following This is so that examples like the following script will only generate
script will only generate a single response to each incoming message a single response to each incoming message with a different subject
with a different subject line. line.
require ["vacation", "variables"]; require ["vacation", "variables"];
if header :matches "subject" "*" { if header :matches "subject" "*" {
vacation :subject "Automatic response to: ${1}" vacation :subject "Automatic response to: ${1}"
"I'm away -- send mail to foo in my absence"; "I'm away -- send mail to foo in my absence";
} }
As noted above, the optional ":handle" parameter can be used to tell As noted above, the optional ":handle" parameter can be used to tell
the Sieve interpreter to treat two vacation actions with different the Sieve interpreter to treat two vacation actions with different
arguments as the same command for purposes of response tracking. The arguments as the same command for purposes of response tracking. The
skipping to change at page 7, line 10 skipping to change at page 6, line 4
hash of either the current handle and the recipient address or, if no hash of either the current handle and the recipient address or, if no
handle is provided, a hash of the vacation action parameters handle is provided, a hash of the vacation action parameters
specifying the message content and the recipient address. If a specifying the message content and the recipient address. If a
script is changed, implementations MAY reset the records of who has script is changed, implementations MAY reset the records of who has
been responded to and when they have been responded to. been responded to and when they have been responded to.
IMPLEMENTATION NOTE: Care must be taken in constructing a hash of IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
vacation action parameters. In particular, since most parameters are vacation action parameters. In particular, since most parameters are
optional, it is important not to let the same string used as the optional, it is important not to let the same string used as the
value for different parameters produce the same hash value. One value for different parameters produce the same hash value. One
possible way to accomplish this apply the hash to a series of counted possible way to accomplish this is to apply the hash to a series of
or null terminated strings, one for each possible parameter in counted or null terminated strings, one for each possible parameter
particular order. in particular order.
Implementations are free to limit the number of remembered responses, Implementations are free to limit the number of remembered responses;
however, the limit MUST NOT be less than 1000. When limiting the however, the limit MUST NOT be less than 1000. When limiting the
number of tracked responses, implementations SHOULD discard the number of tracked responses, implementations SHOULD discard the
oldest ones first. oldest ones first.
4.3. Subject and From Parameters 4.3. Subject and From Parameters
The ":subject" parameter specifies a subject line to attach to any The ":subject" parameter specifies a subject line to attach to any
vacation response that is generated. UTF-8 characters can be used in vacation response that is generated. UTF-8 characters can be used in
the string argument; implementations MUST convert the string to the string argument; implementations MUST convert the string to
[RFC2047] encoded words if and only if non-ASCII characters are [RFC2047] encoded words if and only if non-ASCII characters are
present. Implementations MUST generate an appropriate default present. Implementations MUST generate an appropriate default
subject line as specified below if no :subject parameter is subject line as specified below if no :subject parameter is
specified. specified.
A ":from" parameter may be used to specify an alternate address to A ":from" parameter may be used to specify an alternate address to
use in the From field of vacation messages. The string must specify use in the From field of vacation messages. The string must specify
a valid [RFC2822] mailbox-list. Implementations SHOULD check the a valid [RFC2822] mailbox-list. Implementations SHOULD check the
syntax and generate an error when a syntactically invalid ":from" syntax and generate an error when a syntactically invalid ":from"
parameter is specified. Implementations MAY also impose restrictions parameter is specified. Implementations MAY also impose restrictions
on what addresses can specified in a ":from" parameter; it is on what addresses can specified in a ":from" parameter; it is
suggested that values which fail such a validity check simply be suggested that values that fail such a validity check simply be
ignored rather than causing the vacation action to fail. ignored rather than cause the vacation action to fail.
4.4. MIME Parameter 4.4. MIME Parameter
The ":mime" parameter, if supplied, specifies that the reason string The ":mime" parameter, if supplied, specifies that the reason string
is, in fact, a MIME entity as defined in [RFC2045] section 2.4, is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
including both MIME headers and content. including both MIME headers and content.
If the optional :mime parameter is not supplied, the reason string is If the optional :mime parameter is not supplied, the reason string is
considered to be a UTF-8 string. considered a UTF-8 string.
require "vacation"; require "vacation";
vacation :mime text: vacation :mime text:
Content-Type: multipart/alternative; boundary=foo Content-Type: multipart/alternative; boundary=foo
--foo --foo
I'm at the beach relaxing. Mmmm, surf... I'm at the beach relaxing. Mmmm, surf...
--foo --foo
skipping to change at page 8, line 34 skipping to change at page 7, line 34
--foo-- --foo--
. .
4.5. Address Parameter and Limiting Replies to Personal Messages 4.5. Address Parameter and Limiting Replies to Personal Messages
"Vacation" MUST NOT respond to a message unless the recipient user's "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 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
"Resent-Bcc" line of the original message. An email address is "Resent-Bcc" line of the original message. An email address is
considered to belong to the recipient if it is one of: considered to belong to the recipient if it is one of:
1. An email address known by the implementation to be associated 1. an email address known by the implementation to be associated
with the recipient, with the recipient,
2. the final envelope recipient address if it's available to the 2. the final envelope recipient address if it's available to the
implementation, or implementation, or
3. an address specified by the script writer via the ":addresses" 3. an address specified by the script writer via the ":addresses"
argument described in the next paragraph. argument described in the next paragraph.
Users can supply additional mail addresses that are theirs with the Users can supply additional mail addresses that are theirs with the
":addresses" argument, which takes a string-list listing additional ":addresses" argument, which takes a string-list listing additional
addresses that a user might have. These addresses are considered to addresses that a user might have. These addresses are considered to
belong to the recipient user in addition to the addresses known to belong to the recipient user in addition to the addresses known to
the implementation. the implementation.
4.6. Restricting Replies to Automated Processes and Mailing Lists 4.6. Restricting Replies to Automated Processes and Mailing Lists
Implementations MAY refuse to send a vacation response to a message Implementations MAY refuse to send a vacation response to a message
which contains any header or content that makes it appear that a that contains any header or content that makes it appear that a
response would not be appropriate. response would not be appropriate.
Implementations MUST have a list of addresses which "vacation" MUST Implementations MUST have a list of addresses that "vacation" MUST
NOT send mail to. However, the contents of this list are NOT send mail to. However, the contents of this list are
implementation defined. The purpose of this list is to stop mail implementation defined. The purpose of this list is to stop mail
from going to addresses used by system daemons that would not care if from going to addresses used by system daemons that would not care if
the user is actually reading her mail. the user is actually reading her mail.
Implementations are encouraged, however, to include well-known Implementations are encouraged, however, to include well-known
addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
addresses typically used only by automated systems. Additionally, addresses typically used only by automated systems. Additionally,
addresses ending in "-request" or beginning in "owner-", i.e., addresses ending in "-request" or beginning in "owner-", i.e.,
reserved for mailing list software, are also suggested. reserved for mailing list software, are also suggested.
Implementors may take guidance from [RFC2142], but should be careful. Implementors may take guidance from [RFC2142], but should be careful.
Some addresses, like "POSTMASTER", are generally actually managed by Some addresses, like "POSTMASTER", are generally actually managed by
people, and people do care if the user is going to be unavailable. people, and people do care if the user is going to be unavailable.
Implementations SHOULD NOT respond to any message that contains a Implementations SHOULD NOT respond to any message that contains a
"List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-
Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369]
header field. header field.
Implementations SHOULD NOT respond to any message that has an "Auto- Implementations SHOULD NOT respond to any message that has an "Auto-
submitted" header field with a value other than "no". This header submitted" header field with a value other than "no". This header
field is described in [RFC3834]. field is described in [RFC3834].
4.7. Interaction with Other Sieve Actions 4.7. Interaction with Other Sieve Actions
Vacation does not affect Sieve's implicit keep action. Vacation does not affect Sieve's implicit keep action.
Vacation can only be executed once per script. A script MUST fail Vacation can only be executed once per script. A script MUST fail
with an appropriate error if it attempts to execute two or more with an appropriate error if it attempts to execute two or more
vacation actions. vacation actions.
Implementations MUST NOT consider vacation used with discard, keep, Implementations MUST NOT consider vacation used with discard, keep,
fileinto, or redirect an error. The vacation action is incompatible fileinto, or redirect an error. The vacation action is incompatible
with the Sieve reject and refuse actions with the Sieve reject and refuse actions [REJECT].
[I-D.ietf-sieve-refuse-reject].
4.8. Examples 4.8. Examples
Here is a simple use of vacation. Here is a simple use of vacation.
require "vacation"; require "vacation";
vacation :days 23 :addresses ["tjs@example.edu", vacation :days 23 :addresses ["tjs@example.edu",
"ts4z@landru.example.edu"] "ts4z@landru.example.edu"]
"I'm away until October 19. "I'm away until October 19.
If it's an emergency, call 911, I guess." ; If it's an emergency, call 911, I guess." ;
By mingling vacation with other rules, users can do something more By mingling vacation with other rules, users can do something more
selective. selective.
require "vacation"; require "vacation";
if header :contains "from" "boss@example.edu" { if header :contains "from" "boss@example.edu" {
redirect "pleeb@isp.example.org"; redirect "pleeb@isp.example.org";
} else { } else {
vacation "Sorry, I'm away, I'll read your vacation "Sorry, I'm away, I'll read your
skipping to change at page 10, line 26 skipping to change at page 9, line 34
} }
5. Response Message Generation 5. Response Message Generation
This section details the requirements for the generated response This section details the requirements for the generated response
message. message.
It is worth noting that the input message and arguments may be in 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 UTF-8, and that implementations MUST deal with UTF-8 input, although
implementations MAY transcode to other character sets as regional implementations MAY transcode to other character sets as regional
taste dictates. When :mime is used the reason argument also contains taste dictates. When :mime is used, the reason argument also
MIME header information. The headers must conform to MIME contains MIME header information. The headers must conform to MIME
conventions; in particular, 8bit text is not allowed. conventions; in particular, 8bit text is not allowed.
Implementations SHOULD reject vacation :mime actions containing 8bit Implementations SHOULD reject vacation :mime actions containing 8bit
header material. header material.
5.1. SMTP MAIL FROM address 5.1. SMTP MAIL FROM Address
The SMTP MAIL FROM address of the message envelope SHOULD be set to 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 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
SMTP transaction if the NOTARY SMTP extension [RFC3461] is available. SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.
5.2. Date 5.2. Date
The Date field SHOULD be set to the date and time when the vacation 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 response was generated. Note that this may not be the same as the
time the message was delivered to the user. time the message was delivered to the user.
5.3. Subject 5.3. Subject
Users can specify the Subject of the reply with the ":subject" Users can specify the Subject of the reply with the ":subject"
parameter. If the :subject parameter is not supplied, then the parameter. If the :subject parameter is not supplied, then the
subject is generated as follows: The subject is set to the characters subject is generated as follows: The subject is set to the characters
"Auto: " followed by the original subject. An appropriate fixed "Auto: " followed by the original subject. An appropriate fixed
Subject such as "Automated reply" SHOULD be used in the event that 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 isn't specified and the original message doesn't contain a
Subject field. Subject field.
5.4. From 5.4. From
Unless explicitly overridden with a :from parameter, the From field Unless explicitly overridden with a :from parameter, the From field
SHOULD be set to the address of the owner of the Sieve script. SHOULD be set to the address of the owner of the Sieve script.
5.5. To 5.5. To
The To field SHOULD be set to the address of the recipient of the The To field SHOULD be set to the address of the recipient of the
response. response.
5.6. Auto-submitted 5.6. Auto-Submitted
An Auto-Submitted field with a value of "auto-replied" SHOULD be An Auto-Submitted field with a value of "auto-replied" SHOULD be
included in the message header of any vacation message sent. included in the message header of any vacation message sent.
5.7. Message Body 5.7. Message Body
The body of the message is taken from the reason string in the The body of the message is taken from the reason string in the
vacation command. vacation command.
5.8. In-Reply-To and References 5.8. In-Reply-To and References
skipping to change at page 11, line 49 skipping to change at page 11, line 16
Electronic Mail Electronic Mail
The vacation extension implements a "Personal Responder" in the The vacation extension implements a "Personal Responder" in the
terminology defined in [RFC3834]. Care has been taken in this terminology defined in [RFC3834]. Care has been taken in this
specification to comply with the recommendations of [RFC3834] specification to comply with the recommendations of [RFC3834]
regarding how personal responders should behave. regarding how personal responders should behave.
7. Internationalization Considerations 7. Internationalization Considerations
Internationalization capabilities provided by the base Sieve language Internationalization capabilities provided by the base Sieve language
are discussed in [I-D.ietf-sieve-3028bis]. However, the vacation are discussed in [RFC5228]. However, the vacation extension is the
extension is the first Sieve extension to be defined that is capable first Sieve extension to be defined that is capable of creating
of creating entirely new messages. This section deals with entirely new messages. This section deals with internationalization
internationalization issues raised by the use of the vacation issues raised by the use of the vacation extension.
extension.
Vacation messages are normally written using the UTF-8 charset, Vacation messages are normally written using the UTF-8 charset,
allowing text to be written in most of the world's languages. allowing text to be written in most of the world's languages.
Additionally, the :mime parameter allows specification of arbitrary Additionally, the :mime parameter allows specification of arbitrary
MIME content. In particular, this makes it possible to use MIME content. In particular, this makes it possible to use
multipart/alternative objects to specify vacation responses in multipart/alternative objects to specify vacation responses in
multiple languages simultaneously. multiple languages simultaneously.
The Sieve language itself allows a vacation response to be selected The Sieve language itself allows a vacation response to be selected
based on the content of the original message. For example, the based on the content of the original message. For example, the
skipping to change at page 13, line 4 skipping to change at page 12, line 14
require "vacation"; require "vacation";
if address :matches "from" "*@ourdivision.example.com" if address :matches "from" "*@ourdivision.example.com"
{ {
vacation :subject "Gone fishing" vacation :subject "Gone fishing"
"Having lots of fun! Back in a day or two!"; "Having lots of fun! Back in a day or two!";
} else { } else {
vacation :subject "Je suis parti cette semaine" vacation :subject "Je suis parti cette semaine"
"Je lirai votre message quand je retourne."; "Je lirai votre message quand je retourne.";
} }
IMPLEMENTATION NOTE: A graphical Sieve generation interface could in IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
principle be used to hide the complexity of specifying response principle be used to hide the complexity of specifying response
selection criteria from end users. Figuring out the right set of selection criteria from end users. Figuring out the right set of
options to present in a graphical interface is likely a nontrivial options to present in a graphical interface is likely a nontrivial
proposition, but more because of the need to employ a variety of proposition, but this is more because of the need to employ a variety
criteria to select different sorts of responses to send to different of criteria to select different sorts of responses to send to
classes of people than because of the issues involved in selecting a different classes of people than because of the issues involved in
response in an appropriate language. selecting a response in an appropriate language.
8. Security Considerations 8. Security Considerations
It is critical that implementations correctly implement the behavior It is critical that implementations correctly implement the behavior
and restrictions described throughout this document. Replies MUST and restrictions described throughout this document. Replies MUST
NOT be sent out in response to messages not sent directly to the 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 user, and replies MUST NOT be sent out more often than the :days
argument states unless the script changes. argument states unless the script changes.
If mail is forwarded from a site that uses subaddressing, it may be If mail is forwarded from a site that uses subaddressing, it may be
impossible to list all recipient addresses with ":addresses". impossible to list all recipient addresses with ":addresses".
Security issues associated with mail auto-responders are fully Security issues associated with mail auto-responders are fully
discussed in the security consideration section of [RFC3834]. This discussed in the security considerations section of [RFC3834]. This
document is believed not to introduce any additional security document is believed not to introduce any additional security
considerations in this general area. considerations in this general area.
9. IANA Considerations 9. IANA Considerations
The following template specifies the IANA registration of the The following template specifies the IANA registration of the
vacation Sieve extension specified in this document: vacation Sieve extension specified in this document:
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: vacation Capability name: vacation
Description: This document describes a Sieve extension for Description: adds an action for generating an auto-reply saying
an autoresponder similar to that of the Unix that the original message will not be read or
"vacation" command for replying to messages. answered immediately
RFC number: RFC XXXX RFC number: RFC 5230
Contact address: Ned Freed <ned.freed@mrochek.com> Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
This information should be added to the list of Sieve extensions This information has been added to the list of Sieve extensions given
given on http://www.iana.org/assignments/sieve-extensions. on http://www.iana.org/assignments/sieve-extensions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sieve-3028bis]
Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", draft-ietf-sieve-3028bis-12 (work in progress),
February 2007, <http://www.ietf.org/internet-drafts/
draft-ietf-sieve-3028bis-12.txt>.
[I-D.ietf-sieve-variables]
Homme, K., "Sieve Mail Filtering Language: Variables
Extension", draft-ietf-sieve-variables-08 (work in
progress), December 2005, <http://www.ietf.org/
internet-drafts/draft-ietf-sieve-variables-08.txt>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 14, line 40 skipping to change at page 13, line 34
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003. RFC 3461, January 2003.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004. Electronic Mail", RFC 3834, August 2004.
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, January 2008.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-sieve-refuse-reject] [REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email
Elvey, M. and A. Melnikov, "The SIEVE mail filtering Filtering: Reject Extension", Work in Progress,
language - reject and refuse extensions", October 2007.
draft-ietf-sieve-refuse-reject (work in progress),
May 2005, <http://www.ietf.org/internet-drafts/
draft-ietf-sieve-refuse-reject.txt>.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, July 1998. Message Header Fields", RFC 2369, July 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
skipping to change at page 15, line 23 skipping to change at page 15, line 11
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002. May 2002.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This extension is obviously inspired by Eric Allman's vacation This extension is obviously inspired by Eric Allman's vacation
program under Unix. The authors owe a great deal to Carnegie Mellon program under Unix. The authors owe a great deal to Carnegie Mellon
University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
Jeffrey Hutzelman, Philip Guenther and many others whose names have Jeffrey Hutzelman, Philip Guenther, and many others whose names have
been lost during the inexcusably long gestation period of this been lost during the inexcusably long gestation period of this
document. document.
Authors' Addresses Authors' Addresses
Tim Showalter Tim Showalter
Email: tjs@psaux.com EMail: tjs@psaux.com
Ned Freed (editor) Ned Freed (editor)
Sun Microsystems Sun Microsystems
3401 Centrelake Drive, Suite 410 3401 Centrelake Drive, Suite 410
Ontario, CA 92761-1205 Ontario, CA 92761-1205
USA USA
Phone: +1 909 457 4293 Phone: +1 909 457 4293
Email: ned.freed@mrochek.com EMail: ned.freed@mrochek.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 16, line 44 skipping to change at line 636
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 51 change blocks. 
195 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/