On Wed, 5 Sep 2007 09:00:49 +0200 (CEST), Steffen Kaiser skdovecot@smail.inf.fh-bonn-rhein-sieg.de wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tue, 4 Sep 2007, Marcin Michal Jessa wrote:

The naming of the Sieve script and the configuration variables is explained here:

http://wiki.dovecot.org/LDA/Sieve

Note: The change of the name of global script path.

"script path" refers to a filename, not just the directory of the ".dovecot-sieve" file.

BTW: Because the script is compiled into a byte code representation, everybody needs write permission to the directory of the script (creates .tmp file, on success renames into <<script path>>c ). If you force the compilation process using "sievec", no write permission is required, e.g.:

scriptpath=<> /usr/local/libexec/dovecot/sievec $scriptpath ${scriptpath}c

I just ran a test defining sieve_global_dir = /usr/local/etc/sieve/ in my dovecot.conf and commenting global_script_path = Then I renamed my sieve script to .dovecot-sieve in that dir. And nothing happened. It was not compiled and used. I had to define global_script_path = again and then I could as well give the script a more reasonable name like Junk since it takes care of filtering of junk mail. Any idea why it does not work as you say?

BTW, http://wiki.dovecot.org/LDA/Sieve should have things mentioned for global users as well since I overlooked that part from "Per-user Sieve script location" thinking it did not consider users of global scripts.

Marcin.

On Wednesday 05 September 2007 11:01:57 Steffen Kaiser wrote:

On Wed, 5 Sep 2007, Marcin M. Jessa wrote:

...

...

"script path" refers to a filename, not just the directory of the ".dovecot-sieve" file.

I just ran a test defining sieve_global_dir = /usr/local/etc/sieve/

Er, you missed the >>"script path" refers to a filename<<, didn't you?

No, I commended global_script_path = so it was not used. According to your earlier email it should be enough to use sieve_global_dir and put .dovecot.sieve file with my rules in that directory. This is is also what the example on http://wiki.dovecot.org/LDA/Sieve says. There is only sieve_global_dir = /etc/dovecot/sieve/ there. And what I said was that did not work. Do you mean I should use both global_script_path and sieve_global_dir?

See, get_sieve_path(void) in cmusieve's source ball src/cmusieve-plugin.c The value of "sieve" per user or "sieve_global_dir" is a filename, not a directory. Only if none of them is defined, ".dovecot-sieve" comes into play.

In this case things should work fine when defining sieve_global_dir = /usr/local/etc/sieve/Something but they don't. Or must this be sieve_global_dir = /usr/local/etc/sieve/.dovecot-sieve ?

...

script a more reasonable name like Junk since it takes care of filtering of

You can give the script any name you like. Personally I wouldn't name it "Junk", because there is exactly one Sieve script and you cannot specify another one. AFAIR you can include other scripts in your script and they will be then used by sieve. So it would actually make more sense to have a file called Main and then include Junk and other scripts in it.

...

BTW, http://wiki.dovecot.org/LDA/Sieve should have things mentioned for global users as well since I overlooked that part from "Per-user Sieve script location" thinking it did not consider users of global scripts.

I would think, the sections "Configuring" and "Compiling and errors" apply to you.

The "Per-user" section really is dealing with the configuration per user, whether or not you return the same value for all users.

This is misleading. Wouldn't hurt to mention .dovecot-sieve there.

perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115), 10);'

Steffen Kaiser wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tue, 4 Sep 2007, Marcin Michal Jessa wrote:

The naming of the Sieve script and the configuration variables is explained here:

http://wiki.dovecot.org/LDA/Sieve

Note: The change of the name of global script path.

"script path" refers to a filename, not just the directory of the ".dovecot-sieve" file.

BTW: Because the script is compiled into a byte code representation, everybody needs write permission to the directory of the script (creates .tmp file, on success renames into <<script path>>c ). If you force the compilation process using "sievec", no write permission is required, e.g.:

scriptpath=<> /usr/local/libexec/dovecot/sievec $scriptpath ${scriptpath}c I've tried manually compiling the script. I now have a "sieve" and a "sievec" in my mail folder, and the "sieve" variable in dovecot.conf (1.0.3) is set to /var/mail/%d/%u/sieve (The filename specified should be the script source, not the compiled version, correct?).

