Dovecot managesieved not activated

I noticed this also. And would like to have this fixed!

Agreed, this sohuld be included in the installer and also covered by the how-tos - if should'nt be already yet...

In looking at an ispconfig 3.1 server, I see symlinks /var/vmail/domain/user/.sieve -> sieve/ispconfig.sieve - is this ticket resolved?

Testing this out I find no, this is still not resolved; on latest 3.1.1, sieve is still not added to protocols, you must create a conf-custom file to enable managesieve.

What is needed to implement this, a reliable test for whether sieve is installed or not? Maybe the presence of the managesieve loadable module (/usr/lib/dovecot/managesieve on debian) would be a good test?

+1

+1 I'm happy to help with testing!

Any further comments on appropriate tests for whether managesieve is available or not? It's not part of the perfect server tutorials (yet), of course. We could test for the dovecot-managesieved package being installed on debian, or test the presence of /usr/lib/dovecot/managesieve as previously mentioned.

If noone suggests otherwise, I'll create a test for the latter within distid 'debian60' (ie. any of the last 4 debian releases?) and it'll remain unset otherwise.

UPDATE for current ISPConfig Version (3.1.15p2):

as you already mentioned the ispconfig behavior changed a little bit, now it creates:

sieve/ispconfig.sieve

and adds the symlink:

.sieve -> sieve/ispconfig.sieve

