idnits 2.17.1 draft-freed-sieve-environment-05.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 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. 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 (March 28, 2008) is 5873 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 125, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 125, but not defined ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 3 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 Intended status: Standards Track March 28, 2008 5 Expires: September 29, 2008 7 Sieve Email Filtering: Environment Extension 8 draft-freed-sieve-environment-05 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 September 29, 2008. 35 Abstract 37 This document describes the "environment" extension to the Sieve 38 email filtering language. The "environment" extension gives Sieve 39 access to information about the environment where the Sieve 40 interpreter is running. 42 Change History (to be removed prior to publication as an RFC) 44 Changed one place string result from "UA" to "MUA". 46 Updated the IANA registration template. 48 Moved the ihave extension to a separate document. 50 Added remote-host and remote-ip environment items to the initial set. 52 Updated references, completed IANA registration templates. 54 Added text recommending the use of a "name." prefix for groups of 55 items with a common purpose. Also rearranged the text regarding the 56 IANA registry so that the relevant information isn't more 57 centralized. 59 Added test explaining how to test to see if an implementation knows 60 about a particular environment item. 62 Added text to make it clear that remote-ip and remote-host can refer 63 to LMTP and submsision clients as well as SMTP clients. 65 Changed evaluation-time to evaluation-agent, the former sounds too 66 much like it is going to return a date/time value, 68 Rearranged and cleaned up the IANA considerations text, making it 69 clearer what IANA's concerns are. 71 Clarified that the product version item is product-specific and 72 should always be considered in the context of the product name item. 74 Added a note to the security considerations section about the 75 possibile unreliability of remote-host information. 77 Defined the format of remote-ip more precisely as well as what 78 happens when remote-host cannot be determined. 80 Split the evaluation-type item into separate location and phase 81 items. 83 1. Introduction 85 Sieve [RFC5228] is a language for filtering email messages at or 86 around the time of final delivery. It is designed to be 87 implementable on either a mail client or mail server. It is suitable 88 for running on a mail server where users may not be allowed to 89 execute arbitrary programs, such as on black box Internet Message 90 Access Protocol [RFC3501] servers, as it has no user-controlled loops 91 or the ability to run external programs. 93 Although Sieve is intended to be independent of access protocol, mail 94 architecture, and operating system, in some cases it is useful to 95 allow scripts to access information about their execution context. 96 The "environment" extension provides a new environment test that can 97 be used to implement scripts that behave differently when moved from 98 one system to another, when messages arrive from different remote 99 sources or when otherwise operated in different contexts. 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 [RFC2119]. 107 The terms used to describe the various components of the Sieve 108 language are taken from [RFC5228] section 1.1. 110 This document refers to the ABNF productions IPv4-address-literal, 111 IPv6-address-literal, and General-address-literal defined in 112 [RFC2821] section 4.1.3. 114 The location item makes use of standard terms for email service 115 components. Additional information and background on these terms can 116 be found in [I-D.crocker-email-arch]. 118 3. Capability Identifiers 120 The capability string associated with the extension defined in this 121 document is "environment". 123 4. Environment Test 125 Usage: environment [COMPARATOR] [MATCH-TYPE] 126 127 129 The environment test retrieves the item of environment information 130 specified by the name string and matches it to the values specified 131 in the key-list. The test succeeds if a match occurs. The type of 132 match defaults to ":is" and the default comparator is "i;ascii- 133 casemap". 135 The current message is not a direct source of information for the 136 environment test; the item of information specified by the name 137 string is extracted from the script's operating environment and key- 138 list comes from the script. 140 The environment test MUST fail unconditionally if the specified 141 information item does not exist. A script MUST NOT fail with an 142 error if the item does not exist. This allows scripts to be written 143 that handle nonexistent items gracefully. In particular, the test: 145 if environment :contains "item" "" { ... } 147 only succeeds if "item" is known to the implementation, and always 148 succeeds if it is. 150 The "relational" extension [RFC5231] adds a match type called 151 ":count". The count of an environment test is 0 if the environment 152 information returned is the empty string, or 1 otherwise. 154 Environment items can be standardized or vendor-defined. An IANA 155 registry is defined for both types of items. Extensions designed for 156 interoperable use SHOULD be defined in standards track or 157 experimental RFCs. 159 4.1. Initial Standard Environment Items 161 The initial set of standardized environment items is as follows: 163 "domain" => The primary DNS domain associated with the Sieve 164 execution context, usually but not always a proper 165 suffix of the host name. 166 "host" => The fully-qualified domain name of the host where 167 the Sieve script is executing. 168 "location" 169 => Sieve evaluation can be performed at various 170 different points as messages are processed. This item 171 provides additional information about the type of 172 service that is evaluating the script. Possible values 173 are "MTA", meaning the Sieve is being evaluated by a 174 Message Transfer Agent, "MDA", meaning evaluation is 175 being performed by a Mail Delivery Agent, "MUA", 176 meaning evaluation is being performed by a Mail User 177 Agent, and "MS", meaning evaluation is being performed 178 by a Message Store. Additional information and 179 background on these terms can be found in 180 [I-D.crocker-email-arch]. 181 "name" => The product name associated with the Sieve interpreter. 182 "phase" => The point relative to final delivery where the 183 Sieve script is being evaluated. Possible values are 184 "pre", "during", and "post", referring respectively to 185 processing before, during, and after final delivery 186 has taken place. 187 "remote-host" 188 => Host name of remote SMTP/LMTP/Submission client 189 expressed as a FQDN, if applicable and available. The 190 empty string will be returned if for some reason this 191 information cannot be obtained for the current client. 192 "remote-ip" 193 => IP address of remote SMTP/LMTP/Submission client, if 194 applicable and available. IPv4, IPv6, and other types 195 of addresses are respectively represented in the 196 formats defined by the IPv4-address-literal, 197 IPv6-address-literal, and General-address-literal 198 productions defined in [RFC2821] section 4.1.3. 199 "version" => The product version associated with the Sieve 200 interpreter. The meaning of the product version string 201 is product-specific and should always be considered 202 in the context of the product name given by the 203 "name" item. 205 Implementations SHOULD support as many of the items on this initial 206 list as possible. Additional standardized items can only be defined 207 in standards-track or experimental RFCs. 209 4.2. Vendor-defined Environment Items 211 Environment item names beginning with "vnd." represent vendor-defined 212 extensions. Such extensions are not defined by Internet standards or 213 RFCs, but are still registered with IANA in order to prevent 214 conflicts. 216 4.3. IANA Registration of Environment Items 218 A registry of environment items is provided by IANA. Item names may 219 be registered on a first-come, first-served basis. 221 Groups of items defined in a standards track or experimenal RFC MAY 222 choose to use a common name prefix of the form "name.", where "name" 223 is a string that identifies the group of related items. 225 Items not defined in a standards track or experimental RFC MUST have 226 a name that begins with the "vnd." prefix and this prefix is followed 227 by the name of the vendor or product, such as "vnd.acme.rocket-sled- 228 status". 230 4.3.1. Template for Environment Registrations 232 The following template is to be used for registering new Sieve 233 environment item names with IANA. 235 To: iana@iana.org 236 Subject: Registration of new Sieve environment item 238 Item name: [the string for use in the 'environment' test] 239 Description: [a brief description of the semantics of the 240 value the item returns] 242 RFC number: [for extensions published as RFCs] 243 Contact address: [email and/or physical address to contact for 244 additional information] 246 Multiple items and descriptions MAY be specified in a single 247 registration request. Both standardized and vendor-defined items use 248 this form. 250 5. Security Considerations 252 The environment extension may be used to obtain information about the 253 system the Sieve implementation is running on. This information in 254 turn may reveal details about service provider or enterprise 255 infrastructure. 257 An implementation can use any technique to determine the remote-host 258 environment item defined in this specification, and the 259 trustworthiness of the result will vary. One common method will be 260 to perform a PTR DNS lookup on the client IP address. This 261 information may come from an untrusted source. For example, the 262 test: 264 if environment :matches "remote-host" "*.example.com" { ... } 266 is not a good way to test whether the message came from "outside" 267 because anyone who can create a PTR record can create one that refers 268 to whatever domain they choose. 270 All of the security considerations given in the base Sieve 271 specification also apply to this extension. 273 6. IANA Considerations 275 The following template specifies the IANA registration of the Sieve 276 extension specified in this document: 278 To: iana@iana.org 279 Subject: Registration of new Sieve extension 281 Capability name: environment 282 Description: The "environment" extension provides a new 283 environment test that can be used to implement 284 scripts that behave differently when moved 285 from one system to another or otherwise 286 operated in different contexts. 287 RFC number: RFC XXXX 288 Contact address: Sieve discussion list 290 This specification also defines a new IANA registry for Sieve 291 environment item names. The specifics of this registry are given in 292 Section 4.3. The initial contents of the registry are given in the 293 following section. 295 6.1. Initial Environment Item Registrations 297 The following template specifies the initial IANA registrations for 298 the environment items defined in this document: 300 To: iana@iana.org 301 Subject: Registration of new Sieve environment items 303 Capability name: domain 304 Description: The primary DNS domain associated with the Sieve 305 execution context, usually but not always a 306 proper suffix of the host name. 308 Capability name: host 309 Description: The fully-qualified domain name of the host 310 where the Sieve script is executing. 312 Capability name: location 313 Description: Type of service executing the Sieve script. 315 Capability name: name 316 Description: The product name associated with the Sieve 317 interpreter. 319 Capability name: phase 320 Descrption: Point relative to final delivery at which the 321 Sieve script is being evaluated. 323 Capability name: remote-host 324 Description: Host name of remote SMTP client, if applicable 325 and available. 327 Capability name: remote-ip 328 Description: IP address of remote SMTP client, if applicable 329 and available. 331 Capability name: version 332 Description: The product version associated with the Sieve 333 interpreter. 335 RFC number: RFC XXXX 336 Contact address: Sieve discussion list 338 7. References 339 7.1. Normative references 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 345 April 2001. 347 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 348 Language", RFC 5228, January 2008. 350 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 351 Relational Extension", RFC 5231, January 2008. 353 7.2. Informative references 355 [I-D.crocker-email-arch] 356 Crocker, D., "Internet Mail Architecture", 357 draft-crocker-email-arch (work in progress), 358 February 2008, 359 . 361 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 362 4rev1", RFC 3501, March 2003. 364 Appendix A. Acknowledgements 366 Brian Carpenter, Dave Crocker, Cyrus Daboo, Philip Guenther, Kjetil 367 Torgrim Homme, John Klensin, Mark Mallett, Alexey Melnikov, and 368 Dilyan Palauzo provided helpful suggestions and corrections. 370 Author's Address 372 Ned Freed 373 Sun Microsystems 374 3401 Centrelake Drive, Suite 410 375 Ontario, CA 92761-1205 376 USA 378 Phone: +1 909 457 4293 379 Email: ned.freed@mrochek.com 381 Full Copyright Statement 383 Copyright (C) The IETF Trust (2008). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Intellectual Property 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at 419 ietf-ipr@ietf.org.