[Top] [All Lists]

Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt

2005-03-29 11:15:03


A two week working group last call of this document starts today and ends
on 28th March 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the

Is it worth making it explicit that if deleteheader can't find any matching
headers then this isn't an error?

I think it would be.

I'm sad that we have to say this:

   Actions that create messages in storage or in transport to
   MTAs MUST store and send messages with the current set of
   header fields.

I'm not. This is a very useful feature, one I depend on myself for a couple of
things. It also strikes me as the obvious way for things to work.

Certainly it'll break my implementation, as I package up all redirects and
fileintos and do them (or cancel them) all in a batch at the end.

My implementation works the same way, but even so I had no problem implementing
this aspect of editheader. For me the harder part was making the edits visible
to subsequent tests like header, address, exists, etc. I basically maintain a
change list, which can be forked and attached to fileintos, redirects, etc.
This keeps me from having to duplicate the entire header, but it complicates
the tests a bit, especially when an existing header has been removed. (I did
get it working, but the code is kinda nasty - one of those wierd loops that
starts in the middle and has several points of egress.)

A much bigger worry IMO is how this interacts with body and mime. A change
to one of the primary MIME headers can completely change the meaning
of the content, which in turn will force me to have to rescan the message.
A series of operations like this:

    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "quoted-printable"
    if body :contains "..." ...
    deleteheader "content-transfer-encoding";
    addheader "content-transfer-encoding" "base64"
    if body :contains "..." ...

can force an arbitrary number of rescans. And that's simply not acceptable in a
high performance implementation. Therefore the rule needs to be that both body
and mime may not be affected by the use of editheader operations.

I think the above paragraph means that if I allow editheader (which I do) then
I'll have to change this or more likely not obey the standard until someone
complains.  The feature it gains me seems to be pretty marginal, yet costly to
add, so I suspect my implementation will never change.

Who knows? Depending on your user base you may be able to get away with this.
I already have uses for per-message-copy header editing, so I don't think
I'd be able to get away with it.

I think we are saying that editheader does not cancel the implict keep
(certainly this makes sense), but I don't think we've been very clear about 
I liked the clarity of what was said in the vacation draft: "Vacation does not
affect Sieve's implicit keep action."

Agreed. This needs to be made explicit in the draft.