idnits 2.17.1 draft-daboo-sieve-include-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. ** 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. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 24, 2005) is 6819 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) -- Looks like a reference, but probably isn't: 'LOCATION' on line 155 == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft ISAMET, Inc. 4 Expires: February 25, 2006 August 24, 2005 6 SIEVE Email Filtering: Include Extension 7 draft-daboo-sieve-include-03 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 February 25, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The SIEVE Email Filtering "include" extension permits users to 41 include one SIEVE script inside another. This can make managing 42 large scripts or multiple sets of scripts much easier, as well as 43 supporting common 'libraries' of scripts. Users are able to include 44 their own personal scripts or site-wide scripts provided by the local 45 SIEVE implementation. 47 Change History (to be removed prior to publication as an RFC) 48 Changes from -02 to -03: 49 a. Refreshing expired draft (updated for nits). 50 b. Syntax -> Usage. 51 c. Updated to 3028bis reference. 53 Changes from -01 to -02: 54 a. Minor formatting changes only - refreshing expired draft. 56 Changes from -00 to -01: 57 a. Added IPR boiler plate. 58 b. Re-ordered sections at start to conform to RFC style. 59 c. Moved recursion comment into General Considerations section. 60 d. Switched to using optional parameter to indicate personal vs 61 global. 62 e. Explicitly state that an error occurs when a missing script is 63 included. 65 Open Issues (to be resolved prior to publication as an RFC) 67 a. Intercation with variables (scoping). Should variables be 68 carried over between scripts that are included? Or should 69 variables defined in an included script be local to that script 70 only? 72 Table of Contents 74 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 76 3. SIEVE Include Extension . . . . . . . . . . . . . . . . . . . 4 77 3.1. General Considerations . . . . . . . . . . . . . . . . . . 4 78 3.2. Control Structure Include . . . . . . . . . . . . . . . . 5 79 3.3. Control Structure Return . . . . . . . . . . . . . . . . . 8 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. include registration . . . . . . . . . . . . . . . . . . . 9 83 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 Intellectual Property and Copyright Statements . . . . . . . . . . 11 88 1. Introduction and Overview 90 Its convenient to be able to break SIEVE [1] scripts down into 91 smaller components which can be reused in a variety of different 92 circumstances. For example, users may want to have a default script 93 and a special 'vacation' script, the later being activated when the 94 user goes on vacation. In that case the default actions should 95 continue to be run, but a vacation command should be executed first. 96 One option is to edit the default script to add or remove the 97 vacation command as needed. Another is to have a vacation script 98 that simply has a vacation command and then includes the default 99 script. 101 2. Conventions Used in This Document 103 Conventions for notations are as in SIEVE [1] section 1.1, including 104 use of RFC2119 [2]. 106 3. SIEVE Include Extension 108 3.1. General Considerations 110 SIEVE implementations that implement the "include" and "return" 111 control structures described below have an identifier of "include" 112 for use with the capability mechanism. If either of the "include" or 113 "return" control structures are used in a script, the "include" 114 capability MUST be listed in the "require" statement in that script. 116 SIEVE implementations must track the use of actions in included 117 scripts so that implicit "keep" behaviour can be properly determined 118 based on whether any actions have executed in any script. 120 SIEVE implementations are allowed to limit the total number of nested 121 included scripts, but MUST provide for a total of at least three 122 levels of nested scripts including the top-level script. An error 123 MUST be generated either when the script is uploaded to the SIEVE 124 repository, or when the script is executed, if any nesting limit is 125 exceeded. If such an error is detected whilst processing a SIEVE 126 script, an implicit "keep" action MUST be executed to prevent loss of 127 any messages. 129 SIEVE implementations MUST ensure that recursive includes are not 130 possible. i.e. if script "A" includes script "B", and script "B" 131 includes script "A" an error MUST be generated either when the script 132 is uploaded to the SIEVE repository, or when the script is executed. 133 If such an error is detected whilst processing a SIEVE script, an 134 implicit "keep" action MUST be executed to prevent loss of any 135 messages. 137 SIEVE implementations MUST handle missing scripts being referenced 138 via an includes in an existing script. An error MUST be generated 139 when a missing included script is descovered during execution. If 140 such an error is detected an implicit "keep" action MUST be executed 141 to prevent loss of any messages. 143 3.2. Control Structure Include 145 Usage: include [LOCATION] 147 The "include" control structure includes an optional parameter, and a 148 single string argument representing the name of the script to include 149 in the main script at that point. 151 [LOCATION] is an optional parameter that has one of two values: 153 Usage: ":personal" / ":global" 155 If the [LOCATION] parameter is not present, the location defaults to 156 :personal. 158 The location has the following meanings: 160 :personal 162 Indicates that the named script is stored in the user's own 163 personal (private) SIEVE repository. 165 :global 167 Indicates that the named script is stored in a site-wide SIEVE 168 repository, accessible to all users of the SIEVE system. 170 The included script MUST be a valid SIEVE script, including having 171 necessary "require" statements for all optional capabilities used by 172 the script. The scope of a "require" statement in an included script 173 is for that script only, not the including script. e.g. if script "A" 174 includes script "B", and script "B" uses the "fileinto" extension, 175 script "B" must have a "require" statement for "fileinto", 176 irrespective of whether script "A" has one. In addition, if script 177 "A" does not have a "require" statement for "fileinto", "fileinto" 178 cannot be used anywhere in script "A", even after inclusion of script 179 "B". 181 A "stop" control statement in an included script MUST stop all script 182 processing, including the processing of the scripts that include the 183 current one. The "return" control statement (described below) stops 184 processing of the current script only, and allows the scripts that 185 include it to continue. 187 Examples: 189 In the examples below, script content is indicated by a '|' as the 190 first non-space character on a line for clarity. The '|' characters 191 are not part of the script itself. 193 The user has four scripts stored in their personal repository: 195 "default" 197 This is the default active script that includes several others. 199 | require ["include"]; 200 | 201 | include :personal "always_allow"; 202 | include :global "spam_tests"; 203 | include :personal "my_spam_tests"; 204 | include :personal "mailing_lists"; 206 "always_allow" 208 This script special cases some correspondent email addresses and 209 makes sure any message containing those addresses are always kept. 211 | if header :is "From" "boss@example.com" 212 | { 213 | keep; 214 | } 215 | elsif header :is "From" "ceo@example.com" 216 | { 217 | keep; 218 | } 220 "my_spam_tests" 222 This script does some user-specific spam tests to catch spam 223 messages not caught by the site-wide spam tests. 225 | require ["reject"]; 226 | 227 | if header :contains "Subject" "XXXX" 228 | { 229 | reject; 230 | } 231 | elsif header :is "From" "money@example.com" 232 | { 233 | reject; 234 | } 236 "mailing_lists" 238 This script looks for messages from different mailing lists and 239 files each into a mailbox specific to the mailing list. 241 | require ["fileinto"]; 242 | 243 | if header :is "Sender" "owner-ietf-mta-filters@imc.org" 244 | { 245 | fileinto "lists.sieve"; 246 | } 247 | elsif header :is "Sender" "owner-ietf-imapext@imc.org" 248 | { 249 | fileinto "lists.imapext"; 250 | } 252 There is one script stored in the global repository: 254 "spam_tests" 256 This script does some site-wide spam tests which any user at the 257 site can include in their own scripts at a suitable point. The 258 script content is kept up to date by the site administrator. 260 | require ["reject"]; 261 | 262 | if anyof (header :contains "Subject" "$$", 263 | header :contains "Subject" "Make money") 264 | { 265 | reject; 266 | } 268 The "include" control structure may appear anywhere in the script 269 where a control structure is legal. 271 Example: 273 | require ["include"]; 274 | 275 | if anyof (header :contains "Subject" "$$", 276 | header :contains "Subject" "Make money") 277 | { 278 | include "my_reject_script"; 279 | } 281 3.3. Control Structure Return 283 Usage: return 285 The "return" control structure stops processing of the currently 286 included script only and returns processing control to the script 287 which includes it. If used in the main script (i.e. not in an 288 included script), it has the same effect as the "stop" control 289 structure, including the appropriate "keep" action if no other 290 actions have been executed up to that point. 292 4. Security Considerations 294 SIEVE implementations MUST ensure adequate security for the global 295 script repository to prevent unauthorized changes to global scripts. 297 Beyond that, the "include" extension does not raise any security 298 considerations that are not present in the base SIEVE protocol, and 299 these issues are discussed in SIEVE. 301 5. IANA Considerations 303 The following template specifies the IANA registration of the Sieve 304 extension specified in this document: 306 5.1. include registration 308 To: iana@iana.org 309 Subject: Registration of new Sieve extension 311 Capability name: include 312 Capability keyword: include 313 Capability arguments: N/A 314 Standards Track/IESG-approved experimental RFC number: this RFC 315 Person and email address to contact for further information: 317 Cyrus Daboo 318 ISAMET, Inc. 319 5001 Baum Blvd., Suite 650, 320 Pittsburgh, PA 15213 321 U.S.A. 323 325 This information should be added to the list of sieve extensions 326 given on http://www.iana.org/assignments/sieve-extensions. 328 This information should be added to the list of sieve extensions 329 given on http://www.iana.org/assignments/sieve-extensions. 331 6. Normative References 333 [1] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 334 Language", draft-ietf-sieve-3028bis-04 (work in progress), 335 July 2005. 337 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 338 Levels", BCP 14, RFC 2119, March 1997. 340 Appendix A. Acknowledgments 342 Thanks to Ken Murchison, Rob Siemborski, Alexey Melnikov, Marc Mutz 343 and Kjetil Torgrim Homme for comments and corrections. 345 Author's Address 347 Cyrus Daboo 348 ISAMET, Inc. 349 5001 Baum Blvd. 350 Suite 650 351 Pittsburgh, PA 15213 352 US 354 Email: daboo@isamet.com 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 Disclaimer of Validity 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 385 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 386 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 387 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Copyright Statement 392 Copyright (C) The Internet Society (2005). This document is subject 393 to the rights, licenses and restrictions contained in BCP 78, and 394 except as set forth therein, the authors retain all their rights. 396 Acknowledgment 398 Funding for the RFC Editor function is currently provided by the 399 Internet Society.