I receive no errors from deliver using this method - but no evidence that the script is being followed, either. I thought I'd start with something simple - when that didn't work I added a global fileinto directive - still not doing anything. Do I need to set execute permissions or turn off world-readable permissions on the script or compiled version?

require ["fileinto"]; if header :contains ["From","To"] ["root@amfes.com","root@amfeslan.local"] { fileinto "System-Messages"; } fileinto "System-Messages";

-- Daniel

pod wrote:

...

...

...

...

...

"DM" == Daniel L Miller dmiller@amfes.com writes:

DM> I've tried manually compiling the script.  I now have a "sieve"
DM> and a "sievec" in my mail folder, and the "sieve" variable in
DM> dovecot.conf (1.0.3) is set to /var/mail/%d/%u/sieve (The filename
DM> specified should be the script source, not the compiled version,
DM> correct?).

DM> I receive no errors from deliver using this method - but no
DM> evidence that the script is being followed, either.  I thought I'd
DM> start with something simple - when that didn't work I added a
DM> global fileinto directive - still not doing anything.  Do I need
DM> to set execute permissions or turn off world-readable permissions
DM> on the script or compiled version?

Create the following config file or something similar:

log_path = /dev/stderr info_log_path = /dev/stderr

mail_debug = yes mail_location = maildir:%h/tmp/Maildir

protocol lda { postmaster_address = postmaster@example.org mail_plugins = cmusieve }

put it in, say, ~/tmp/dovecot.lda-debug.conf. Directly invoke deliver as a regular user with the -c option pointing to this config file, e.g.

user@shell$ date | /usr/libexec/dovecot/deliver -c ~/tmp/dovecot.lda-debug.conf

Observe the output.

Thank you for that extremely detailed debugging procedure. Resulting output is below:

deliver(vmail): Sep 05 13:05:28 Info: Loading modules from directory: /usr/lib/dovecot/modules/lda deliver(vmail): Sep 05 13:05:28 Info: Module loaded: /usr/lib/dovecot/modules/lda/lib90_cmusieve_plugin.so deliver(vmail): Sep 05 13:05:28 Info: maildir: data=/var/mail/amfes.com/dmiller deliver(vmail): Sep 05 13:05:28 Info: maildir: root=/var/mail/amfes.com/dmiller, index=/var/mail/amfes.com/dmiller, control=, inbox= deliver(vmail): Sep 05 13:05:28 Info: msgid=: saved mail to INBOX

Based on this, the sieve script is not being executed at all. My temp config is:

log_path = /dev/stderr info_log_path = /dev/stderr mail_debug = yes mail_location = maildir:/var/mail/amfes.com/dmiller protocol lda { postmaster_address = postmaster@amfes.com mail_plugins = cmusieve sieve = /var/mail/%d/%u/sieve }

I did make a discovery - hardcoding the sieve path, without variables, e.g. sieve = /var/mail/amfes.com/dmiller/sieve - worked!

Is there a problem using the domain / user variables in the configuration file?

DM> require ["fileinto"];
DM> if header :contains ["From","To"] ["root@amfes.com","root@amfeslan.local"] {
DM>   fileinto "System-Messages";
DM> }
DM> fileinto "System-Messages";

I think you ought to consider using an ADDRESS test rather than a HEADER test for this sort of match, thus

