7Network Working Group J. Degener
8Request for Comments: 5293 P. Guenther
9Category: Standards Track Sendmail, Inc.
13 Sieve Email Filtering: Editheader Extension
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 This document defines two new actions for the "Sieve" email filtering
26 language that add and delete email header fields.
30 Email header fields are a flexible and easy-to-understand means of
31 communication between email processors. This extension enables sieve
32 scripts to interact with other components that consume or produce
33 header fields by allowing the script to delete and add header fields.
352. Conventions Used in This Document
37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
39 document are to be interpreted as described in [KEYWORDS].
41 Conventions for notations are as in Section 1.1 of [SIEVE], including
42 use of the "Usage:" label for the definition of action and tagged
45 The term "header field" is used here as in [IMAIL] to mean a logical
46 line of an email message header.
483. Capability Identifier
50 The capability string associated with the extension defined in this
51 document is "editheader".
58Degener & Guenther Standards Track [Page 1]
60RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
65 Usage: "addheader" [":last"] <field-name: string> <value: string>
67 The addheader action adds a header field to the existing message
68 header. If the field-name is not a valid 7-bit US-ASCII header field
69 name, as described by the [IMAIL] "field-name" nonterminal syntax
70 element, the implementation MUST flag an error. The addheader action
71 does not affect Sieve's implicit keep.
73 If the specified field value does not match the [IMAIL]
74 "unstructured" nonterminal syntax element or exceeds a length limit
75 set by the implementation, the implementation MUST either flag an
76 error or encode the field using folding white space and the encodings
77 described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].
79 An implementation MAY impose a length limit onto the size of the
80 encoded header field; such a limit MUST NOT be less than 998
81 characters, not including the terminating CRLF supplied by the
84 By default, the header field is inserted at the beginning of the
85 existing message header. If the optional flag ":last" is specified,
86 it is appended at the end.
90 /* Don't redirect if we already redirected */
91 if not header :contains "X-Sieve-Filtered"
92 ["<kim@job.example.com>", "<kim@home.example.com>"]
94 addheader "X-Sieve-Filtered" "<kim@job.example.com>";
95 redirect "kim@home.example.com";
100 Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
101 [COMPARATOR] [MATCH-TYPE]
103 [<value-patterns: string-list>]
105 By default, the deleteheader action deletes all occurrences of the
106 named header field. The deleteheader action does not affect Sieve's
114Degener & Guenther Standards Track [Page 2]
116RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
119 The field-name is mandatory and always matched as a case-insensitive
120 US-ASCII string. If the field-name is not a valid 7-bit header field
121 name as described by the [IMAIL] "field-name" nonterminal syntax
122 element, the implementation MUST flag an error.
124 The value-patterns, if specified, restrict which occurrences of the
125 header field are deleted to those whose values match any of the
126 specified value-patterns, the matching being according to the match-
127 type and comparator and performed as if by the "header" test. In
128 particular, leading and trailing whitespace in the field values is
129 ignored. If no value-patterns are specified, then the comparator and
130 match-type options are silently ignored.
132 If :index <fieldno> is specified, the attempts to match a value are
133 limited to the <fieldno> occurrence of the named header field,
134 beginning at 1, the first named header field. If :last is specified,
135 the count is backwards; 1 denotes the last named header field, 2 the
136 second to last, and so on. The counting happens before the <value-
137 patterns> match, if any. For example:
139 deleteheader :index 1 :contains "Delivered-To"
142 deletes the first "Delivered-To" header field if it contains the
143 string "bob@example.com" (not the first "Delivered-To" field that
144 contains "bob@example.com").
146 It is not an error if no header fields match the conditions in the
147 deleteheader action or if the :index argument is greater than the
148 number of named header fields.
150 The implementation MUST flag an error if :last is specified without
151 also specifying :index.
1536. Implementation Limitations on Changes
155 As a matter of local policy, implementations MAY limit which header
156 fields may be deleted and which header fields may be added. However,
157 implementations MUST NOT permit attempts to delete "Received" and
158 "Auto-Submitted" header fields and MUST permit both addition and
159 deletion of the "Subject" header field.
161 If a script tries to make a change that isn't permitted, the attempt
162 MUST be silently ignored.
170Degener & Guenther Standards Track [Page 3]
172RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
1757. Interaction with Other Sieve Extensions
177 Actions that generate [MDN], [DSN], or similar disposition messages
178 MUST do so using the original, unmodified message header. Similarly,
179 if an error terminates processing of the script, the original message
180 header MUST be used when doing the implicit keep required by Section
183 All other actions that store, send, or alter the message MUST do so
184 with the current set of header fields. This includes the addheader
185 and deleteheader actions themselves. For example, the following
186 leaves the message unchanged:
188 addheader "X-Hello" "World";
189 deleteheader :index 1 "X-Hello";
191 Similarly, given a message with three or more "X-Hello" header
192 fields, the following example deletes the first and third of them,
193 not the first and second:
195 deleteheader :index 1 "X-Hello";
196 deleteheader :index 2 "X-Hello";
198 Tests and actions such as "exists", "header", or "vacation"
199 [VACATION] that examine header fields MUST examine the current state
200 of a header as modified by any actions that have taken place so far.
202 As an example, the "header" test in the following fragment will
203 always evaluate to true, regardless of whether or not the incoming
204 message contained an "X-Hello" header field:
206 addheader "X-Hello" "World";
207 if header :contains "X-Hello" "World"
209 fileinto "international";
212 However, if the presence or value of a header field affects how the
213 implementation parses or decodes other parts of the message, then,
214 for the purposes of that parsing or decoding, the implementation MAY
215 ignore some or all changes made to those header fields. For example,
216 in an implementation that supports the [BODY] extension, "body" tests
217 may be unaffected by deleting or adding "Content-Type" or "Content-
218 Transfer-Encoding" header fields. This does not rescind the
219 requirement that changes to those header fields affect direct tests;
220 only the semantic side effects of changes to the fields may be
226Degener & Guenther Standards Track [Page 4]
228RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
231 For the purpose of weeding out duplicates, a message modified by
232 addheader or deleteheader MUST be considered the same as the original
233 message. For example, in an implementation that obeys the constraint
234 in Section 2.10.3 of [SIEVE] and does not deliver the same message to
235 a folder more than once, the following code fragment
238 addheader "X-Flavor" "vanilla";
241 MUST only file one message. It is up to the implementation to pick
242 which of the redundant "fileinto" or "keep" actions is executed, and
243 which ones are ignored.
245 The "implicit keep" is thought to be executed at the end of the
246 script, after the headers have been modified. (However, a canceled
247 "implicit keep" remains canceled.)
2498. IANA Considerations
251 The following template specifies the IANA registration of the Sieve
252 extension specified in this document:
255 Subject: Registration of new Sieve extension
257 Capability name: editheader
258 Description: Adds actions 'addheader' and 'deleteheader' that
259 modify the header of the message being processed
261 Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>
2639. Security Considerations
265 Someone with write access to a user's script storage may use this
266 extension to generate headers that a user would otherwise be shielded
267 from (e.g., by a gateway Mail Transport Agent (MTA) that removes
270 This is the first Sieve extension to be standardized that allows
271 alteration of messages being processed by Sieve engines. A Sieve
272 script that uses Sieve tests defined in [SIEVE], the editheader
273 extension, and the redirect action back to the same user can keep
274 some state between different invocations of the same script for the
275 same message. But note that it would not be possible to introduce an
276 infinite loop using any such script, because each iteration adds a
277 new Received header field, so email loop prevention described in
278 [SMTP] will eventually non deliver the message, and because the
282Degener & Guenther Standards Track [Page 5]
284RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
287 editheader extension is explicitly prohibited to alter or delete
288 Received header fields (i.e., it can't interfere with loop
291 A sieve filter that removes header fields may unwisely destroy
292 evidence about the path a message has taken.
294 Any change in message content may interfere with digital signature
295 mechanisms that include the header in the signed material. For
296 example, changes to (or deletion/addition of) header fields included
297 in the "SHOULD be included in the signature" list in Section 5.5 of
298 [DKIM] can invalidate DKIM signatures. This also includes DKIM
299 signatures that guarantee a header field absence.
301 The editheader extension doesn't directly affect [IMAIL] header field
302 signatures generated using [SMIME] or [OPENPGP], because these
303 signature schemes include a separate copy of the header fields inside
304 the signed message/rfc822 body part. However, software written to
305 detect differences between the inner (signed) copy of header fields
306 and the outer (modified by editheader) header fields might be
307 affected by changes made by editheader.
309 Since normal message delivery adds "Received" header fields and other
310 trace fields to the beginning of a message, many such digital
311 signature mechanisms are impervious to headers prefixed to a message,
312 and will work with "addheader" unless :last is used.
314 Any decision mechanism in a user's filter that is based on headers is
315 vulnerable to header spoofing. For example, if the user adds an
316 APPROVED header or tag, a malicious sender may add that tag or header
317 themselves. One way to guard against this is to delete or rename any
318 such headers or stamps prior to processing the message.
322 Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt
323 Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William
324 Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall
325 Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive
326 corrections and suggestions.
338Degener & Guenther Standards Track [Page 6]
340RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
34511.1. Normative References
347 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
350 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
351 Requirement Levels", BCP 14, RFC 2119, March 1997.
353 [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
354 Part Three: Message Header Extensions for Non-ASCII
355 Text", RFC 2047, November 1996.
357 [MIMEPARAM] Freed, N. and K. Moore, "MIME Parameter Value and
358 Encoded Word Extensions: Character Sets, Languages, and
359 Continuations", RFC 2231, November 1997.
361 [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
362 Email Filtering Language", RFC 5228, January 2008.
36411.2. Informative References
366 [BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:
367 Body Extension", RFC 5173, April 2008.
369 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
370 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
371 Signatures", RFC 4871, May 2007.
373 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message
374 Format for Delivery Status Notifications", RFC 3464,
377 [MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
378 Disposition Notification", RFC 3798, May 2004.
380 [OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
381 "MIME Security with OpenPGP", RFC 3156, August 2001.
383 [SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
384 Extensions (S/MIME) Version 3.1 Message Specification",
387 [SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
394Degener & Guenther Standards Track [Page 7]
396RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
399 [VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering:
400 Vacation Extension", RFC 5230, January 2008.
405 5245 College Ave, Suite #127
408 EMail: jutta@pobox.com
413 6475 Christie Ave., Ste 350
416 EMail: guenther@sendmail.com
450Degener & Guenther Standards Track [Page 8]
452RFC 5293 Sieve Email Filtering: Editheader Extension August 2008
455Full Copyright Statement
457 Copyright (C) The IETF Trust (2008).
459 This document is subject to the rights, licenses and restrictions
460 contained in BCP 78, and except as set forth therein, the authors
461 retain all their rights.
463 This document and the information contained herein are provided on an
464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
466 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
467 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
468 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
473 The IETF takes no position regarding the validity or scope of any
474 Intellectual Property Rights or other rights that might be claimed to
475 pertain to the implementation or use of the technology described in
476 this document or the extent to which any license under such rights
477 might or might not be available; nor does it represent that it has
478 made any independent effort to identify any such rights. Information
479 on the procedures with respect to rights in RFC documents can be
480 found in BCP 78 and BCP 79.
482 Copies of IPR disclosures made to the IETF Secretariat and any
483 assurances of licenses to be made available, or the result of an
484 attempt made to obtain a general license or permission for the use of
485 such proprietary rights by implementers or users of this
486 specification can be obtained from the IETF on-line IPR repository at
487 http://www.ietf.org/ipr.
489 The IETF invites any interested party to bring to its attention any
490 copyrights, patents or patent applications, or other proprietary
491 rights that may cover technology that may be required to implement
492 this standard. Please address the information to the IETF at
506Degener & Guenther Standards Track [Page 9]