draft-ietf-sieve-vacation-01.txt   draft-ietf-sieve-vacation-02.txt 
SIEVE Email Filtering Working T. Showalter SIEVE Email Filtering Working T. Showalter
Group ?? Group ??
Internet-Draft N. Freed, Ed. Internet-Draft N. Freed, Ed.
Expires: October 3, 2005 Sun Microsystems Expires: October 15, 2005 Sun Microsystems
April 1, 2005 April 13, 2005
Sieve Email Filtering: Vacation Extension Sieve Email Filtering: Vacation Extension
draft-ietf-sieve-vacation-01 draft-ietf-sieve-vacation-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 3, 2005. This Internet-Draft will expire on October 15, 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 3, line 5 skipping to change at page 2, line 18
2. Added :from parameter. 2. Added :from parameter.
3. Added :handle parameter. 3. Added :handle parameter.
4. Added more detailed description of :subject parameter 4. Added more detailed description of :subject parameter
5. Clarified some discussion text. 5. Clarified some discussion text.
6. Fixed various minor typos. 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
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4
3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 5 3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 5
3.3 Subject and from parameters . . . . . . . . . . . . . . . 6 3.3 Subject and from parameters . . . . . . . . . . . . . . . 7
3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6 3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Address Parameter and Limiting Replies to Personal 3.5 Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Restricting Replies to Automated Processes and Mailing 3.6 Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 7 3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 8
3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Response Message Generation . . . . . . . . . . . . . . . . . 8 4. Response Message Generation . . . . . . . . . . . . . . . . . 9
4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 8 4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 9
4.2 Subject Parameter . . . . . . . . . . . . . . . . . . . . 8 4.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 In-Reply-To and References . . . . . . . . . . . . . . . . 9 4.3 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 9 4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 9
4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 9 4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
4.8 In-Reply-To and References . . . . . . . . . . . . . . . . 10
5. Relationship to Recommendations for Automatic Responses to 5. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 9 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13
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 to a particular recipient will not be
answered immediately.
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]
[":addresses" string-list] [":mime"] [":handle" string] [":from" string] [":addresses" string-list]
<reason: string> [":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
to. to.
3.1 Days Parameter 3.1 Days Parameter
The ":days" argument is used to specify the period in which addresses 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. 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 The minimum value used for this parameter is normally 1. Sites MAY
define a different minimum value. Sites MAY also define a maximum define a different minimum value as long as the minimum is greater
days value, which MUST be greater than 7, and SHOULD be greater than than 0. Sites MAY also define a maximum days value, which MUST be
30. greater than 7, and SHOULD be greater than 30.
If ":days" is omitted, the default value is either 7 or the minimum If ":days" is omitted, the default value is either 7 or the minimum
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.
3.2 Previous Response Tracking 3.2 Previous Response Tracking
"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 Tracking is not just per address, but must also take the vacation
set of vacation command arguments. For instance, If response itself into account. A script writer might, for example,
coyote@desert.example.org sends mail to roadrunner@acme.example.com have a vacation action that will send a general notice only once in
twice, once with the subject "Cyrus bug" and once with the subject any two-week period. However, even if a sender has received this
"come over for dinner", and roadrunner@acme.example.com has the general notice, it may be important to send a specific notice when a
script shown below, coyote@desert.example.org would receive two message about something timely or something specific has been
responses, once with the first message, once with the second. detected.
Example: require "vacation"; 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 to be the same response for tracking
purposes.
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 which use an identical combination of
these arguments are considered to be the same for tracking purposes.
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, once with the
first message, once with the second.
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 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 vacation
tion responses have been triggered. This behavior is REQUIRED. responses have been triggered. This behavior is REQUIRED.
The "per set of arguments" described above is intended to ensure that There is one important exception to this rule, however. If the sieve
a respondee gets all of the various possible responses, not merely variables extension [I-D.ietf-sieve-variables] is used, the arguments
the first one. So, if the :subject or :mime parameters would result MUST NOT have undergone variable expansion prior to their use in
in a different message, a different message MUST be sent by the response tracking. This is so that examples like the following
implementation. script will only generate a single response to each incomining
message with a different subject line.
The optional ":handle" parameter can be used to tell the sieve require ["vacation", "variables"];
interpreter to treat two vacation commands with different arguments if header :matches "subject" "*" {
as the same command for purposes of response tracking. The argument vacation :subject "Automatic response to: ${1}"
to ":handle" is a string that identifies the type of response being "I'm away -- send mail to foo in my absence";
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.
Example: require "vacation"; 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.)
require "vacation";
if header :contains "subject" "lunch" { if header :contains "subject" "lunch" {
vacation :handle "ran-away" "I'm out and can't meet for lunch"; vacation :handle "ran-away" "I'm out and can't meet for lunch";
} else { } else {
vacation :handle "ran-away" "I'm out"; vacation :handle "ran-away" "I'm out";
} }
Note that one way to implement the necessary mechanism here is to NOTE: One way to implement the necessary mechanism here is to store a
store a hash of either the current handle and the recipient or, if no hash of either the current handle and the recipient or, if no handle
handle is provided, a hash of the generated message content and the is provided, a hash of the vacation action parameters specifying the
recipient. If a script is changed, implementations MAY reset the message content and the recipient. If a script is changed,
records of who has been responded to and when they have been implementations MAY reset the records of who has been responded to
responded to. and when they have been responded to.
Implementations are free to limit the number of remembered responses, Implementations are free to limit the number of remembered responses,
provided the limit is no less than 1000. When limiting the number of provided the limit is no less than 1000. When limiting the number of
tracked responses, implementations SHOULD discard the oldest ones tracked responses, implementations SHOULD discard the oldest ones
first. 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
skipping to change at page 7, line 39 skipping to change at page 8, line 18
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 with a header that Implementations SHOULD NOT respond to any message with a 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-
"Auto-submitted" header field with a value other than "no". This submitted" header field with a value other than "no". This header
header field is described in [RFC3834]. 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
two vacation actions are used. it attempts to execute two or more 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. fileinto, or redirect an error. The vacation is incompatible with
reject.
3.8 Examples 3.8 Examples
Here is a simple use of vacation. Here is a simple use of vacation.
Example:
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.
Example: 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
message when I get around to it."; message when I get around to it.";
} }
4. Response Message Generation 4. 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. 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.
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 [RFC3461]is available. SMTP transaction if the NOTARY SMTP extension [RFC3461]is available.
4.2 Subject Parameter 4.2 Date
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
"Re: " followed by the original subject with all leading occurrence
of the characters "Re: " stripped off.
4.3 In-Reply-To and References 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.
Replies MUST have the In-Reply-To field set to the Message-ID of the 4.3 Subject
original message, and the References field must be updated with the
Message-ID of the original message.
If the original message lacks a Message-ID, an In-Reply-To need not Users can specify the Subject of the reply with the ":subject"
be generated, and References need not bne changed. 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.
4.4 From 4.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.
4.5 To 4.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.
skipping to change at page 9, line 34 skipping to change at page 10, line 10
4.6 Auto-submitted 4.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.
4.7 Message Body 4.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.
4.8 In-Reply-To and References
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.
If the original message lacks a Message-ID, an In-Reply-To need not
be generated, and References need not be changed.
5. Relationship to Recommendations for Automatic Responses to 5. Relationship to Recommendations for Automatic Responses to
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 [RFC3834] makes in specification to comply with the recommendations [RFC3834] makes in
regards to how personal responders should behave. regards to how personal responders should behave.
6. Security Considerations 6. Security Considerations
It is critical that implementations correctly implement the It is critical that implementations correctly implement the behavior
limitations described above. Replies MUST NOT be sent out in and rescriptions described throughout this document. Replies MUST
response to messages not sent directly to the user, and replies MUST NOT be sent out in response to messages not sent directly to the
NOT be sent out more often than the :days argument states. user, and replies MUST NOT be sent out more often than the :days
argument states unless the script changes.
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]. discussed in the security consideration section of [RFC3834].
7. IANA Considerations 7. 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
Capability keyword: vacation Capability keyword: vacation
Capability arguments: N/A Capability arguments: N/A
Standards Track/IESG-approved experimental RFC number: this RFC Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information: Person and email address to contact for further information:
Tim Showalter Ned Freed
E-Mail: tjs@psaux.com E-Mail: ned.freed@mrochek.com
This information should be added to the list of Sieve extensions This information should be added to the list of Sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
8. References 8. References
8.1 Normative References 8.1 Normative References
[I-D.ietf-sieve-variables]
Homme, K., "Sieve Mail Filtering Language: Variables
Extension", draft-ietf-sieve-variables-02 (work in
progress), April 2005, <http://www.ietf.org/
internet-drafts/draft-ietf-sieve-variables-02.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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2001. April 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 [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.
skipping to change at page 11, line 19 skipping to change at page 12, line 14
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
Ontario, CA 92761-1205
USA
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 authors owe a great deal to Carnegie Mellon
University, Cyrus Daboo, Lawrence Greenfield, and many others whose University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
names have been lost during the inexcusably long gestation period of Torgrim Homme, Arnt Gulbrandsen, and many others whose names have
this document. been lost during the inexcusably long gestation period of this
document.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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