if address :is :all ["from", "to"] ["root@amfes.com", "root@amfeslan.local"] { # ... etc }

which will do proper address matching (i.e. phrase or comment parts in headers won't match) against a reasonable set of sender and recipient headers (for example a CC header).

I appreciate the assistance with the script as well - I obviously need to learn the sieve language.

-- Daniel

Thanks to everybody who chipped in. I came up with a workaround that seems fairly simple - I'm actually worried that it's working too well!

I'm using a pure virtual user setup, storing a minimal amount in LDAP.
The whole mail tree is stored under /var/mail, and it's all owned by vmail.mail. For purely selfish reasons, I'm doing everything possible to avoid storing the mail folder in LDAP. So I came up with the following:

Postfix is capable of generating the mail folder path via LDAP manipulation, and I was working on some wrapper scripts for delivery agents - but since I've now totally converted to Dovecot's deliver agent that's immaterial.

passdb ldap, just looking up the password. userdb static { args = uid=5000 gid=8 home=/var/mail/%d/%n mail=/var/mail/%d/%n allow_all_users=yes } plugin { sieve = sieve }

Deliver + sieve is working great. By setting the sieve variable to "sieve", a non-hidden file, it doesn't appear in the folder list. I made a similar change to pysieved to use a non-hidden folder - in combination with avelsieve and squirrelmail I now have a user-maintainable server-side filter solution. Awesome!

Is there a hidden "gotcha" I'm missing here? It's doing exactly what I want!

P.S. what's the "nice" parameter that can be listed in args?

-- Daniel A spam trap for your crawler pleasure: listpost@amfes.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Fri, 7 Sep 2007, Geert Hendrickx wrote:

Other meta-data, like .dovecot.lda-dupes (autoreplied senders db for the vacation plugin) will still be visible as (corrupted) mailfolders in IMAP.

There was some mail from Timo about this topic, that it is a bad idea to have home==maildir.

I'd try sort of:

userdb static { args = uid=5000 gid=8 home=/var/mail/%d/%n/home mail=/var/mail/%d/%n allow_all_users=yes }

As far as I know, there is no need (just habbit) to have the Maildir located below/in home.

Bye,

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRuEXSC9SORjhbDpvAQKE3Qf/VejI8j8H2byWv7uy6col0H11Z/FTMD9Z smtgqJHjzPNbXHOgCINRfr56SnygChs2hqyPNkk0C3ei30uPzcnZwG/GmM42GaWR N/om4Rp92HcRSyOrWwTBH+HgkeR94uEWq7qvPoz+mOrgBkSAdMU36DkVgpbBktNB XA9vsOFvGqEsNlcgywHawN4MqxXjadIUdYDU6HV1gjbVvCT75NVsVIE0IFDtcIcY 2RShXD/u5K0eJr96Gy779g/yn5vieUGH/F8NNwkz4zZbGzusMRMbng/lSmdkf0g1 5ehvxWIXQ46au8s7fB27IMZJb8IUGaCl+LV826LJVVamgj1T2zmnEw== =EpPP -----END PGP SIGNATURE-----

Nils Vogels wrote:

Daniel L. Miller wrote on 7-9-2007 2:24:

...

userdb static { args = uid=5000 gid=8 home=/var/mail/%d/%n mail=/var/mail/%d/%n allow_all_users=yes } plugin { sieve = sieve }

Deliver + sieve is working great. By setting the sieve variable to "sieve", a non-hidden file, it doesn't appear in the folder list. I made a similar change to pysieved to use a non-hidden folder - in combination with avelsieve and squirrelmail I now have a user-maintainable server-side filter solution. Awesome!

Is there a hidden "gotcha" I'm missing here? It's doing exactly what I want!

Everything that would for some reason go into the users homedir, you would be able to reach via Imap.

If I were you, I'd make home and mail point to a different directory, which could be as simple as home=/var/mail/%d/%n mail=/var/mail/%d/%n/Maildir. This way, dovecot will only look for mail in the $HOME/Maildir, but still can do administrative stuff in $HOME.

Grts,

Nils

What "administrative stuff"? These directories are used exclusively for mail - if any user actually has a local account their home folders are located under "/home" - but I don't want that mixed with mail service at all.

-- Daniel

On Fri, 2007-09-07 at 12:26 -0700, Daniel L. Miller wrote:

...

If I were you, I'd make home and mail point to a different directory, which could be as simple as home=/var/mail/%d/%n mail=/var/mail/%d/%n/Maildir. This way, dovecot will only look for mail in the $HOME/Maildir, but still can do administrative stuff in $HOME.

What "administrative stuff"?

Currently sieve scripts, in future possibly some other files. Don't think "home" as a traditional user's home directory, but rather as a directory where Dovecot can safely create whatever files it wants without having them show up as mailboxes to user.