idnits 2.17.1 draft-freed-sieve-ihave-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. 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 : ---------------------------------------------------------------------------- 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 (February 23, 2008) is 5899 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 (~~), 2 warnings (==), 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 Expires: August 26, 2008 February 23, 2008 6 Sieve Email Filtering: Ihave Extension 7 draft-freed-sieve-ihave-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 26, 2008. 34 Abstract 36 This document describes the "ihave" extension to the Sieve email 37 filtering language. The "ihave" extension provides a means to write 38 scripts that can take advantage of optional Sieve features but can 39 still run when those optional features are not available. The 40 extension also defines a new error control command intended to be 41 used to report situations where no combination of available 42 extensions satifies the needs of the script. 44 Change History (to be removed prior to publication as an RFC 46 Changed the comparator used in the ihave test from "i;ascii-casemap" 47 to "i;octet". 49 Updated the IANA registration template. 51 Simplified the semantics of ihave to be independent of block 52 structure. 54 Moved the environment extension to a separate document so the 55 standards status of the two extensions can be different. 57 Added error action. 59 1. Introduction 61 Sieve [RFC5228] is a language for filtering email messages at or 62 around the time of final delivery. It is designed to be 63 implementable on either a mail client or mail server. It is suitable 64 for running on a mail server where users may not be allowed to 65 execute arbitrary programs, such as on black box Internet Message 66 Access Protocol [RFC3501] servers, as it has no user-controlled loops 67 or the ability to run external programs. 69 Various sieve extensions have already been defined, e.g., [RFC5229] 70 [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235], and many more are 71 sure to be created over time. Sieve's require clause is used to 72 specify the extensions a particular sieve needs; an error results if 73 the script's require clause calls for an extension that isn't 74 available. This mechanism is sufficient in most situations. 75 However, there can be cases where a script may be able to take 76 advantage of an extension if it is available but can still function 77 if it is not, possibly with some degradation of capabilities. Cases 78 can also arise where a script would prefer one extension but can 79 employ a different one if the first one is not available. 81 The "ihave" extension provides a means to write scripts that make use 82 of extensions only when they are actually available. Ihave defines a 83 new ihave test that takes a list of capability names as an argument 84 and succeeds if and only if all of the those capabilities are 85 present. Additionally, specification of the "ihave" extension in the 86 require clause disables parse time checking of extension use in 87 scripts; run-time checking must be used instead. 89 The "ihave" extension also defines a new error control command. 90 Error causes script execution to terminate with the error message 91 given as the argument to the error control. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 The terms used to describe the various components of the Sieve 100 language are taken from [RFC5228] section 1.1. 102 3. Capability Identifiers 104 The capability string associated with the extension defined in this 105 document is "ihave". 107 4. Ihave Test 109 Usage: ihave 111 The ihave test provides a means for Sieve scripts to test for the 112 existence of a given extension prior to actually using it. The 113 capabilities argument to ihave is the same as the similarly-named 114 argument to the require control statement: It specifies the names of 115 one or more Sieve extensions or comparators. The ihave test succeeds 116 if all the extensions specified in the capabilities list are 117 available to the script. 119 Unlike most Sieve tests, ihave accepts no match or comparator 120 arguments. The type of match for ihave is always ":is" and the 121 comparator is always "i;octet". 123 The strings in the capabilities list are constant strings in context 124 of Sieve variables [RFC5229]. It is an error to pass a non-constant 125 string as an argument to ihave. 127 The Sieve base specification demands that that all Sieve extensions 128 used in a given script be specified in the initial require control 129 statement. It is an error for a script to call for extensions the 130 interpreter doesn't support or to attempt to use extensions that have 131 not been listed in the script's require clause. Using ihave changes 132 Sieve interpreter behavior and the underlying requirements in the 133 following ways: 135 1. Use of a given extension is allowed subsequent to the successful 136 evaluation of an ihave test on that extension. The extension 137 then operates just as if it had been specified in the script's 138 require clause. The extension cannot be used prior to the 139 evaluation of such a test and a runtime error MUST be generated 140 if such usage is attempted. 142 2. Sieve interpreters normally have the option of checking extension 143 use at either parse time or execution time. The specification of 144 "ihave" in a script's require clause changes this behavior: 145 Scripts MUST either defer extension checking to run time or else 146 take the presence of ihave tests into account at parse time. 147 Note that since ihave can be used inside of anyof, allof, and not 148 tests full parse time checking of ihave may be very difficult to 149 implement. 151 3. Although it makes little sense to do so, an extension can be 152 specified in both the require control statement and in an ihave 153 test. If this is done and the extension has been implemented the 154 extension can be used anywhere in the script and an ihave test of 155 that extension will always return true. 157 4. Ihave accepts a list of capabilities. The ihave test fails and 158 none of the capabilities are enabled if any of the specified 159 capabilities are unavailable. 161 Ihave is designed to be used with extensions that add tests, actions, 162 or comparators. It MUST NOT be used with extensions that change how 163 the content of Sieve scripts are interpreted such as the variables 164 extension [RFC5229]. 166 5. Error Control 168 Usage: error 170 The error control causes script execution to terminate with a run- 171 time error. The message argument provides a text description of the 172 error condition that SHOULD be included in any generated report 173 regarding the error. Section 2.10.6 of [RFC5228] describes how run- 174 time errors are handled in Sieve. 176 The error control is included as part of the ihave extension so that 177 it is unconditionally available to scripts using ihave. 179 6. Security Considerations 181 A potential security issue with Sieve scripts is that when a script 182 fails to run due to the lack of some extension it may fail to block 183 dangerous email. The ihave extension makes it possible to improve 184 script portability and generality, which may improve the overall 185 security provided by Sieve. 187 Script robustness aside, ihave is essentially a more flexible variant 188 of Sieve's existing require mechanism. As such, it does not add any 189 additional capabilities to a Sieve implementation that could create 190 security issues. Of course all of the security considerations given 191 in the base Sieve specification and in any extensions that are 192 employed are still relevant. 194 7. IANA Considerations 196 The following template specifies the IANA registration of the Sieve 197 extension specified in this document: 199 To: iana@iana.org 200 Subject: Registration of new Sieve extension 202 Capability name: ihave 203 Description: The "ihave" extension provides a means to write 204 scripts that make use of other extensions only 205 when they are actually available. 206 RFC number: RFC XXXX 207 Contact address: Sieve discussion list 209 8. References 211 8.1. Normative references 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 217 Language", RFC 5228, January 2008. 219 8.2. Informative references 221 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 222 4rev1", RFC 3501, March 2003. 224 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 225 RFC 5229, January 2008. 227 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 228 Vacation Extension", RFC 5230, January 2008. 230 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 232 Relational Extension", RFC 5231, January 2008. 234 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 235 Extension", RFC 5232, January 2008. 237 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 238 Extension", RFC 5233, January 2008. 240 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 241 Extensions", RFC 5235, January 2008. 243 Author's Address 245 Ned Freed 246 Sun Microsystems 247 3401 Centrelake Drive, Suite 410 248 Ontario, CA 92761-1205 249 USA 251 Phone: +1 909 457 4293 252 Email: ned.freed@mrochek.com 254 Full Copyright Statement 256 Copyright (C) The IETF Trust (2008). 258 This document is subject to the rights, licenses and restrictions 259 contained in BCP 78, and except as set forth therein, the authors 260 retain all their rights. 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 265 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 266 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 267 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org.