idnits 2.17.1 draft-ietf-sieve-editheader-04.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 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '... The field-name MUST be a valid 7-bit...' RFC 2119 keyword, line 74: '...tation, the implementation MUST either...' RFC 2119 keyword, line 79: '...n implementation MAY impose a length l...' RFC 2119 keyword, line 80: '...r field; such a limit MUST NOT be less...' RFC 2119 keyword, line 109: '... The field-name MUST be a valid 7-bit...' (7 more instances...) 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 (March 2006) is 6615 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? 'SIEVE' on line 345 looks like a reference -- Missing reference section? 'KEYWORDS' on line 334 looks like a reference -- Missing reference section? 'IMAIL' on line 331 looks like a reference -- Missing reference section? 'RFC2047' on line 337 looks like a reference -- Missing reference section? 'RFC2231' on line 341 looks like a reference -- Missing reference section? 'COMPARATOR' on line 100 looks like a reference -- Missing reference section? 'MATCH-TYPE' on line 100 looks like a reference -- Missing reference section? 'VACATION' on line 353 looks like a reference -- Missing reference section? 'BODY' on line 350 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jutta Degener 2 Internet Draft Philip Guenther 3 Expires: September 2006 Sendmail, Inc. 4 March 2006 6 Sieve Email Filtering: Editheader Extension 7 draft-ietf-sieve-editheader-04.txt 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 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This document defines two new actions for the "Sieve" email 40 filtering language that add and delete email header fields. 42 1. Introduction 44 Email header fields are a flexible and easy to understand means 45 of communication between email processors. 46 This extension enables sieve scripts to interact with other 47 components that consume or produce header fields by allowing 48 the script to delete and add header fields. 50 2. Conventions used. 52 Conventions for notations are as in [SIEVE] section 1.1, including 53 use of [KEYWORDS] and the "Usage:" label for the definition of 54 action and tagged arguments syntax. 56 The term "header field" is used here as in [IMAIL] to mean a 57 logical line of an email message header. 59 The capability string associated with the extension defined in 60 this document is "editheader". 62 3. Action addheader 64 Usage: "addheader" [":last"] 66 The addheader action adds a header field to the existing message 67 header. The field-name MUST be a valid 7-bit US-ASCII header 68 field name as described by the [IMAIL] "field-name" nonterminal 69 syntax element. The addheader action does not affect Sieve's 70 implicit keep. 72 If the specified field value does not match the RFC 2822 73 "unstructured" nonterminal syntax element or exceeds a length 74 limit set by the implementation, the implementation MUST either 75 flag an error or encode the field using folding white space and 76 the encodings described in [RFC2047] or [RFC2231] to be compliant 77 with RFC 2822. 79 An implementation MAY impose a length limit onto the size of 80 the encoded header field; such a limit MUST NOT be less 81 than 998 characters, not including the terminating CRLF 82 supplied by the implementation. 84 By default, the header field is inserted at the beginning of the 85 existing message header. If the optional flag ":last" is 86 specified, it is appended at the end. 88 Example: 89 /* Don't redirect if we already redirected */ 90 if not header :contains "X-Sieve-Filtered" 91 ["", ""] 92 { 93 addheader "X-Sieve-Filtered" ""; 94 redirect "kim@home.example.com"; 95 } 97 4. Action deleteheader 99 Usage: "deleteheader" [":index" [":last"]] 100 [COMPARATOR] [MATCH-TYPE] 101 102 [] 104 By default, the deleteheader action deletes all occurrences of 105 the named header field. The deleteheader action does not affect 106 Sieve's implicit keep. 108 The field-name is mandatory and always matched as a case-insensitive 109 US-ASCII string. The field-name MUST be a valid 7-bit header 110 field name as described by the [IMAIL] "field-name" nonterminal 111 syntax element. 113 The value-patterns, if specified, restrict which occurrences of 114 the header field are deleted to those whose values match any of 115 the specified value-patterns, the matching being according to 116 the match-type and comparator. 118 If :index is specified, the attempts to match a value 119 are limited to the occurrence of the named header 120 field, beginning at 1, the first named header field. If :last 121 is specified, the count is backwards; 1 denotes the last named 122 header field, 2 the second to last, and so on. The counting 123 happens before the match, if any. For example: 125 deleteheader :index 2 :contains "Received" "via carrier-pigeon" 127 deletes the second "Received:" header field if it contains 128 the string "via carrier-pigeon" (not the second Received: field 129 that contains "via carrier-pigeon"). 131 It is not an error if no header fields match the conditions in 132 the deleteheader action or if the :index argument is greater 133 than the number of named header fields. 135 5. Interaction with Other Sieve Extensions 137 Tests and actions such as "exists", "header", or "vacation" 138 [VACATION] that examine header fields MUST examine the current 139 state of a header as modified by any actions that have taken 140 place so far. 142 As an example, the "header" test in the following fragment will 143 always evaluate to true, regardless of whether the incoming 144 message contained an "X-Hello" header field or not: 146 addheader "X-Hello" "World"; 147 if header :contains "X-Hello" "World" 148 { 149 fileinto "international"; 150 } 152 However, if the presence or value of a header field affects how 153 the implementation parses or decodes other parts of the message, 154 then for the purposes of that parsing or decoding the implementation 155 MAY ignore some or all changes made to those header fields. For 156 example, in an implementation that supports the [BODY] extension, 157 "body" tests may be unaffected by deleting or adding Content-Type 158 or Content-Transfer-Encoding header fields. This does not rescind 159 the requirement that changes to those header fields affect direct 160 tests; only the semantic side effects of changes to the fields 161 may be ignored. 163 Actions that store or send the message MUST do so with the current 164 set of header fields. 166 For the purpose of weeding out duplicates, a message modified 167 by addheader or deleteheader MUST be considered the same as 168 the original message. For example, in an implementation that 169 obeys the constraint in [SIEVE] section 2.10.3 and does not deliver 170 the same message to a folder more than once, the following 171 code fragment 173 keep; 174 addheader "X-Flavor" "vanilla"; 175 keep; 177 MUST only file one message. It is up to the implementation 178 to pick which of the redundant "fileinto" or "keep" actions is 179 executed, and which ones are ignored. 181 The "implicit keep" is thought to be executed at the end of 182 the script, after the headers have been modified. (However, 183 a canceled "implicit keep" remains canceled.) 185 6. IANA Considerations 187 The following template specifies the IANA registration of the Sieve 188 extension specified in this document: 190 To: iana@iana.org 191 Subject: Registration of new Sieve extension 193 Capability name: editheader 194 Capability keyword: editheader 195 Capability arguments: N/A 196 Standards Track/IESG-approved experimental RFC number: this RFC 197 Person and email address to contact for further information: 199 Jutta Degener 200 jutta@pobox.com 202 This information should be added to the list of sieve extensions 203 given on http://www.iana.org/assignments/sieve-extensions. 205 7. Security Considerations 207 Someone with write access to a user's script storage may use this 208 extension to generate headers that a user would otherwise be 209 shielded from (by a gateway MTA that removes them). 211 A sieve filter that removes header fields may unwisely destroy 212 evidence about the path a message has taken. 214 Any change in a message content may interfere with digital 215 signature mechanisms that include the header in the signed 216 material. Since normal message delivery adds "Received:" 217 header fields to the beginning of a message, many such schemas 218 are impervious to headers prefixed to a message, and will 219 work with "addheader" unless :last is used. 221 Any decision mechanism in a user's filter that is based 222 on headers is vulnerable to header spoofing. For example, 223 if the user adds an APPROVED header or tag, a malicious sender 224 may add that tag or header themselves. One way to guard against 225 this is to delete or rename any such headers or stamps prior 226 to processing the message. 228 Modifying the header of a message and then using the "reject" 229 action may let a sender 'probe' the logic of the sieve filter. 231 8. Acknowledgments 233 Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, 234 Arnt Gulbrandsen, Simon Josefsson, Will Lee, William Leibzon, 235 Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, 236 Nigel Swinson, Kjetil Torgrim Homme, and Rand Wacker for extensive 237 corrections and suggestions. 239 9. Authors' Addresses 241 Jutta Degener 242 5245 College Ave, Suite #127 243 Oakland, CA 94618 245 Email: jutta@pobox.com 247 Philip Guenther 248 Sendmail, Inc. 249 6425 Christie Ave, 4th Floor 250 Emeryville, CA 94608 252 Email: guenther@sendmail.com 254 10. Discussion 256 This section will be removed when this document leaves the 257 Internet-Draft stage. 259 This draft is intended as an extension to the Sieve mail filtering 260 language. Sieve extensions are discussed on the MTA Filters mailing 261 list at . Subscription requests can 262 be sent to (send an email 263 message with the word "subscribe" in the body). 265 More information on the mailing list along with a WWW archive of 266 back messages is available at . 268 10.1 Changes from draft-ietf-sieve-editheader-03.txt 270 Change "Syntax:" to "Usage:" 272 Updated references 274 10.2 Changes from draft-ietf-sieve-editheader-02.txt 276 Clarify that value-patterns restrict which occurences are deleted. 278 Add informative reference to [BODY]. 280 10.3 Changes from draft-ietf-sieve-editheader-01.txt 282 Whitespace and line length tweaks noted by ID-nits. 284 Clarified what is being counted by :index. 286 Update the [SIEVE] reference to the I-D of the revision. 288 10.4 Changes from draft-ietf-sieve-editheader-00.txt 290 Updated IPR boilerplate to RFC 3978/3979. 292 Many corrections in response to WGLC comments. Of particular note: 293 - correct a number of spelling and grammar errors 294 - document that neither addheader nor deleteheader affects the 295 implicit keep 296 - add normative references to RFC 2047 and RFC 2231 297 - it is not an error for deleteheader to affect nothing 298 - change "foo.tld" to "foo.example.com" 299 - add an informative reference to [VACATION], citing it as an 300 example of an action that examines header fields 301 - add weasel words about changes to fields that have secondary 302 effects 303 - add security consideration for combination of header changes 304 and "reject" 306 10.5 Changes from draft-degener-sieve-editheader-03.txt 308 Renamed to draft-ietf-sieve-editheader-00.txt; 309 tweaked the title and abstract. 311 Added Philip Guenther as co-author. 313 Updated IPR boilerplate. 315 10.6 Changes from draft-degener-sieve-editheader-02.txt 317 Changed the duplicate restrictions from "messages with different 318 headers MUST be considered different" to their direct opposite, 319 "messages with different headers MUST be considered the same," 320 as requested by workgroup members on the mailing list. 322 Expanded mention of header signature schemes to Security 323 Considerations. 325 Added IANA Considerations section. 327 Appendices 329 Appendix A. Normative References 331 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 332 2001. 334 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", RFC 2119, March 1997. 337 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 338 Extensions) Part Three: Message Header Extensions for 339 Non-ASCII Text", RFC 2047, November 1996. 341 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 342 Encoded Word Extensions: Character Sets, Languages, and 343 Continuations", RFC 2231, November 1997. 345 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 346 Language", draft-ietf-sieve-3028bis-06, March 2006. 348 Appendix B. Informative References 350 [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: 351 Body Extension", draft-ietf-sieve-body-03, March 2006 353 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 354 Vacation Extension", draft-ietf-sieve-vacation-05, 355 December 2005 357 Copyright Statement 359 Copyright (C) The Internet Society (2006). This document is 360 subject to the rights, licenses and restrictions contained in 361 BCP 78, and except as set forth therein, the authors retain all 362 their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 366 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 367 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 368 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use 386 of such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository 388 at http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention 391 any copyrights, patents or patent applications, or other 392 proprietary rights that may cover technology that may be required 393 to implement this standard. Please address the information to the 394 IETF at ietf-ipr@ietf.org. 396 Acknowledgement 398 Funding for the RFC Editor function is currently provided by 399 the Internet Society.