On Thu, 2006-05-11 at 17:19 +0100, Alex Pimperton wrote:

While we're talking about the sieve implementation in Dovecot, is there any way to get slightly better logging?

All I get currently is:

May 11 16:58:17 server01 deliver: entered bc_action_emit with filelen: 588 May 11 16:58:17 server01 deliver: entered bc_action_emit with filelen: 720

I've removed these already long time ago.

Is there any way of getting slightly more in depth logging like with procmail?

Message X moved to Folder Y etc

I just now added a lot more logging. It logs everything else except "keep".

On Fri, 2006-05-12 at 18:02 +1000, Peter Fern wrote:

And while we're at feature-requests for -lda, I'd just like to reiterate a previous request for have a globally enforceable script that runs regardless of an existing user script, something like:

# Always run the global sieve script before user scripts global_script_enforce = 1

Then I guess we do two sieve runs if the user sieve script exists. I'm no C coder, but I might see if I can get a patch together for this...

I think you do not need any new config parameters here. I would just do a sequence run of scripts from specific to generic.

First execute per-user script, then per-domain script, then system-wide script. This way you can override more generic filters. Maybe some runs could be avoided if a previous run matches and acts.

thanks

-- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: Digital Manipulator exceeding velocity parameters

On Fri, 2006-05-12 at 15:27 +0300, Timo Sirainen wrote:

For example if the Sieve script has "keep" command, should it really save it to INBOX, or should it just ignore and let the next script handle it (and only use the final script's "keep")?

What if the first script eg. forwards the message somewhere, should the second script still be run?

I think there should be some "exit" command in Sieve so you could specify which behavior you want, but there isn't..

The next script should always run in my humble opinion. This way users are not able to modify behaviour of scripts imposed by higher levels of administration (domain admin, system admin). Or maybe this could be configurable, with a parameter defining if a match in a script inhibits other scripts execution or not.

-- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: no "any" key on keyboard

On Fri, 2006-05-12 at 09:25 -0400, John Peacock wrote:

SIEVE is not just some clever scheme that Timo (or anyone else) just made up. Each library implementation may be independent, but the language and its behavior are publicly defined:

http://www.faqs.org/rfcs/rfc3028.html

If you don't like the limitations of Sieve (which was a deliberate choice, BTW), then maildrop and procmail are just down the hall... ;-)

I know SIEVE is a standard language defined by an RFC. I admit I do not know much about SIEVE internals, but I still think it is quite cool featurewise and like it more than adding one more MDA, be it maildrop/procmail/whatever, to the delivery pipe when I can do much more using just the dovecot LDA.

I'll do my homework on the SIEVE RFCs and come back with some hopefully more interesting and useful ideas on the subject. That said I think this is more dovecot/LDA related than SIEVE related, since we are discussing about how script execution should be hadled and organized, not about the SIEVE language itself. All you need to know from the SIEVE code is what actually happened to the message after filtering, then you can decide how tyo handle execution of the remaining scripts.

Please, prove me wrong so that I can happily say RTFM to myself :)

-- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: Arcserve crashed the server again.

On Fri, May 12, 2006 at 03:23:22PM +0200, Steffen Kaiser wrote:

On Fri, 12 May 2006, Timo Sirainen wrote:

...

The problem with this is that I'm not sure how exactly it should work. For example if the Sieve script has "keep" command, should it really save it to INBOX, or should it just ignore and let the next script handle it (and only use the final script's "keep")?

I think of "implicit keep" as being an application-level thing, although that's not specified in any detail. But since implicit keep is performed after script execution, it's not really hard to think of it as an application parameter.

With this perspective, if a single application is able to execute multiple scripts sequentially, then the implicit keep is still done at the end of processing. Any one of the scripts can cancel the implicit keep (e.g. via "discard"), but if none do, the application will still file the message into the default box.

If an application can only invoke one script, one alternative is to have a special way of invoking the program in a "pass-through" mode, such that implicit keep doesn't really write to the mailbox but allows the next application to deal with it. That's tricky (but doable) for a pipeline, where the implicit keep would write to stdout:

deliver -p script1 | deliver -p script2 | deliver script3

but much less tricky if with the qmail (.qmail) model of having a list of actions including running multiple processes one after another:

deliver -p script1 deliver -p script2 deliver script3

where any script along the way can signal that it has completely handled the message and thus the controlling process should not bother proceeding to the next step. Of course, one problem with using multiple applications is that you lose a lot of other context; e.g. it's hard to collapse multiple requests to file into the same mailbox into one.

...

What if the first script eg. forwards the message somewhere, should the second script still be run?

I think there should be some "exit" command in Sieve so you could specify which behavior you want, but there isn't..

Like "stop" ? Or something else?

Hmm, Sieve is sort of extensible, I'd suggest to look at the multiple-Sieve-script problematic like

as if all Sieve scripts had be written into one file, e.g. like C's #include preprocessor directive.

Hmm, good idea :) (just a joke, since mine does that)

There is an "include" draft for sieve that has been floated, but it uses the word "include" in a different way, which I think is problematic.

mm