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