SIEVE Email Filtering Working T. Showalter Group ?? Internet-Draft N. Freed, Ed. Expires: October 15, 2005 Sun Microsystems April 13, 2005 Sieve Email Filtering: Vacation Extension draft-ietf-sieve-vacation-02 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 October 15, 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. Change History (to be removed prior to publication as an RFC) Showalter & Freed Expires October 15, 2005 [Page 1] Internet-Draft Sieve Vacation April 2005 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 Showalter & Freed Expires October 15, 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 . . . . . . . . . . . . . . . 7 3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Response Message Generation . . . . . . . . . . . . . . . . . 9 4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 9 4.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 9 4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 10 4.8 In-Reply-To and References . . . . . . . . . . . . . . . . 10 5. Relationship to Recommendations for Automatic Responses to Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Showalter & Freed Expires October 15, 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 to a particular recipient will not be answered immediately. 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] 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 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. 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. Showalter & Freed Expires October 15, 2005 [Page 4] Internet-Draft Sieve Vacation April 2005 If ":days" exceeds the site-defined maximum, the site-defined maximum 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.) 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. 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 vacation Showalter & Freed Expires October 15, 2005 [Page 5] Internet-Draft Sieve Vacation April 2005 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 incomining 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 or, if no handle is provided, a hash of the vacation action parameters specifying the 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. Showalter & Freed Expires October 15, 2005 [Page 6] Internet-Draft Sieve Vacation April 2005 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. 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. Showalter & Freed Expires October 15, 2005 [Page 7] Internet-Draft Sieve Vacation April 2005 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 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 is incompatible with reject. 3.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. 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."; } Showalter & Freed Expires October 15, 2005 [Page 8] Internet-Draft Sieve Vacation April 2005 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. When :mime is used the reason argument also contains MIME header information. The headers must conform to MIME conventions; in particular, 8bit text is not allowed. Implementations SHOULD reject vacation :mime actions containing 8bit header material. 4.1 SMTP MAIL FROM address 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 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. 4.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. 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. Showalter & Freed Expires October 15, 2005 [Page 9] Internet-Draft Sieve Vacation April 2005 4.7 Message Body The body of the message is taken from the reason string in the vacation command. 4.8 In-Reply-To and References Replies MUST have the In-Reply-To field set to the Message-ID of the original message, and the References field SHOULD be updated with the Message-ID of the original message. If the original message lacks a Message-ID, an In-Reply-To need not be generated, and References need not be changed. 5. Relationship to Recommendations for Automatic Responses to 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 behavior and rescriptions 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. Security issues associated with mail auto-responders are fully discussed in the security consideration section of [RFC3834]. 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: Ned Freed Showalter & Freed Expires October 15, 2005 [Page 10] Internet-Draft Sieve Vacation April 2005 E-Mail: ned.freed@mrochek.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 [I-D.ietf-sieve-variables] Homme, K., "Sieve Mail Filtering Language: Variables Extension", draft-ietf-sieve-variables-02 (work in progress), April 2005, . [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. 8.2 Informative References [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. Showalter & Freed Expires October 15, 2005 [Page 11] Internet-Draft Sieve Vacation April 2005 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 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, and many others whose names have been lost during the inexcusably long gestation period of this document. Showalter & Freed Expires October 15, 2005 [Page 12] 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 15, 2005 [Page 13]