idnits 2.17.1 draft-showalter-sieve-vacation-06.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 400. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 391), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 6) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 84: '...rmally 1. Sites MAY define a differen...' RFC 2119 keyword, line 85: '...ays value, which MUST be greater than ...' RFC 2119 keyword, line 86: '... SHOULD be greater than 30....' RFC 2119 keyword, line 128: '...triggered. This behavior is REQUIRED....' RFC 2119 keyword, line 133: '...t message, a different message MUST be...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 69 has weird spacing: '...command avail...' -- 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 (26 October 2004) is 7122 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) -- Missing reference section? 'SIEVE' on line 360 looks like a reference -- Missing reference section? 'KEYWORDS' on line 353 looks like a reference -- Missing reference section? 'MAILBOXNAMES' on line 365 looks like a reference -- Missing reference section? 'AUTO' on line 349 looks like a reference -- Missing reference section? 'MIME' on line 356 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Showalter 2 Internet Draft: Sieve: Vacation Extension 3 Document: draft-showalter-sieve-vacation-06.txt 26 October 2004 4 Expires April 25, 2004 6 Sieve: Vacation Extension 8 Intellectual Property Rights Statement 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Status of this memo 17 "Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html" 34 Copyright 36 Copyright (C) The Internet Society 2004. All Rights Reserved. 38 Abstract 40 This document describes an extension to the Sieve mail filtering 41 language for an autoresponder similar to that of the Unix 42 "vacation" command for replying to messages with certain safety 43 features to prevent problems. 45 Internet DRAFT Sieve: Vacation Extension 26 October 2004 47 1. Introduction 49 This is an extension to the Sieve language defined by [SIEVE] for 50 notification that messages will not be immediately answered. 52 Conventions for notations are as in [SIEVE] section 1.1. 54 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", 55 and "MAY" in this document are to be interpreted as defined in 56 [KEYWORDS]. 58 2. Capability Identifier 60 Sieve implementations that implement vacation have an identifier of 61 "vacation" for use with the capability mechanism. 63 3. Vacation Action 65 Syntax: vacation [":days" number] [":addresses" string-list] 66 [":subject" string] [":mime"] 68 The "vacation" action implements a vacation autoresponder similar 69 to the vacation command available under many versions of Unix. 70 Its purpose is to provide correspondents with notification that the 71 user is away for an extended period of time and that they should 72 not expect quick responses. 74 "Vacation" is used to respond to a message with another message. 75 Vacation's messages are always addressed to the Return-Path address 76 (that is, the envelope from address) of the message being responded 77 to. 79 3.1. Days Parameter 81 The ":days" argument is used to specify the period in which 82 addresses are kept and are not responded to, and is always 83 specified in days. The minimum value used for this parameter is 84 normally 1. Sites MAY define a different minimum value. Sites MAY 85 also define a maximum days value, which MUST be greater than 7, and 86 SHOULD be greater than 30. 88 If ":days" is omitted, the default value is either 7 or the minimum 89 value (as defined above), whichever is greater. 91 If the parameter given to ":days" is less than the minimum value, 92 then the minimum value is used instead. 94 Internet DRAFT Sieve: Vacation Extension 26 October 2004 96 If ":days" exceeds the site-defined maximum, the site-defined 97 maximum is used instead. 99 3.2. Previous Response Tracking 101 "Vacation" keeps track of all of the responses it has sent to each 102 address in some period (as specified by the :days optional 103 argument). If vacation has not previously sent the response to 104 this address within that time period, it sends the "reason" 105 argument to the SMTP MAIL FROM address of the message that is being 106 responded to. (The SMTP MAIL FROM address should be available in 107 the Return-path: header field if sieve processing occurs after 108 final delivery.) 110 Vacation responses are not just per address, but are per address 111 per set of arguments to the vacation command. For instance, If 112 coyote@desert.example.org sends mail to 113 roadrunner@acme.example.com, once with the subject "Cyrus bug" and 114 once with the subject "come over for dinner", and 115 roadrunner@acme.example.com has the script below, 116 coyote@desert.example.org would receive two responses, once with 117 the first message, once with the second. 119 Example: require "vacation"; 120 if subject :contains "cyrus" { 121 vacation "I'm out -- send mail to cyrus-bugs"; 122 } else { 123 vacation "I'm out -- call me at 304 555 1212"; 124 } 126 In the above example, coyote@desert.example.org gets the second 127 message despite having gotten the first one because separate vaca- 128 tion responses have been triggered. This behavior is REQUIRED. 130 The "per set of arguments" described above is intended to ensure 131 that a respondee gets all of the various possible responses, not 132 merely the first one. So, if the :subject or :mime parameters 133 would result in a different message, a different message MUST be 134 sent by the implementation. 136 If a script is changed, implementations MAY reset the records of 137 who has been responded to and when they have been responded to. 138 Alternatively, implementations can store records of who has 139 received which message, perhaps by storing a hash of the message 140 and the recipient. 142 Implementations are free to limit the number of remembered 143 responses, provided the limit is no less than 1000. 145 Internet DRAFT Sieve: Vacation Extension 26 October 2004 147 Implementations SHOULD make the limit no less than 1000 per vaca- 148 tion command if using the hash algorithm described above. When 149 limiting the number of tracked responses, implementations SHOULD 150 discard the oldest ones first. 152 3.4. MIME Parameter 154 The ":mime" parameter, if supplied, specifies that the reason 155 string is, in fact, a MIME part, including MIME headers (see 156 section 2.4.2.4 of [SIEVE]). 158 If the optional :mime parameter is not supplied, the reason string 159 is considered to be a UTF-8 string. 161 3.6. Address Parameter and Limiting Replies to Personal Messages 163 "Vacation" MUST NOT respond to a message unless the user's email 164 address is in the "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 165 "Resent-Bcc" line of the original message. Implementations are 166 assumed to know the user's email address, but users may have 167 additional addresses beyond the control of the local mail system. 169 Users can supply additional mail addresses that are theirs with the 170 ":addresses" argument, which takes a string-list listing additional 171 addresses that a user might have. These addresses are considered 172 in addition to the addresses that the implementation knows. 174 3.7. Restricting Replies to Automated Processes and Mailing Lists 176 Implementations MUST have a list of addresses that "vacation" MUST 177 NOT send mail to. However, the contents of this list are 178 implementation defined. The purpose of this list is to stop mail 179 from going to addresses used by system daemons that would not care 180 if the user is actually reading her mail. 182 Implementations are encouraged, however, to include well-known 183 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 184 addresses typically used only by automated systems. Additionally, 185 addresses ending in "-request" or beginning in "owner-", i.e., 186 reserved for mailing list software, are also suggested. 188 Implementors may take guidance from [MAILBOXNAMES], but should be 189 careful. Some addresses, like "POSTMASTER", are generally actually 190 managed by people, and people do care if the user is going to be 191 unavailable. 193 Implementations SHOULD NOT not to respond to any message with a 194 header that begins with "List-". 196 Internet DRAFT Sieve: Vacation Extension 26 October 2004 198 Implementations SHOULD NOT respond to any message that has an 199 "Auto-submitted" header field with a value other than "no". This 200 header field is described in [AUTO]. 202 3.8. Interaction with Other Sieve Actions 204 Vacation does not affect the implicit keep. 206 Vacation can only be executed once per script. If vacation is used 207 with another vacation, the script fails. 209 Implementations MUST NOT consider vacation used with discard, keep, 210 fileinto, or redirect an error. 212 3.9. Examples 214 Here is a simple use of vacation. 216 Example: 217 require "vacation"; 218 vacation :days 23 :addresses ["tjs@example.edu", 219 "ts4z@landru.example.edu"] 220 "I'm away until October 19. 221 If it's an emergency, call 911, I guess." ; 223 By mingling vacation with other rules, users can do something more 224 selective. 226 Example: require "vacation"; 227 if header :contains "from" "boss@example.edu" { 228 redirect "pleeb@isp.example.org"; 229 } else { 230 vacation "Sorry, I'm away, I'll read your 231 message when I get around to it."; 232 } 234 4. Response Message Generation 236 This section details the requirements for the generated response 237 message. 239 It is worth noting that the input message and arguments may be in 240 UTF-8, and that implementations MUST deal with UTF-8 input, 241 although implementations MAY transcode to other character sets as 242 regional taste dictates. 244 Internet DRAFT Sieve: Vacation Extension 26 October 2004 246 4.1. SMTP MAIL FROM address 248 The SMTP MAIL FROM address of the message envelope SHOULD be set to 249 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 250 SMTP transaction if possible. 252 4.2. Subject Parameter 254 Users can specify the subject of the reply with the ":subject" 255 parameter. If the :subject parameter is not supplied, then the 256 subject is generated as follows: The subject is set to the 257 characters "Re: " followed by the original subject with all leading 258 occurrence of the characters "Re: " stripped off. 260 4.3. In-Reply-To and References 262 Replies MUST have the In-Reply-To field set to the Message-ID of 263 the original message, and the References field must be updated with 264 the Message-ID of the original message. 266 If the original message lacks a Message-ID, an In-Reply-To need not 267 be generated, and References need not bne changed. 269 4.4. From 271 The From field SHOULD be set to the address of the owner of the 272 Sieve script. 274 4.5. To 276 The To field SHOULD be set to the address of the recipient of the 277 response. 279 4.7 Auto-submitted 281 An Auto-Submitted field with a value of "auto-replied" SHOULD be 282 included in the message header of any vacation message sent. 284 4.7. Message Body 286 The body of the message is taken from the reason string in the 287 vacation command. 289 5. Relationship to Recommendations for Automatic Responses to Electronic 290 Mail 292 The vacation extension implements a "Personal Responder" in the 293 terminology defined in [AUTO]. Care has been taken in this 295 Internet DRAFT Sieve: Vacation Extension 26 October 2004 297 specification to comply with the recommendations [AUTO] makes in 298 regards to how personal responders should behave. 300 6. Security Considerations 302 It is critical that implementations correctly implement the 303 limitations described above. Replies MUST NOT be sent out in 304 response to messages not sent directly to the user, and replies 305 MUST NOT be sent out more often than the :days argument states. 307 Security issues associated with mail auto-responders are fully 308 discussed in the security consideration section of [AUTO]. 310 7. IANA Considerations 312 The following template specifies the IANA registration of the 313 vacation Sieve extension specified in this document: 315 To: iana@iana.org 316 Subject: Registration of new Sieve extension 318 Capability name: vacation 319 Capability keyword: vacation 320 Capability arguments: N/A 321 Standards Track/IESG-approved experimental RFC number: this RFC 322 Person and email address to contact for further information: 323 Tim Showalter 324 E-Mail: tjs@psaux.com 326 This information should be added to the list of sieve extensions 327 given on http://www.iana.org/assignments/sieve-extensions. 329 8. Acknowledgements 331 This extension is obviously inspired by Eric Allman's vacation 332 program under Unix. The author owes a great deal to Carnegie 333 Mellon University, Cyrus Daboo, Ned Freed, Lawrence Greenfield, and 334 many others whose names have been lost during the inexcusably long 335 gestation period of this document. 337 9. Author's Address 339 Tim Showalter 341 E-Mail: tjs@psaux.com 343 Internet DRAFT Sieve: Vacation Extension 26 October 2004 345 Appendix A. References 347 Appendix A.1. Normative References" 349 [AUTO] Moore, K., "Recommendations for Automatic Responses to 350 Electronic Mail", Internet-Draft, draft-moore-auto-email- 351 response-05.txt. 353 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", RFC 2119, Harvard University, March 1997. 356 [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 357 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 358 2045, Innosoft and First Virtual, November 1996. 360 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 361 Mirapoint, Inc., RFC 3028, January, 2001. 363 Appendix A.2. Informative References 365 [MAILBOXNAMES] Crocker, D. "Mailbox Names for Common Services, 366 Roles, and Functions", RFC 2142, Internet Mail Consortium, May, 367 1997. 369 Appendix B. Intellectual Property Rights Statement 371 The IETF takes no position regarding the validity or scope of any 372 intellectual property or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; neither does it represent that it 376 has made any effort to identify any such rights. Information on 377 the IETF's procedures with respect to rights in standards-track and 378 standards-related documentation can be found in BCP-11. Copies of 379 claims of rights made available for publication and any assurances 380 of licenses to be made available, or the result of an attempt made 381 to obtain a general license or permission for the use of such 382 proprietary rights by implementors or users of this specification 383 can be obtained from the IETF Secretariat. 385 Internet DRAFT Sieve: Vacation Extension 26 October 2004 387 Appendix C. Full Copyright Statement 389 Copyright (C) The Internet Society 2004. This document is subject 390 to the rights, licenses and restrictions contained in BCP 78, and 391 except as set forth therein, the authors retain all their rights. 393 This document and the information contained herein are provided on 394 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 395 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 396 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 397 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 398 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 399 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 400 PARTICULAR PURPOSE. 402 (See RFC 3667 sections 5.4 and 5.5.)