Sieve Email Filtering: Editheader Extension
RFC 5293

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sieve mailing list <ietf-mta-filters@imc.org>, 
    sieve chair <sieve-chairs@tools.ietf.org>
Subject: Protocol Action: 'Sieve Email Filtering: Editheader 
         Extension' to Proposed Standard 

The IESG has approved the following document:

- 'Sieve Email Filtering: Editheader Extension '
   <draft-ietf-sieve-editheader-12.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 Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-12.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@daboo.name>
AD: Lisa Dusseault <mailto:lisa@osafoundation.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.