[Dovecot] Pigeonhole feature request: automatically copy sieve_global_path (default script) to user's sieve_dir
We have used the great managesieve you have merged together, with sieve, to create pigeonhole. However, when a user creates a custom script through a GUI of ours, the default, as we expected, would be ignored. Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings.
Maybe, in the future, you can do, just like the master auth for logging into users' imap accounts, you could have the master=yes allow login to each user's managesieve.
Just some suggestions but, until a new feature comes around, I will have a cron job or a imap-login script do the trick. Timo has said that you are a separate developer from dovecot. I just want to thank you for the great job on sieve as well,
Kudos,
Jerrale G
--
Jerrale G. SC Senior Admin
On 12.10.2010 06:47, Jerrale G wrote:
Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings.
sieve_before and/or sieve_after should be enough: http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration
Why do you need an extra setting? I am not sure I follow.
This way the administrators can create a skeleton directory and the users can retain the default skeleton settings.
You can already do this in your user creation script.
Eray
On 10/12/2010 2:55 AM, Eray Aslan wrote:
On 12.10.2010 06:47, Jerrale G wrote:
Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. sieve_before and/or sieve_after should be enough: http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration
Why do you need an extra setting? I am not sure I follow.
This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. You can already do this in your user creation script.
sieve_before and sieve_after is close to what I'm referring to but it allows one script to be specified, correct? I'm talking that, when a user first logs into their imap, all scripts in the sieve_global_dir be copied to the sieve_dir of the user so that they can see what filters are automatically specified for them, like moving spam to the spam folder, and choose to keep them or not. If us admins specify a sieve_global_path, it is ignored when a user creates their own, through the GUI we've given them. It would be nice for, when a user logs into their managesieve the first time, an option to automatically copy either the sieve_global_dir= scripts or the ONE sieve_global_path to the user's own directory to exist. This way they can see what we specified for them and they don't have to worry about " why aren't my spams not going into my spam folder anymore" after they create their first script.
We have a lot of users liking both you and Timo's programming, along with other programmers of dovecot but they all ask the same question, even when it is specified in the GUI "once you create your first filter, our filters will not be in effect anymore and, to keep them in effect, you must create them yourself". I know this should be facile if they are able to create their first filter, as they know what they want.
Pigeonhole would be even nicer with a "skelton directory" specified to copy a user's scripts from it, to their sieve_dir folder, on the user's first login of managesieve.
Thanks for the reply,
Jerrale G. SC Senior Admin
On 10/12/2010 11:16 AM, Jerrale G wrote:
On 10/12/2010 2:55 AM, Eray Aslan wrote:
On 12.10.2010 06:47, Jerrale G wrote:
Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. sieve_before and/or sieve_after should be enough: http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration
Why do you need an extra setting? I am not sure I follow.
This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. You can already do this in your user creation script.
sieve_before and sieve_after is close to what I'm referring to but it allows one script to be specified, correct? I'm talking that, when a user first logs into their imap, all scripts in the sieve_global_dir be copied to the sieve_dir of the user so that they can see what filters are automatically specified for them, like moving spam to the spam folder, and choose to keep them or not. If us admins specify a sieve_global_path, it is ignored when a user creates their own, through the GUI we've given them. It would be nice for, when a user logs into their managesieve the first time, an option to automatically copy either the sieve_global_dir= scripts or the ONE sieve_global_path to the user's own directory to exist. This way they can see what we specified for them and they don't have to worry about " why aren't my spams not going into my spam folder anymore" after they create their first script.
We have a lot of users liking both you and Timo's programming, along with other programmers of dovecot but they all ask the same question, even when it is specified in the GUI "once you create your first filter, our filters will not be in effect anymore and, to keep them in effect, you must create them yourself". I know this should be facile if they are able to create their first filter, as they know what they want.
Pigeonhole would be even nicer with a "skelton directory" specified to copy a user's scripts from it, to their sieve_dir folder, on the user's first login of managesieve.
Thanks for the reply,
Jerrale G. SC Senior Admin
Here is my current sieve config: sieve_dir = /home/mail/%d/%n/sieve sieve_global_dir = /home/mail/sieve sieve_global_path = /home/mail/sieve/global.sieve
The global.sieve is the default if a user doesn't create a filter.
Jerrale G. SC Senior Admin
On 12.10.2010 18:16, Jerrale G wrote:
We have a lot of users liking both you
It's not me but Stephan Bosch you are looking for. Sorry for the misunderstanding.
Pigeonhole would be even nicer with a "skelton directory" specified to copy a user's scripts from it, to their sieve_dir folder, on the user's first login of managesieve.
Just place the default sieve script in $sieve_dir when creating the user, chown to user and you are done.
-- Eray
On 10/12/2010 1:07 PM, Eray Aslan wrote:
On 12.10.2010 18:16, Jerrale G wrote:
We have a lot of users liking both you It's not me but Stephan Bosch you are looking for. Sorry for the misunderstanding.
Pigeonhole would be even nicer with a "skelton directory" specified to copy a user's scripts from it, to their sieve_dir folder, on the user's first login of managesieve. Just place the default sieve script in $sieve_dir when creating the user, chown to user and you are done.
Ok, I figure I will just keep using the script we are using but I was referring to automation when other admins who do not know much about programming, the ones that just maintain accounts in the GUI we have, add new accounts.
Thanks,
Jerrale G. SC Senior Admin
Op 12-10-2010 5:47, Jerrale G schreef:
We have used the great managesieve you have merged together, with sieve, to create pigeonhole. However, when a user creates a custom script through a GUI of ours, the default, as we expected, would be ignored. Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. You could put the sieve directory with the default script in your skeleton. I'm not sure though what you need exactly.
Maybe, in the future, you can do, just like the master auth for logging into users' imap accounts, you could have the master=yes allow login to each user's managesieve.
Haven't tested, but this should already work for ManageSieve I believe.
Just some suggestions but, until a new feature comes around, I will have a cron job or a imap-login script do the trick.
Well, post-login scripting should also work for ManageSieve:
http://wiki2.dovecot.org/PostLoginScripting
Regards,
Stephan.
On 13/10/2010 08:43, Stephan Bosch wrote:
Op 12-10-2010 5:47, Jerrale G schreef:
We have used the great managesieve you have merged together, with sieve, to create pigeonhole. However, when a user creates a custom script through a GUI of ours, the default, as we expected, would be ignored. Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. You could put the sieve directory with the default script in your skeleton. I'm not sure though what you need exactly.
I think that's his point - how to do this economically with many users?
What if you want to update the global script later?
I think all the replies so far misunderstand what he is saying. I think he is describing a situation where he has say a slightly more than trivial default script in the global directory, which takes effect when the user has no "per user" script set. His problem is as soon as the user creates their own "per user" script then the global script stops being used. He might desire to say provide a standardised: Spam, Out of office, etc set of filters, PLUS allow the user to add their own filters
- if later he wants to update the "standardised default script" for all users then this gets complex using some of the possible solutions (eg copying into the skel)
So he is making the case that the user innocently adds one extra tiny feature to the default config of his mailserver, but at that point all the normal functionality also stops working... User is baffled, places support call to find that they really need to create a much more complex per user script including all the (previously) default stuff?
Perhaps a workaround for his situation is for the global script to include the per-user script? Does pigeon hole allow for this? In this way the global script can run and then pass control over to the user created script if it exists?
Ed W
On 14/10/10 10:32, Ed W wrote:
On 13/10/2010 08:43, Stephan Bosch wrote:
Op 12-10-2010 5:47, Jerrale G schreef:
We have used the great managesieve you have merged together, with sieve, to create pigeonhole. However, when a user creates a custom script through a GUI of ours, the default, as we expected, would be ignored. Maybe you could add a retain_sieve_global=yes|no setting OR be more complex by having the sieve_global_dir copied to the users sieve_dir on first managesieve script save, if another setting to do this was set to yes. This way the administrators can create a skeleton directory and the users can retain the default skeleton settings. You could put the sieve directory with the default script in your skeleton. I'm not sure though what you need exactly.
I think that's his point - how to do this economically with many users? What if you want to update the global script later?
I think all the replies so far misunderstand what he is saying. I think he is describing a situation where he has say a slightly more than trivial default script in the global directory, which takes effect when the user has no "per user" script set. His problem is as soon as the user creates their own "per user" script then the global script stops being used. He might desire to say provide a standardised: Spam, Out of office, etc set of filters, PLUS allow the user to add their own filters
- if later he wants to update the "standardised default script" for all users then this gets complex using some of the possible solutions (eg copying into the skel)
So he is making the case that the user innocently adds one extra tiny feature to the default config of his mailserver, but at that point all the normal functionality also stops working... User is baffled, places support call to find that they really need to create a much more complex per user script including all the (previously) default stuff?
Perhaps a workaround for his situation is for the global script to include the per-user script? Does pigeon hole allow for this? In this way the global script can run and then pass control over to the user created script if it exists?
Ed W
I solved this by:
sieve_global_dir=/etc/dovecot/sieve.d/
In file /etc/dovecot/sieve.d/global-spam.sieve, add your fancy stuff. Then, create for each user (and in the /etc/skel/ dir) a new default sieve file with content:
============== require ["include"];
# Everytime you remove this line, god kills a kitten include :global "global-spam.sieve";
# Add your own stuff here
The user can still shoot himself in the foot, but can add stuff to his own sieve file without killing all your hard work.
-- Regards, Tom
On 14/10/2010 09:48, Tom Hendrikx wrote:
# Everytime you remove this line, god kills a kitten include :global "global-spam.sieve";
My suggestion was to do the reverse of this, ie have the global script include the local script - does that work also? The use case there would be if you didn't want the user to be able to remove the default script from running?
Cheers
Ed W
On 14/10/10 10:58, Ed W wrote:
On 14/10/2010 09:48, Tom Hendrikx wrote:
# Everytime you remove this line, god kills a kitten include :global "global-spam.sieve";
My suggestion was to do the reverse of this, ie have the global script include the local script - does that work also?
Including a local script from a global one is not possible because the script is precompiled, and there is only one global precompiled script for all users.
The use case there would be if you didn't want the user to be able to remove the default script from running?
This is what sieve_before is all about. Earlier in the thread, sieve_before is being rejected as a solution, but i'm not sure why it isn't applicable here. If your users complain that they cannot see how their mails are processed by the global configuration, then educate them (i.e. publish the global script on your intranet for their eyes to see).
-- Tom
participants (5)
-
Ed W
-
Eray Aslan
-
Jerrale G
-
Stephan Bosch
-
Tom Hendrikx