idnits 2.17.1 draft-freed-sieve-environment-ihave-00.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** 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 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 (November 13, 2006) is 6372 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: 'COMPARATOR' is mentioned on line 117, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 117, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-09 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 5 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: May 17, 2007 November 13, 2006 6 Sieve Email Filtering: Environment and Ihave Extensions 7 draft-freed-sieve-environment-ihave-00 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 May 17, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes the "environment" and "ihave" extensions to 41 the Sieve email filtering language. The "environment" extension 42 gives Sieve access to information about the environment where the 43 Sieve interpreter is running. The "ihave" extension provides a means 44 to write scripts that can take advantage of optional Sieve features 45 but can still run when those optional features are not available. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions used in this document . . . . . . . . . . . . . . 3 51 3. Capability Identifiers . . . . . . . . . . . . . . . . . . . . 3 52 4. Environment Test . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. Standard Environment Items . . . . . . . . . . . . . . . . 4 54 4.2. Vendor-defined Environment Items . . . . . . . . . . . . . 5 55 4.3. IANA Registration of Environment Items . . . . . . . . . . 5 56 4.3.1. Template for Environment Registrations . . . . . . . . 5 57 4.3.2. Initial Environment Item Registrations . . . . . . . . 6 58 5. Ihave Test . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8.1. Normative references . . . . . . . . . . . . . . . . . . . 8 63 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 Sieve [I-D.ietf-sieve-3028bis] is a language for filtering email 70 messages at or around the time of final delivery. It is designed to 71 be implementable on either a mail client or mail server. It is 72 suitable for running on a mail server where users may not be allowed 73 to execute arbitrary programs, such as on black box Internet Message 74 Access Protocol [RFC3501] servers, as it has no user-controlled loops 75 or the ability to run external programs. 77 Although sieve is intended to be independent of access protocol, mail 78 architecture, and operating system, in some cases it is useful to 79 allow scripts to access information about their execution context. 80 The "environment" extension provides a new environment test that can 81 be used to implement scripts that behave differently when moved from 82 one system to another or otherwise operated in different contexts. 84 A large number of sieve extensions have already been defined and more 85 are sure to be created over time. Sieve's require clause is used to 86 specify the extensions a particular sieve needs; an error results if 87 the script's require clause calls for an extension that isn't 88 available. This mechanism is sufficient in most situations. 89 However, there can be cases where a script may be able to take 90 advantage of an extension if it is available but can still function 91 if it is not, possibly with some degradation of capabilities. 93 The "ihave" extension provides a means to write scripts that make use 94 of other extensions only when they are actually available. Ihave 95 defines a new ihave test that takes a list of capability names as an 96 argument and succeeds if all of the those capabilities are present. 97 Additionally, specification of the "ihave" extension in the require 98 clause disables parse-time checking of extension use in scripts; run- 99 time checking must be used instead. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 The terms used to describe the various components of the Sieve 108 language are taken from [I-D.ietf-sieve-3028bis] section 1.1. 110 3. Capability Identifiers 112 The capability strings associated with the two extensions defined in 113 this document are "environment" and "ihave". 115 4. Environment Test 117 Usage: environment [COMPARATOR] [MATCH-TYPE] 118 119 121 The environment test retrieves the item of environment information 122 specified by the name string and matches it to the values specified 123 in the key-list. The test succeeds if a match occurs. The type of 124 match defaults to ":is" and the default comparator is "i;ascii- 125 casemap". 127 The current message is not a direct source of information for the 128 environment test; the item of information specified by the name 129 string is extracted from the environment and key-list comes from the 130 script. 132 The environment test MUST fail unconditionally if the specified 133 information item does not exist. A script MUST NOT fail with an 134 error if the item does not exist. This allows scripts to be written 135 that handle nonexistent items gracefully. 137 The "relational" extension [I-D.ietf-sieve-3431bis] adds a match type 138 called ":count". The count of an environment test is 0 if the 139 environment information returned is the empty string, or 1 otherwise. 141 Environment items can be standardized or vendor-defined. An IANA 142 registry is defined for both types of items. 144 4.1. Standard Environment Items 146 The initial set of standardized environment items is as follows: 148 "name" => the product name associated with the Sieve interpreter 149 "version" => the product version associated with the Sieve 150 interpreter 151 "host" => the fully-qualified domain name of the host where the 152 Sieve script is executing 153 "domain" => the primary DNS domain associated with the Sieve 154 execution context, usually but not always a proper 155 suffix of the host name 156 "place" => Sieve processing is normally performing around or after 157 the time of final delivery. This item provides 158 additional information about the relationship to final 159 delivery. Possible return values are "MTA", meaning the 160 Sieve is being evaluated before final delivery, "MDA", 161 meaning evaluation is occurring during final delivery", 162 and "UA", meaning evaluation is occurring after final 163 delivery. 165 Implementations SHOULD support as many of the items on this initial 166 list as possible. Additional standardized items can only be defined 167 in standards-track or experimental RFCs. 169 4.2. Vendor-defined Environment Items 171 Environment item names beginning with "vnd." represent vendor-defined 172 extensions. Such extensions are not defined by Internet standards or 173 RFCs, but are still registered with IANA in order to prevent 174 conflicts. Environment item names starting with "vnd." SHOULD be 175 followed by the name of the vendor and product, such as 176 "vnd.acme.rocket-sled-status". 178 4.3. IANA Registration of Environment Items 180 A registry of environment items is provided by IANA. Item names may 181 be registered on a first-come, first-served basis. Extensions 182 designed for interoperable use SHOULD be defined as standards track 183 or IESG approved experimental RFCs. 185 4.3.1. Template for Environment Registrations 187 The following template is to be used for registering new Sieve 188 environment item names with IANA. 190 To: iana@iana.org 191 Subject: Registration of new Sieve environment item 193 Item name: [the string for use in the 'environment' test] 194 Description: [a brief description of the semantics of the 195 value the item returns] 196 RFC number: [for extensions published as RFCs] 197 Contact address: [email and/or physical address to contact for 198 additional information] 200 4.3.2. Initial Environment Item Registrations 202 TBD once the initial list has been determined. 204 5. Ihave Test 206 Usage: ihave 208 The ihave test provides a means for Sieve scripts to test for the 209 existence of a given extension prior to actually using it. The 210 capabilities argument to ihave is the same as the similarly-named 211 argument to the require control statement: It specifies the names of 212 one or more Sieve extensions or comparators. 214 Unlike most Sieve tests, ihave accepts no match or comparator 215 arguments. The type of match for ihave is always ":is" and the 216 comparator is always "i;ascii-casemap". 218 The strings in the capabilities list are constant strings in context 219 of Sieve variables [I-D.ietf-sieve-variables]. It is an error to 220 pass a non-constant string as an argument to ihave. 222 The Sieve base specification demands that that all Sieve extensions 223 used in a given script be specified in the initial require control 224 statement. It is an error for a script to call for extensions the 225 interpreter doesn't support or to attempt to use extensions that have 226 not been listed in the script's require clause. Use of ihave changes 227 Sieve interpreter behavior and the underlying requirements in the 228 following ways: 230 1. Use of a given extension is allowed inside of a block enclosed by 231 an ihave test on that extension just as if the extension had been 232 specified in the script's require clause. The extension cannot 233 be used outside of such a block and a runtime error MUST be 234 generated if such usage is attempted. 236 2. Sieve interpreters normally have the option of checking extension 237 use at either parse time or execution time. The specification of 238 "ihave" in a script's require clause changes this behavior: 239 Scripts MUST either defer extension checking to run time or else 240 take the presence of ihave tests into account. 242 3. Although it makes little sense to do so, an extension can be 243 specified in both the require control statement and in an ihave 244 test. If this is done the ihave test will always return true. 246 4. Using ihave to set a variable to a particular value and then 247 testing that variable in another block is not permitted as it 248 unduly complicates parse time analysis of scripts. 250 Ihave is designed to be used with extensions that add tests, actions, 251 or comparators. It MUST NOT be used with extensions that change how 252 the content of Sieve scripts are interpreted such as the variables 253 extension [I-D.ietf-sieve-variables] 255 6. Security Considerations 257 The environment extension may be used to obtain information about the 258 system the sieve implementation is running on. This information in 259 turn may reveal details about service provider or enterprise 260 infrastructure. Ihave, on the other hand, reveals nothing that 261 cannot be found out by trying different require clauses. 263 All of the security considerations given in the base Sieve 264 specification also apply to these extensions. 266 7. IANA Considerations 268 This specification defines a new IANA registry for Sieve environment 269 item names. The specifics of this registry are given in Section 4.3. 271 The following templates specify the IANA registrations of the two 272 Sieve extensions specified in this document: 274 To: iana@iana.org 275 Subject: Registration of new Sieve extensions 277 Capability name: ENVIRONMENT 278 Capability keyword: environment 279 Capability arguments: N/A 280 Standards Track/IESG-approved experimental RFC number: this RFC 281 Person and email address to contact for further information: 283 Ned Freed 284 E-Mail: ned.freed@mrochek.com 286 Capability name: IHAVE 287 Capability keyword: ihave 288 Capability arguments: N/A 289 Standards Track/IESG-approved experimental RFC number: this RFC 290 Person and email address to contact for further information: 292 Ned Freed 293 E-Mail: ned.freed@mrochek.com 295 This information should be added to the list of sieve extensions 296 given on http://www.iana.org/assignments/sieve-extensions. 298 8. References 300 8.1. Normative references 302 [I-D.ietf-sieve-3028bis] 303 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 304 Language", draft-ietf-sieve-3028bis-09 (work in progress), 305 August 2006, . 308 [I-D.ietf-sieve-3431bis] 309 Segmuller, W. and B. Leiba, "Sieve Extension: Relational 310 Tests", draft-ietf-sieve-3431bis-04 (work in progress), 311 December 2005, . 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 8.2. Informative references 319 [I-D.ietf-sieve-variables] 320 Homme, K., "Sieve Mail Filtering Language: Variables 321 Extension", draft-ietf-sieve-variables-08 (work in 322 progress), December 2005, . 325 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 326 4rev1", RFC 3501, March 2003. 328 Author's Address 330 Ned Freed 331 Sun Microsystems 332 3401 Centrelake Drive, Suite 410 333 Ontario, CA 92761-1205 334 USA 336 Phone: +1 909 457 4293 337 Email: ned.freed@mrochek.com 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The Internet Society (2006). This document is subject 376 to the rights, licenses and restrictions contained in BCP 78, and 377 except as set forth therein, the authors retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.