I'm at the beach relaxing. Mmmm, surf... --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. Showalter & Freed Standards Track [Page 7] RFC 5230 Sieve: Vacation Extension January 2008 4.6. Restricting Replies to Automated Processes and Mailing Lists Implementations MAY refuse to send a vacation response to a message that contains any header or content that makes it appear that a response would not be appropriate. Implementations MUST have a list of addresses that "vacation" MUST NOT send mail to. However, the contents of this list are implementation defined. The purpose of this list is to stop mail from going to addresses used by system daemons that would not care if the user is actually reading her mail. Implementations are encouraged, however, to include well-known addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other addresses typically used only by automated systems. Additionally, addresses ending in "-request" or beginning in "owner-", i.e., reserved for mailing list software, are also suggested. Implementors may take guidance from [RFC2142], but should be careful. Some addresses, like "POSTMASTER", are generally actually managed by people, and people do care if the user is going to be unavailable. Implementations SHOULD NOT respond to any message 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 [REJECT]. Showalter & Freed Standards Track [Page 8] RFC 5230 Sieve: Vacation Extension January 2008 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. 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. Showalter & Freed Standards Track [Page 9] RFC 5230 Sieve: Vacation Extension January 2008 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 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. Showalter & Freed Standards Track [Page 10] RFC 5230 Sieve: Vacation Extension January 2008 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 [RFC5228]. However, the vacation 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: Showalter & Freed Standards Track [Page 11] RFC 5230 Sieve: Vacation Extension January 2008 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."; } 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 this is 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 considerations 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: adds an action for generating an auto-reply saying that the original message will not be read or answered immediately RFC number: RFC 5230 Showalter & Freed Standards Track [Page 12] RFC 5230 Sieve: Vacation Extension January 2008 Contact address: The Sieve discussion list This information has been added to the list of Sieve extensions given on http://www.iana.org/assignments/sieve-extensions. 10. References 10.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [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. [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008. [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008. 10.2. Informative References [REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email Filtering: Reject Extension", Work in Progress, October 2007. [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 for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. Showalter & Freed Standards Track [Page 13] RFC 5230 Sieve: Vacation Extension January 2008 [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. Showalter & Freed Standards Track [Page 14] RFC 5230 Sieve: Vacation Extension January 2008 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 Standards Track [Page 15] RFC 5230 Sieve: Vacation Extension January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Showalter & Freed Standards Track [Page 16]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4
