|
From: SourceForge.net <no...@so...> - 2012-03-04 23:52:09
|
Feature Requests item #3496325, was opened at 2012-03-02 08:42 Message generated for change (Comment added) made by alex-j You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3496325&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Alexander (alex-j) Assigned to: Nobody/Anonymous (nobody) Summary: Drop support of Vacation in favor of SIEVE Initial Comment: I propose to drop support of "Vacation" in favor of standardized SIEVE (RFC 3028, RFC 5230, RFC 5804, RFC 5435) that support vacations auto-responder in addition to very powerful filtering mechanism. SIEVE already supported in major email's clients (Thunderbird, RoundCube, Horde and etc) and allow much more flexibility to assign Vacation response(it could be special rules to avoid respond to robots, or other auto-responders/notificators) SIEVE supported very well by well known Dovecot, Courier for a long time and actually it will be better to leave actual mail delivery to primary servers instead of custom, non standard Perl's spike. So, IMHO it would be a good step forward in 3.x development to drop custom, non standard Vacation support in favor of supporting SIEVE language. Since postfixadmin allows regular users to manage own settings, it will be good to implement in a future web based SIEVE's rules management via postfixadmin in manner as it done in INGO application from Horde framework for example that bring a lot of power to users and administrators to manage Vacation, Spam filtering, forwarding, black/white listing and much more without actual need to learn SIEVE language... ---------------------------------------------------------------------- Comment By: Alexander (alex-j) Date: 2012-03-04 15:52 Message: >How would this work with both a Global >script and is the User has created their own? It is pretty simple, first will be executed global and after that - user's script exactly on delivery. So it is up to you, as admin you can discard mail, redirect, or reject and then issue "stop" command on the end, which is mean - no further processing or in other words - do not run users script after some action. >Would the Domain Admin be able to enforce >a Global Sieve script, Yes, if you place your global script to "sieve_before" option then global script will be executed first, before users. > and users could add their own, but it would be called from the Global, No. There no such things as "calling" in Sieve. First, will be executed global and after that user's script if no "stop" command issued in a global script. >and the user would not be allowed to >override anything in the Global script? Sure. If you already discard mail for example in global script and issue "stop" command then user's script will not be executed and user will not receive any mail for processing. Users can't see source of global script and don't have any legal access to global script to be able to control mail delivery handled by global script. In dovecot for example there is parameters "sieve_before" that point to directory with global scripts that will be executed before calling user's scripts. If you need to do something after users scripts there is parameter "sieve_after". As for global scripts - there is two options that behave completely different. For example "sieve_global_path" will be executed only in case if there no users scripts, so it act as your recommended, non enforced action, but global scripts from "sieve_before" will be executed always before users and users has no choice to control mail delivery before that global script is finished. > As for where the sieve scripts are stored, > dovecot currently has excellent > sieve support when using its LDA, and it > prefers that the users sieve scripts live > in ~ (user home dir)... It just safety default settings and nothing else. We use for example: sieve = /usr/local/virtual/%Ld/%Ln/dovecot.sieve where "dovecot.sieve" is simlink to /usr/local/virtual/%Ld/%Ln/sieve directory. Since dovecot show to users only that directories where first character is "." then "sieve" directory is invisible for users and accessible only through network protocol. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2012-03-04 08:05 Message: A few questions... How would this work with both a Global script and is the User has created their own? Would the Domain Admin be able to enforce a Global Sieve script, and users could add their own, but it would be called from the Global, and the user would not be allowed to override anything in the Global script? As for where the sieve scripts are stored, dovecot currently has excellent sieve support when using its LDA, and it prefers that the users sieve scripts live in ~ (user home dir), *outside* the user mail dir (usually ~/mail)... http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration ---------------------------------------------------------------------- Comment By: Alexander (alex-j) Date: 2012-03-03 16:46 Message: @libertytrek You're absolutely right. I just wanted to say that "sieve" is much much better. @gingerdog I prepared a few screen shots taken from Horde that is self explanatory. http://www.mejuba.com/albums/Alexander_J/90865 >"Does the sieve file need writing out to disk somewhere?" No. It is the network protocol. All sieve scripts kept on server side. Global sieve script available only for server's administrators, but users scripts are located in there mailboxes as hidden directory and allowed to edit it over SIEVE protocol. I think it would be possible to fork Horde's or RoundCube's scripts that communicate over SIEVE to embeds it to postfixadmin in a future . Horde's SIEVE scripts are here: (horde//ingo/lib/Script) https://github.com/horde/horde/tree/e261dbd1eaacee9243d5230d04b9da19547dfec1/ingo/lib/Script ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2012-03-02 09:03 Message: Not to belabor the obvious, but I'm assuming this would be done by first *adding* support for sieve, then, once it is working well, provide dual support for a time, warning everyone well in advance before vacation support was removed... ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2012-03-02 09:00 Message: If this is possible, it'd obviously be a good move. I'm not sure how feasible it is to write a rool which is a wizard for a sieve file though - perhaps there could just be a number of pre-generated ones - where the user fills in some blanks or something? Does the sieve file need writing out to disk somewhere? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3496325&group_id=191583 |