this means even if you enable managesieved in your dovecot configuration, any changes you make to the ruleset ispconfig.sieve will overwritten/messed up whenever ispconfig writes its configuration based on the mysql-data. if you create your own custom ruleset eg. custom.sieve and activate it (this changes the symlink to .sieve -> sieve/custom.sieve, next time ispconfig writes its config (eg. if you activate the autoresonder or change a filter within ispconfig), the symlink will be changed back to the ispconfig.sieve-ruleset.

the only solution would be to hack:

/usr/local/ispconfig/server/plugins-available/maildeliver_plugin.inc.php

and comment out all the lines where it deletes or creates the symlink:

line nr. 102: //if(is_file($sieve_file)) unlink($sieve_file) or $app->log("Unable to delete file: $sieve_file", LOGLEVEL_WARN);

line nr. 227: //symlink("sieve/ispconfig.sieve", ".sieve") or $app->log("Unable to create symlink to active sieve filter", LOGLEVEL_WARN);

line nr.245: //if(is_file($sieve_file)) unlink($sieve_file) or $app->log("Unable to delete file: $sieve_file", LOGLEVEL_WARN);

BUT this means you cannot use the ispconfig autoresonder/filters at all, the solution to have your own ruleset AND a working ispconfig ruleset is to tell the dovecot plugin to include the ispconfig.sieve ruleset before any other ruleset:

/etc/dovecot/conf.d/99-managesieve.conf:

protocols = pop3 imap sieve

plugin {
  sieve_before = /var/vmail/%d/%n/sieve/ispconfig.sieve
}

the only problem now is, that you are still able to manipulate the ispconfig.sieve-ruleset outside of ispconfig, which can still lead to the above mentioned problems, but if you never touch ispconfig.sieve outside ispconfig, it should work as expected with this setup, you have both, the ispconfig filters and your custom ruleset.

the roundcube plugin "managesieve" has a nice config option which allows you to hide scripts, so if you add this:

roundcube/plugins/managesieve/config.inc.php

// List of reserved script names (without extension).
// Scripts listed here will be not presented to the user.
$config['managesieve_filename_exceptions'] = array('ispconfig');

the ispconfig ruleset will be hidden, and there is no chance for roundcube-users to mess things up.

--

well, hacking ispconfig source files is not best practice.

if we would have a config-option to turn of the .sieve-symlink like "Manage .sieve Symlink Yes/No" it would be easy to change the above lines to take this into account, that would be awesome. it could be a default-yes-option, with a warning "only change this if you know what you are doing".

following the perfect setup + adding dovecot-managesieved + some little configurationchange in dovecot + roundcube plugin managesieve would get you the full power of sieve filters.

what dou you think, did i miss something?

edit

in this setup the existing .sieve -> sieve/ispconfig.sieve symlinks are obsolete, and can be safely removed by:

find /var/vmail -lname sieve/ispconfig.sieve -exec rm {} \;

if you keep the symlink, the roundcube plugin will show the ispconfig rules, even if you tell it not to show the ispconfig.sieve ruleset, again it would be easy to mess things up.

if there is no symlink, next time you access the filters in roundcube, it will automatically create an empty roundcube.sieve ruleset and activate it by adding the symlink .sieve -> sieve/roundcube.sieve.

if you enable managesieved in your dovecot configuration, any changes you make to the ruleset ispconfig.sieve will overwritten/messed up whenever ispconfig writes its configuration based on the mysql-data. if you create your own custom ruleset eg. custom.sieve and activate it (this changes the symlink to .sieve -> sieve/custom.sieve, next time ispconfig writes its config (eg. if you activate the autoresonder or change a filter within ispconfig), the symlink will be changed back to the ispconfig.sieve-ruleset.

Yes, in general you can't user multiple filter management systems if any of them try to take full management of the filters. That's the same as my old system (DTC panel) where I had both squirrelmail and roundcube installed - either one could manage the filters, but you couldn't use both of them. My initial take on this was similar, that you either user ISPConfig to manage the filters or use roundcube, but don't try to use both. But it's surely worth considering ideas on how it might be made to be compatible.

tell the dovecot plugin to include the ispconfig.sieve ruleset before any other ruleset:

/etc/dovecot/conf.d/99-managesieve.conf:
protocols = pop3 imap sieve

plugin {
  sieve_before = /var/vmail/%d/%n/sieve/ispconfig.sieve
}
the only problem now is, that you are still able to manipulate the ispconfig.sieve-ruleset outside of ispconfig, which can still lead to the above mentioned problems

I wonder (and might experiment to find out) if you could simply put all the ispconfig.sieve files in a directory structure that's not the server sieve script path, eg. /usr/local/ispconfig/server/sieve-scripts/%d/%n/ispconfig.sieve. Would that 1) allow sieve_before to be used there, 2) not error if/when that ispconfig.sieve script is not found, 3) allow users to manage their own scripts through managesieve (eg. roundcube), and 4) not show up "ispconfig" as a manageable script ?

I could see sometimes when you'd want/need to use sieve_after rather than sieve_before. If you implement a custom sieve script, you should be able to let the message pass through to the default filter if needed, so my first thought is the simplicity of a single sieve_after might outweigh the effort it would take to try to implement in the ui wether each filter rule, autoresponder and "move spam to Junk folder" setting should be "before" or "after".

And a second idea to kick around, one sieve script can include another; it might be possible to have an "ispconfig.sieve" script (maybe created with immutable attribute if you don't want users to be able to edit it via managesieve .. I don't know how big an issue that really is?), which has effectively include "custom-early then all the filter rules / auto responder / spam to Junk, and then include "custom-late". You might have to create empty custom-early.sieve and custom-late.sieve files. But that should put enough pieces in place for users to either edit "custom-early" and/or "custom-late" via roundcube to tie in wherever they need to relative to ISPConfig's rules.

some really good thoughts!

my proposal above was just ment to be a quick fix to get what i want, KISS.

i have read that V3.2 will drop courier support and ispconfig will stick to dovecot. this could be a chance to implement a solid managesieve implementation.

maybe it would be the best to have some global configuration options, e.g. if you want to use the ispconfig-rules as "before" or "after" (=> no symlink) and to set the path for the ispconfig-sievescript (e.g. /var/vmail/%d/%u should be sufficient, could be set automatically as default if before/after is set).

i am not sure how "include two scripts" editable via roundcube could work, because what you see in roundcube are rulesets (scriptfiles) and only one of them can be active at a time, the one which is linked to ../.sieve. whenever you set a ruleset (file) as "active", sieve will change the symlink to the active script. if you include those files in the ispconfig-sieve-script which is set as before or after, an activated and included custom-early/custom-late filterset will be used twice.

FWIW I'm testing this right now and seems like it should work just fine:

plugin {
  quota = dict:user::file:/var/vmail/%d/%n/.quotausage
  sieve=/var/vmail/%d/%n/.sieve
  sieve_after=/etc/dovecot/sieve-scripts/%d/%n/ispconfig-after.sieve
  sieve_max_script_size = 2M
  sieve_max_actions = 100
  sieve_max_redirects = 25
}

It would be simple to have ISPConfig's current code change the location of the sieve script it generates to match that, and should be quite flexible. If users do nothing, they get the ISPConfig-generated script. If they want to do some filtering, it happens ahead of ISPConfig's script, so the user has full control (they can do whatever they want, and anything that isn't handled with a "stop;" will fall through to ISPConfig filtering).

https://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration#Executing_Multiple_Scripts_Sequentially

https://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration#Executing_Multiple_Scripts_Sequentially

sure you can add multiple sieve_before/sieve_after scripts, and it would be easy possible to include custom-early and custom-late and make it editable in roundcube, but how would you prevent users from clicking "activate" on those scripts?

i know activating custom-early or custom-late in roundcube is stupid as they will be included anyways, but how can an ordinary user know that? they look at those rulesets in roundcube and see they are not activated. they will notice that they can activate only one of them at a time. i am sure those who do not know how this works will be somehow confused, and they will think: "if it is not activated, it will not work, but how can i activate both? it seems broken.".

what is the benefit of having those extra rulesets "surrounding" the roundcube rulset?

what can you do with it, what cannot be done within the roundcube ruleset itself?

drag&drop rules to rearrange the order already works great and should be sufficient, do i miss something?

--

sieve_after=/etc/dovecot/sieve-scripts/%d/%n/ispconfig-after.sieve

for the path of the sieve_before/after i would prefer to have it at /var/vmail/%d/%n/ispconfig-after.sieve, it would be much cleaner to have everything at one place.

how would you prevent users from clicking "activate" on those scripts?

You don't store them under /var/vmail/%d/%n/sieve/; everything there is available as a sieve script and which the user can activate (by default).

i know activating custom-early or custom-late in roundcube is stupid as they will be included anyways, but how can an ordinary user know that?

They don't need to know that if the ISPConfig created sieve script is not visible in roundcube, it simply functions if you create filters or select "move spam to junk folder."

what is the benefit of having those extra rulesets "surrounding" the roundcube rulset?

I think I would just do an "after" ruleset, not before. The benefits are that the filters users have created within ISPConfig continue to work as always; if users want to overwrite the ISPConfig behavior (eg. file to 'SPAM' instead of 'Junk') they can, or they can let it run as usual; and there's no confusion on what is the active script, because the ISPConfig created script is hidden to all managesieve clients (including roundcube).

for the path of the sieve_before/after i would prefer to have it at /var/vmail/%d/%n/ispconfig-after.sieve, it would be much cleaner to have everything at one place.

I believe that would be fine (ie. would work, and the script would not be visible in roundcube); maybe even just call it 'ispconfig.sieve' as I don't see much need for a 'before'. I'll change to this setup and test that.

I settled on /var/vmail/%d/%n/.ispconfig.sieve for the location, and can confirm it works as desired (does not display in roundcube). I'll need to dig into the "create sieve script" logic in ISPConfig and have it handle/clean up the old filename, but should be pretty straightforward.

@tbrehm just want to confirm you're good with that change? Ie. the sieve script which ISPConfig generates will change from /var/vmail/%d/%n/sieve/ispconfig.sieve to /var/vmail/%d/%n/.ispconfig.sieve (so that it doesn't show up in managesieve clients), and it will load via sieve_after in dovecot.conf. Users can then create and activate their own custom sieve script, and anything that doesn't end there (due to the user's specific instruction to do so via 'stop') falls through to the ISPConfig generated script. When ISPConfig generates a new sieve script, it will remove the old name if found (and .sieve symlink if it points to it).

fwiw, I'd guess sieve probably doesn't work in any old dovecot 1.2 installations (except debian6 and possibly fedora), judging by the config file - can anyone confirm? I'm updating dovecot2 template files, but have no dovecot 1.2 to test anything - if anyone has such a system and wants to help test there I'd be glad to do so.

In the upcoming merge request, sieve delivery should work in old dovecot 1.2 if it did previously, but managesieve will not be setup (I have not attempted to guess at a working config, and can't test it).

Ok, thats good!

@jnorell thanks for the clarification!

an inaccessible ispconfig.sieve as sieve_after in dovecot will be perfect :)

big up to you for your efforts on this long standing feature request!

mentioned in merge request !932 (merged)

mentioned in commit d9a2d355

mentioned in commit f60d97f4

mentioned in commit 1e9c3880

changed milestone to %3.2

added Implemented label

Dovecot managesieved not activated

Designs

Child items ...

Activity