Skip to main content

Sieve Email Filtering: Vacation Extension
draft-ietf-sieve-vacation-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5230.
Authors Tim Showalter , Ned Freed
Last updated 2020-01-21 (Latest revision 2007-03-05)
Replaces draft-showalter-sieve-vacation
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5230 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Scott Hollenbeck
Send notices to alexey.melnikov@isode.com
draft-ietf-sieve-vacation-07
SIEVE Email Filtering Working                               T. Showalter
Group
Internet-Draft                                             N. Freed, Ed.
Expires: September 4, 2007                              Sun Microsystems
                                                           March 3, 2007

               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
   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).

Abstract

   This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

Showalter & Freed       Expires September 4, 2007               [Page 1]
Internet-Draft          Sieve Vacation Extension              March 2007

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.)

Showalter & Freed       Expires September 4, 2007               [Page 2]
Internet-Draft          Sieve Vacation Extension              March 2007

   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

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Capability Identifier  . . . . . . . . . . . . . . . . . . . .  4
   4.  Vacation Action  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Days Parameter . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Previous Response Tracking . . . . . . . . . . . . . . . .  5
     4.3.  Subject and From Parameters  . . . . . . . . . . . . . . .  7
     4.4.  MIME Parameter . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Address Parameter and Limiting Replies to Personal
           Messages . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.6.  Restricting Replies to Automated Processes and Mailing
           Lists  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Interaction with Other Sieve Actions . . . . . . . . . . .  9
     4.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Response Message Generation  . . . . . . . . . . . . . . . . . 10
     5.1.  SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10
     5.2.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  Subject  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.5.  To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.6.  Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11
     5.7.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 11
     5.8.  In-Reply-To and References . . . . . . . . . . . . . . . . 11
   6.  Relationship to Recommendations for Automatic Responses to
       Electronic Mail  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Internationalization Considerations  . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Showalter & Freed       Expires September 4, 2007               [Page 3]
Internet-Draft          Sieve Vacation Extension              March 2007

1.  Introduction

   This document defines an extension to the Sieve language defined in
   [I-D.ietf-sieve-3028bis] for notification that messages to a
   particular recipient will not be answered immediately.

2.  Conventions used in this document

   Conventions for notations are as in [I-D.ietf-sieve-3028bis] section
   1.1.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED"
   and "MAY" in this document are to be interpreted as defined in
   [RFC2119].

3.  Capability Identifier

   Sieve implementations that implement vacation have an identifier of
   "vacation" for use with the capability mechanism.

4.  Vacation Action

   Usage:   vacation [":days" number] [":subject" string]
                     [":from" string] [":addresses" string-list]
                     [":mime"] [":handle" string] <reason: string>

   The "vacation" action implements a vacation autoresponder similar to
   the vacation command available under many versions of Unix.  Its
   purpose is to provide correspondents with notification that the user
   is away for an extended period of time and that they should not
   expect quick responses.

   "Vacation" is used to respond to a message with another message.
   Vacation's messages are always addressed to the Return-Path address
   (that is, the envelope from address) of the message being responded
   to.

4.1.  Days Parameter

   The ":days" argument is used to specify the period in which addresses
   are kept and are not responded to, and is always specified in days.
   The minimum value used for this parameter is normally 1.  Sites MAY
   define a different minimum value as long as the minimum is greater
   than 0.  Sites MAY also define a maximum days value, which MUST be
   greater than 7, and SHOULD be greater than 30.

Showalter & Freed       Expires September 4, 2007               [Page 4]
Internet-Draft          Sieve Vacation Extension              March 2007

   If ":days" is omitted, the default value is either 7 or the minimum
   value (as defined above), whichever is greater.

   If the parameter given to ":days" is less than the minimum value,
   then the minimum value is used instead.

   If ":days" exceeds the site-defined maximum, the site-defined maximum
   is used instead.

