idnits 2.17.1 draft-ietf-sieve-editheader-08.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 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 470. 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 2007) is 6253 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: September 2007 March 2007 5 Updates: RFC-ietf-sieve-3028bis-12 7 Sieve Email Filtering: Editheader Extension 8 draft-ietf-sieve-editheader-08.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. 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 If an script uses the deleteheader action to remove "Received" 143 header fields and then performs a "redirect" action, the 144 implementation SHOULD NOT send the outgoing message with fewer 145 Received header fields than the original message. If the 146 implementation does not permit that for the involved script, it 147 is implementation defined what Received header fields are present 148 in such an outgoing message. The above overrides the requirement 149 on Received header fields in RFC-ietf-sieve-3028bis-12 section 150 4.2. 152 5. Interaction with Other Sieve Extensions 154 Actions that generate [MDN], [DSN], or similar disposition 155 messages MUST do so using the original, unmodified message header. 156 Similarly, if an error terminates processing of the script, the 157 original message header MUST be used when doing the implicit 158 keep required by [SIEVE] section 2.10.6. 160 With the exception of the special handling of "redirect" and 161 "Received" header fields described above, all other actions that 162 store or send the message MUST do so with the current set of 163 header fields. 165 Tests and actions such as "exists", "header", or "vacation" 166 [VACATION] that examine header fields MUST examine the current 167 state of a header as modified by any actions that have taken 168 place so far. 170 As an example, the "header" test in the following fragment will 171 always evaluate to true, regardless of whether the incoming 172 message contained an "X-Hello" header field or not: 174 addheader "X-Hello" "World"; 175 if header :contains "X-Hello" "World" 176 { 177 fileinto "international"; 178 } 180 However, if the presence or value of a header field affects how 181 the implementation parses or decodes other parts of the message, 182 then for the purposes of that parsing or decoding the implementation 183 MAY ignore some or all changes made to those header fields. For 184 example, in an implementation that supports the [BODY] extension, 185 "body" tests may be unaffected by deleting or adding Content-Type 186 or Content-Transfer-Encoding header fields. This does not rescind 187 the requirement that changes to those header fields affect direct 188 tests; only the semantic side effects of changes to the fields 189 may be ignored. 191 For the purpose of weeding out duplicates, a message modified 192 by addheader or deleteheader MUST be considered the same as 193 the original message. For example, in an implementation that 194 obeys the constraint in [SIEVE] section 2.10.3 and does not deliver 195 the same message to a folder more than once, the following 196 code fragment 198 keep; 199 addheader "X-Flavor" "vanilla"; 200 keep; 202 MUST only file one message. It is up to the implementation 203 to pick which of the redundant "fileinto" or "keep" actions is 204 executed, and which ones are ignored. 206 The "implicit keep" is thought to be executed at the end of 207 the script, after the headers have been modified. (However, 208 a canceled "implicit keep" remains canceled.) 210 6. IANA Considerations 212 The following template specifies the IANA registration of the Sieve 213 extension specified in this document: 215 To: iana@iana.org 216 Subject: Registration of new Sieve extension 218 Capability name: editheader 219 Description: adds actions 'addheader' and 'deleteheader' 220 that modify the header of the message being 221 processed 222 RFC number: this RFC 223 Contact Address: Jutta Degener 225 This information should be added to the list of sieve extensions 226 given on http://www.iana.org/assignments/sieve-extensions. 228 7. Security Considerations 230 Someone with write access to a user's script storage may use this 231 extension to generate headers that a user would otherwise be 232 shielded from (e.g., by a gateway MTA that removes them). 234 A sieve filter that removes header fields may unwisely destroy 235 evidence about the path a message has taken. 237 While this specification overrides the requirement that redirected 238 messages have more Received header fields than the message as 239 received, doing so removes an important mechanisms for detecting 240 loops and therefore should not be permitted by implementations 241 without due consideration, such as requiring administrative 242 action to enable it. 244 Any change in a message content may interfere with digital 245 signature mechanisms that include the header in the signed 246 material. Since normal message delivery adds "Received:" 247 header fields to the beginning of a message, many such schemas 248 are impervious to headers prefixed to a message, and will 249 work with "addheader" unless :last is used. 251 Any decision mechanism in a user's filter that is based 252 on headers is vulnerable to header spoofing. For example, 253 if the user adds an APPROVED header or tag, a malicious sender 254 may add that tag or header themselves. One way to guard against 255 this is to delete or rename any such headers or stamps prior 256 to processing the message. 258 8. Acknowledgments 260 Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, 261 Arnt Gulbrandsen, Simon Josefsson, Will Lee, William Leibzon, 262 Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, 263 Nigel Swinson, Kjetil Torgrim Homme, and Rand Wacker for extensive 264 corrections and suggestions. 266 9. Authors' Addresses 268 Jutta Degener 269 5245 College Ave, Suite #127 270 Oakland, CA 94618 272 Email: jutta@pobox.com 274 Philip Guenther 275 Sendmail, Inc. 276 6425 Christie Ave, 4th Floor 277 Emeryville, CA 94608 279 Email: guenther@sendmail.com 281 10. Discussion 283 This section will be removed when this document leaves the 284 Internet-Draft stage. 286 This draft is intended as an extension to the Sieve mail filtering 287 language. Sieve extensions are discussed on the MTA Filters mailing 288 list at . Subscription requests can 289 be sent to (send an email 290 message with the word "subscribe" in the body). 292 More information on the mailing list along with a WWW archive of 293 back messages is available at . 295 10.1 Changes from draft-ietf-sieve-editheader-07.txt 297 Let implementations permit redirected messages to have fewer 298 Received header fields, but warn about the consequences. 300 Updated boilerplate to match RFC 4748. 302 Added "Intended-Status: Standards Track" and 303 "Updates: draft-ietf-sieve-3028bis-12" 305 Change the references from appendices to sections. 306 Update [SIEVE], [BODY], [DSN], and [MDN] references. 308 10.2 Changes from draft-ietf-sieve-editheader-06.txt 310 Make deleteheader match addheader on the description of invalid 311 field-names. 313 Update copyright boilerplate 315 Update references 317 10.3 Changes from draft-ietf-sieve-editheader-05.txt 319 MDN and DSN references are merely informative 321 10.4 Changes from draft-ietf-sieve-editheader-04.txt 323 Ignore leading and trailing whitespace when matching header field 324 values. 326 Header modifications are ignored when continuing after an error 327 or generating MDNs or DSNs 329 Added references for MDN and DSN 331 Update IANA registration to match 3028bis 333 Added [KEYWORDS] boilerplate text 335 Describe an invalid field-name to addheader as an error (might 336 be detected at runtime) 338 10.5 Changes from draft-ietf-sieve-editheader-03.txt 340 Change "Syntax:" to "Usage:". 342 Updated references. 344 10.6 Changes from draft-ietf-sieve-editheader-02.txt 346 Clarify that value-patterns restrict which occurrences are deleted. 348 Add informative reference to [BODY]. 350 10.7 Changes from draft-ietf-sieve-editheader-01.txt 352 Whitespace and line length tweaks noted by ID-nits. 354 Clarified what is being counted by :index. 356 Update the [SIEVE] reference to the I-D of the revision. 358 10.8 Changes from draft-ietf-sieve-editheader-00.txt 360 Updated IPR boilerplate to RFC 3978/3979. 362 Many corrections in response to WGLC comments. Of particular note: 363 - correct a number of spelling and grammar errors 364 - document that neither addheader nor deleteheader affects the 365 implicit keep 366 - add normative references to RFC 2047 and RFC 2231 367 - it is not an error for deleteheader to affect nothing 368 - change "foo.tld" to "foo.example.com" 369 - add an informative reference to [VACATION], citing it as an 370 example of an action that examines header fields 371 - add weasel words about changes to fields that have secondary 372 effects 373 - add security consideration for combination of header changes 374 and "reject" 376 10.9 Changes from draft-degener-sieve-editheader-03.txt 378 Renamed to draft-ietf-sieve-editheader-00.txt; 379 tweaked the title and abstract. 381 Added Philip Guenther as co-author. 383 Updated IPR boilerplate. 385 10.10 Changes from draft-degener-sieve-editheader-02.txt 387 Changed the duplicate restrictions from "messages with different 388 headers MUST be considered different" to their direct opposite, 389 "messages with different headers MUST be considered the same," 390 as requested by workgroup members on the mailing list. 392 Expanded mention of header signature schemes to Security 393 Considerations. 395 Added IANA Considerations section. 397 11. Normative References 399 [IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 400 2001. 402 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", RFC 2119, March 1997. 405 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 406 Extensions) Part Three: Message Header Extensions for 407 Non-ASCII Text", RFC 2047, November 1996. 409 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 410 Encoded Word Extensions: Character Sets, Languages, and 411 Continuations", RFC 2231, November 1997. 413 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 414 Language", draft-ietf-sieve-3028bis-12, February 2007. 416 12. Informative References 418 [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: 419 Body Extension", draft-ietf-sieve-body-06, February 2007. 421 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 422 for Delivery Status Notifications", RFC 3464, January 423 2003. 425 [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition 426 Notification", RFC 3798, May 2004. 428 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 429 Vacation Extension", draft-ietf-sieve-vacation-06, 430 February 2006. 432 Full Copyright Statement 434 Copyright (C) The IETF Trust (2007). 436 This document is subject to the rights, licenses and restrictions 437 contained in BCP 78, and except as set forth therein, the authors 438 retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 443 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 444 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 445 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 Intellectual Property 450 The IETF takes no position regarding the validity or scope of any 451 Intellectual Property Rights or other rights that might be claimed to 452 pertain to the implementation or use of the technology described in 453 this document or the extent to which any license under such rights 454 might or might not be available; nor does it represent that it has 455 made any independent effort to identify any such rights. Information 456 on the procedures with respect to rights in RFC documents can be 457 found in BCP 78 and BCP 79. 459 Copies of IPR disclosures made to the IETF Secretariat and any 460 assurances of licenses to be made available, or the result of an 461 attempt made to obtain a general license or permission for the use of 462 such proprietary rights by implementers or users of this 463 specification can be obtained from the IETF on-line IPR repository at 464 http://www.ietf.org/ipr. 466 The IETF invites any interested party to bring to its attention any 467 copyrights, patents or patent applications, or other proprietary 468 rights that may cover technology that may be required to implement 469 this standard. Please address the information to the IETF at 470 ietf-ipr@ietf.org. 472 Acknowledgement 474 Funding for the RFC Editor function is currently provided by the IETF 475 Administrative Support Activity (IASA).