From b2bf17054221010da349ece70ecac061bfb7246c Mon Sep 17 00:00:00 2001
From: Stephan Bosch <stephan@rename-it.nl>
Date: Mon, 22 Oct 2007 12:54:02 +0200
Subject: [PATCH] Added draft RFC for vacation extension.
---
.../vacation/draft-ietf-sieve-vacation-07.txt | 896 ++++++++++++++++++
1 file changed, 896 insertions(+)
create mode 100644 src/lib-sieve/plugins/vacation/draft-ietf-sieve-vacation-07.txt
diff --git a/src/lib-sieve/plugins/vacation/draft-ietf-sieve-vacation-07.txt b/src/lib-sieve/plugins/vacation/draft-ietf-sieve-vacation-07.txt
new file mode 100644
index 000000000..e5833e2f7
--- /dev/null
+++ b/src/lib-sieve/plugins/vacation/draft-ietf-sieve-vacation-07.txt
@@ -0,0 +1,896 @@
+
+
+
+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]
+
--
GitLab