4.2.  Previous Response Tracking

   "Vacation" keeps track of all of the responses it has sent to each
   address in some period (as specified by the :days optional argument).
   If vacation has not previously sent the response to this address
   within the given time period, it sends the "reason" argument to the
   SMTP MAIL FROM address [RFC2821] of the message that is being
   responded to.  (The SMTP MAIL FROM address should be available in the
   Return-path: header field if Sieve processing occurs after final
   delivery.)

   Tracking is not just per address, but must also take the vacation
   response itself into account.  A script writer might, for example,
   have a vacation action that will send a general notice only once in
   any two-week period.  However, even if a sender has received this
   general notice, it may be important to send a specific notice when a
   message about something timely or something specific has been
   detected.

   A particular vacation response can be identified in one of two ways.
   The first way is via an explicit :handle argument, which attaches a
   name to the response.  All vacation statements that use the same
   handle will be considered 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.

Showalter & Freed       Expires September 4, 2007               [Page 5]
Internet-Draft          Sieve Vacation Extension              March 2007

   require "vacation";
   if header :contains "subject" "cyrus" {
       vacation "I'm out -- send mail to cyrus-bugs";
   } else {
       vacation "I'm out -- call me at +1 304 555 0123";
   }

   In the above example, coyote@desert.example.org gets the second
   message despite having gotten the first one because separate vacation
   responses have been triggered.  This behavior is REQUIRED.

   There is one important exception to this rule, however.  If the Sieve
   variables extension [I-D.ietf-sieve-variables] is used, the arguments
   MUST NOT have undergone variable expansion prior to their use in
   response tracking.  This is so that examples like the following
   script will only generate a single response to each incoming message
   with a different subject line.

   require ["vacation", "variables"];
   if header :matches "subject" "*" {
       vacation :subject "Automatic response to: ${1}"
                "I'm away -- send mail to foo in my absence";
   }

   As noted above, the optional ":handle" parameter can be used to tell
   the Sieve interpreter to treat two vacation actions with different
   arguments as the same command for purposes of response tracking.  The
   argument to ":handle" is a string that identifies the type of
   response being sent.  For instance, if tweety@cage.example.org sends
   mail to spike@doghouse.example.com twice, one with the subject
   "lunch?" and once with the subject "dinner?", and
   spike@doghouse.example.com has the script shown below,
   tweety@cage.example.org will only receive a single response.  (Which
   response is sent depends on the order in which the messages are
   processed.)

   require "vacation";
   if header :contains "subject" "lunch" {
       vacation :handle "ran-away" "I'm out and can't meet for lunch";
   } else {
       vacation :handle "ran-away" "I'm out";
   }

   NOTE: One way to implement the necessary mechanism here is to store a
   hash of either the current handle and the recipient address or, if no
   handle is provided, a hash of the vacation action parameters
   specifying the message content and the recipient address.  If a
   script is changed, implementations MAY reset the records of who has

Showalter & Freed       Expires September 4, 2007               [Page 6]
Internet-Draft          Sieve Vacation Extension              March 2007

   been responded to and when they have been responded to.

   IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
   vacation action parameters.  In particular, since most parameters are
   optional, it is important not to let the same string used as the
   value for different parameters produce the same hash value.  One
   possible way to accomplish this apply the hash to a series of counted
   or null terminated strings, one for each possible parameter in
   particular order.

   Implementations are free to limit the number of remembered responses,
   however, the limit MUST NOT be less than 1000.  When limiting the
   number of tracked responses, implementations SHOULD discard the
   oldest ones first.

