idnits 2.17.1 draft-ietf-sieve-editheader-10.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 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 508. 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 (February 2008) is 5908 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: 'COMPARATOR' is mentioned on line 104, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 104, but not defined ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL') (Obsoleted by RFC 5322) == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-07 -- Obsolete informational reference (is this intentional?): RFC 3798 (ref. 'MDN') (Obsoleted by RFC 8098) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 Intended status: Standards Track Sendmail, Inc. 4 Expires: August 2008 February 2008 6 Sieve Email Filtering: Editheader Extension 7 draft-ietf-sieve-editheader-10.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 IETF Trust (2008). 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [KEYWORDS]. 56 Conventions for notations are as in [SIEVE] section 1.1, including 57 use of the "Usage:" label for the definition of action and tagged 58 arguments syntax. 60 The term "header field" is used here as in [IMAIL] to mean a 61 logical line of an email message header. 63 The capability string associated with the extension defined in 64 this document is "editheader". 66 3. Action addheader 68 Usage: "addheader" [":last"] 70 The addheader action adds a header field to the existing message 71 header. If the field-name is not a valid 7-bit US-ASCII header 72 field name as described by the [IMAIL] "field-name" nonterminal 73 syntax element, the implementation MUST flag an error. The 74 addheader action does not affect Sieve's implicit keep. 76 If the specified field value does not match the RFC 2822 77 "unstructured" nonterminal syntax element or exceeds a length 78 limit set by the implementation, the implementation MUST either 79 flag an error or encode the field using folding white space and 80 the encodings described in [RFC2047] or [RFC2231] to be compliant 81 with RFC 2822. 83 An implementation MAY impose a length limit onto the size of 84 the encoded header field; such a limit MUST NOT be less 85 than 998 characters, not including the terminating CRLF 86 supplied by the implementation. 88 By default, the header field is inserted at the beginning of the 89 existing message header. If the optional flag ":last" is 90 specified, it is appended at the end. 92 Example: 93 /* Don't redirect if we already redirected */ 94 if not header :contains "X-Sieve-Filtered" 95 ["", ""] 96 { 97 addheader "X-Sieve-Filtered" ""; 98 redirect "kim@home.example.com"; 99 } 101 4. Action deleteheader 103 Usage: "deleteheader" [":index" [":last"]] 104 [COMPARATOR] [MATCH-TYPE] 105 106 [] 108 By default, the deleteheader action deletes all occurrences of 109 the named header field. The deleteheader action does not affect 110 Sieve's implicit keep. 112 The field-name is mandatory and always matched as a case-insensitive 113 US-ASCII string. If the field-name is not a valid 7-bit header 114 field name as described by the [IMAIL] "field-name" nonterminal 115 syntax element, the implementation MUST flag an error. 117 The value-patterns, if specified, restrict which occurrences of 118 the header field are deleted to those whose values match any of 119 the specified value-patterns, the matching being according to 120 the match-type and comparator and performed as if by the "header" 121 test. In particular, leading and trailing whitespace in the 122 field values is ignored. If no value-patterns are specified 123 then the comparator and match-type options are silently ignored. 125 If :index is specified, the attempts to match a value 126 are limited to the occurrence of the named header 127 field, beginning at 1, the first named header field. If :last 128 is specified, the count is backwards; 1 denotes the last named 129 header field, 2 the second to last, and so on. The counting 130 happens before the match, if any. For example: 132 deleteheader :index 2 :contains "Received" "via carrier-pigeon" 134 deletes the second "Received" header field if it contains 135 the string "via carrier-pigeon" (not the second "Received" field 136 that contains "via carrier-pigeon"). 138 It is not an error if no header fields match the conditions in 139 the deleteheader action or if the :index argument is greater 140 than the number of named header fields. 142 The implementation MUST flag an error if :last is specified 143 without also specifying :index. 145 5. Implementation Limitations on Changes 147 As a matter of local policy, implementations MAY limit which 148 header fields may be deleted and which header fields may be 149 added. However, implementations MUST NOT permit attempts to 150 delete "Received" header fields and MUST permit both addition 151 and deletion of the "Subject" header field. 153 If a script tries to make a change that isn't permitted, the 154 attempt MUST be silently ignored. 156 6. Interaction with Other Sieve Extensions 158 Actions that generate [MDN], [DSN], or similar disposition 159 messages MUST do so using the original, unmodified message header. 160 Similarly, if an error terminates processing of the script, the 161 original message header MUST be used when doing the implicit 162 keep required by [SIEVE] section 2.10.6. 164 With the exception of the special handling of redirect and 165 "Received" header fields described above, all other actions that 166 store, send, or alter the message MUST do so with the current set 167 of header fields. This includes the addheader and deleteheader 168 actions themselves. For example, the following leaves the message 169 unchanged: 171 addheader "X-Hello" "World"; 172 deleteheader :index 1 "X-Hello"; 174 Similarly, given a message with three or more "X-Hello" header 175 fields, the following example deletes the first and third of 176 them, not the first and second: 178 deleteheader :index 1 "X-Hello"; 179 deleteheader :index 2 "X-Hello"; 181 Tests and actions such as "exists", "header", or "vacation" 182 [VACATION] that examine header fields MUST examine the current 183 state of a header as modified by any actions that have taken 184 place so far. 186 As an example, the "header" test in the following fragment will 187 always evaluate to true, regardless of whether the incoming 188 message contained an "X-Hello" header field or not: 190 addheader "X-Hello" "World"; 191 if header :contains "X-Hello" "World" 192 { 193 fileinto "international"; 194 } 196 However, if the presence or value of a header field affects how 197 the implementation parses or decodes other parts of the message, 198 then for the purposes of that parsing or decoding the implementation 199 MAY ignore some or all changes made to those header fields. For 200 example, in an implementation that supports the [BODY] extension, 201 "body" tests may be unaffected by deleting or adding "Content-Type" 202 or "Content-Transfer-Encoding" header fields. This does not rescind 203 the requirement that changes to those header fields affect direct 204 tests; only the semantic side effects of changes to the fields 205 may be ignored. 207 For the purpose of weeding out duplicates, a message modified 208 by addheader or deleteheader MUST be considered the same as 209 the original message. For example, in an implementation that 210 obeys the constraint in [SIEVE] section 2.10.3 and does not deliver 211 the same message to a folder more than once, the following 212 code fragment 214 keep; 215 addheader "X-Flavor" "vanilla"; 216 keep; 218 MUST only file one message. It is up to the implementation 219 to pick which of the redundant "fileinto" or "keep" actions is 220 executed, and which ones are ignored. 222 The "implicit keep" is thought to be executed at the end of 223 the script, after the headers have been modified. (However, 224 a canceled "implicit keep" remains canceled.) 226 7. IANA Considerations 228 The following template specifies the IANA registration of the Sieve 229 extension specified in this document: 231 To: iana@iana.org 232 Subject: Registration of new Sieve extension 234 Capability name: editheader 235 Description: adds actions 'addheader' and 'deleteheader' 236 that modify the header of the message being 237 processed 238 RFC number: this RFC 239 Contact Address: Jutta Degener 241 This information should be added to the list of sieve extensions 242 given on http://www.iana.org/assignments/sieve-extensions. 244 8. Security Considerations 246 Someone with write access to a user's script storage may use this 247 extension to generate headers that a user would otherwise be 248 shielded from (e.g., by a gateway MTA that removes them). 250 A sieve filter that removes header fields may unwisely destroy 251 evidence about the path a message has taken. 253 While this specification overrides the requirement that redirected 254 messages have more "Received" header fields than the message as 255 received, doing so removes an important mechanisms for detecting 256 loops and MUST NOT be permitted by implementations without due 257 consideration, such as requiring administrative action to enable 258 it. 260 Any change in a message content may interfere with digital 261 signature mechanisms that include the header in the signed 262 material. Since normal message delivery adds "Received" 263 header fields and other trace fields to the beginning of a 264 message, many such schemas are impervious to headers prefixed 265 to a message, and will work with "addheader" unless :last is 266 used. 268 Any decision mechanism in a user's filter that is based 269 on headers is vulnerable to header spoofing. For example, 270 if the user adds an APPROVED header or tag, a malicious sender 271 may add that tag or header themselves. One way to guard against 272 this is to delete or rename any such headers or stamps prior 273 to processing the message. 275 9. Acknowledgments 277 Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, 278 Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, 279 Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, 280 Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, 281 and Rand Wacker for extensive corrections and suggestions. 283 10. Authors' Addresses 285 Jutta Degener 286 5245 College Ave, Suite #127 287 Oakland, CA 94618 289 Email: jutta@pobox.com 291 Philip Guenther 292 Sendmail, Inc. 293 6475 Christie Ave., Ste 350 294 Emeryville, CA 94608 296 Email: guenther@sendmail.com 298 11. Discussion 300 This section will be removed when this document leaves the 301 Internet-Draft stage. 303 This draft is intended as an extension to the Sieve mail filtering 304 language. Sieve extensions are discussed on the MTA Filters mailing 305 list at . Subscription requests can 306 be sent to (send an email 307 message with the word "subscribe" in the body). 309 More information on the mailing list along with a WWW archive of 310 back messages is available at . 312 11.2 Changes from draft-ietf-sieve-editheader-09.txt 314 Add section 5, completely banning <> 315 but requiring that "Subject" changes be permitted. 317 Since deletion of "Received" headers is now banned, this spec 318 no longer updates the base-spec. 320 Updated references to Sieves specs that have been published. 322 11.3 Changes from draft-ietf-sieve-editheader-08.txt 324 Tighten up the permissible behaviors involving redirect and 325 deleteheader "Recieved". 327 Consistently quote the names of header fields, but not actions. 329 For deleteheader, :last without :index is an error. On the other 330 hand, the match-type and comparator are ignored if there are no 331 value-patterns. 333 Clarify that addheader and deleteheader operate on the 'current' 334 set of header fields and give examples demonstrating this. 336 11.4 Changes from draft-ietf-sieve-editheader-07.txt 338 Let implementations permit redirected messages to have fewer 339 "Received" header fields, but warn about the consequences. 341 Updated boilerplate to match RFC 4748. 343 Added "Intended-Status: Standards Track" and 344 "Updates: draft-ietf-sieve-3028bis-12" 346 Change the references from appendices to sections. 347 Update [SIEVE], [BODY], [DSN], and [MDN] references. 349 11.5 Changes from draft-ietf-sieve-editheader-06.txt 351 Make deleteheader match addheader on the description of invalid 352 field-names. 354 Update copyright boilerplate 356 Update references 358 11.6 Changes from draft-ietf-sieve-editheader-05.txt 360 MDN and DSN references are merely informative 362 11.7 Changes from draft-ietf-sieve-editheader-04.txt 364 Ignore leading and trailing whitespace when matching header field 365 values. 367 Header modifications are ignored when continuing after an error 368 or generating MDNs or DSNs 370 Added references for MDN and DSN 372 Update IANA registration to match 3028bis 374 Added [KEYWORDS] boilerplate text 375 Describe an invalid field-name to addheader as an error (might 376 be detected at runtime) 378 11.8 Changes from draft-ietf-sieve-editheader-03.txt 380 Change "Syntax:" to "Usage:". 382 Updated references. 384 11.9 Changes from draft-ietf-sieve-editheader-02.txt 386 Clarify that value-patterns restrict which occurrences are deleted. 388 Add informative reference to [BODY]. 390 11.10 Changes from draft-ietf-sieve-editheader-01.txt 392 Whitespace and line length tweaks noted by ID-nits. 394 Clarified what is being counted by :index. 396 Update the [SIEVE] reference to the I-D of the revision. 398 11.11 Changes from draft-ietf-sieve-editheader-00.txt 400 Updated IPR boilerplate to RFC 3978/3979. 402 Many corrections in response to WGLC comments. Of particular note: 403 - correct a number of spelling and grammar errors 404 - document that neither addheader nor deleteheader affects the 405 implicit keep 406 - add normative references to RFC 2047 and RFC 2231 407 - it is not an error for deleteheader to affect nothing 408 - change "foo.tld" to "foo.example.com" 409 - add an informative reference to [VACATION], citing it as an 410 example of an action that examines header fields 411 - add weasel words about changes to fields that have secondary 412 effects 413 - add security consideration for combination of header changes 414 and "reject" 416 11.12 Changes from draft-degener-sieve-editheader-03.txt 418 Renamed to draft-ietf-sieve-editheader-00.txt; 419 tweaked the title and abstract. 421 Added Philip Guenther as co-author. 422 Updated IPR boilerplate. 424 11.13 Changes from draft-degener-sieve-editheader-02.txt 426 Changed the duplicate restrictions from "messages with different 427 headers MUST be considered different" to their direct opposite, 428 "messages with different headers MUST be considered the same," 429 as requested by workgroup members on the mailing list. 431 Expanded mention of header signature schemes to Security 432 Considerations. 434 Added IANA Considerations section. 436 12. Normative References 438 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 439 2001. 441 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", RFC 2119, March 1997. 444 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 445 Extensions) Part Three: Message Header Extensions for 446 Non-ASCII Text", RFC 2047, November 1996. 448 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 449 Encoded Word Extensions: Character Sets, Languages, and 450 Continuations", RFC 2231, November 1997. 452 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 453 Language", RFC 5228, January 2008. 455 13. Informative References 457 [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: 458 Body Extension", draft-ietf-sieve-body-07, June 2008. 460 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 461 for Delivery Status Notifications", RFC 3464, January 462 2003. 464 [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition 465 Notification", RFC 3798, May 2004. 467 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 468 Vacation Extension", RFC 5230, January 2008. 470 Full Copyright Statement 472 Copyright (C) The IETF Trust (2008). 474 This document is subject to the rights, licenses and restrictions 475 contained in BCP 78, and except as set forth therein, the authors 476 retain all their rights. 478 This document and the information contained herein are provided on an 479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 481 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 482 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 483 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Intellectual Property 488 The IETF takes no position regarding the validity or scope of any 489 Intellectual Property Rights or other rights that might be claimed to 490 pertain to the implementation or use of the technology described in 491 this document or the extent to which any license under such rights 492 might or might not be available; nor does it represent that it has 493 made any independent effort to identify any such rights. Information 494 on the procedures with respect to rights in RFC documents can be 495 found in BCP 78 and BCP 79. 497 Copies of IPR disclosures made to the IETF Secretariat and any 498 assurances of licenses to be made available, or the result of an 499 attempt made to obtain a general license or permission for the use of 500 such proprietary rights by implementers or users of this 501 specification can be obtained from the IETF on-line IPR repository at 502 http://www.ietf.org/ipr. 504 The IETF invites any interested party to bring to its attention any 505 copyrights, patents or patent applications, or other proprietary 506 rights that may cover technology that may be required to implement 507 this standard. Please address the information to the IETF at 508 ietf-ipr@ietf.org.