idnits 2.17.1 draft-ietf-sieve-vacation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2005) is 6982 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2045' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3028 (Obsoleted by RFC 5228, RFC 5429) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIEVE Email Filtering Working T. Showalter 2 Group ?? 3 Internet-Draft N. Freed 4 Expires: September 15, 2005 Sun Microsystems 5 March 14, 2005 7 Sieve Email Filtering: Vacation Extension 8 draft-ietf-sieve-vacation-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 15, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes an extension to the Sieve email filtering 44 language for an autoresponder similar to that of the Unix "vacation" 45 command for replying to messages. Various safety features are 46 included to prevent problems such as message loops. 48 Change History (to be removed prior to publication as an RFC) 50 Changes from draft-showalter-sieve-vacation-06.txt: 51 1. Updated to XML source. 52 2. Added :from parameter. 53 3. Added more detailed description of :subject parameter 54 4. Fixed various minor typos. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 60 3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 4 63 3.3 Subject and from parameters . . . . . . . . . . . . . . . 5 64 3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 5 65 3.5 Address Parameter and Limiting Replies to Personal 66 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.6 Restricting Replies to Automated Processes and Mailing 68 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 6 70 3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Response Message Generation . . . . . . . . . . . . . . . . . 7 72 4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 7 73 4.2 Subject Parameter . . . . . . . . . . . . . . . . . . . . 7 74 4.3 In-Reply-To and References . . . . . . . . . . . . . . . . 7 75 4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 7 78 4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Relationship to Recommendations for Automatic Responses to 80 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 8 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 85 8.2 Informative References . . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 87 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 88 Intellectual Property and Copyright Statements . . . . . . . . 10 90 1. Introduction 92 This is an extension to the Sieve language defined by [RFC3028] for 93 notification that messages will not be immediately answered. 95 Conventions for notations are as in [RFC3028] section 1.1. 97 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and 98 "MAY" in this document are to be interpreted as defined in [RFC2119]. 100 2. Capability Identifier 102 Sieve implementations that implement vacation have an identifier of 103 "vacation" for use with the capability mechanism. 105 3. Vacation Action 107 Syntax: vacation [":days" number] [":subject" string] [":from" string] 108 [":addresses" string-list] [":mime"] 110 The "vacation" action implements a vacation autoresponder similar to 111 the vacation command available under many versions of Unix. Its 112 purpose is to provide correspondents with notification that the user 113 is away for an extended period of time and that they should not 114 expect quick responses. 116 "Vacation" is used to respond to a message with another message. 117 Vacation's messages are always addressed to the Return-Path address 118 (that is, the envelope from address) of the message being responded 119 to. 121 3.1 Days Parameter 123 The ":days" argument is used to specify the period in which addresses 124 are kept and are not responded to, and is always specified in days. 125 The minimum value used for this parameter is normally 1. Sites MAY 126 define a different minimum value. Sites MAY also define a maximum 127 days value, which MUST be greater than 7, and SHOULD be greater than 128 30. 130 If ":days" is omitted, the default value is either 7 or the minimum 131 value (as defined above), whichever is greater. 133 If the parameter given to ":days" is less than the minimum value, 134 then the minimum value is used instead. 136 If ":days" exceeds the site-defined maximum, the site-defined maximum 137 is used instead. 139 3.2 Previous Response Tracking 141 "Vacation" keeps track of all of the responses it has sent to each 142 address in some period (as specified by the :days optional argument). 143 If vacation has not previously sent the response to this address 144 within the given time period, it sends the "reason" argument to the 145 SMTP MAIL FROM address of the message that is being responded to. 146 (The SMTP MAIL FROM address should be available in the Return-path: 147 header field if Sieve processing occurs after final delivery.) 149 Vacation responses are not just per address, but are per address per 150 set of arguments to the vacation command. For instance, If 151 coyote@desert.example.org sends mail to roadrunner@acme.example.com, 152 once with the subject "Cyrus bug" and once with the subject "come 153 over for dinner", and roadrunner@acme.example.com has the script 154 below, coyote@desert.example.org would receive two responses, once 155 with the first message, once with the second. 157 Example: require "vacation"; 158 if subject :contains "cyrus" { 159 vacation "I'm out -- send mail to cyrus-bugs"; 160 } else { 161 vacation "I'm out -- call me at 304 555 1212"; 162 } 164 In the above example, coyote@desert.example.org gets the second 165 message despite having gotten the first one because separate vaca- 166 tion responses have been triggered. This behavior is REQUIRED. 168 The "per set of arguments" described above is intended to ensure that 169 a respondee gets all of the various possible responses, not merely 170 the first one. So, if the :subject or :mime parameters would result 171 in a different message, a different message MUST be sent by the 172 implementation. 174 If a script is changed, implementations MAY reset the records of who 175 has been responded to and when they have been responded to. 176 Alternatively, implementations can store records of who has received 177 which message, perhaps by storing a hash of the message and the 178 recipient. 180 Implementations are free to limit the number of remembered responses, 181 provided the limit is no less than 1000. 183 Implementations SHOULD make the limit no less than 1000 per vacation 184 command if using the hash algorithm described above. When limiting 185 the number of tracked responses, implementations SHOULD discard the 186 oldest ones first. 188 3.3 Subject and from parameters 190 The ":subject" parameter specifies a subject line to attach to any 191 vacation response that is generated. UTF-8 characters can be used in 192 the string argument; implementations MUST convert the string to 193 [RFC2047] encoded words if non-ASCII characters are present. 194 Implementations SHOULD insert an apppropriate default subject line if 195 no :subject parameter is specified. 197 A ":from" parameter MAY be used to specify an alternate address to 198 use in the From field of vacation messages. The string must specify 199 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 200 syntax and generate an error when a syntactically invalid ":from" 201 parameter is specified. Implementations MAY also impose security 202 restrictions on what addresses can specified in a ":from" parameter; 203 it is suggested that values which fail such a security check simply 204 be ignored rather than causing the vacation action to fail. 206 3.4 MIME Parameter 208 The ":mime" parameter, if supplied, specifies that the reason string 209 is, in fact, a MIME part, including MIME headers (see section 2.4.2.4 210 of [RFC3028]). 212 If the optional :mime parameter is not supplied, the reason string is 213 considered to be a UTF-8 string. 215 3.5 Address Parameter and Limiting Replies to Personal Messages 217 "Vacation" MUST NOT respond to a message unless the user's email 218 address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 219 "Resent-Bcc" line of the original message. Implementations are 220 assumed to know the user's email address, but users may have 221 additional addresses beyond the control of the local mail system. 223 Users can supply additional mail addresses that are theirs with the 224 ":addresses" argument, which takes a string-list listing additional 225 addresses that a user might have. These addresses are considered in 226 addition to the addresses that the implementation knows. 228 3.6 Restricting Replies to Automated Processes and Mailing Lists 230 Implementations MUST have a list of addresses that "vacation" MUST 231 NOT send mail to. However, the contents of this list are 232 implementation defined. The purpose of this list is to stop mail 233 from going to addresses used by system daemons that would not care if 234 the user is actually reading her mail. 236 Implementations are encouraged, however, to include well-known 237 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 238 addresses typically used only by automated systems. Additionally, 239 addresses ending in "-request" or beginning in "owner-", i.e., 240 reserved for mailing list software, are also suggested. 242 Implementors may take guidance from [RFC2142], but should be careful. 243 Some addresses, like "POSTMASTER", are generally actually managed by 244 people, and people do care if the user is going to be unavailable. 246 Implementations SHOULD NOT not to respond to any message with a 247 header that begins with "List-". 249 Implementations SHOULD NOT respond to any message that has an 250 "Auto-submitted" header field with a value other than "no". This 251 header field is described in [RFC3834]. 253 3.7 Interaction with Other Sieve Actions 255 Vacation does not affect Sieve's implicit keep action. 257 Vacation can only be executed once per script. A script will fail if 258 two vacation actions are used. 260 Implementations MUST NOT consider vacation used with discard, keep, 261 fileinto, or redirect an error. 263 3.8 Examples 265 Here is a simple use of vacation. 267 Example: 268 require "vacation"; 269 vacation :days 23 :addresses ["tjs@example.edu", 270 "ts4z@landru.example.edu"] 271 "I'm away until October 19. 272 If it's an emergency, call 911, I guess." ; 274 By mingling vacation with other rules, users can do something more 275 selective. 277 Example: require "vacation"; 278 if header :contains "from" "boss@example.edu" { 279 redirect "pleeb@isp.example.org"; 280 } else { 281 vacation "Sorry, I'm away, I'll read your 282 message when I get around to it."; 283 } 285 4. Response Message Generation 287 This section details the requirements for the generated response 288 message. 290 It is worth noting that the input message and arguments may be in 291 UTF-8, and that implementations MUST deal with UTF-8 input, although 292 implementations MAY transcode to other character sets as regional 293 taste dictates. 295 4.1 SMTP MAIL FROM address 297 The SMTP MAIL FROM address of the message envelope SHOULD be set to 298 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 299 SMTP transaction if the NOTARY SMTP extension is available. 301 4.2 Subject Parameter 303 Users can specify the subject of the reply with the ":subject" 304 parameter. If the :subject parameter is not supplied, then the 305 subject is generated as follows: The subject is set to the characters 306 "Re: " followed by the original subject with all leading occurrence 307 of the characters "Re: " stripped off. 309 4.3 In-Reply-To and References 311 Replies MUST have the In-Reply-To field set to the Message-ID of the 312 original message, and the References field must be updated with the 313 Message-ID of the original message. 315 If the original message lacks a Message-ID, an In-Reply-To need not 316 be generated, and References need not bne changed. 318 4.4 From 320 Unless explicitly overridden with a :from parameter, the From field 321 SHOULD be set to the address of the owner of the Sieve script. 323 4.5 To 325 The To field SHOULD be set to the address of the recipient of the 326 response. 328 4.6 Auto-submitted 330 An Auto-Submitted field with a value of "auto-replied" SHOULD be 331 included in the message header of any vacation message sent. 333 4.7 Message Body 335 The body of the message is taken from the reason string in the 336 vacation command. 338 5. Relationship to Recommendations for Automatic Responses to 339 Electronic Mail 341 The vacation extension implements a "Personal Responder" in the 342 terminology defined in [RFC3834]. Care has been taken in this 343 specification to comply with the recommendations [RFC3834] makes in 344 regards to how personal responders should behave. 346 6. Security Considerations 348 It is critical that implementations correctly implement the 349 limitations described above. Replies MUST NOT be sent out in 350 response to messages not sent directly to the user, and replies MUST 351 NOT be sent out more often than the :days argument states. 353 Security issues associated with mail auto-responders are fully 354 discussed in the security consideration section of [RFC3834]. 356 7. IANA Considerations 358 The following template specifies the IANA registration of the 359 vacation Sieve extension specified in this document: 361 To: iana@iana.org 362 Subject: Registration of new Sieve extension 364 Capability name: vacation 365 Capability keyword: vacation 366 Capability arguments: N/A 367 Standards Track/IESG-approved experimental RFC number: this RFC 368 Person and email address to contact for further information: 369 Tim Showalter 370 E-Mail: tjs@psaux.com 372 This information should be added to the list of Sieve extensions 373 given on http://www.iana.org/assignments/sieve-extensions. 375 8. References 377 8.1 Normative References 379 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 380 Extensions (MIME) Part One: Format of Internet Message 381 Bodies", RFC 2045, November 1996. 383 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 384 Part Three: Message Header Extensions for Non-ASCII Text", 385 RFC 2047, November 1996. 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, March 1997. 390 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 391 2001. 393 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 394 RFC 3028, January 2001. 396 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 397 Electronic Mail", RFC 3834, August 2004. 399 8.2 Informative References 401 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 402 FUNCTIONS", RFC 2142, May 1997. 404 Authors' Addresses 406 Tim Showalter 407 ?? 409 Email: tjs@psaux.com 411 Ned Freed 412 Sun Microsystems 414 Phone: +1 909 457 4293 415 Email: ned.freed@mrochek.com 417 Appendix A. Acknowledgements 419 This extension is obviously inspired by Eric Allman's vacation 420 program under Unix. The author owes a great deal to Carnegie Mellon 421 University, Cyrus Daboo, Lawrence Greenfield, and many others whose 422 names have been lost during the inexcusably long gestation period of 423 this document. 425 Intellectual Property Statement 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Disclaimer of Validity 451 This document and the information contained herein are provided on an 452 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 453 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 454 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 455 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 456 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 457 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 459 Copyright Statement 461 Copyright (C) The Internet Society (2005). This document is subject 462 to the rights, licenses and restrictions contained in BCP 78, and 463 except as set forth therein, the authors retain all their rights. 465 Acknowledgment 467 Funding for the RFC Editor function is currently provided by the 468 Internet Society.