4.3.  Subject and From Parameters

   The ":subject" parameter specifies a subject line to attach to any
   vacation response that is generated.  UTF-8 characters can be used in
   the string argument; implementations MUST convert the string to
   [RFC2047] encoded words if and only if non-ASCII characters are
   present.  Implementations MUST generate an appropriate default
   subject line as specified below if no :subject parameter is
   specified.

   A ":from" parameter may be used to specify an alternate address to
   use in the From field of vacation messages.  The string must specify
   a valid [RFC2822] mailbox-list.  Implementations SHOULD check the
   syntax and generate an error when a syntactically invalid ":from"
   parameter is specified.  Implementations MAY also impose restrictions
   on what addresses can specified in a ":from" parameter; it is
   suggested that values which fail such a validity check simply be
   ignored rather than causing the vacation action to fail.

4.4.  MIME Parameter

   The ":mime" parameter, if supplied, specifies that the reason string
   is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
   including both MIME headers and content.

   If the optional :mime parameter is not supplied, the reason string is
   considered to be a UTF-8 string.

Showalter & Freed       Expires September 4, 2007               [Page 7]
Internet-Draft          Sieve Vacation Extension              March 2007

   require "vacation";
   vacation :mime text:
   Content-Type: multipart/alternative; boundary=foo

   --foo

   I'm at the beach relaxing.  Mmmm, surf...

   --foo
   Content-Type: text/html; charset=us-ascii

   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
    "http://www.w3.org/TR/REC-html40/strict.dtd">
   <HTML><HEAD><TITLE>How to relax</TITLE>
   <BASE HREF="http://home.example.com/pictures/"></HEAD>
   <BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
   Mmmm, <A HREF="ocean.gif">surf</A>...
   </BODY></HTML>

   --foo--
   .

4.5.  Address Parameter and Limiting Replies to Personal Messages

   "Vacation" MUST NOT respond to a message unless the recipient user's
   email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   "Resent-Bcc" line of the original message.  An email address is
   considered to belong to the recipient if it is one of:

   1.  An email address known by the implementation to be associated
       with the recipient,

   2.  the final envelope recipient address if it's available to the
       implementation, or

   3.  an address specified by the script writer via the ":addresses"
       argument described in the next paragraph.

   Users can supply additional mail addresses that are theirs with the
   ":addresses" argument, which takes a string-list listing additional
   addresses that a user might have.  These addresses are considered to
   belong to the recipient user in addition to the addresses known to
   the implementation.

4.6.  Restricting Replies to Automated Processes and Mailing Lists

   Implementations MAY refuse to send a vacation response to a message
   which contains any header or content that makes it appear that a

Showalter & Freed       Expires September 4, 2007               [Page 8]
Internet-Draft          Sieve Vacation Extension              March 2007

   response would not be appropriate.

   Implementations MUST have a list of addresses which "vacation" MUST
   NOT send mail to.  However, the contents of this list are
   implementation defined.  The purpose of this list is to stop mail
   from going to addresses used by system daemons that would not care if
   the user is actually reading her mail.

   Implementations are encouraged, however, to include well-known
   addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
   addresses typically used only by automated systems.  Additionally,
   addresses ending in "-request" or beginning in "owner-", i.e.,
   reserved for mailing list software, are also suggested.

   Implementors may take guidance from [RFC2142], but should be careful.
   Some addresses, like "POSTMASTER", are generally actually managed by
   people, and people do care if the user is going to be unavailable.

   Implementations SHOULD NOT respond to any message that contains a
   "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-
   Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369]
   header field.

   Implementations SHOULD NOT respond to any message that has an "Auto-
   submitted" header field with a value other than "no".  This header
   field is described in [RFC3834].

4.7.  Interaction with Other Sieve Actions

   Vacation does not affect Sieve's implicit keep action.

   Vacation can only be executed once per script.  A script MUST fail
   with an appropriate error if it attempts to execute two or more
   vacation actions.

   Implementations MUST NOT consider vacation used with discard, keep,
   fileinto, or redirect an error.  The vacation action is incompatible
   with the Sieve reject and refuse actions
   [I-D.ietf-sieve-refuse-reject].

