[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-showalter-sieve-vacation) 00 01 02 03 04 05 06 07 RFC 5230

SIEVE Email Filtering Working                               T. Showalter
Group                                                                 ??
Internet-Draft                                             N. Freed, Ed.
Expires: October 3, 2005                                Sun Microsystems
                                                           April 1, 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 October 3, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 October 3, 2005                [Page 1]

Internet-Draft               Sieve Vacation                   April 2005


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.




































Showalter & Freed        Expires October 3, 2005                [Page 2]

Internet-Draft               Sieve Vacation                   April 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Capability Identifier  . . . . . . . . . . . . . . . . . . . .  4
   3.  Vacation Action  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Days Parameter . . . . . . . . . . . . . . . . . . . . . .  4
     3.2   Previous Response Tracking . . . . . . . . . . . . . . . .  5
     3.3   Subject and from parameters  . . . . . . . . . . . . . . .  6
     3.4   MIME Parameter . . . . . . . . . . . . . . . . . . . . . .  6
     3.5   Address Parameter and Limiting Replies to Personal
           Messages . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.6   Restricting Replies to Automated Processes and Mailing
           Lists  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.7   Interaction with Other Sieve Actions . . . . . . . . . . .  7
     3.8   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Response Message Generation  . . . . . . . . . . . . . . . . .  8
     4.1   SMTP MAIL FROM address . . . . . . . . . . . . . . . . . .  8
     4.2   Subject Parameter  . . . . . . . . . . . . . . . . . . . .  8
     4.3   In-Reply-To and References . . . . . . . . . . . . . . . .  9
     4.4   From . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5   To . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.6   Auto-submitted . . . . . . . . . . . . . . . . . . . . . .  9
     4.7   Message Body . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Relationship to Recommendations for Automatic Responses to
       Electronic Mail  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12


















Showalter & Freed        Expires October 3, 2005                [Page 3]

Internet-Draft               Sieve Vacation                   April 2005


1.  Introduction

   This is an extension to the Sieve language defined by [RFC3028] for
   notification that messages will not be immediately answered.

   Conventions for notations are as in [RFC3028] section 1.1.

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

2.  Capability Identifier

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

3.  Vacation Action

   Syntax:   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.

3.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.  Sites MAY also define a maximum
   days value, which MUST be greater than 7, and SHOULD be greater than
   30.

   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



Showalter & Freed        Expires October 3, 2005                [Page 4]

Internet-Draft               Sieve Vacation                   April 2005


   is used instead.

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

   Vacation responses are not just per address, but are per address per
   set of vacation command arguments.  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.

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

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

   The "per set of arguments" described above is intended to ensure that
   a respondee gets all of the various possible responses, not merely
   the first one.  So, if the :subject or :mime parameters would result
   in a different message, a different message MUST be sent by the
   implementation.

   The optional ":handle" parameter can be used to tell the sieve
   interpreter to treat two vacation commands 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.




Showalter & Freed        Expires October 3, 2005                [Page 5]

Internet-Draft               Sieve Vacation                   April 2005


   Example:  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 that one way to implement the necessary mechanism here is to
   store a hash of either the current handle and the recipient or, if no
   handle is provided, a hash of the generated message content and the
   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

   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 non-ASCII characters are present.
   Implementations SHOULD insert an apppropriate default subject line 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 security
   restrictions on what addresses can specified in a ":from" parameter;
   it is suggested that values which fail such a security check simply
   be ignored rather than causing the vacation action to fail.

3.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 (see section 2.4.2.4 of
   [RFC3028]).

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





Showalter & Freed        Expires October 3, 2005                [Page 6]

Internet-Draft               Sieve Vacation                   April 2005


3.5  Address Parameter and Limiting Replies to Personal Messages

   "Vacation" MUST NOT respond to a message unless the user's email
   address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
   "Resent-Bcc" line of the original message.  Implementations are
   assumed to know the user's email address, but users may have
   additional addresses beyond the control of the local mail system.

   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 in
   addition to the addresses that the implementation knows.

3.6  Restricting Replies to Automated Processes and Mailing Lists

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

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

   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 with a header that
   begins with "List-".

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

3.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 will fail if
   two vacation actions are used.

   Implementations MUST NOT consider vacation used with discard, keep,
   fileinto, or redirect an error.




Showalter & Freed        Expires October 3, 2005                [Page 7]

Internet-Draft               Sieve Vacation                   April 2005


3.8  Examples

   Here is a simple use of vacation.

   Example:
                  require "vacation";
                  vacation :days 23 :addresses ["tjs@example.edu",
                                         "ts4z@landru.example.edu"]
                         "I'm away until October 19.
                          If it's an emergency, call 911, I guess." ;

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

   Example:  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.";
                  }


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

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

4.2  Subject Parameter

   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.





Showalter & Freed        Expires October 3, 2005                [Page 8]

Internet-Draft               Sieve Vacation                   April 2005


4.3  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 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
   be generated, and References need not bne changed.

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

4.5  To

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

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

4.7  Message Body

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

5.  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 [RFC3834] makes in
   regards to how personal responders should behave.

6.  Security Considerations

   It is critical that implementations correctly implement the
   limitations described above.  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.

   Security issues associated with mail auto-responders are fully
   discussed in the security consideration section of [RFC3834].





Showalter & Freed        Expires October 3, 2005                [Page 9]

Internet-Draft               Sieve Vacation                   April 2005


7.  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
   Capability keyword: vacation
   Capability arguments: N/A
   Standards Track/IESG-approved experimental RFC number: this RFC
   Person and email address to contact for further information:
       Tim Showalter
       E-Mail: tjs@psaux.com

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

8.  References

8.1  Normative References

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

   [RFC3028]  Showalter, T., "Sieve: A Mail Filtering Language",
              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
              Electronic Mail", RFC 3834, August 2004.




Showalter & Freed        Expires October 3, 2005               [Page 10]

Internet-Draft               Sieve Vacation                   April 2005


8.2  Informative References

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.


Authors' Addresses

   Tim Showalter
   ??

   Email: tjs@psaux.com


   Ned Freed (editor)
   Sun Microsystems

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

Appendix A.  Acknowledgements

   This extension is obviously inspired by Eric Allman's vacation
   program under Unix.  The author owes a great deal to Carnegie Mellon
   University, Cyrus Daboo, Lawrence Greenfield, and many others whose
   names have been lost during the inexcusably long gestation period of
   this document.
























Showalter & Freed        Expires October 3, 2005               [Page 11]

Internet-Draft               Sieve Vacation                   April 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Showalter & Freed        Expires October 3, 2005               [Page 12]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/