Sieve Email Filtering: Editheader Extension
draft-ietf-sieve-editheader-11

[Ballot comment]
The security of the base documents seems to be partially contingent on be evaluating the documents were "safe" or not. There was discussion of how this was not possible due to little details like the halting problem but the claim was made that Sieve was not turing complete. I have a hard time imagining how this does not make it turing complete but note that it does not discuss any of this in the security section.

[Ballot comment]
The security of the base documents seems to be partially contingent on be evaluating the documents were "safe" or not. There was discussion of how this was not possible due to little details like the halting problem but the claim was made that Sieve was not turing complete. I have a hard time imagining how this does not make it turing complete but note that it does not discuss any of this in the security section.

[Ballot discuss]
This is the first SIEVE extension that modifies the RFC2822 message,
and at the very least, needs a clear statement saying so (the author
has proposed text already).

I agree with Tim's DISCUSS about needing more concrete discussion
about implications for the most common signature mechanisms
(S/MIME, OpenPGP, DKIM), since they behave quite differently
here (e.g. in DKIM, header field non-existence can be signed; while
S/MIME doesn't sign the "topmost" header at all).

[Ballot discuss]
The security considerations contain general statements about implications of changing message
content with respect to digital signature mechanisms.  This general information should be
supplemented with specific information about the IETF standards track mechanisms, since sieve
filter authors may not be experts in all the different signed message formats and could miss
the nuances.

At a minimum, the security considerations should note that RFC 4871 specifies a set of
"header fields [that] SHOULD be included in the signature" in Section 5.5, Recomended
Signature Content.  As a result, removing these fields is expected to break DKIM signatures.
(I am less confident of this one, but I believe adding any of these header fields with :last could
also cause problems.)

[Ballot comment]
The security of the base documents seems to be partially contingent on be evaluating the documents were "safe" or not. There was discussion of how this was not possible due to little details like the halting problem but the claim was made that Sieve was not turing complete. I have a hard time impinging how this does not make it turing complete but note that it does not discuss any of this in the security section.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignment in the "Sieve Extensions" registry at
http://www.iana.org/assignments/sieve-extensions

Capability name: editheader
Description: Adds actions 'addheader' and 'deleteheader'
that modify the header of the message being processed
RFC number: [RFC-sieve-editheader-11]
Contact Address: Jutta Degener

We understand the above to be the only IANA Action for this
document.

Abbreviated PROTO writeup questionnaire responses
- Shepherd: Cyrus Daboo 
- has had adequate review from WG members. Not from non-WG members.
- Jeffrey Hutzelman has done a security review of the document.
- No special concerns with this document.
- There is strong WG consensus behind this document.