4.8.  Examples

   Here is a simple use of vacation.

   require "vacation";
   vacation :days 23 :addresses ["tjs@example.edu",
                                 "ts4z@landru.example.edu"]
   "I'm away until October 19.

Showalter & Freed       Expires September 4, 2007               [Page 9]
Internet-Draft          Sieve Vacation Extension              March 2007

   If it's an emergency, call 911, I guess." ;

   By mingling vacation with other rules, users can do something more
   selective.

   require "vacation";
   if header :contains "from" "boss@example.edu" {
       redirect "pleeb@isp.example.org";
   } else {
       vacation "Sorry, I'm away, I'll read your
   message when I get around to it.";
   }

5.  Response Message Generation

   This section details the requirements for the generated response
   message.

   It is worth noting that the input message and arguments may be in
   UTF-8, and that implementations MUST deal with UTF-8 input, although
   implementations MAY transcode to other character sets as regional
   taste dictates.  When :mime is used the reason argument also contains
   MIME header information.  The headers must conform to MIME
   conventions; in particular, 8bit text is not allowed.
   Implementations SHOULD reject vacation :mime actions containing 8bit
   header material.

5.1.  SMTP MAIL FROM address

   The SMTP MAIL FROM address of the message envelope SHOULD be set to
   <>.  NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
   SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.

5.2.  Date

   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.

5.3.  Subject

   Users can specify the Subject of the reply with the ":subject"
   parameter.  If the :subject parameter is not supplied, then the
   subject is generated as follows: The subject is set to the characters
   "Auto: " followed by the original subject.  An appropriate fixed
   Subject such as "Automated reply" SHOULD be used in the event that
   :subject isn't specified and the original message doesn't contain a

Showalter & Freed       Expires September 4, 2007              [Page 10]
Internet-Draft          Sieve Vacation Extension              March 2007

   Subject field.

5.4.  From

   Unless explicitly overridden with a :from parameter, the From field
   SHOULD be set to the address of the owner of the Sieve script.

5.5.  To

   The To field SHOULD be set to the address of the recipient of the
   response.

5.6.  Auto-submitted

   An Auto-Submitted field with a value of "auto-replied" SHOULD be
   included in the message header of any vacation message sent.

5.7.  Message Body

   The body of the message is taken from the reason string in the
   vacation command.

5.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.

   Section 3.6.4 of [RFC2822] provides a complete description of how
   References fields should be generated.

6.  Relationship to Recommendations for Automatic Responses to
    Electronic Mail

   The vacation extension implements a "Personal Responder" in the
   terminology defined in [RFC3834].  Care has been taken in this
   specification to comply with the recommendations of [RFC3834]
   regarding how personal responders should behave.

7.  Internationalization Considerations

   Internationalization capabilities provided by the base Sieve language
   are discussed in [I-D.ietf-sieve-3028bis].  However, the vacation

Showalter & Freed       Expires September 4, 2007              [Page 11]
Internet-Draft          Sieve Vacation Extension              March 2007

   extension is the first Sieve extension to be defined that is capable
   of creating entirely new messages.  This section deals with
   internationalization issues raised by the use of the vacation
   extension.

   Vacation messages are normally written using the UTF-8 charset,
   allowing text to be written in most of the world's languages.
   Additionally, the :mime parameter allows specification of arbitrary
   MIME content.  In particular, this makes it possible to use
   multipart/alternative objects to specify vacation responses in
   multiple languages simultaneously.

   The Sieve language itself allows a vacation response to be selected
   based on the content of the original message.  For example, the
   Accept-Language or Content-Language header fields [RFC3282] could be
   checked and used to select appropriate text:

   require "vacation";
   if header :contains ["accept-language", "content-language"] "en"
   {
       vacation "I am away this week.";
   } else {
       vacation "Estoy ausente esta semana.";
   }

   Note that this rather simplistic test of the field values fails to
   take the structure of the fields into account and hence could be
   fooled by some more complex field values.  A more elaborate test
   could be used to deal with this problem.

   The approach of explicitly coding language selection criteria in
   scripts is preferred because in many cases language selection issues
   are conflated with other selection issues.  For example, it may be
   appropriate to use informal text in one language for vacation
   responses sent to a fellow employee while using more formal text in a
   different language in a response sent to a total stranger outside the
   company:

   require "vacation";
   if address :matches "from" "*@ourdivision.example.com"
   {
       vacation :subject "Gone fishing"
                "Having lots of fun! Back in a day or two!";
   } else {
       vacation :subject "Je suis parti cette semaine"
                "Je lirai votre message quand je retourne.";
   }

