draft-ietf-sieve-vacation-00.txt   draft-ietf-sieve-vacation-01.txt 
SIEVE Email Filtering Working T. Showalter SIEVE Email Filtering Working T. Showalter
Group ?? Group ??
Internet-Draft N. Freed Internet-Draft N. Freed, Ed.
Expires: September 15, 2005 Sun Microsystems Expires: October 3, 2005 Sun Microsystems
March 14, 2005 April 1, 2005
Sieve Email Filtering: Vacation Extension Sieve Email Filtering: Vacation Extension
draft-ietf-sieve-vacation-00 draft-ietf-sieve-vacation-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 15, 2005. This Internet-Draft will expire on October 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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) Change History (to be removed prior to publication as an RFC)
Changes from draft-showalter-sieve-vacation-06.txt: Changes from draft-showalter-sieve-vacation-06.txt:
1. Updated to XML source. 1. Updated to XML source.
2. Added :from parameter. 2. Added :from parameter.
3. Added more detailed description of :subject parameter
4. Fixed various minor typos. 3. Added :handle parameter.
4. Added more detailed description of :subject parameter
5. Clarified some discussion text.
6. Fixed various minor typos.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4
3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3 3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 4 3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 5
3.3 Subject and from parameters . . . . . . . . . . . . . . . 5 3.3 Subject and from parameters . . . . . . . . . . . . . . . 6
3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 5 3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Address Parameter and Limiting Replies to Personal 3.5 Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Restricting Replies to Automated Processes and Mailing 3.6 Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 6 3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 7
3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Response Message Generation . . . . . . . . . . . . . . . . . 7 4. Response Message Generation . . . . . . . . . . . . . . . . . 8
4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 7 4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 8
4.2 Subject Parameter . . . . . . . . . . . . . . . . . . . . 7 4.2 Subject Parameter . . . . . . . . . . . . . . . . . . . . 8
4.3 In-Reply-To and References . . . . . . . . . . . . . . . . 7 4.3 In-Reply-To and References . . . . . . . . . . . . . . . . 9
4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 7 4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 9
4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 8 4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 9
5. Relationship to Recommendations for Automatic Responses to 5. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 8 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12
1. Introduction 1. Introduction
This is an extension to the Sieve language defined by [RFC3028] for This is an extension to the Sieve language defined by [RFC3028] for
notification that messages will not be immediately answered. notification that messages will not be immediately answered.
Conventions for notations are as in [RFC3028] section 1.1. Conventions for notations are as in [RFC3028] section 1.1.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
"MAY" in this document are to be interpreted as defined in [RFC2119]. "MAY" in this document are to be interpreted as defined in [RFC2119].
2. Capability Identifier 2. 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.
3. Vacation Action 3. Vacation Action
Syntax: vacation [":days" number] [":subject" string] [":from" string] Syntax: vacation [":days" number] [":subject" string] [":from" string]
[":addresses" string-list] [":mime"] <reason: string> [":addresses" string-list] [":mime"] [":handle" string]
<reason: string>
The "vacation" action implements a vacation autoresponder similar to The "vacation" action implements a vacation autoresponder similar to
the vacation command available under many versions of Unix. Its the vacation command available under many versions of Unix. Its
purpose is to provide correspondents with notification that the user purpose is to provide correspondents with notification that the user
is away for an extended period of time and that they should not is away for an extended period of time and that they should not
expect quick responses. expect quick responses.
"Vacation" is used to respond to a message with another message. "Vacation" is used to respond to a message with another message.
Vacation's messages are always addressed to the Return-Path address Vacation's messages are always addressed to the Return-Path address
(that is, the envelope from address) of the message being responded (that is, the envelope from address) of the message being responded
skipping to change at page 4, line 16 skipping to change at page 5, line 17
"Vacation" keeps track of all of the responses it has sent to each "Vacation" keeps track of all of 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 of the message that is being responded to. SMTP MAIL FROM address of the message that is being responded to.
(The SMTP MAIL FROM address should be available in the Return-path: (The SMTP MAIL FROM address should be available in the Return-path:
header field if Sieve processing occurs after final delivery.) header field if Sieve processing occurs after final delivery.)
Vacation responses are not just per address, but are per address per Vacation responses are not just per address, but are per address per
set of arguments to the vacation command. For instance, If set of vacation command arguments. For instance, If
coyote@desert.example.org sends mail to roadrunner@acme.example.com, coyote@desert.example.org sends mail to roadrunner@acme.example.com
once with the subject "Cyrus bug" and once with the subject "come twice, once with the subject "Cyrus bug" and once with the subject
over for dinner", and roadrunner@acme.example.com has the script "come over for dinner", and roadrunner@acme.example.com has the
below, coyote@desert.example.org would receive two responses, once script shown below, coyote@desert.example.org would receive two
with the first message, once with the second. responses, once with the first message, once with the second.
Example: require "vacation"; Example: require "vacation";
if subject :contains "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 304 555 1212"; vacation "I'm out -- call me at 304 555 1212";
} }
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 vaca- message despite having gotten the first one because separate vaca-
tion responses have been triggered. This behavior is REQUIRED. tion responses have been triggered. This behavior is REQUIRED.
The "per set of arguments" described above is intended to ensure that The "per set of arguments" described above is intended to ensure that
a respondee gets all of the various possible responses, not merely a respondee gets all of the various possible responses, not merely
the first one. So, if the :subject or :mime parameters would result the first one. So, if the :subject or :mime parameters would result
in a different message, a different message MUST be sent by the in a different message, a different message MUST be sent by the
implementation. implementation.
If a script is changed, implementations MAY reset the records of who The optional ":handle" parameter can be used to tell the sieve
has been responded to and when they have been responded to. interpreter to treat two vacation commands with different arguments
Alternatively, implementations can store records of who has received as the same command for purposes of response tracking. The argument
which message, perhaps by storing a hash of the message and the to ":handle" is a string that identifies the type of response being
recipient. 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.
Implementations are free to limit the number of remembered responses, Example: require "vacation";
provided the limit is no less than 1000. 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";
}
Implementations SHOULD make the limit no less than 1000 per vacation Note that one way to implement the necessary mechanism here is to
command if using the hash algorithm described above. When limiting store a hash of either the current handle and the recipient or, if no
the number of tracked responses, implementations SHOULD discard the handle is provided, a hash of the generated message content and the
oldest ones first. recipient. If a script is changed, implementations MAY reset the
records of who has been responded to and when they have been
responded to.
Implementations are free to limit the number of remembered responses,
provided the limit is no less than 1000. When limiting the number of
tracked responses, implementations SHOULD discard the oldest ones
first.
3.3 Subject and from parameters 3.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 non-ASCII characters are present. [RFC2047] encoded words if non-ASCII characters are present.
Implementations SHOULD insert an apppropriate default subject line if Implementations SHOULD insert an apppropriate default subject line if
no :subject parameter is specified. no :subject parameter is specified.
skipping to change at page 5, line 26 skipping to change at page 6, line 45
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 security parameter is specified. Implementations MAY also impose security
restrictions on what addresses can specified in a ":from" parameter; restrictions on what addresses can specified in a ":from" parameter;
it is suggested that values which fail such a security check simply it is suggested that values which fail such a security check simply
be ignored rather than causing the vacation action to fail. be ignored rather than causing the vacation action to fail.
3.4 MIME Parameter 3.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 part, including MIME headers (see section 2.4.2.4 is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
of [RFC3028]). including both MIME headers and content (see section 2.4.2.4 of
[RFC3028]).
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 to be a UTF-8 string.
3.5 Address Parameter and Limiting Replies to Personal Messages 3.5 Address Parameter and Limiting Replies to Personal Messages
"Vacation" MUST NOT respond to a message unless the user's email "Vacation" MUST NOT respond to a message unless the user's email
address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
"Resent-Bcc" line of the original message. Implementations are "Resent-Bcc" line of the original message. Implementations are
assumed to know the user's email address, but users may have assumed to know the user's email address, but users may have
skipping to change at page 6, line 15 skipping to change at page 7, line 36
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 not to respond to any message with a Implementations SHOULD NOT respond to any message with a header that
header that begins with "List-". begins with "List-".
Implementations SHOULD NOT respond to any message that has an Implementations SHOULD NOT respond to any message that has an
"Auto-submitted" header field with a value other than "no". This "Auto-submitted" header field with a value other than "no". This
header field is described in [RFC3834]. header field is described in [RFC3834].
3.7 Interaction with Other Sieve Actions 3.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 will fail if Vacation can only be executed once per script. A script will fail if
skipping to change at page 7, line 19 skipping to change at page 8, line 41
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. taste dictates.
4.1 SMTP MAIL FROM address 4.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 is available. SMTP transaction if the NOTARY SMTP extension [RFC3461]is available.
4.2 Subject Parameter 4.2 Subject Parameter
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
"Re: " followed by the original subject with all leading occurrence "Re: " followed by the original subject with all leading occurrence
of the characters "Re: " stripped off. of the characters "Re: " stripped off.
4.3 In-Reply-To and References 4.3 In-Reply-To and References
skipping to change at page 9, line 20 skipping to change at page 10, line 45
[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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001. 2001.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001. RFC 3028, January 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
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.
8.2 Informative References 8.2 Informative References
[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.
Authors' Addresses Authors' Addresses
Tim Showalter Tim Showalter
?? ??
Email: tjs@psaux.com Email: tjs@psaux.com
Ned Freed Ned Freed (editor)
Sun Microsystems Sun Microsystems
Phone: +1 909 457 4293 Phone: +1 909 457 4293
Email: ned.freed@mrochek.com Email: ned.freed@mrochek.com
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 author owes a great deal to Carnegie Mellon program under Unix. The author owes a great deal to Carnegie Mellon
University, Cyrus Daboo, Lawrence Greenfield, and many others whose University, Cyrus Daboo, Lawrence Greenfield, and many others whose
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/