I sent out three new sieve drafts last week that may be of interest:
<http://www.ietf.org/internet-drafts/draft-degener-sieve-copy-00.txt>
fileinto :copy, redirect :copy -- keyword parameter that
prevents cancelling the implicit "keep".
This isn't a problem I've seen myself, but it seems like a reasonable
thing to have and the implementation burden should be low.
<http://www.ietf.org/internet-drafts/draft-degener-sieve-editheader-00.txt>
Deleting, adding, and changing message header fields.
I see several issues here:
(1) The use of separate field-name/field-value arguments to specify a header
field matches up nicely with the header test. But it effectively precludes
specification of more than one header in a single addheader or
deleteheader command. I prefer the approach of having a single argument,
which can either be a string specifying a single field or a list
specifying multiple fields.
(2) I sure wish we'd allowed signed integers as numbers in the base sieve
specification. If we had them available we could use negative indices
to represent offsets from the last occurence of a given field. This in
turn would make it possible to specify ranges of fields in deleteheader
fairly easily. I wish I had an alternative to suggest here that would
give us this functionality, but I don't.
(3) I see considerable value in addheader and deleteheader. Replaceheader,
however, goes a bit too far for my tastes. Do we really need this? Is
it worth the complexity?
<http://www.ietf.org/internet-drafts/draft-degener-sieve-multiscript-00.txt>
Sequential execution of (unrelated) sieve scripts by the
environment. A meta-feature -- it doesn't define new sieve
language elements -- that's interesting in particular in
contrast to Cyrus's "include" draft.
Hmm. The approach taken here is very similar but not quite identical to the
approach I've used to combine multiple scripts. We agree in that any script
that ends in an implicit keep in effect cedes control to the next script in the
sequence, and that the explicit actions reject, fileinto, and redirect that
cancel implicit keep prevent subsequent scripts from running.
The place where we differ is in the handling of explicit keep. The draft calls
for subsequent scripts to be called. I don't do that; in my implementation an
explicit keep prevents subsequent scripts from acting.
I don't think this is something I can change at this point either. One of the
things that's often done is to have some kind of filtering in a system-level
sieve script. That script may elect to discard a message. I wanted the ability
for users to override such system-level decisions by issuing an explicit "keep"
in their scripts. This trick got documented and is now in use.
I suppose I could always implement an option to control how explicit keeps
affect the operation of multiple scripts.
There's also one semantics issue I see here: RFC 3028 says that fileinto
"INBOX" and "keep" are equivalent in an IMAP environment. This specification
tweaks that equivalence somewhat.
There may or may not be another one for fileinto in the wings.
It's about Kjetil's open issue 0.3 b):
Some implementations of "fileinto" create IMAP folders on the
fly if they don't exist; others don't. (They redirect to
the inbox instead.) Sieve doesn't proscribe either way.
My own implementation used to only reuse existing folders; but now
that we're thinking about creating them on demand in conjunction
with the "variables" extension, I'm getting requests for a way
for a user to express their intention; something like
fileinto :create "If it doesn't exist, create it"
or
fileinto :exists "If it doesn't exist, redirect to INBOX."
or something in that area.
Is anyone hearing similar requests from their users?
Have you thought about the issue and come to conclusions for
your own releases?
We opted for the other course: We create new folders on demand. Thus far I
don't believe we've gotten requests for "only file to folders that already
exist", but of course that could change once variables support is available.
I have no problem with implementing such an extension in any case.
Ned