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@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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
