The IESG has approved the following document:
- 'Sieve Email Filtering: Editheader Extension '
<draft-ietf-sieve-editheader-11.txt> as a Proposed Standard
This document is the product of the Sieve Mail Filtering Language Working
Group.
The IESG contact persons are Lisa Dusseault and Chris Newman.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-11.txt
Technical Summary
The SIEVE editheader extensions provides a way for a SIEVE script to add
or remove top-level message headers in the message being processed. This
allows SIEVE to interact with other components in the mail delivery
system via information in message headers.
The extension defines an addheader action with the option to have the
header inserted at the start or end of the entire block of message
headers. Consideration is given to issues of header encoding and
possible length limits, as required by internet email standards.
The extension defines a deleteheader action which can optionally delete
all, the last, or a specific indexed header in the top-level message
headers.
The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.
The security considerations section covers several identified security
concerns.
Working Group Summary
This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.
The editheader extension was originally submitted as an individual
contribution in April 2003. The first revision involved some major
changes (one of which is discussed below) as suggested by feedback on
the list. Subsequent to that, only minor changes were done. Working
group last call was issued in March 2005 and a number of minor
clarifications and errors were fixed based on comments.
One issue which did arise during last call was that of the original
replaceheader action, which was dropped after the very first draft. That
received a fair amount of discussion at the time, and there was a
feeling that it was too complex. A number of people have expressed
disappointment that that action was not present in the draft during
last call. However, the original arguments against it were felt to still
be valid, and there was consensus that editheader should proceed without
this action.
Protocol Quality
A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this spec published as an RFC.
Personal
Document Shepherd: Cyrus Daboo <mailto:cyrus(_at_)daboo(_dot_)name>
AD: Lisa Dusseault <mailto:lisa(_at_)osafoundation(_dot_)org>
Note to RFC Editor
In Section 9, add a new paragraph after the first paragraph.
This is the first Sieve extension to be standardized that allows
alteration of messages being processed by Sieve engines.
A Sieve script that uses Sieve tests defined in RFC 5228 [SIEVE],
the editheader extension, and the redirect action back to the same user
can keep some state between different invocations of the same script
for the same message. But note that it would not be possible to
introduce an infinite loop using any such script, because each iteration
adds a new Received header field, so email loop prevention described
in RFC 2821 will eventually non deliver the message, and because
the editheader extension is explicitly prohibited to alter or delete
Received header fields (i.e. it can't interfere with loop prevention).
In Section 9, 3rd paragraph, add new material after the first sentence:
Any change in a message content may interfere with digital
signature mechanisms that include the header in the signed
material.
NEW material:
For example, changes to (or deletion/addition of) header fields
included in the "SHOULD be included in the signature" list in
section 5.5 of [RFC4871] can invalidate DKIM signatures. This also
includes DKIM signatures that guaranty a header field absence.
The editheader extension doesn't directly affect RFC 2822 header field
signatures generated using S/MIME [RFC3851] or OpenPGP [RFC3156],
because when S/MIME/OpenPGP is used to signed header fields, a copy
of RFC 2822 header fields is included inside signed message/rfc822
body part. However a software written to detect differences between
the inner (signed) copy of header fields and the outer (modified
by editheader) header fields might be affected by changes done by
editheader.
OLD:
However, implementations MUST NOT permit attempts to
delete "Received" header fields and MUST permit both addition
and deletion of the "Subject" header field.
NEW:
However, implementations MUST NOT permit attempts to
delete "Received" and "Auto-Submitted" header fields and MUST permit both
addition
^^^^^^^^^^^^^^^^^^^^
and deletion of the "Subject" header field.