idnits 2.17.1 draft-ietf-sieve-editheader-09.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 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 509. 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 (July 2007) is 6127 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 105, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 105, but not defined ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL') (Obsoleted by RFC 5322) == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 == Outdated reference: A later version (-09) exists of draft-ietf-sieve-body-06 -- Obsolete informational reference (is this intentional?): RFC 3798 (ref. 'MDN') (Obsoleted by RFC 8098) == Outdated reference: A later version (-07) exists of draft-ietf-sieve-vacation-06 Summary: 2 errors (**), 0 flaws (~~), 6 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: December 2007 July 2007 5 Updates: RFC-ietf-sieve-3028bis-12 7 Sieve Email Filtering: Editheader Extension 8 draft-ietf-sieve-editheader-09.txt 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 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines two new actions for the "Sieve" email 41 filtering language that add and delete email header fields. 43 1. Introduction 45 Email header fields are a flexible and easy to understand means 46 of communication between email processors. 47 This extension enables sieve scripts to interact with other 48 components that consume or produce header fields by allowing 49 the script to delete and add header fields. 51 2. Conventions used. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [KEYWORDS]. 57 Conventions for notations are as in [SIEVE] section 1.1, including 58 use of the "Usage:" label for the definition of action and tagged 59 arguments syntax. 61 The term "header field" is used here as in [IMAIL] to mean a 62 logical line of an email message header. 64 The capability string associated with the extension defined in 65 this document is "editheader". 67 3. Action addheader 69 Usage: "addheader" [":last"] 71 The addheader action adds a header field to the existing message 72 header. If the field-name is not a valid 7-bit US-ASCII header 73 field name as described by the [IMAIL] "field-name" nonterminal 74 syntax element, the implementation MUST flag an error. The 75 addheader action does not affect Sieve's implicit keep. 77 If the specified field value does not match the RFC 2822 78 "unstructured" nonterminal syntax element or exceeds a length 79 limit set by the implementation, the implementation MUST either 80 flag an error or encode the field using folding white space and 81 the encodings described in [RFC2047] or [RFC2231] to be compliant 82 with RFC 2822. 84 An implementation MAY impose a length limit onto the size of 85 the encoded header field; such a limit MUST NOT be less 86 than 998 characters, not including the terminating CRLF 87 supplied by the implementation. 89 By default, the header field is inserted at the beginning of the 90 existing message header. If the optional flag ":last" is 91 specified, it is appended at the end. 93 Example: 94 /* Don't redirect if we already redirected */ 95 if not header :contains "X-Sieve-Filtered" 96 ["", ""] 97 { 98 addheader "X-Sieve-Filtered" ""; 99 redirect "kim@home.example.com"; 100 } 102 4. Action deleteheader 104 Usage: "deleteheader" [":index" [":last"]] 105 [COMPARATOR] [MATCH-TYPE] 106 107 [] 109 By default, the deleteheader action deletes all occurrences of 110 the named header field. The deleteheader action does not affect 111 Sieve's implicit keep. 113 The field-name is mandatory and always matched as a case-insensitive 114 US-ASCII string. If the field-name is not a valid 7-bit header 115 field name as described by the [IMAIL] "field-name" nonterminal 116 syntax element, the implementation MUST flag an error. 118 The value-patterns, if specified, restrict which occurrences of 119 the header field are deleted to those whose values match any of 120 the specified value-patterns, the matching being according to 121 the match-type and comparator and performed as if by the "header" 122 test. In particular, leading and trailing whitespace in the 123 field values is ignored. If no value-patterns are specified 124 then the comparator and match-type options are silently ignored. 126 If :index is specified, the attempts to match a value 127 are limited to the occurrence of the named header 128 field, beginning at 1, the first named header field. If :last 129 is specified, the count is backwards; 1 denotes the last named 130 header field, 2 the second to last, and so on. The counting 131 happens before the match, if any. For example: 133 deleteheader :index 2 :contains "Received" "via carrier-pigeon" 135 deletes the second "Received" header field if it contains 136 the string "via carrier-pigeon" (not the second "Received" field 137 that contains "via carrier-pigeon"). 139 It is not an error if no header fields match the conditions in 140 the deleteheader action or if the :index argument is greater 141 than the number of named header fields. 143 The implementation MUST flag an error if :last is specified 144 without also specifying :index. 146 If an script uses the deleteheader action to remove "Received" 147 header fields and then performs a redirect action, then the 148 implementation MUST either: 149 A) silently ignore all of the deleteheader actions that removed 150 "Received" header fields when generating the outgoing message, 151 B) silently ignore just enough of the deleteheader actions that 152 removed "Received" header fields when generating the outgoing 153 message, such that it has more "Received" header fields than 154 the message as recieved by the implementation, or 155 C) obey all the deleteheader actions, possibly sending out a 156 message with no more "Received" header fields than where in 157 the message as received. This overrides the requirement on 158 "Received" header fields in RFC-ietf-sieve-3028bis-12 159 section 4.2. 161 Implementations MUST NOT do choice (C) without due consideration, 162 such as requiring explicit administrative action to enable it. 164 5. Interaction with Other Sieve Extensions 166 Actions that generate [MDN], [DSN], or similar disposition 167 messages MUST do so using the original, unmodified message header. 168 Similarly, if an error terminates processing of the script, the 169 original message header MUST be used when doing the implicit 170 keep required by [SIEVE] section 2.10.6. 172 With the exception of the special handling of redirect and 173 "Received" header fields described above, all other actions that 174 store, send, or alter the message MUST do so with the current set 175 of header fields. This includes the addheader and deleteheader 176 actions themselves. For example, the following leaves the message 177 unchanged: 179 addheader "X-Hello" "World"; 180 deleteheader :index 1 "X-Hello"; 182 Similarly, given a message with three or more "X-Hello" header 183 fields, the following example deletes the first and third of 184 them, not the first and second: 186 deleteheader :index 1 "X-Hello"; 187 deleteheader :index 2 "X-Hello"; 189 Tests and actions such as "exists", "header", or "vacation" 190 [VACATION] that examine header fields MUST examine the current 191 state of a header as modified by any actions that have taken 192 place so far. 194 As an example, the "header" test in the following fragment will 195 always evaluate to true, regardless of whether the incoming 196 message contained an "X-Hello" header field or not: 198 addheader "X-Hello" "World"; 199 if header :contains "X-Hello" "World" 200 { 201 fileinto "international"; 202 } 204 However, if the presence or value of a header field affects how 205 the implementation parses or decodes other parts of the message, 206 then for the purposes of that parsing or decoding the implementation 207 MAY ignore some or all changes made to those header fields. For 208 example, in an implementation that supports the [BODY] extension, 209 "body" tests may be unaffected by deleting or adding "Content-Type" 210 or "Content-Transfer-Encoding" header fields. This does not rescind 211 the requirement that changes to those header fields affect direct 212 tests; only the semantic side effects of changes to the fields 213 may be ignored. 215 For the purpose of weeding out duplicates, a message modified 216 by addheader or deleteheader MUST be considered the same as 217 the original message. For example, in an implementation that 218 obeys the constraint in [SIEVE] section 2.10.3 and does not deliver 219 the same message to a folder more than once, the following 220 code fragment 222 keep; 223 addheader "X-Flavor" "vanilla"; 224 keep; 226 MUST only file one message. It is up to the implementation 227 to pick which of the redundant "fileinto" or "keep" actions is 228 executed, and which ones are ignored. 230 The "implicit keep" is thought to be executed at the end of 231 the script, after the headers have been modified. (However, 232 a canceled "implicit keep" remains canceled.) 234 6. IANA Considerations 236 The following template specifies the IANA registration of the Sieve 237 extension specified in this document: 239 To: iana@iana.org 240 Subject: Registration of new Sieve extension 242 Capability name: editheader 243 Description: adds actions 'addheader' and 'deleteheader' 244 that modify the header of the message being 245 processed 246 RFC number: this RFC 247 Contact Address: Jutta Degener 249 This information should be added to the list of sieve extensions 250 given on http://www.iana.org/assignments/sieve-extensions. 252 7. Security Considerations 254 Someone with write access to a user's script storage may use this 255 extension to generate headers that a user would otherwise be 256 shielded from (e.g., by a gateway MTA that removes them). 258 A sieve filter that removes header fields may unwisely destroy 259 evidence about the path a message has taken. 261 While this specification overrides the requirement that redirected 262 messages have more "Received" header fields than the message as 263 received, doing so removes an important mechanisms for detecting 264 loops and MUST NOT be permitted by implementations without due 265 consideration, such as requiring administrative action to enable 266 it. 268 Any change in a message content may interfere with digital 269 signature mechanisms that include the header in the signed 270 material. Since normal message delivery adds "Received" 271 header fields and other trace fields to the beginning of a 272 message, many such schemas are impervious to headers prefixed 273 to a message, and will work with "addheader" unless :last is 274 used. 276 Any decision mechanism in a user's filter that is based 277 on headers is vulnerable to header spoofing. For example, 278 if the user adds an APPROVED header or tag, a malicious sender 279 may add that tag or header themselves. One way to guard against 280 this is to delete or rename any such headers or stamps prior 281 to processing the message. 283 8. Acknowledgments 285 Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, 286 Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, 287 Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, 288 Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, 289 and Rand Wacker for extensive corrections and suggestions. 291 9. Authors' Addresses 293 Jutta Degener 294 5245 College Ave, Suite #127 295 Oakland, CA 94618 297 Email: jutta@pobox.com 299 Philip Guenther 300 Sendmail, Inc. 301 6475 Christie St., Ste 350 302 Emeryville, CA 94608 304 Email: guenther@sendmail.com 306 10. Discussion 308 This section will be removed when this document leaves the 309 Internet-Draft stage. 311 This draft is intended as an extension to the Sieve mail filtering 312 language. Sieve extensions are discussed on the MTA Filters mailing 313 list at . Subscription requests can 314 be sent to (send an email 315 message with the word "subscribe" in the body). 317 More information on the mailing list along with a WWW archive of 318 back messages is available at . 320 10.1 Changes from draft-ietf-sieve-editheader-08.txt 322 Tighten up the permissible behaviors involving redirect and 323 deleteheader "Recieved". 325 Consistently quote the names of header fields, but not actions. 327 For deleteheader, :last without :index is an error. On the other 328 hand, the match-type and comparator are ignored if there are no 329 value-patterns. 331 Clarify that addheader and deleteheader operate on the 'current' 332 set of header fields and give examples demonstrating this. 334 10.2 Changes from draft-ietf-sieve-editheader-07.txt 336 Let implementations permit redirected messages to have fewer 337 "Received" header fields, but warn about the consequences. 339 Updated boilerplate to match RFC 4748. 341 Added "Intended-Status: Standards Track" and 342 "Updates: draft-ietf-sieve-3028bis-12" 344 Change the references from appendices to sections. 345 Update [SIEVE], [BODY], [DSN], and [MDN] references. 347 10.3 Changes from draft-ietf-sieve-editheader-06.txt 349 Make deleteheader match addheader on the description of invalid 350 field-names. 352 Update copyright boilerplate 354 Update references 356 10.4 Changes from draft-ietf-sieve-editheader-05.txt 358 MDN and DSN references are merely informative 360 10.5 Changes from draft-ietf-sieve-editheader-04.txt 362 Ignore leading and trailing whitespace when matching header field 363 values. 365 Header modifications are ignored when continuing after an error 366 or generating MDNs or DSNs 368 Added references for MDN and DSN 370 Update IANA registration to match 3028bis 372 Added [KEYWORDS] boilerplate text 374 Describe an invalid field-name to addheader as an error (might 375 be detected at runtime) 377 10.6 Changes from draft-ietf-sieve-editheader-03.txt 379 Change "Syntax:" to "Usage:". 381 Updated references. 383 10.7 Changes from draft-ietf-sieve-editheader-02.txt 385 Clarify that value-patterns restrict which occurrences are deleted. 387 Add informative reference to [BODY]. 389 10.8 Changes from draft-ietf-sieve-editheader-01.txt 391 Whitespace and line length tweaks noted by ID-nits. 393 Clarified what is being counted by :index. 395 Update the [SIEVE] reference to the I-D of the revision. 397 10.9 Changes from draft-ietf-sieve-editheader-00.txt 399 Updated IPR boilerplate to RFC 3978/3979. 401 Many corrections in response to WGLC comments. Of particular note: 402 - correct a number of spelling and grammar errors 403 - document that neither addheader nor deleteheader affects the 404 implicit keep 405 - add normative references to RFC 2047 and RFC 2231 406 - it is not an error for deleteheader to affect nothing 407 - change "foo.tld" to "foo.example.com" 408 - add an informative reference to [VACATION], citing it as an 409 example of an action that examines header fields 410 - add weasel words about changes to fields that have secondary 411 effects 412 - add security consideration for combination of header changes 413 and "reject" 415 10.10 Changes from draft-degener-sieve-editheader-03.txt 417 Renamed to draft-ietf-sieve-editheader-00.txt; 418 tweaked the title and abstract. 420 Added Philip Guenther as co-author. 422 Updated IPR boilerplate. 424 10.11 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 11. 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: A Mail Filtering 453 Language", draft-ietf-sieve-3028bis-12, February 2007. 455 12. Informative References 457 [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: 458 Body Extension", draft-ietf-sieve-body-06, February 2007. 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", draft-ietf-sieve-vacation-06, 469 February 2006. 471 Full Copyright Statement 473 Copyright (C) The IETF Trust (2007). 475 This document is subject to the rights, licenses and restrictions 476 contained in BCP 78, and except as set forth therein, the authors 477 retain all their rights. 479 This document and the information contained herein are provided on an 480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 482 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 483 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 484 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 487 Intellectual Property 489 The IETF takes no position regarding the validity or scope of any 490 Intellectual Property Rights or other rights that might be claimed to 491 pertain to the implementation or use of the technology described in 492 this document or the extent to which any license under such rights 493 might or might not be available; nor does it represent that it has 494 made any independent effort to identify any such rights. Information 495 on the procedures with respect to rights in RFC documents can be 496 found in BCP 78 and BCP 79. 498 Copies of IPR disclosures made to the IETF Secretariat and any 499 assurances of licenses to be made available, or the result of an 500 attempt made to obtain a general license or permission for the use of 501 such proprietary rights by implementers or users of this 502 specification can be obtained from the IETF on-line IPR repository at 503 http://www.ietf.org/ipr. 505 The IETF invites any interested party to bring to its attention any 506 copyrights, patents or patent applications, or other proprietary 507 rights that may cover technology that may be required to implement 508 this standard. Please address the information to the IETF at 509 ietf-ipr@ietf.org. 511 Acknowledgement 513 Funding for the RFC Editor function is currently provided by the IETF 514 Administrative Support Activity (IASA).