Showalter & Freed       Expires September 4, 2007              [Page 12]
Internet-Draft          Sieve Vacation Extension              March 2007

   IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
   principle be used to hide the complexity of specifying response
   selection criteria from end users.  Figuring out the right set of
   options to present in a graphical interface is likely a nontrivial
   proposition, but more because of the need to employ a variety of
   criteria to select different sorts of responses to send to different
   classes of people than because of the issues involved in selecting a
   response in an appropriate language.

8.  Security Considerations

   It is critical that implementations correctly implement the behavior
   and restrictions described throughout this document.  Replies MUST
   NOT be sent out in response to messages not sent directly to the
   user, and replies MUST NOT be sent out more often than the :days
   argument states unless the script changes.

   If mail is forwarded from a site that uses subaddressing, it may be
   impossible to list all recipient addresses with ":addresses".

   Security issues associated with mail auto-responders are fully
   discussed in the security consideration section of [RFC3834].  This
   document is believed not to introduce any additional security
   considerations in this general area.

9.  IANA Considerations

   The following template specifies the IANA registration of the
   vacation Sieve extension specified in this document:

      To: iana@iana.org
      Subject: Registration of new Sieve extension

      Capability name: vacation
      Description:     This document describes a Sieve extension for
                       an autoresponder similar to that of the  Unix
                       "vacation" command for replying to messages.
      RFC number:      RFC XXXX
      Contact address: Ned Freed <ned.freed@mrochek.com>

   This information should be added to the list of Sieve extensions
   given on http://www.iana.org/assignments/sieve-extensions.

10.  References

Showalter & Freed       Expires September 4, 2007              [Page 13]
Internet-Draft          Sieve Vacation Extension              March 2007

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
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 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
              Electronic Mail", RFC 3834, August 2004.

10.2.  Informative References

   [I-D.ietf-sieve-refuse-reject]
              Elvey, M. and A. Melnikov, "The SIEVE mail filtering
              language - reject and refuse extensions",
              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
              FUNCTIONS", RFC 2142, May 1997.

   [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax

Showalter & Freed       Expires September 4, 2007              [Page 14]
Internet-Draft          Sieve Vacation Extension              March 2007

              for Core Mail List Commands and their Transport through
              Message Header Fields", RFC 2369, July 1998.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2919]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
              and Namespace for the Identification of Mailing Lists",
              RFC 2919, March 2001.

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              May 2002.

Appendix A.  Acknowledgements

   This extension is obviously inspired by Eric Allman's vacation
   program under Unix.  The authors owe a great deal to Carnegie Mellon
   University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
   Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
   Jeffrey Hutzelman, Philip Guenther and many others whose names have
   been lost during the inexcusably long gestation period of this
   document.

Authors' Addresses

   Tim Showalter

   Email: tjs@psaux.com

   Ned Freed (editor)
   Sun Microsystems
   3401 Centrelake Drive, Suite 410
   Ontario, CA  92761-1205
   USA

   Phone: +1 909 457 4293
   Email: ned.freed@mrochek.com

Showalter & Freed       Expires September 4, 2007              [Page 15]
Internet-Draft          Sieve Vacation Extension              March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Showalter & Freed       Expires September 4, 2007              [Page 16]