idnits 2.17.1 draft-freed-sieve-ihave-03.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 334. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 9, 2008) is 5649 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) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft Sun Microsystems 4 Intended status: Standards Track October 9, 2008 5 Expires: April 12, 2009 7 Sieve Email Filtering: Ihave Extension 8 draft-freed-sieve-ihave-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 12, 2009. 35 Abstract 37 This document describes the "ihave" extension to the Sieve email 38 filtering language. The "ihave" extension provides a means to write 39 scripts that can take advantage of optional Sieve features but can 40 still run when those optional features are not available. The 41 extension also defines a new error control command intended to be 42 used to report situations where no combination of available 43 extensions satisfies the needs of the script. 45 Change History (to be removed prior to publication as an RFC) 47 Changed the comparator used in the ihave test from "i;ascii-casemap" 48 to "i;octet". 50 Updated the IANA registration template. 52 Simplified the semantics of ihave to be independent of block 53 structure. 55 Moved the environment extension to a separate document so the 56 standards status of the two extensions can be different. 58 Added error action. 60 Added some text to make the portability advantages of ihave clearer. 62 Added a note about the possibility that the argument to error uses 63 UTF-8 characters. 65 (from WGLC) Various editorial fixups. 67 (from WGLC) Incorporated the same short-circuit, left to right 68 requirements the variables extension imposes, because without it 69 invocation of the variables extension could potentially change the 70 meaning of ihave constructs in anyof or allof clauses. 72 (from WGLC) Added a resriction that ihave MUST NOT be used with any 73 extension that changes the underlying Sieve grammar. Hopefully there 74 won't be any such extensions, but better safe than sorry. 76 1. Introduction 78 Sieve [RFC5228] is a language for filtering email messages at or 79 around the time of final delivery. It is designed to be 80 implementable on either a mail client or mail server. It is suitable 81 for running on a mail server where users may not be allowed to 82 execute arbitrary programs, such as on black box Internet Message 83 Access Protocol [RFC3501] servers, as it has no user-controlled loops 84 or the ability to run external programs. 86 Various sieve extensions have already been defined, e.g., [RFC5229] 87 [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235], and many more are 88 sure to be created over time. Sieve's require clause is used to 89 specify the extensions a particular sieve needs; an error results if 90 the script's require clause calls for an extension that isn't 91 available. This mechanism is sufficient in most situations. 92 However, there can be cases where a script may be able to take 93 advantage of an extension if it is available but can still operate if 94 it is not, possibly with some degradation of functionality. Cases 95 can also arise where a script would prefer one extension but can 96 employ a different one if the first one is not available. 98 The "ihave" extension provides a means to write scripts that make use 99 of extensions only when they are actually available. Ihave defines a 100 new ihave test that takes a list of capability names as an argument 101 and succeeds if and only if all of those capabilities are present. 102 Additionally, specification of the "ihave" extension in the require 103 clause disables parse time checking of extension use in scripts; run- 104 time checking must be used instead. This makes it possible to write 105 portable scripts that can operate in multiple environments making 106 effective use of whatever extensions are available even though 107 differing sets of extensions are provided in different places. 109 The "ihave" extension also defines a new error control command. 110 Error causes script execution to terminate with the error message 111 given as the argument to the error control. 113 2. Conventions Used in this Document 115 "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 The terms used to describe the various components of the Sieve 120 language are taken from Section 1.1 of [RFC5228]. 122 3. Capability Identifiers 124 The capability string associated with the extension defined in this 125 document is "ihave". 127 4. Ihave Test 129 Usage: ihave 131 The ihave test provides a means for Sieve scripts to test for the 132 existence of a given extension prior to actually using it. The 133 capabilities argument to ihave is the same as the similarly-named 134 argument to the require control statement: It specifies the names of 135 one or more Sieve extensions or comparators. The ihave test succeeds 136 if all the extensions specified in the capabilities list are 137 available to the script. 139 Unlike most Sieve tests, ihave accepts no match or comparator 140 arguments. The type of match for ihave is always ":is" and the 141 comparator is always "i;octet". 143 The strings in the capabilities list are constant strings in the 144 context of Sieve variables [RFC5229]. It is an error to pass a non- 145 constant string as an argument to ihave. 147 The Sieve base specification demands that all Sieve extensions used 148 in a given script be specified in the initial require control 149 statement. It is an error for a script to call for extensions the 150 interpreter doesn't support or to attempt to use extensions that have 151 not been listed in the script's require clause. Using ihave changes 152 Sieve interpreter behavior and the underlying requirements in the 153 following ways: 155 1. Use of a given extension is allowed subsequent to the successful 156 evaluation of an ihave test on that extension all the way to the 157 end of the script, even outside the block enclosed by the ihave 158 test. In other words, subsequent to a successful ihave things 159 operate just as if the extension had been specified in the 160 script's require clause. The extension cannot be used prior to 161 the evaluation of such a test and a runtime error MUST be 162 generated if such usage is attempted. However, subsequent use of 163 that extension may still need to be conditionally handled via an 164 ihave test to deal with the case where it is not supported. The 165 extension cannot be used prior to the evaluation of such a test 166 and a runtime error MUST be generated if such usage is attempted. 168 2. Sieve interpreters normally have the option of checking extension 169 use at either parse time or execution time. The specification of 170 "ihave" in a script's require clause changes this behavior: 171 Scripts MUST either defer extension checking to run time or else 172 take the presence of ihave tests into account at parse time. 173 Note that since ihave can be used inside of anyof, allof, and not 174 tests full parse time checking of ihave may be very difficult to 175 implement. 177 3. Although it makes little sense to do so, an extension can be 178 specified in both the require control statement and in an ihave 179 test. If this is done and the extension has been implemented the 180 extension can be used anywhere in the script and an ihave test of 181 that extension will always return true. 183 4. Ihave accepts a list of capabilities. The ihave test fails and 184 none of the capabilities are enabled if any of the specified 185 capabilities are unavailable. 187 5. The Sieve base specification does not require that interpreters 188 evaluate arguments in any particular order or that test 189 evaluation be short-circuited. If ihave is enabled the 190 interpreter MUST short-circuit tests, i.e., not perform more 191 tests than necessary to find the result. Additionally, 192 evaluation order MUST be left to right if ihave is enabled. 194 Ihave is designed to be used with extensions that add tests, actions, 195 comparators, or arguments. It MUST NOT be used with extensions that 196 change the underlying Sieve grammer or extensions like variables 197 [RFC5229] that change how the content of Sieve scripts are 198 interpreted. 200 5. Error Control 202 Usage: error 204 The error control causes script execution to terminate with a run- 205 time error. The message argument provides a text description of the 206 error condition that SHOULD be included in any generated report 207 regarding the error. Section 2.10.6 of [RFC5228] describes how run- 208 time errors are handled in Sieve. 210 Note that the message argument, like all Sieve strings, employs the 211 UTF-8 charset and can contain non-US-ASCII characters. This must be 212 taken into consideration when reporting script errors. 214 The error control is included as part of the ihave extension so that 215 it is unconditionally available to scripts using ihave. 217 6. Security Considerations 219 A potential security issue with Sieve scripts is that when a script 220 fails to run due to the lack of some extension it may fail to block 221 dangerous email. The ihave extension makes it possible to improve 222 script portability and generality, which may improve the overall 223 security provided by Sieve. 225 Script robustness aside, ihave is essentially a more flexible variant 226 of Sieve's existing require mechanism. As such, it does not add any 227 additional capabilities to a Sieve implementation that could create 228 security issues. Of course all of the security considerations given 229 in the base Sieve specification and in any extensions that are 230 employed are still relevant. 232 7. IANA Considerations 234 The following template specifies the IANA registration of the Sieve 235 extension specified in this document: 237 To: iana@iana.org 238 Subject: Registration of new Sieve extension 240 Capability name: ihave 241 Description: The "ihave" extension provides a means to write 242 scripts that make use of other extensions only 243 when they are actually available. 244 RFC number: RFC XXXX 245 Contact address: Sieve discussion list 247 8. References 249 8.1. Normative references 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 255 Language", RFC 5228, January 2008. 257 8.2. Informative references 259 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 260 4rev1", RFC 3501, March 2003. 262 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 263 RFC 5229, January 2008. 265 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 266 Vacation Extension", RFC 5230, January 2008. 268 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 269 Relational Extension", RFC 5231, January 2008. 271 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 272 Extension", RFC 5232, January 2008. 274 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 275 Extension", RFC 5233, January 2008. 277 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 278 Extensions", RFC 5235, January 2008. 280 Appendix A. Acknowledgements 282 Stephan Bosch, Cyrus Daboo, Arnt Gulbrandsen, Andrew McKeon, and 283 Alexey Melnikov provided helpful suggestions and corrections. 285 Author's Address 287 Ned Freed 288 Sun Microsystems 289 800 Royal Oaks 290 Monrovia, CA 91016-6347 291 USA 293 Phone: +1 909 457 4293 294 Email: ned.freed@mrochek.com 296 Full Copyright Statement 298 Copyright (C) The IETF Trust (2008). 300 This document is subject to the rights, licenses and restrictions 301 contained in BCP 78, and except as set forth therein, the authors 302 retain all their rights. 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 307 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 308 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 309 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Intellectual Property 314 The IETF takes no position regarding the validity or scope of any 315 Intellectual Property Rights or other rights that might be claimed to 316 pertain to the implementation or use of the technology described in 317 this document or the extent to which any license under such rights 318 might or might not be available; nor does it represent that it has 319 made any independent effort to identify any such rights. Information 320 on the procedures with respect to rights in RFC documents can be 321 found in BCP 78 and BCP 79. 323 Copies of IPR disclosures made to the IETF Secretariat and any 324 assurances of licenses to be made available, or the result of an 325 attempt made to obtain a general license or permission for the use of 326 such proprietary rights by implementers or users of this 327 specification can be obtained from the IETF on-line IPR repository at 328 http://www.ietf.org/ipr. 330 The IETF invites any interested party to bring to its attention any 331 copyrights, patents or patent applications, or other proprietary 332 rights that may cover technology that may be required to implement 333 this standard. Please address the information to the IETF at 334 ietf-ipr@ietf.org.