On Fri, 2009-04-03 at 12:34 -0700, James Butler wrote:

...

How can I add an extension to Dovecot's Sieve implementation?

I would like to use 'editheader' and 'redirect'.

I'm not really sure what you mean. editheader isn't implemented, although Konstantin is apparently trying to implement it for dovecot-libsieve. redirect is implemented and can be used in the same way as all other sieve implementations:

redirect "email@example.com";

Thank you for your response!

• Dovecot v.1.2.beta4
• Sieve 0.1.4

I am getting this in my sieve log:

main script: line 7: error: unsupported sieve capability 'editheader'. main script: line 7: error: unsupported sieve capability 'discard'. main script: line 7: error: unsupported sieve capability 'redirect'. main script: line 12: error: unknown command 'addheader'.

I wish to receive list messages to a list user (i.e. lists@example.com), then distribute them to the appropriate end users, then discard the original message. Here's what I am currently experimenting with:

if not header :contains "X-noloop" "true" { if header :contains "Subject" "List Title" { addheader :last "X-noloop: true"; redirect ["enduser1@example.com","enduser2@example.com"]; discard; stop; } }

Since this is a global script, I figured I need to add a header or flag to the message then detect it and avoid a loop condition.

James

On Fri, 2009-04-03 at 13:08 -0700, James Butler wrote:

...

• Dovecot v.1.2.beta4
• Sieve 0.1.4

I am getting this in my sieve log:

main script: line 7: error: unsupported sieve capability 'editheader'.

Right, this isn't supported.

...

main script: line 7: error: unsupported sieve capability 'discard'. main script: line 7: error: unsupported sieve capability 'redirect'.

These don't need to be "require"d.

...

Since this is a global script, I figured I need to add a header or flag to the message then detect it and avoid a loop condition.

I think MTAs are pretty good at catching loops nowadays.

So this is pretty common ... forking messages to users on the same server using a global script that will get hit again when the forks arrive? I hesitate to test because I've previously experienced loops with a Sendmail/Procmail setup that brought my (remote) server to its knees. (I'm now using Postfix v.2.5.5.)

If it's cool, though, I'm going to start here with my recipe writing:

if header :contains "Subject" "List Title" { redirect ["enduser1@example.com","enduser2@example.com"]; discard; stop; }

Thanks, again.

James

On Fri, 2009-04-03 at 13:43 -0700, James Butler wrote:

And if it's not too much trouble, is there a way to include currently un-included extensions, like 'editheader', into Dovecot/Sieve? How complicated is it? I'm guessing that it is more complicated than simply writing a Capability definition and generating a plugin ...

I guess it depends on what you mean by "generating a plugin". The working kind of "generating" is "writing the necessary code" :) So no, it's not simple. If it were, it would have been implemented already.

Hmmm. I'm having difficulty finding a good place for a global Sieve script.

The problem seems to be related to saving the compiled version (xxx.svbin.tmp) in the same location as the script (xxx.sieve), which happens using the credentials of the recipient user.

i.e.

drwxr-xr-x dovecoter dovecoter /scripts -rw-r--r-- dovecoter dovecoter /scripts/global.sieve -rw------- recipient USERGROUP /scripts/global.svbin.tmp

Where should I be storing a global script that will process all incoming mail, and is not user-specific? Also, I would love some suggestions regarding how the permissions should be set, or anything that would make this work as expected.

(Also, is there any documentation available regarding this type of thing?)

Thanks.

James

Thank you for your response, Mr. Bosch.

...

Hmmm. I'm having difficulty finding a good place for a global Sieve script. First of all, you should start a new thread (i.e. don't reply on an existing message) if you have a completely new question. Otherwise, some

James Butler schreef: people may miss it and you'll mess the threads up in general.

I apologize. I thought I had created a new thread. I will be more careful in the future.

...

The problem seems to be related to saving the compiled version (xxx.svbin.tmp) in the same location as the script (xxx.sieve), which happens using the credentials of the recipient user. The .svbin.tmp is a temporary version of the binary that is produced (and removed) when the script is recompiled. So, the actual name for the Sieve binary is global.svbin.

Thank you.

...

i.e.

drwxr-xr-x dovecoter dovecoter /scripts -rw-r--r-- dovecoter dovecoter /scripts/global.sieve -rw------- recipient USERGROUP /scripts/global.svbin.tmp

Where should I be storing a global script that will process all incoming mail, and is not user-specific? Also, I would love some suggestions regarding how the permissions should be set, or anything that would make this work as expected.

The main problem is that the recipient users will not be able to write in the global directory, or they are not able to replace an existing binary with a recompiled version. This makes it impossible for deliver to store compiled global script binaries (it will work though). To prevent this, you must manually pre-compile your global scripts using the sievec tool each time you change them. Read the man page for more info.

If this is the method for utilizing a global script, I am still unable to implement it.

I have manually pre-compiled the global.sieve script into global.svbin in the same location, however I still get the error (shown below), plus there is now another error, since a normal user does not have permission to even access the binary, which is owned by the Dovecot user.

Here are the errors:

(Running as recipient user1, try to open the pre-compiled script, which is owned by the Dovecot user:)

dovecot: deliver(user1): sieve: binary open(/dovecot/global.svbin) failed: Permission denied

(No permissions, so it tries to create its own .tmp file:)

dovecot: deliver(user1): sieve: rename(/dovecot/global.svbin.tmp, /dovecot/global.svbin) failed for binary save: Permission denied

For the record, here's my global script stuff:

drwxr-xr-x dovecotuser:dovecotgroup /scripts -rw-r--r-- dovecotuser:dovecotgroup /scripts/global.sieve -rw------- dovecotuser:dovecotgroup /scripts/global.svbin

And here's what is being attempted with regard to error #2, above:

-rw------- user1:user1group /scripts/global.svbin.tmp

Note that this .tmp file remains in the directory along with the other files, and it is not removed.

Mr. Bosch, I am curious about your statement:

"This makes it impossible for deliver to store compiled global script binaries (it will work though)."

I'm not sure what is 'impossible' and what 'will work though'. I can definitely *store* a compiled global script binary ... it just seems to be tricky to *use* it. ;) I appreciate any clarity you can give.

James

Timo Sirainen wrote:

On Fri, 2009-04-03 at 12:34 -0700, James Butler wrote:

...

How can I add an extension to Dovecot's Sieve implementation?

I would like to use 'editheader' and 'redirect'.

I'm not really sure what you mean. editheader isn't implemented, although Konstantin is apparently trying to implement it for dovecot-libsieve. redirect is implemented and can be used in the same way as all other sieve implementations:

redirect "email@example.com";

Will Sieve become part of the standard distribution? Or will remain a patch/add-on for the foreseeable future?

-- Daniel