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

Versions: 00 01 02 03 04 05 06 draft-ietf-sieve-vacation

Network Working Group                                       T. Showalter
Internet Draft: Sieve: Vacation Extension                      Mirapoint
Document: draft-showalter-sieve-vacation-05.txt              12 May 2003
Expire in six months


                       Sieve: Vacation Extension


Status of this memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     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

Copyright

     Copyright (C) The Internet Society 2003.  All Rights Reserved.

Abstract

     This document describes an extension to the Sieve mail filtering
     language for an autoresponder similar to that of the Unix
     "vacation" command for replying to messages with certain safety
     features to prevent problems.










Showalter                 Expire in Six Months                  [Page 1]


Internet DRAFT          Sieve: Vacation Extension            12 May 2003


1. Introduction

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

     Conventions for notations are as in [SIEVE] 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
     [KEYWORDS].

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] [":addresses" string-list]
               [":subject" string] [":mime"] <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 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



Showalter                 Expire in Six Months                  [Page 2]


Internet DRAFT          Sieve: Vacation Extension            12 May 2003


     maximum is used instead.

3.2. Previous Response Tracking

     "Vacation" keeps track of all of the addresses that it has
     responded to in some period (as specified by the :days optional
     argument).  If vacation has not previously responded to this
     address within that time period, it sends the "reason" argument to
     the Return-Path address of the message that is being responded to.

     Vacation responses are not just per address, but are per address
     per vacation command.  For instance, If coyote@desert.example.org
     sends mail to roadrunner@acme.example.com, once with the subject
     "Cyrus bug" and once with the subject "come over for dinner", and
     roadrunner@acme.example.com has the script below,
     coyote@desert.example.org would receive two responses, once with
     the first message, once with the second.

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


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

     If a sieve script changes, implementations MAY reset the records of
     who has been responded to and when they have been responded to.
     Alternatively, implementations can store records of who has
     received which message, perhaps by storing a hash of the message
     and the recipient.

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

3.4. MIME Parameter

     The ":mime" parameter, if supplied, specifies that the reason
     string is, in fact, a MIME part, including MIME headers (see



Showalter                 Expire in Six Months                  [Page 3]


Internet DRAFT          Sieve: Vacation Extension            12 May 2003


     section 2.4.2.4 of [SIEVE]).

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

3.5. In-Reply-To

     Replies MUST have the In-Reply-To field set to the Message-ID of
     the original message.

3.6. Address Parameter and Limiting Replies to Personal Messages

     "Vacation" MUST NOT respond to a message unless the user's email
     address is in the "To", "Cc", or "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.7. 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 [MAILBOXNAMES], 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 not to respond to any message with a
     header that begins with "List-".







Showalter                 Expire in Six Months                  [Page 4]


Internet DRAFT          Sieve: Vacation Extension            12 May 2003


3.8. Interaction with Other Sieve Actions

     Vacation does not affect the implicit keep.

     Vacation can only be executed once per script.  If vacation is used
     with another vacation, the script fails.

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

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

5. Author's Address

     Tim Showalter
     Mirapoint, Inc.
     909 Hermosa Court
     Sunnyvale, CA 94085

     E-Mail: tjs@mirapoint.com




Showalter                 Expire in Six Months                  [Page 5]


Internet DRAFT          Sieve: Vacation Extension            12 May 2003


Appendix A.  References

     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

     [MAILBOXNAMES] Crocker, D. "Mailbox Names for Common Services,
     Roles, and Functions", RFC 2142, Internet Mail Consortium, May,
     1997.

     [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
     2045, Innosoft and First Virtual, November 1996.

     [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language",
     Mirapoint, Inc., RFC 3028, January, 2001.

Appendix B. Full Copyright Statement

     Copyright (C) The Internet Society 2000. All Rights Reserved.

     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into languages
     other than English.

     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS 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.








Showalter                 Expire in Six Months                  [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/