idnits 2.17.1 draft-ietf-sieve-vacation-01.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 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. ** 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 3 instances of too long lines in the document, the longest one being 14 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 (April 1, 2005) is 6965 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: 'RFC3461' is defined on line 422, 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, Ed. 4 Expires: October 3, 2005 Sun Microsystems 5 April 1, 2005 7 Sieve Email Filtering: Vacation Extension 8 draft-ietf-sieve-vacation-01 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 October 3, 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: 52 1. Updated to XML source. 54 2. Added :from parameter. 56 3. Added :handle parameter. 58 4. Added more detailed description of :subject parameter 60 5. Clarified some discussion text. 62 6. Fixed various minor typos. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 68 3. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1 Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2 Previous Response Tracking . . . . . . . . . . . . . . . . 5 71 3.3 Subject and from parameters . . . . . . . . . . . . . . . 6 72 3.4 MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6 73 3.5 Address Parameter and Limiting Replies to Personal 74 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.6 Restricting Replies to Automated Processes and Mailing 76 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.7 Interaction with Other Sieve Actions . . . . . . . . . . . 7 78 3.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4. Response Message Generation . . . . . . . . . . . . . . . . . 8 80 4.1 SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 8 81 4.2 Subject Parameter . . . . . . . . . . . . . . . . . . . . 8 82 4.3 In-Reply-To and References . . . . . . . . . . . . . . . . 9 83 4.4 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.5 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.6 Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 9 86 4.7 Message Body . . . . . . . . . . . . . . . . . . . . . . . 9 87 5. Relationship to Recommendations for Automatic Responses to 88 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 9 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 93 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 95 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 96 Intellectual Property and Copyright Statements . . . . . . . . 12 98 1. Introduction 100 This is an extension to the Sieve language defined by [RFC3028] for 101 notification that messages will not be immediately answered. 103 Conventions for notations are as in [RFC3028] section 1.1. 105 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and 106 "MAY" in this document are to be interpreted as defined in [RFC2119]. 108 2. Capability Identifier 110 Sieve implementations that implement vacation have an identifier of 111 "vacation" for use with the capability mechanism. 113 3. Vacation Action 115 Syntax: vacation [":days" number] [":subject" string] [":from" string] 116 [":addresses" string-list] [":mime"] [":handle" string] 117 119 The "vacation" action implements a vacation autoresponder similar to 120 the vacation command available under many versions of Unix. Its 121 purpose is to provide correspondents with notification that the user 122 is away for an extended period of time and that they should not 123 expect quick responses. 125 "Vacation" is used to respond to a message with another message. 126 Vacation's messages are always addressed to the Return-Path address 127 (that is, the envelope from address) of the message being responded 128 to. 130 3.1 Days Parameter 132 The ":days" argument is used to specify the period in which addresses 133 are kept and are not responded to, and is always specified in days. 134 The minimum value used for this parameter is normally 1. Sites MAY 135 define a different minimum value. Sites MAY also define a maximum 136 days value, which MUST be greater than 7, and SHOULD be greater than 137 30. 139 If ":days" is omitted, the default value is either 7 or the minimum 140 value (as defined above), whichever is greater. 142 If the parameter given to ":days" is less than the minimum value, 143 then the minimum value is used instead. 145 If ":days" exceeds the site-defined maximum, the site-defined maximum 146 is used instead. 148 3.2 Previous Response Tracking 150 "Vacation" keeps track of all of the responses it has sent to each 151 address in some period (as specified by the :days optional argument). 152 If vacation has not previously sent the response to this address 153 within the given time period, it sends the "reason" argument to the 154 SMTP MAIL FROM address of the message that is being responded to. 155 (The SMTP MAIL FROM address should be available in the Return-path: 156 header field if Sieve processing occurs after final delivery.) 158 Vacation responses are not just per address, but are per address per 159 set of vacation command arguments. For instance, If 160 coyote@desert.example.org sends mail to roadrunner@acme.example.com 161 twice, once with the subject "Cyrus bug" and once with the subject 162 "come over for dinner", and roadrunner@acme.example.com has the 163 script shown below, coyote@desert.example.org would receive two 164 responses, once with the first message, once with the second. 166 Example: require "vacation"; 167 if header :contains "subject" "cyrus" { 168 vacation "I'm out -- send mail to cyrus-bugs"; 169 } else { 170 vacation "I'm out -- call me at 304 555 1212"; 171 } 173 In the above example, coyote@desert.example.org gets the second 174 message despite having gotten the first one because separate vaca- 175 tion responses have been triggered. This behavior is REQUIRED. 177 The "per set of arguments" described above is intended to ensure that 178 a respondee gets all of the various possible responses, not merely 179 the first one. So, if the :subject or :mime parameters would result 180 in a different message, a different message MUST be sent by the 181 implementation. 183 The optional ":handle" parameter can be used to tell the sieve 184 interpreter to treat two vacation commands with different arguments 185 as the same command for purposes of response tracking. The argument 186 to ":handle" is a string that identifies the type of response being 187 sent. For instance, if tweety@cage.example.org sends mail to 188 spike@doghouse.example.com twice, one with the subject "lunch?" and 189 once with the subject "dinner?", and spike@doghouse.example.com has 190 the script shown below, tweety@cage.example.org will only receive a 191 single response. (Which response is sent depends on the order in 192 which the messages are processed. 194 Example: require "vacation"; 195 if header :contains "subject" "lunch" { 196 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 197 } else { 198 vacation :handle "ran-away" "I'm out"; 199 } 201 Note that one way to implement the necessary mechanism here is to 202 store a hash of either the current handle and the recipient or, if no 203 handle is provided, a hash of the generated message content and the 204 recipient. If a script is changed, implementations MAY reset the 205 records of who has been responded to and when they have been 206 responded to. 208 Implementations are free to limit the number of remembered responses, 209 provided the limit is no less than 1000. When limiting the number of 210 tracked responses, implementations SHOULD discard the oldest ones 211 first. 213 3.3 Subject and from parameters 215 The ":subject" parameter specifies a subject line to attach to any 216 vacation response that is generated. UTF-8 characters can be used in 217 the string argument; implementations MUST convert the string to 218 [RFC2047] encoded words if non-ASCII characters are present. 219 Implementations SHOULD insert an apppropriate default subject line if 220 no :subject parameter is specified. 222 A ":from" parameter MAY be used to specify an alternate address to 223 use in the From field of vacation messages. The string must specify 224 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 225 syntax and generate an error when a syntactically invalid ":from" 226 parameter is specified. Implementations MAY also impose security 227 restrictions on what addresses can specified in a ":from" parameter; 228 it is suggested that values which fail such a security check simply 229 be ignored rather than causing the vacation action to fail. 231 3.4 MIME Parameter 233 The ":mime" parameter, if supplied, specifies that the reason string 234 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 235 including both MIME headers and content (see section 2.4.2.4 of 236 [RFC3028]). 238 If the optional :mime parameter is not supplied, the reason string is 239 considered to be a UTF-8 string. 241 3.5 Address Parameter and Limiting Replies to Personal Messages 243 "Vacation" MUST NOT respond to a message unless the user's email 244 address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 245 "Resent-Bcc" line of the original message. Implementations are 246 assumed to know the user's email address, but users may have 247 additional addresses beyond the control of the local mail system. 249 Users can supply additional mail addresses that are theirs with the 250 ":addresses" argument, which takes a string-list listing additional 251 addresses that a user might have. These addresses are considered in 252 addition to the addresses that the implementation knows. 254 3.6 Restricting Replies to Automated Processes and Mailing Lists 256 Implementations MUST have a list of addresses that "vacation" MUST 257 NOT send mail to. However, the contents of this list are 258 implementation defined. The purpose of this list is to stop mail 259 from going to addresses used by system daemons that would not care if 260 the user is actually reading her mail. 262 Implementations are encouraged, however, to include well-known 263 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 264 addresses typically used only by automated systems. Additionally, 265 addresses ending in "-request" or beginning in "owner-", i.e., 266 reserved for mailing list software, are also suggested. 268 Implementors may take guidance from [RFC2142], but should be careful. 269 Some addresses, like "POSTMASTER", are generally actually managed by 270 people, and people do care if the user is going to be unavailable. 272 Implementations SHOULD NOT respond to any message with a header that 273 begins with "List-". 275 Implementations SHOULD NOT respond to any message that has an 276 "Auto-submitted" header field with a value other than "no". This 277 header field is described in [RFC3834]. 279 3.7 Interaction with Other Sieve Actions 281 Vacation does not affect Sieve's implicit keep action. 283 Vacation can only be executed once per script. A script will fail if 284 two vacation actions are used. 286 Implementations MUST NOT consider vacation used with discard, keep, 287 fileinto, or redirect an error. 289 3.8 Examples 291 Here is a simple use of vacation. 293 Example: 294 require "vacation"; 295 vacation :days 23 :addresses ["tjs@example.edu", 296 "ts4z@landru.example.edu"] 297 "I'm away until October 19. 298 If it's an emergency, call 911, I guess." ; 300 By mingling vacation with other rules, users can do something more 301 selective. 303 Example: require "vacation"; 304 if header :contains "from" "boss@example.edu" { 305 redirect "pleeb@isp.example.org"; 306 } else { 307 vacation "Sorry, I'm away, I'll read your 308 message when I get around to it."; 309 } 311 4. Response Message Generation 313 This section details the requirements for the generated response 314 message. 316 It is worth noting that the input message and arguments may be in 317 UTF-8, and that implementations MUST deal with UTF-8 input, although 318 implementations MAY transcode to other character sets as regional 319 taste dictates. 321 4.1 SMTP MAIL FROM address 323 The SMTP MAIL FROM address of the message envelope SHOULD be set to 324 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 325 SMTP transaction if the NOTARY SMTP extension [RFC3461]is available. 327 4.2 Subject Parameter 329 Users can specify the subject of the reply with the ":subject" 330 parameter. If the :subject parameter is not supplied, then the 331 subject is generated as follows: The subject is set to the characters 332 "Re: " followed by the original subject with all leading occurrence 333 of the characters "Re: " stripped off. 335 4.3 In-Reply-To and References 337 Replies MUST have the In-Reply-To field set to the Message-ID of the 338 original message, and the References field must be updated with the 339 Message-ID of the original message. 341 If the original message lacks a Message-ID, an In-Reply-To need not 342 be generated, and References need not bne changed. 344 4.4 From 346 Unless explicitly overridden with a :from parameter, the From field 347 SHOULD be set to the address of the owner of the Sieve script. 349 4.5 To 351 The To field SHOULD be set to the address of the recipient of the 352 response. 354 4.6 Auto-submitted 356 An Auto-Submitted field with a value of "auto-replied" SHOULD be 357 included in the message header of any vacation message sent. 359 4.7 Message Body 361 The body of the message is taken from the reason string in the 362 vacation command. 364 5. Relationship to Recommendations for Automatic Responses to 365 Electronic Mail 367 The vacation extension implements a "Personal Responder" in the 368 terminology defined in [RFC3834]. Care has been taken in this 369 specification to comply with the recommendations [RFC3834] makes in 370 regards to how personal responders should behave. 372 6. Security Considerations 374 It is critical that implementations correctly implement the 375 limitations described above. Replies MUST NOT be sent out in 376 response to messages not sent directly to the user, and replies MUST 377 NOT be sent out more often than the :days argument states. 379 Security issues associated with mail auto-responders are fully 380 discussed in the security consideration section of [RFC3834]. 382 7. IANA Considerations 384 The following template specifies the IANA registration of the 385 vacation Sieve extension specified in this document: 387 To: iana@iana.org 388 Subject: Registration of new Sieve extension 390 Capability name: vacation 391 Capability keyword: vacation 392 Capability arguments: N/A 393 Standards Track/IESG-approved experimental RFC number: this RFC 394 Person and email address to contact for further information: 395 Tim Showalter 396 E-Mail: tjs@psaux.com 398 This information should be added to the list of Sieve extensions 399 given on http://www.iana.org/assignments/sieve-extensions. 401 8. References 403 8.1 Normative References 405 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 406 Extensions (MIME) Part One: Format of Internet Message 407 Bodies", RFC 2045, November 1996. 409 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 410 Part Three: Message Header Extensions for Non-ASCII Text", 411 RFC 2047, November 1996. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 417 2001. 419 [RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", 420 RFC 3028, January 2001. 422 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 423 Extension for Delivery Status Notifications (DSNs)", 424 RFC 3461, January 2003. 426 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 427 Electronic Mail", RFC 3834, August 2004. 429 8.2 Informative References 431 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 432 FUNCTIONS", RFC 2142, May 1997. 434 Authors' Addresses 436 Tim Showalter 437 ?? 439 Email: tjs@psaux.com 441 Ned Freed (editor) 442 Sun Microsystems 444 Phone: +1 909 457 4293 445 Email: ned.freed@mrochek.com 447 Appendix A. Acknowledgements 449 This extension is obviously inspired by Eric Allman's vacation 450 program under Unix. The author owes a great deal to Carnegie Mellon 451 University, Cyrus Daboo, Lawrence Greenfield, and many others whose 452 names have been lost during the inexcusably long gestation period of 453 this document. 455 Intellectual Property Statement 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 Disclaimer of Validity 481 This document and the information contained herein are provided on an 482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 484 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 485 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 486 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 489 Copyright Statement 491 Copyright (C) The Internet Society (2005). This document is subject 492 to the rights, licenses and restrictions contained in BCP 78, and 493 except as set forth therein, the authors retain all their rights. 495 Acknowledgment 497 Funding for the RFC Editor function is currently provided by the 498 Internet Society.