7Network Working Group T. Showalter
8Request for Comments: 5230
9Category: Standards Track N. Freed, Ed.
14 Sieve Email Filtering: Vacation Extension
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 This document describes an extension to the Sieve email filtering
27 language for an autoresponder similar to that of the Unix "vacation"
28 command for replying to messages. Various safety features are
29 included to prevent problems such as message loops.
58Showalter & Freed Standards Track [Page 1]
60RFC 5230 Sieve: Vacation Extension January 2008
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
68 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
69 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
70 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
71 4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
72 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
73 4.5. Address Parameter and Limiting Replies to Personal
74 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
75 4.6. Restricting Replies to Automated Processes and Mailing
76 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
78 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
79 5. Response Message Generation . . . . . . . . . . . . . . . . . 9
80 5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
81 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
82 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
83 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
84 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
85 5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
86 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
87 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
88 6. Relationship to Recommendations for Automatic Responses to
89 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
90 7. Internationalization Considerations . . . . . . . . . . . . . 11
91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
95 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
96 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
114Showalter & Freed Standards Track [Page 2]
116RFC 5230 Sieve: Vacation Extension January 2008
121 This document defines an extension to the Sieve language defined in
122 [RFC5228] for notification that messages to a particular recipient
123 will not be answered immediately.
1252. Conventions Used in This Document
127 Conventions for notations are as in [RFC5228] section 1.1.
129 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED",
130 and "MAY" in this document are to be interpreted as defined in
1333. Capability Identifier
135 Sieve implementations that implement vacation have an identifier of
136 "vacation" for use with the capability mechanism.
140 Usage: vacation [":days" number] [":subject" string]
141 [":from" string] [":addresses" string-list]
142 [":mime"] [":handle" string] <reason: string>
144 The "vacation" action implements a vacation autoresponder similar to
145 the vacation command available under many versions of Unix. Its
146 purpose is to provide correspondents with notification that the user
147 is away for an extended period of time and that they should not
148 expect quick responses.
150 "Vacation" is used to respond to a message with another message.
151 Vacation's messages are always addressed to the Return-Path address
152 (that is, the envelope from address) of the message being responded
157 The ":days" argument is used to specify the period in which addresses
158 are kept and are not responded to, and is always specified in days.
159 The minimum value used for this parameter is normally 1. Sites MAY
160 define a different minimum value as long as the minimum is greater
161 than 0. Sites MAY also define a maximum days value, which MUST be
162 greater than 7, and SHOULD be greater than 30.
164 If ":days" is omitted, the default value is either 7 or the minimum
165 value (as defined above), whichever is greater.
170Showalter & Freed Standards Track [Page 3]
172RFC 5230 Sieve: Vacation Extension January 2008
175 If the parameter given to ":days" is less than the minimum value,
176 then the minimum value is used instead.
178 If ":days" exceeds the site-defined maximum, the site-defined maximum
1814.2. Previous Response Tracking
183 "Vacation" keeps track of all the responses it has sent to each
184 address in some period (as specified by the :days optional argument).
185 If vacation has not previously sent the response to this address
186 within the given time period, it sends the "reason" argument to the
187 SMTP MAIL FROM address [RFC2821] of the message that is being
188 responded to. (The SMTP MAIL FROM address should be available in the
189 Return-path: header field if Sieve processing occurs after final
192 Tracking is not just per address, but must also take the vacation
193 response itself into account. A script writer might, for example,
194 have a vacation action that will send a general notice only once in
195 any two-week period. However, even if a sender has received this
196 general notice, it may be important to send a specific notice when a
197 message about something timely or something specific has been
200 A particular vacation response can be identified in one of two ways.
201 The first way is via an explicit :handle argument, which attaches a
202 name to the response. All vacation statements that use the same
203 handle will be considered the same response for tracking purposes.
205 The second way is via a synthesis of the :subject, :from, :mime, and
206 reason vacation command arguments. All vacation actions that do not
207 contain an explicit handle and that use an identical combination of
208 these arguments are considered the same for tracking purposes.
210 For instance, if coyote@desert.example.org sends mail to
211 roadrunner@acme.example.com twice, once with the subject "Cyrus bug"
212 and once with the subject "come over for dinner", and
213 roadrunner@acme.example.com has the script shown below,
214 coyote@desert.example.org would receive two responses, one with the
215 first message, one with the second.
218 if header :contains "subject" "cyrus" {
219 vacation "I'm out -- send mail to cyrus-bugs";
221 vacation "I'm out -- call me at +1 304 555 0123";
226Showalter & Freed Standards Track [Page 4]
228RFC 5230 Sieve: Vacation Extension January 2008
231 In the above example, coyote@desert.example.org gets the second
232 message despite having gotten the first one because separate vacation
233 responses have been triggered. This behavior is REQUIRED.
235 There is one important exception to this rule, however. If the Sieve
236 variables extension [RFC5229] is used, the arguments MUST NOT have
237 undergone variable expansion prior to their use in response tracking.
238 This is so that examples like the following script will only generate
239 a single response to each incoming message with a different subject
242 require ["vacation", "variables"];
243 if header :matches "subject" "*" {
244 vacation :subject "Automatic response to: ${1}"
245 "I'm away -- send mail to foo in my absence";
248 As noted above, the optional ":handle" parameter can be used to tell
249 the Sieve interpreter to treat two vacation actions with different
250 arguments as the same command for purposes of response tracking. The
251 argument to ":handle" is a string that identifies the type of
252 response being sent. For instance, if tweety@cage.example.org sends
253 mail to spike@doghouse.example.com twice, one with the subject
254 "lunch?" and once with the subject "dinner?", and
255 spike@doghouse.example.com has the script shown below,
256 tweety@cage.example.org will only receive a single response. (Which
257 response is sent depends on the order in which the messages are
261 if header :contains "subject" "lunch" {
262 vacation :handle "ran-away" "I'm out and can't meet for lunch";
264 vacation :handle "ran-away" "I'm out";
267 NOTE: One way to implement the necessary mechanism here is to store a
268 hash of either the current handle and the recipient address or, if no
269 handle is provided, a hash of the vacation action parameters
270 specifying the message content and the recipient address. If a
271 script is changed, implementations MAY reset the records of who has
272 been responded to and when they have been responded to.
274 IMPLEMENTATION NOTE: Care must be taken in constructing a hash of
275 vacation action parameters. In particular, since most parameters are
276 optional, it is important not to let the same string used as the
277 value for different parameters produce the same hash value. One
282Showalter & Freed Standards Track [Page 5]
284RFC 5230 Sieve: Vacation Extension January 2008
287 possible way to accomplish this is to apply the hash to a series of
288 counted or null terminated strings, one for each possible parameter
291 Implementations are free to limit the number of remembered responses;
292 however, the limit MUST NOT be less than 1000. When limiting the
293 number of tracked responses, implementations SHOULD discard the
2964.3. Subject and From Parameters
298 The ":subject" parameter specifies a subject line to attach to any
299 vacation response that is generated. UTF-8 characters can be used in
300 the string argument; implementations MUST convert the string to
301 [RFC2047] encoded words if and only if non-ASCII characters are
302 present. Implementations MUST generate an appropriate default
303 subject line as specified below if no :subject parameter is
306 A ":from" parameter may be used to specify an alternate address to
307 use in the From field of vacation messages. The string must specify
308 a valid [RFC2822] mailbox-list. Implementations SHOULD check the
309 syntax and generate an error when a syntactically invalid ":from"
310 parameter is specified. Implementations MAY also impose restrictions
311 on what addresses can specified in a ":from" parameter; it is
312 suggested that values that fail such a validity check simply be
313 ignored rather than cause the vacation action to fail.
317 The ":mime" parameter, if supplied, specifies that the reason string
318 is, in fact, a MIME entity as defined in [RFC2045] section 2.4,
319 including both MIME headers and content.
321 If the optional :mime parameter is not supplied, the reason string is
322 considered a UTF-8 string.
338Showalter & Freed Standards Track [Page 6]
340RFC 5230 Sieve: Vacation Extension January 2008
345 Content-Type: multipart/alternative; boundary=foo
349 I'm at the beach relaxing. Mmmm, surf...
352 Content-Type: text/html; charset=us-ascii
354 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
355 "http://www.w3.org/TR/REC-html40/strict.dtd">
356 <HTML><HEAD><TITLE>How to relax</TITLE>
357 <BASE HREF="http://home.example.com/pictures/"></HEAD>
358 <BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing.
359 Mmmm, <A HREF="ocean.gif">surf</A>...
3654.5. Address Parameter and Limiting Replies to Personal Messages
367 "Vacation" MUST NOT respond to a message unless the recipient user's
368 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
369 "Resent-Bcc" line of the original message. An email address is
370 considered to belong to the recipient if it is one of:
372 1. an email address known by the implementation to be associated
375 2. the final envelope recipient address if it's available to the
378 3. an address specified by the script writer via the ":addresses"
379 argument described in the next paragraph.
381 Users can supply additional mail addresses that are theirs with the
382 ":addresses" argument, which takes a string-list listing additional
383 addresses that a user might have. These addresses are considered to
384 belong to the recipient user in addition to the addresses known to
394Showalter & Freed Standards Track [Page 7]
396RFC 5230 Sieve: Vacation Extension January 2008
3994.6. Restricting Replies to Automated Processes and Mailing Lists
401 Implementations MAY refuse to send a vacation response to a message
402 that contains any header or content that makes it appear that a
403 response would not be appropriate.
405 Implementations MUST have a list of addresses that "vacation" MUST
406 NOT send mail to. However, the contents of this list are
407 implementation defined. The purpose of this list is to stop mail
408 from going to addresses used by system daemons that would not care if
409 the user is actually reading her mail.
411 Implementations are encouraged, however, to include well-known
412 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
413 addresses typically used only by automated systems. Additionally,
414 addresses ending in "-request" or beginning in "owner-", i.e.,
415 reserved for mailing list software, are also suggested.
417 Implementors may take guidance from [RFC2142], but should be careful.
418 Some addresses, like "POSTMASTER", are generally actually managed by
419 people, and people do care if the user is going to be unavailable.
421 Implementations SHOULD NOT respond to any message that contains a
422 "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-
423 Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369]
426 Implementations SHOULD NOT respond to any message that has an "Auto-
427 submitted" header field with a value other than "no". This header
428 field is described in [RFC3834].
4304.7. Interaction with Other Sieve Actions
432 Vacation does not affect Sieve's implicit keep action.
434 Vacation can only be executed once per script. A script MUST fail
435 with an appropriate error if it attempts to execute two or more
438 Implementations MUST NOT consider vacation used with discard, keep,
439 fileinto, or redirect an error. The vacation action is incompatible
440 with the Sieve reject and refuse actions [REJECT].
450Showalter & Freed Standards Track [Page 8]
452RFC 5230 Sieve: Vacation Extension January 2008
457 Here is a simple use of vacation.
460 vacation :days 23 :addresses ["tjs@example.edu",
461 "ts4z@landru.example.edu"]
462 "I'm away until October 19.
463 If it's an emergency, call 911, I guess." ;
465 By mingling vacation with other rules, users can do something more
469 if header :contains "from" "boss@example.edu" {
470 redirect "pleeb@isp.example.org";
472 vacation "Sorry, I'm away, I'll read your
473 message when I get around to it.";
4765. Response Message Generation
478 This section details the requirements for the generated response
481 It is worth noting that the input message and arguments may be in
482 UTF-8, and that implementations MUST deal with UTF-8 input, although
483 implementations MAY transcode to other character sets as regional
484 taste dictates. When :mime is used, the reason argument also
485 contains MIME header information. The headers must conform to MIME
486 conventions; in particular, 8bit text is not allowed.
487 Implementations SHOULD reject vacation :mime actions containing 8bit
4905.1. SMTP MAIL FROM Address
492 The SMTP MAIL FROM address of the message envelope SHOULD be set to
493 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
494 SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.
498 The Date field SHOULD be set to the date and time when the vacation
499 response was generated. Note that this may not be the same as the
500 time the message was delivered to the user.
506Showalter & Freed Standards Track [Page 9]
508RFC 5230 Sieve: Vacation Extension January 2008
513 Users can specify the Subject of the reply with the ":subject"
514 parameter. If the :subject parameter is not supplied, then the
515 subject is generated as follows: The subject is set to the characters
516 "Auto: " followed by the original subject. An appropriate fixed
517 Subject, such as "Automated reply", SHOULD be used in the event that
518 :subject isn't specified and the original message doesn't contain a
523 Unless explicitly overridden with a :from parameter, the From field
524 SHOULD be set to the address of the owner of the Sieve script.
528 The To field SHOULD be set to the address of the recipient of the
533 An Auto-Submitted field with a value of "auto-replied" SHOULD be
534 included in the message header of any vacation message sent.
538 The body of the message is taken from the reason string in the
5415.8. In-Reply-To and References
543 Replies MUST have the In-Reply-To field set to the Message-ID of the
544 original message, and the References field SHOULD be updated with the
545 Message-ID of the original message.
547 If the original message lacks a Message-ID, an In-Reply-To need not
548 be generated, and References need not be changed.
550 Section 3.6.4 of [RFC2822] provides a complete description of how
551 References fields should be generated.
562Showalter & Freed Standards Track [Page 10]
564RFC 5230 Sieve: Vacation Extension January 2008
5676. Relationship to Recommendations for Automatic Responses to
570 The vacation extension implements a "Personal Responder" in the
571 terminology defined in [RFC3834]. Care has been taken in this
572 specification to comply with the recommendations of [RFC3834]
573 regarding how personal responders should behave.
5757. Internationalization Considerations
577 Internationalization capabilities provided by the base Sieve language
578 are discussed in [RFC5228]. However, the vacation extension is the
579 first Sieve extension to be defined that is capable of creating
580 entirely new messages. This section deals with internationalization
581 issues raised by the use of the vacation extension.
583 Vacation messages are normally written using the UTF-8 charset,
584 allowing text to be written in most of the world's languages.
585 Additionally, the :mime parameter allows specification of arbitrary
586 MIME content. In particular, this makes it possible to use
587 multipart/alternative objects to specify vacation responses in
588 multiple languages simultaneously.
590 The Sieve language itself allows a vacation response to be selected
591 based on the content of the original message. For example, the
592 Accept-Language or Content-Language header fields [RFC3282] could be
593 checked and used to select appropriate text:
596 if header :contains ["accept-language", "content-language"] "en"
598 vacation "I am away this week.";
600 vacation "Estoy ausente esta semana.";
603 Note that this rather simplistic test of the field values fails to
604 take the structure of the fields into account and hence could be
605 fooled by some more complex field values. A more elaborate test
606 could be used to deal with this problem.
608 The approach of explicitly coding language selection criteria in
609 scripts is preferred because in many cases language selection issues
610 are conflated with other selection issues. For example, it may be
611 appropriate to use informal text in one language for vacation
612 responses sent to a fellow employee while using more formal text in a
613 different language in a response sent to a total stranger outside the
618Showalter & Freed Standards Track [Page 11]
620RFC 5230 Sieve: Vacation Extension January 2008
624 if address :matches "from" "*@ourdivision.example.com"
626 vacation :subject "Gone fishing"
627 "Having lots of fun! Back in a day or two!";
629 vacation :subject "Je suis parti cette semaine"
630 "Je lirai votre message quand je retourne.";
633 IMPLEMENTATION NOTE: A graphical Sieve generation interface could in
634 principle be used to hide the complexity of specifying response
635 selection criteria from end users. Figuring out the right set of
636 options to present in a graphical interface is likely a nontrivial
637 proposition, but this is more because of the need to employ a variety
638 of criteria to select different sorts of responses to send to
639 different classes of people than because of the issues involved in
640 selecting a response in an appropriate language.
6428. Security Considerations
644 It is critical that implementations correctly implement the behavior
645 and restrictions described throughout this document. Replies MUST
646 NOT be sent out in response to messages not sent directly to the
647 user, and replies MUST NOT be sent out more often than the :days
648 argument states unless the script changes.
650 If mail is forwarded from a site that uses subaddressing, it may be
651 impossible to list all recipient addresses with ":addresses".
653 Security issues associated with mail auto-responders are fully
654 discussed in the security considerations section of [RFC3834]. This
655 document is believed not to introduce any additional security
656 considerations in this general area.
6589. IANA Considerations
660 The following template specifies the IANA registration of the
661 vacation Sieve extension specified in this document:
664 Subject: Registration of new Sieve extension
666 Capability name: vacation
667 Description: adds an action for generating an auto-reply saying
668 that the original message will not be read or
674Showalter & Freed Standards Track [Page 12]
676RFC 5230 Sieve: Vacation Extension January 2008
679 Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
681 This information has been added to the list of Sieve extensions given
682 on http://www.iana.org/assignments/sieve-extensions.
68610.1. Normative References
688 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
689 Extensions (MIME) Part One: Format of Internet Message
690 Bodies", RFC 2045, November 1996.
692 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
693 Part Three: Message Header Extensions for Non-ASCII Text",
694 RFC 2047, November 1996.
696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
697 Requirement Levels", BCP 14, RFC 2119, March 1997.
699 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
702 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
703 Extension for Delivery Status Notifications (DSNs)",
704 RFC 3461, January 2003.
706 [RFC3834] Moore, K., "Recommendations for Automatic Responses to
707 Electronic Mail", RFC 3834, August 2004.
709 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
710 Filtering Language", RFC 5228, January 2008.
712 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
713 RFC 5229, January 2008.
71510.2. Informative References
717 [REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email
718 Filtering: Reject Extension", Work in Progress,
721 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
722 FUNCTIONS", RFC 2142, May 1997.
724 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
725 for Core Mail List Commands and their Transport through
726 Message Header Fields", RFC 2369, July 1998.
730Showalter & Freed Standards Track [Page 13]
732RFC 5230 Sieve: Vacation Extension January 2008
735 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
738 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
739 and Namespace for the Identification of Mailing Lists",
740 RFC 2919, March 2001.
742 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
786Showalter & Freed Standards Track [Page 14]
788RFC 5230 Sieve: Vacation Extension January 2008
791Appendix A. Acknowledgements
793 This extension is obviously inspired by Eric Allman's vacation
794 program under Unix. The authors owe a great deal to Carnegie Mellon
795 University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil
796 Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov,
797 Jeffrey Hutzelman, Philip Guenther, and many others whose names have
798 been lost during the inexcusably long gestation period of this
810 3401 Centrelake Drive, Suite 410
811 Ontario, CA 92761-1205
814 Phone: +1 909 457 4293
815 EMail: ned.freed@mrochek.com
842Showalter & Freed Standards Track [Page 15]
844RFC 5230 Sieve: Vacation Extension January 2008
847Full Copyright Statement
849 Copyright (C) The IETF Trust (2008).
851 This document is subject to the rights, licenses and restrictions
852 contained in BCP 78, and except as set forth therein, the authors
853 retain all their rights.
855 This document and the information contained herein are provided on an
856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
858 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
859 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
860 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
865 The IETF takes no position regarding the validity or scope of any
866 Intellectual Property Rights or other rights that might be claimed to
867 pertain to the implementation or use of the technology described in
868 this document or the extent to which any license under such rights
869 might or might not be available; nor does it represent that it has
870 made any independent effort to identify any such rights. Information
871 on the procedures with respect to rights in RFC documents can be
872 found in BCP 78 and BCP 79.
874 Copies of IPR disclosures made to the IETF Secretariat and any
875 assurances of licenses to be made available, or the result of an
876 attempt made to obtain a general license or permission for the use of
877 such proprietary rights by implementers or users of this
878 specification can be obtained from the IETF on-line IPR repository at
879 http://www.ietf.org/ipr.
881 The IETF invites any interested party to bring to its attention any
882 copyrights, patents or patent applications, or other proprietary
883 rights that may cover technology that may be required to implement
884 this standard. Please address the information to the IETF at
898Showalter & Freed Standards Track [Page 16]