idnits 2.17.1 draft-freed-sieve-ihave-02.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 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 315. 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 (May 25, 2008) is 5814 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 May 25, 2008 5 Expires: November 26, 2008 7 Sieve Email Filtering: Ihave Extension 8 draft-freed-sieve-ihave-02 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 November 26, 2008. 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 1. Introduction 67 Sieve [RFC5228] is a language for filtering email messages at or 68 around the time of final delivery. It is designed to be 69 implementable on either a mail client or mail server. It is suitable 70 for running on a mail server where users may not be allowed to 71 execute arbitrary programs, such as on black box Internet Message 72 Access Protocol [RFC3501] servers, as it has no user-controlled loops 73 or the ability to run external programs. 75 Various sieve extensions have already been defined, e.g., [RFC5229] 76 [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235], and many more are 77 sure to be created over time. Sieve's require clause is used to 78 specify the extensions a particular sieve needs; an error results if 79 the script's require clause calls for an extension that isn't 80 available. This mechanism is sufficient in most situations. 81 However, there can be cases where a script may be able to take 82 advantage of an extension if it is available but can still operate if 83 it is not, possibly with some degradation of functionality. Cases 84 can also arise where a script would prefer one extension but can 85 employ a different one if the first one is not available. 87 The "ihave" extension provides a means to write scripts that make use 88 of extensions only when they are actually available. Ihave defines a 89 new ihave test that takes a list of capability names as an argument 90 and succeeds if and only if all of the those capabilities are 91 present. Additionally, specification of the "ihave" extension in the 92 require clause disables parse time checking of extension use in 93 scripts; run-time checking must be used instead. This makes it 94 possible to write portable scripts that can operate in multiple 95 environments making effective use of whatever extensions are 96 available even though differing sets of extensions are provided in 97 different places. 99 The "ihave" extension also defines a new error control command. 100 Error causes script execution to terminate with the error message 101 given as the argument to the error control. 103 2. Conventions Used in this Document 105 "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 The terms used to describe the various components of the Sieve 110 language are taken from Section 1.1 of [RFC5228]. 112 3. Capability Identifiers 114 The capability string associated with the extension defined in this 115 document is "ihave". 117 4. Ihave Test 119 Usage: ihave 121 The ihave test provides a means for Sieve scripts to test for the 122 existence of a given extension prior to actually using it. The 123 capabilities argument to ihave is the same as the similarly-named 124 argument to the require control statement: It specifies the names of 125 one or more Sieve extensions or comparators. The ihave test succeeds 126 if all the extensions specified in the capabilities list are 127 available to the script. 129 Unlike most Sieve tests, ihave accepts no match or comparator 130 arguments. The type of match for ihave is always ":is" and the 131 comparator is always "i;octet". 133 The strings in the capabilities list are constant strings in context 134 of Sieve variables [RFC5229]. It is an error to pass a non-constant 135 string as an argument to ihave. 137 The Sieve base specification demands that that all Sieve extensions 138 used in a given script be specified in the initial require control 139 statement. It is an error for a script to call for extensions the 140 interpreter doesn't support or to attempt to use extensions that have 141 not been listed in the script's require clause. Using ihave changes 142 Sieve interpreter behavior and the underlying requirements in the 143 following ways: 145 1. Use of a given extension is allowed subsequent to the successful 146 evaluation of an ihave test on that extension all the way to the 147 end of the script, even outside the block enclosed by the ihave 148 test. In other words, subsequent to a successful ihave things 149 operate just as if the extension had been specified in the 150 script's require clause. The extension cannot be used prior to 151 the evaluation of such a test and a runtime error MUST be 152 generated if such usage is attempted. However, subsequent use of 153 that extension may still need to be conditionally handled via an 154 ihave test to deal with the case where it is not supported. The 155 extension cannot be used prior to the evaluation of such a test 156 and a runtime error MUST be generated if such usage is attempted. 158 2. Sieve interpreters normally have the option of checking extension 159 use at either parse time or execution time. The specification of 160 "ihave" in a script's require clause changes this behavior: 161 Scripts MUST either defer extension checking to run time or else 162 take the presence of ihave tests into account at parse time. 163 Note that since ihave can be used inside of anyof, allof, and not 164 tests full parse time checking of ihave may be very difficult to 165 implement. 167 3. Although it makes little sense to do so, an extension can be 168 specified in both the require control statement and in an ihave 169 test. If this is done and the extension has been implemented the 170 extension can be used anywhere in the script and an ihave test of 171 that extension will always return true. 173 4. Ihave accepts a list of capabilities. The ihave test fails and 174 none of the capabilities are enabled if any of the specified 175 capabilities are unavailable. 177 Ihave is designed to be used with extensions that add tests, actions, 178 or comparators. It MUST NOT be used with extensions that change how 179 the content of Sieve scripts are interpreted such as the variables 180 extension [RFC5229]. 182 5. Error Control 184 Usage: error 186 The error control causes script execution to terminate with a run- 187 time error. The message argument provides a text description of the 188 error condition that SHOULD be included in any generated report 189 regarding the error. Section 2.10.6 of [RFC5228] describes how run- 190 time errors are handled in Sieve. 192 Note that the message argument, like all Sieve string, employs the 193 UTF-8 charset and can contain non-US-ASCII characters. This must be 194 taken into consideration when reporting script errors. 196 The error control is included as part of the ihave extension so that 197 it is unconditionally available to scripts using ihave. 199 6. Security Considerations 201 A potential security issue with Sieve scripts is that when a script 202 fails to run due to the lack of some extension it may fail to block 203 dangerous email. The ihave extension makes it possible to improve 204 script portability and generality, which may improve the overall 205 security provided by Sieve. 207 Script robustness aside, ihave is essentially a more flexible variant 208 of Sieve's existing require mechanism. As such, it does not add any 209 additional capabilities to a Sieve implementation that could create 210 security issues. Of course all of the security considerations given 211 in the base Sieve specification and in any extensions that are 212 employed are still relevant. 214 7. IANA Considerations 216 The following template specifies the IANA registration of the Sieve 217 extension specified in this document: 219 To: iana@iana.org 220 Subject: Registration of new Sieve extension 222 Capability name: ihave 223 Description: The "ihave" extension provides a means to write 224 scripts that make use of other extensions only 225 when they are actually available. 226 RFC number: RFC XXXX 227 Contact address: Sieve discussion list 229 8. References 230 8.1. Normative references 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 236 Language", RFC 5228, January 2008. 238 8.2. Informative references 240 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 241 4rev1", RFC 3501, March 2003. 243 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 244 RFC 5229, January 2008. 246 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 247 Vacation Extension", RFC 5230, January 2008. 249 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 250 Relational Extension", RFC 5231, January 2008. 252 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 253 Extension", RFC 5232, January 2008. 255 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 256 Extension", RFC 5233, January 2008. 258 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 259 Extensions", RFC 5235, January 2008. 261 Appendix A. Acknowledgements 263 Cyrus Daboo and Alexey Melnikov provided helpful suggestions and 264 corrections. 266 Author's Address 268 Ned Freed 269 Sun Microsystems 270 3401 Centrelake Drive, Suite 410 271 Ontario, CA 92761-1205 272 USA 274 Phone: +1 909 457 4293 275 Email: ned.freed@mrochek.com 277 Full Copyright Statement 279 Copyright (C) The IETF Trust (2008). 281 This document is subject to the rights, licenses and restrictions 282 contained in BCP 78, and except as set forth therein, the authors 283 retain all their rights. 285 This document and the information contained herein are provided on an 286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 288 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 289 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 290 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 293 Intellectual Property 295 The IETF takes no position regarding the validity or scope of any 296 Intellectual Property Rights or other rights that might be claimed to 297 pertain to the implementation or use of the technology described in 298 this document or the extent to which any license under such rights 299 might or might not be available; nor does it represent that it has 300 made any independent effort to identify any such rights. Information 301 on the procedures with respect to rights in RFC documents can be 302 found in BCP 78 and BCP 79. 304 Copies of IPR disclosures made to the IETF Secretariat and any 305 assurances of licenses to be made available, or the result of an 306 attempt made to obtain a general license or permission for the use of 307 such proprietary rights by implementers or users of this 308 specification can be obtained from the IETF on-line IPR repository at 309 http://www.ietf.org/ipr. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights that may cover technology that may be required to implement 314 this standard. Please address the information to the IETF at 315 ietf-ipr@ietf.org.