idnits 2.17.1 draft-showalter-sieve-vacation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 79: '... Sites MAY define a different mini...' RFC 2119 keyword, line 80: '...ays value, which MUST be greater than ...' RFC 2119 keyword, line 117: '...triggered. This behavior is REQUIRED....' RFC 2119 keyword, line 119: '... implementations MAY reset the records...' RFC 2119 keyword, line 144: '... Replies MUST have the In-Reply-To...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 64 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 (12 May 2003) is 7648 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 243 looks like a reference -- Missing reference section? 'KEYWORDS' on line 232 looks like a reference -- Missing reference section? 'MAILBOXNAMES' on line 235 looks like a reference -- Missing reference section? 'MIME' on line 239 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Showalter 3 Internet Draft: Sieve: Vacation Extension Mirapoint 4 Document: draft-showalter-sieve-vacation-05.txt 12 May 2003 5 Expire in six months 7 Sieve: Vacation Extension 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright 33 Copyright (C) The Internet Society 2003. All Rights Reserved. 35 Abstract 37 This document describes an extension to the Sieve mail filtering 38 language for an autoresponder similar to that of the Unix 39 "vacation" command for replying to messages with certain safety 40 features to prevent problems. 42 1. Introduction 44 This is an extension to the Sieve language defined by [SIEVE] for 45 notification that messages will not be immediately answered. 47 Conventions for notations are as in [SIEVE] section 1.1. 49 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", 50 and "MAY" in this document are to be interpreted as defined in 51 [KEYWORDS]. 53 2. Capability Identifier 55 Sieve implementations that implement vacation have an identifier of 56 "vacation" for use with the capability mechanism. 58 3. Vacation Action 60 Syntax: vacation [":days" number] [":addresses" string-list] 61 [":subject" string] [":mime"] 63 The "vacation" action implements a vacation autoresponder similar 64 to the vacation command available under many versions of Unix. 65 Its purpose is to provide correspondents with notification that the 66 user is away for an extended period of time and that they should 67 not expect quick responses. 69 "Vacation" is used to respond to a message with another message. 70 Vacation's messages are always addressed to the Return-Path address 71 (that is, the envelope from address) of the message being responded 72 to. 74 3.1. Days Parameter 76 The ":days" argument is used to specify the period in which 77 addresses are kept and are not responded to, and is always 78 specified in days. The minimum value used for this parameter is 1. 79 Sites MAY define a different minimum value. Sites MAY also define 80 a maximum days value, which MUST be greater than 7, and SHOULD be 81 greater than 30. 83 If ":days" is omitted, the default value is either 7 or the minimum 84 value (as defined above), whichever is greater. 86 If the parameter given to ":days" is less than the minimum value, 87 then the minimum value is used instead. 89 If ":days" exceeds the site-defined maximum, the site-defined 90 maximum is used instead. 92 3.2. Previous Response Tracking 94 "Vacation" keeps track of all of the addresses that it has 95 responded to in some period (as specified by the :days optional 96 argument). If vacation has not previously responded to this 97 address within that time period, it sends the "reason" argument to 98 the Return-Path address of the message that is being responded to. 100 Vacation responses are not just per address, but are per address 101 per vacation command. For instance, If coyote@desert.example.org 102 sends mail to roadrunner@acme.example.com, once with the subject 103 "Cyrus bug" and once with the subject "come over for dinner", and 104 roadrunner@acme.example.com has the script below, 105 coyote@desert.example.org would receive two responses, once with 106 the first message, once with the second. 108 Example: require "vacation"; 109 if subject :contains "cyrus" { 110 vacation "I'm out -- send mail to cyrus-bugs"; 111 } else { 112 vacation "I'm out -- call me at 304 555 1212"; 113 } 115 Note that coyote@desert.example.org gets the second message despite 116 having gotten the first one because separate vacation responses 117 have been triggered. This behavior is REQUIRED. 119 If a sieve script changes, implementations MAY reset the records of 120 who has been responded to and when they have been responded to. 121 Alternatively, implementations can store records of who has 122 received which message, perhaps by storing a hash of the message 123 and the recipient. 125 3.3. Subject Parameter 127 Users can specify the subject of the reply with the ":subject" 128 parameter. If the :subject parameter is not supplied, then the 129 subject is generated as follows: The subject is set to the 130 characters "Re: " followed by the original subject with all leading 131 occurrence of the characters "Re: " stripped off. 133 3.4. MIME Parameter 135 The ":mime" parameter, if supplied, specifies that the reason 136 string is, in fact, a MIME part, including MIME headers (see 137 section 2.4.2.4 of [SIEVE]). 139 If the optional :mime parameter is not supplied, the reason string 140 is considered to be a UTF-8 string. 142 3.5. In-Reply-To 144 Replies MUST have the In-Reply-To field set to the Message-ID of 145 the original message. 147 3.6. Address Parameter and Limiting Replies to Personal Messages 149 "Vacation" MUST NOT respond to a message unless the user's email 150 address is in the "To", "Cc", or "Bcc" line of the original 151 message. Implementations are assumed to know the user's email 152 address, but users may have additional addresses beyond the control 153 of the local mail system. 155 Users can supply additional mail addresses that are theirs with the 156 ":addresses" argument, which takes a string-list listing additional 157 addresses that a user might have. These addresses are considered 158 in addition to the addresses that the implementation knows. 160 3.7. Restricting Replies to Automated Processes and Mailing Lists 162 Implementations MUST have a list of addresses that "vacation" MUST 163 NOT send mail to. However, the contents of this list are 164 implementation defined. The purpose of this list is to stop mail 165 from going to addresses used by system daemons that would not care 166 if the user is actually reading her mail. 168 Implementations are encouraged, however, to include well-known 169 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 170 addresses typically used only by automated systems. Additionally, 171 addresses ending in "-request" or beginning in "owner-", i.e., 172 reserved for mailing list software, are also suggested. 174 Implementors may take guidance from [MAILBOXNAMES], but should be 175 careful. Some addresses, like "POSTMASTER", are generally actually 176 managed by people, and people do care if the user is going to be 177 unavailable. 179 Implementations SHOULD NOT not to respond to any message with a 180 header that begins with "List-". 182 3.8. Interaction with Other Sieve Actions 184 Vacation does not affect the implicit keep. 186 Vacation can only be executed once per script. If vacation is used 187 with another vacation, the script fails. 189 Implementations MUST NOT consider vacation used with discard, keep, 190 fileinto, or redirect an error. 192 3.9. Examples 194 Here is a simple use of vacation. 196 Example: 197 require "vacation"; 198 vacation :days 23 :addresses ["tjs@example.edu", 199 "ts4z@landru.example.edu"] 200 "I'm away until October 19. 201 If it's an emergency, call 911, I guess." ; 203 By mingling vacation with other rules, users can do something more 204 selective. 206 Example: require "vacation"; 207 if header :contains "from" "boss@example.edu" { 208 redirect "pleeb@isp.example.org"; 209 } else { 210 vacation "Sorry, I'm away, I'll read your 211 message when I get around to it."; 212 } 214 4. Security Considerations 216 It is critical that implementations correctly implement the 217 limitations described above. Replies MUST NOT be sent out in 218 response to messages not sent directly to the user, and replies 219 MUST NOT be sent out more often than the :days argument states. 221 5. Author's Address 223 Tim Showalter 224 Mirapoint, Inc. 225 909 Hermosa Court 226 Sunnyvale, CA 94085 228 E-Mail: tjs@mirapoint.com 230 Appendix A. References 232 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", RFC 2119, Harvard University, March 1997. 235 [MAILBOXNAMES] Crocker, D. "Mailbox Names for Common Services, 236 Roles, and Functions", RFC 2142, Internet Mail Consortium, May, 237 1997. 239 [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 240 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 241 2045, Innosoft and First Virtual, November 1996. 243 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", 244 Mirapoint, Inc., RFC 3028, January, 2001. 246 Appendix B. Full Copyright Statement 248 Copyright (C) The Internet Society 2000. All Rights Reserved. 250 This document and translations of it may be copied and furnished to 251 others, and derivative works that comment on or otherwise explain 252 it or assist in its implementation may be prepared, copied, 253 published and distributed, in whole or in part, without restriction 254 of any kind, provided that the above copyright notice and this 255 paragraph are included on all such copies and derivative works. 256 However, this document itself may not be modified in any way, such 257 as by removing the copyright notice or references to the Internet 258 Society or other Internet organizations, except as needed for the 259 purpose of developing Internet standards in which case the 260 procedures for copyrights defined in the Internet Standards process 261 must be followed, or as required to translate it into languages 262 other than English. 264 The limited permissions granted above are perpetual and will not be 265 revoked by the Internet Society or its successors or assigns. 267 This document and the information contained herein is provided on 268 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 269 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 270 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 271 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 272 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.