draft-ietf-sieve-editheader-08.txt   draft-ietf-sieve-editheader-09.txt 
Network Working Group Jutta Degener Network Working Group Jutta Degener
Internet Draft Philip Guenther Internet Draft Philip Guenther
Intended status: Standards Track Sendmail, Inc. Intended status: Standards Track Sendmail, Inc.
Updates: RFC-ietf-sieve-3028bis-12 Updates: RFC-ietf-sieve-3028bis-12
Sieve Email Filtering: Editheader Extension Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-08.txt draft-ietf-sieve-editheader-09.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 26 skipping to change at page 3, line 26
The field-name is mandatory and always matched as a case-insensitive The field-name is mandatory and always matched as a case-insensitive
US-ASCII string. If the field-name is not a valid 7-bit header US-ASCII string. If the field-name is not a valid 7-bit header
field name as described by the [IMAIL] "field-name" nonterminal field name as described by the [IMAIL] "field-name" nonterminal
syntax element, the implementation MUST flag an error. syntax element, the implementation MUST flag an error.
The value-patterns, if specified, restrict which occurrences of The value-patterns, if specified, restrict which occurrences of
the header field are deleted to those whose values match any of the header field are deleted to those whose values match any of
the specified value-patterns, the matching being according to the specified value-patterns, the matching being according to
the match-type and comparator and performed as if by the "header" the match-type and comparator and performed as if by the "header"
test. In particular, leading and trailing whitespace in the test. In particular, leading and trailing whitespace in the
field values is ignored. field values is ignored. If no value-patterns are specified
then the comparator and match-type options are silently ignored.
If :index <fieldno> is specified, the attempts to match a value If :index <fieldno> is specified, the attempts to match a value
are limited to the <fieldno> occurrence of the named header are limited to the <fieldno> occurrence of the named header
field, beginning at 1, the first named header field. If :last field, beginning at 1, the first named header field. If :last
is specified, the count is backwards; 1 denotes the last named is specified, the count is backwards; 1 denotes the last named
header field, 2 the second to last, and so on. The counting header field, 2 the second to last, and so on. The counting
happens before the <value-patterns> match, if any. For example: happens before the <value-patterns> match, if any. For example:
deleteheader :index 2 :contains "Received" "via carrier-pigeon" deleteheader :index 2 :contains "Received" "via carrier-pigeon"
deletes the second "Received" header field if it contains deletes the second "Received" header field if it contains
the string "via carrier-pigeon" (not the second Received field the string "via carrier-pigeon" (not the second "Received" field
that contains "via carrier-pigeon"). that contains "via carrier-pigeon").
It is not an error if no header fields match the conditions in It is not an error if no header fields match the conditions in
the deleteheader action or if the :index argument is greater the deleteheader action or if the :index argument is greater
than the number of named header fields. than the number of named header fields.
The implementation MUST flag an error if :last is specified
without also specifying :index.
If an script uses the deleteheader action to remove "Received" If an script uses the deleteheader action to remove "Received"
header fields and then performs a "redirect" action, the header fields and then performs a redirect action, then the
implementation SHOULD NOT send the outgoing message with fewer implementation MUST either:
Received header fields than the original message. If the A) silently ignore all of the deleteheader actions that removed
implementation does not permit that for the involved script, it "Received" header fields when generating the outgoing message,
is implementation defined what Received header fields are present B) silently ignore just enough of the deleteheader actions that
in such an outgoing message. The above overrides the requirement removed "Received" header fields when generating the outgoing
on Received header fields in RFC-ietf-sieve-3028bis-12 section message, such that it has more "Received" header fields than
4.2. the message as recieved by the implementation, or
C) obey all the deleteheader actions, possibly sending out a
message with no more "Received" header fields than where in
the message as received. This overrides the requirement on
"Received" header fields in RFC-ietf-sieve-3028bis-12
section 4.2.
Implementations MUST NOT do choice (C) without due consideration,
such as requiring explicit administrative action to enable it.
5. Interaction with Other Sieve Extensions 5. Interaction with Other Sieve Extensions
Actions that generate [MDN], [DSN], or similar disposition Actions that generate [MDN], [DSN], or similar disposition
messages MUST do so using the original, unmodified message header. messages MUST do so using the original, unmodified message header.
Similarly, if an error terminates processing of the script, the Similarly, if an error terminates processing of the script, the
original message header MUST be used when doing the implicit original message header MUST be used when doing the implicit
keep required by [SIEVE] section 2.10.6. keep required by [SIEVE] section 2.10.6.
With the exception of the special handling of "redirect" and With the exception of the special handling of redirect and
"Received" header fields described above, all other actions that "Received" header fields described above, all other actions that
store or send the message MUST do so with the current set of store, send, or alter the message MUST do so with the current set
header fields. of header fields. This includes the addheader and deleteheader
actions themselves. For example, the following leaves the message
unchanged:
addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello";
Similarly, given a message with three or more "X-Hello" header
fields, the following example deletes the first and third of
them, not the first and second:
deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello";
Tests and actions such as "exists", "header", or "vacation" Tests and actions such as "exists", "header", or "vacation"
[VACATION] that examine header fields MUST examine the current [VACATION] that examine header fields MUST examine the current
state of a header as modified by any actions that have taken state of a header as modified by any actions that have taken
place so far. place so far.
As an example, the "header" test in the following fragment will As an example, the "header" test in the following fragment will
always evaluate to true, regardless of whether the incoming always evaluate to true, regardless of whether the incoming
message contained an "X-Hello" header field or not: message contained an "X-Hello" header field or not:
skipping to change at page 4, line 38 skipping to change at page 5, line 20
if header :contains "X-Hello" "World" if header :contains "X-Hello" "World"
{ {
fileinto "international"; fileinto "international";
} }
However, if the presence or value of a header field affects how However, if the presence or value of a header field affects how
the implementation parses or decodes other parts of the message, the implementation parses or decodes other parts of the message,
then for the purposes of that parsing or decoding the implementation then for the purposes of that parsing or decoding the implementation
MAY ignore some or all changes made to those header fields. For MAY ignore some or all changes made to those header fields. For
example, in an implementation that supports the [BODY] extension, example, in an implementation that supports the [BODY] extension,
"body" tests may be unaffected by deleting or adding Content-Type "body" tests may be unaffected by deleting or adding "Content-Type"
or Content-Transfer-Encoding header fields. This does not rescind or "Content-Transfer-Encoding" header fields. This does not rescind
the requirement that changes to those header fields affect direct the requirement that changes to those header fields affect direct
tests; only the semantic side effects of changes to the fields tests; only the semantic side effects of changes to the fields
may be ignored. may be ignored.
For the purpose of weeding out duplicates, a message modified For the purpose of weeding out duplicates, a message modified
by addheader or deleteheader MUST be considered the same as by addheader or deleteheader MUST be considered the same as
the original message. For example, in an implementation that the original message. For example, in an implementation that
obeys the constraint in [SIEVE] section 2.10.3 and does not deliver obeys the constraint in [SIEVE] section 2.10.3 and does not deliver
the same message to a folder more than once, the following the same message to a folder more than once, the following
code fragment code fragment
skipping to change at page 5, line 40 skipping to change at page 6, line 33
7. Security Considerations 7. Security Considerations
Someone with write access to a user's script storage may use this Someone with write access to a user's script storage may use this
extension to generate headers that a user would otherwise be extension to generate headers that a user would otherwise be
shielded from (e.g., by a gateway MTA that removes them). shielded from (e.g., by a gateway MTA that removes them).
A sieve filter that removes header fields may unwisely destroy A sieve filter that removes header fields may unwisely destroy
evidence about the path a message has taken. evidence about the path a message has taken.
While this specification overrides the requirement that redirected While this specification overrides the requirement that redirected
messages have more Received header fields than the message as messages have more "Received" header fields than the message as
received, doing so removes an important mechanisms for detecting received, doing so removes an important mechanisms for detecting
loops and therefore should not be permitted by implementations loops and MUST NOT be permitted by implementations without due
without due consideration, such as requiring administrative consideration, such as requiring administrative action to enable
action to enable it. it.
Any change in a message content may interfere with digital Any change in a message content may interfere with digital
signature mechanisms that include the header in the signed signature mechanisms that include the header in the signed
material. Since normal message delivery adds "Received:" material. Since normal message delivery adds "Received"
header fields to the beginning of a message, many such schemas header fields and other trace fields to the beginning of a
are impervious to headers prefixed to a message, and will message, many such schemas are impervious to headers prefixed
work with "addheader" unless :last is used. to a message, and will work with "addheader" unless :last is
used.
Any decision mechanism in a user's filter that is based Any decision mechanism in a user's filter that is based
on headers is vulnerable to header spoofing. For example, on headers is vulnerable to header spoofing. For example,
if the user adds an APPROVED header or tag, a malicious sender if the user adds an APPROVED header or tag, a malicious sender
may add that tag or header themselves. One way to guard against may add that tag or header themselves. One way to guard against
this is to delete or rename any such headers or stamps prior this is to delete or rename any such headers or stamps prior
to processing the message. to processing the message.
8. Acknowledgments 8. Acknowledgments
Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed,
Arnt Gulbrandsen, Simon Josefsson, Will Lee, William Leibzon, Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson,
Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, Will Lee, William Leibzon, Mark E. Mallett, Chris Markle,
Nigel Swinson, Kjetil Torgrim Homme, and Rand Wacker for extensive Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson,
corrections and suggestions. and Rand Wacker for extensive corrections and suggestions.
9. Authors' Addresses 9. Authors' Addresses
Jutta Degener Jutta Degener
5245 College Ave, Suite #127 5245 College Ave, Suite #127
Oakland, CA 94618 Oakland, CA 94618
Email: jutta@pobox.com Email: jutta@pobox.com
Philip Guenther Philip Guenther
Sendmail, Inc. Sendmail, Inc.
6425 Christie Ave, 4th Floor 6475 Christie St., Ste 350
Emeryville, CA 94608 Emeryville, CA 94608
Email: guenther@sendmail.com Email: guenther@sendmail.com
10. Discussion 10. Discussion
This section will be removed when this document leaves the This section will be removed when this document leaves the
Internet-Draft stage. Internet-Draft stage.
This draft is intended as an extension to the Sieve mail filtering This draft is intended as an extension to the Sieve mail filtering
language. Sieve extensions are discussed on the MTA Filters mailing language. Sieve extensions are discussed on the MTA Filters mailing
list at <ietf-mta-filters@imc.org>. Subscription requests can list at <ietf-mta-filters@imc.org>. Subscription requests can
be sent to <ietf-mta-filters-request@imc.org> (send an email be sent to <ietf-mta-filters-request@imc.org> (send an email
message with the word "subscribe" in the body). message with the word "subscribe" in the body).
More information on the mailing list along with a WWW archive of More information on the mailing list along with a WWW archive of
back messages is available at <http://www.imc.org/ietf-mta-filters/>. back messages is available at <http://www.imc.org/ietf-mta-filters/>.
10.1 Changes from draft-ietf-sieve-editheader-07.txt 10.1 Changes from draft-ietf-sieve-editheader-08.txt
Tighten up the permissible behaviors involving redirect and
deleteheader "Recieved".
Consistently quote the names of header fields, but not actions.
For deleteheader, :last without :index is an error. On the other
hand, the match-type and comparator are ignored if there are no
value-patterns.
Clarify that addheader and deleteheader operate on the 'current'
set of header fields and give examples demonstrating this.
10.2 Changes from draft-ietf-sieve-editheader-07.txt
Let implementations permit redirected messages to have fewer Let implementations permit redirected messages to have fewer
Received header fields, but warn about the consequences. "Received" header fields, but warn about the consequences.
Updated boilerplate to match RFC 4748. Updated boilerplate to match RFC 4748.
Added "Intended-Status: Standards Track" and Added "Intended-Status: Standards Track" and
"Updates: draft-ietf-sieve-3028bis-12" "Updates: draft-ietf-sieve-3028bis-12"
Change the references from appendices to sections. Change the references from appendices to sections.
Update [SIEVE], [BODY], [DSN], and [MDN] references. Update [SIEVE], [BODY], [DSN], and [MDN] references.
10.2 Changes from draft-ietf-sieve-editheader-06.txt 10.3 Changes from draft-ietf-sieve-editheader-06.txt
Make deleteheader match addheader on the description of invalid Make deleteheader match addheader on the description of invalid
field-names. field-names.
Update copyright boilerplate Update copyright boilerplate
Update references Update references
10.3 Changes from draft-ietf-sieve-editheader-05.txt 10.4 Changes from draft-ietf-sieve-editheader-05.txt
MDN and DSN references are merely informative MDN and DSN references are merely informative
10.4 Changes from draft-ietf-sieve-editheader-04.txt 10.5 Changes from draft-ietf-sieve-editheader-04.txt
Ignore leading and trailing whitespace when matching header field Ignore leading and trailing whitespace when matching header field
values. values.
Header modifications are ignored when continuing after an error Header modifications are ignored when continuing after an error
or generating MDNs or DSNs or generating MDNs or DSNs
Added references for MDN and DSN Added references for MDN and DSN
Update IANA registration to match 3028bis Update IANA registration to match 3028bis
Added [KEYWORDS] boilerplate text Added [KEYWORDS] boilerplate text
Describe an invalid field-name to addheader as an error (might Describe an invalid field-name to addheader as an error (might
be detected at runtime) be detected at runtime)
10.5 Changes from draft-ietf-sieve-editheader-03.txt 10.6 Changes from draft-ietf-sieve-editheader-03.txt
Change "Syntax:" to "Usage:". Change "Syntax:" to "Usage:".
Updated references. Updated references.
10.6 Changes from draft-ietf-sieve-editheader-02.txt 10.7 Changes from draft-ietf-sieve-editheader-02.txt
Clarify that value-patterns restrict which occurrences are deleted. Clarify that value-patterns restrict which occurrences are deleted.
Add informative reference to [BODY]. Add informative reference to [BODY].
10.7 Changes from draft-ietf-sieve-editheader-01.txt 10.8 Changes from draft-ietf-sieve-editheader-01.txt
Whitespace and line length tweaks noted by ID-nits. Whitespace and line length tweaks noted by ID-nits.
Clarified what is being counted by :index. Clarified what is being counted by :index.
Update the [SIEVE] reference to the I-D of the revision. Update the [SIEVE] reference to the I-D of the revision.
10.8 Changes from draft-ietf-sieve-editheader-00.txt 10.9 Changes from draft-ietf-sieve-editheader-00.txt
Updated IPR boilerplate to RFC 3978/3979. Updated IPR boilerplate to RFC 3978/3979.
Many corrections in response to WGLC comments. Of particular note: Many corrections in response to WGLC comments. Of particular note:
- correct a number of spelling and grammar errors - correct a number of spelling and grammar errors
- document that neither addheader nor deleteheader affects the - document that neither addheader nor deleteheader affects the
implicit keep implicit keep
- add normative references to RFC 2047 and RFC 2231 - add normative references to RFC 2047 and RFC 2231
- it is not an error for deleteheader to affect nothing - it is not an error for deleteheader to affect nothing
- change "foo.tld" to "foo.example.com" - change "foo.tld" to "foo.example.com"
- add an informative reference to [VACATION], citing it as an - add an informative reference to [VACATION], citing it as an
example of an action that examines header fields example of an action that examines header fields
- add weasel words about changes to fields that have secondary - add weasel words about changes to fields that have secondary
effects effects
- add security consideration for combination of header changes - add security consideration for combination of header changes
and "reject" and "reject"
10.9 Changes from draft-degener-sieve-editheader-03.txt 10.10 Changes from draft-degener-sieve-editheader-03.txt
Renamed to draft-ietf-sieve-editheader-00.txt; Renamed to draft-ietf-sieve-editheader-00.txt;
tweaked the title and abstract. tweaked the title and abstract.
Added Philip Guenther as co-author. Added Philip Guenther as co-author.
Updated IPR boilerplate. Updated IPR boilerplate.
10.10 Changes from draft-degener-sieve-editheader-02.txt 10.11 Changes from draft-degener-sieve-editheader-02.txt
Changed the duplicate restrictions from "messages with different Changed the duplicate restrictions from "messages with different
headers MUST be considered different" to their direct opposite, headers MUST be considered different" to their direct opposite,
"messages with different headers MUST be considered the same," "messages with different headers MUST be considered the same,"
as requested by workgroup members on the mailing list. as requested by workgroup members on the mailing list.
Expanded mention of header signature schemes to Security Expanded mention of header signature schemes to Security
Considerations. Considerations.
Added IANA Considerations section. Added IANA Considerations section.
 End of changes. 24 change blocks. 
40 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/