Deleting an active sieve script leaves sieve unfunctional
Dear devs,
I noticed this using Dovecot 2.3.7.2, set up on a newly created Ubuntu 20.04 server.
If I delete a sieve script via KMail's managesieve interface, and the script is active, it leaves sieve unfunctional afterwards.
What's happening is this:
Dovecot creates a USER.sieve script containing all active scripts, e. g.:
require ["include"];
include :personal "some-script";
include :personal "some-other-script";Now if I delete "some-script", it's actually deleted, but USER.sieve is not updated (and still contains 'include :personal "some-script";').
So next time an email is filtered, this happens:
mail log:
Jul 5 15:20:01 server dovecot: lda(user@domain)<123456>
<xxxxxxxxxxxxxxxxxxxxxx>: sieve: Failed to compile script
`/srv/sieve/user@domain/active-script.sieve' (view user logfile
`/srv/sieve/user@domain/active-script.sieve.log' for more information)active-script.sieve.log:
sieve: info: started log at Jul 05 14:57:54.
USER: line 12: error: included personal script 'some_script' does not
exist.
USER: error: validation failed.So, to avoid this, one has to FIRST deactivate the respectice script, so that USER.sieve is updated and THEN delete the script. Or to manually fix USER.sieve on the server, which is surely not what's intended.
So the question is now: Is this a KMail bug, a Doveceot bug, or is the server misconfigured?!
Thanks for all help!
Cheers, Tobias
On 07-05-2021 10:29 am, Tobias Leupold wrote:
So, to avoid this, one has to FIRST deactivate the respectice script, so that USER.sieve is updated and THEN delete the script. Or to manually fix USER.sieve on the server, which is surely not what's intended.
Curious, can you also fix the situation by just removing the symlink pointing to the non existent script?
There's no symlink pointing to that very script. I have virtual users, so I keep the respective sieve scripts in /srv/sieve/user@domain/.
Such a directory looks like that:
active-script.sieve -> USER.sieve
USER.sieve
some-script.sieve
some-other-script.sieve
...Where USER.sieve is the generated file which includes the activated scripts:
# USER Management Script
#
# This script includes the various active sieve scripts
# it is AUTOMATICALLY GENERATED. DO NOT EDIT MANUALLY!
#
# For more information, see http://wiki.kolab.org/KEP:14#USER
#
require ["include"];
include :personal "some-script";
include :personal "some-other-script";Am Montag, 5. Juli 2021, 18:46:30 CEST schrieb dovecot@ptld.com:
On 07-05-2021 10:29 am, Tobias Leupold wrote:
So, to avoid this, one has to FIRST deactivate the respectice script, so that USER.sieve is updated and THEN delete the script. Or to manually fix USER.sieve on the server, which is surely not what's intended.
Curious, can you also fix the situation by just removing the symlink pointing to the non existent script?
There's no symlink pointing to that very script. I have virtual users, so I keep the respective sieve scripts in /srv/sieve/user@domain/.
Such a directory looks like that:
active-script.sieve -> USER.sieve
USER.sieve
some-script.sieve
some-other-script.sieve
...Where USER.sieve is the generated file which includes the activated scripts:
# USER Management Script
#
# This script includes the various active sieve scripts
# it is AUTOMATICALLY GENERATED. DO NOT EDIT MANUALLY!
#
# For more information, see http://wiki.kolab.org/KEP:14#USER
#
require ["include"];
include :personal "some-script";
include :personal "some-other-script";Am Montag, 5. Juli 2021, 18:46:30 CEST schrieb dovecot@ptld.com:
On 07-05-2021 10:29 am, Tobias Leupold wrote:
So, to avoid this, one has to FIRST deactivate the respectice script, so that USER.sieve is updated and THEN delete the script. Or to manually fix USER.sieve on the server, which is surely not what's intended.
Curious, can you also fix the situation by just removing the symlink pointing to the non existent script?
On 07-05-2021 1:04 pm, Tobias Leupold wrote: There's no symlink pointing to that very script. I have virtual users, so I keep the respective sieve scripts in /srv/sieve/user@domain/.
Such a directory looks like that:
active-script.sieve -> USER.sieve USER.sieve some-script.sieve some-other-script.sieve
Yes, that is the one im talking about: active-script.sieve Just remove that symlink and sieve will be disabled for that user and you shouldn't have any errors.
Yes, that is the one im talking about: active-script.sieve Just remove that symlink and sieve will be disabled for that user and you shouldn't have any errors.
Yeah, of course I won't -- but sieve filtering won't work as well without the symlink ...
Am Montag, 5. Juli 2021, 19:27:50 CEST schrieb dovecot@ptld.com:
On 07-05-2021 1:04 pm, Tobias Leupold wrote: There's no symlink pointing to that very script. I have virtual users, so I keep the respective sieve scripts in /srv/sieve/user@domain/.
Such a directory looks like that: active-script.sieve -> USER.sieve USER.sieve some-script.sieve some-other-script.sieve
On 07-05-2021 1:34 pm, Tobias Leupold wrote:
Yes, that is the one im talking about: active-script.sieve Just remove that symlink and sieve will be disabled for that user and you shouldn't have any errors.
Yeah, of course I won't -- but sieve filtering won't work as well without the symlink ...
Maybe im misunderstanding what answer you are looking for. Ofcourse sieve wont work without the symlink, that's the point. That is how you disable it. To prevent errors generated by a missing / corrupt script.
Then when you want to use sieve again, create a proper script and enable it, which will autocreate the symlink again.
Okay, I'll try to explain it better ;-)
What I would expect is:
When I delete a sieve script via the managesieve interface of KMail, I would expect that this script is removed from the USER.sieve script so that it's no longer included and not run anymore. Then, it should be deleted.
What happens is:
The script is deleted, but USER.sieve is unchanged and still tries to include it. This leads to a compile error when the next filtering is done.
IMO this simply should not happen: After deleting a script, sieve should simply continue to work -- without the script. But what I actually have to do is that I disable the script, so that USER.sieve doesn't include it anymore and then delete it.
So the question is if KMail should do this automatically (and thus it's a KMail bug) or if Dovecot doesn't act properly (and thus it's a Dovecot bug) -- or if this is a config issue caused by me not being able to setup dovecot properly :-D
I simply think that deleting a sieve script via a managesieve interface should not make the filtering crash and make it necessary to fix this manually ...
Am Montag, 5. Juli 2021, 19:45:37 CEST schrieb dovecot@ptld.com:
On 07-05-2021 1:34 pm, Tobias Leupold wrote:
Yes, that is the one im talking about: active-script.sieve Just remove that symlink and sieve will be disabled for that user and you shouldn't have any errors.
Yeah, of course I won't -- but sieve filtering won't work as well without the symlink ...
Maybe im misunderstanding what answer you are looking for. Ofcourse sieve wont work without the symlink, that's the point. That is how you disable it. To prevent errors generated by a missing / corrupt script.
Then when you want to use sieve again, create a proper script and enable it, which will autocreate the symlink again.
On 07-05-2021 2:04 pm, Tobias Leupold wrote:
When I delete a sieve script via the managesieve interface of KMail, I would expect that this script is removed from the USER.sieve script so that it's no longer included and not run anymore. Then, it should be deleted.
As far as sieve is concerned, USER.sieve is the script, still exist and is still active.
Sounds like all you have done is removed a required component of the script being an include file. Sieve doesn't know this, all it knows is USER.sieve is the script, and its active, so it runs it, which fails cause as you know, missing an include file.
The issue is that you have a corrupted sieve script (USER.sieve). I would not consider this a sieve issue. I would consider this a poor design by the makers of whatever control panel you using to update your includes as it should rebuild the script after making such changes. I think your language choice could be confusing, you aren't deleting "a script". You are deleting an include file for "the script" being USER.sieve.
My educated guess is, yes this is a KMail issue.
My educated guess is, yes this is a KMail issue.
Okay, thanks :-) I'll file a bug report there.
Am Montag, 5. Juli 2021, 21:30:54 CEST schrieb dovecot@ptld.com:
On 07-05-2021 2:04 pm, Tobias Leupold wrote:
When I delete a sieve script via the managesieve interface of KMail, I would expect that this script is removed from the USER.sieve script so that it's no longer included and not run anymore. Then, it should be deleted.
As far as sieve is concerned, USER.sieve is the script, still exist and is still active.
Sounds like all you have done is removed a required component of the script being an include file. Sieve doesn't know this, all it knows is USER.sieve is the script, and its active, so it runs it, which fails cause as you know, missing an include file.
The issue is that you have a corrupted sieve script (USER.sieve). I would not consider this a sieve issue. I would consider this a poor design by the makers of whatever control panel you using to update your includes as it should rebuild the script after making such changes. I think your language choice could be confusing, you aren't deleting "a script". You are deleting an include file for "the script" being USER.sieve.
On 2021-07-05 16:29, Tobias Leupold wrote:
So the question is now: Is this a KMail bug, a Doveceot bug, or is the server misconfigured?!
in roundcube one would create another filter-set, with no filter-rules in, then one set the filter-set with no rules in to be default, this will disable sieve, reason is that it must always be atleast one filter-set active, but its not required to have rules in a filter set
hope this works
Well, my workaround for KMail is to simply disable the script to delete before deleting it. This way, it's removed from the auto-generated USER.sieve (where active-script.sieve points to) and it's no problem when the file is actually deleted.
Question is if KMail should do this automatically, or if Dovecot should remove a script to delete from USER.sieve before deleting it. Or if I did something wrong configuring Dovecot ;-)
Am Montag, 5. Juli 2021, 18:58:15 CEST schrieb Benny Pedersen:
On 2021-07-05 16:29, Tobias Leupold wrote:
So the question is now: Is this a KMail bug, a Doveceot bug, or is the server misconfigured?!
in roundcube one would create another filter-set, with no filter-rules in, then one set the filter-set with no rules in to be default, this will disable sieve, reason is that it must always be atleast one filter-set active, but its not required to have rules in a filter set
hope this works
On 2021-07-05 10:29 a.m., Tobias Leupold wrote:
require ["include"]; include :personal "some-script"; include :personal "some-other-script";
Now if I delete "some-script", it's actually deleted, but USER.sieve is not updated (and still contains 'include :personal "some-script";').
active-script.sieve.log:
sieve: info: started log at Jul 05 14:57:54. USER: line 12: error: included personal script 'some_script' does not exist. USER: error: validation failed.
So the question is now: Is this a KMail bug, a Doveceot bug, or is the server misconfigured?!
IMHO the client (KMail) should take care of it. Perhaps it could also add the "optional" flag in the "include" statement
include :personal :optional "some-script";
https://datatracker.ietf.org/doc/html/rfc6609
3.2. Control Structure "include"
Usage: include [LOCATION] [":once"] [":optional"] <value: string> LOCATION = ":personal" / ":global"
The ":optional" parameter indicates that the script may be missing. Ordinarily, an implementation MUST generate an error during execution if an "include" command specifies a script that does not exist. When ":optional" is specified, implementations MUST NOT generate an error for a missing script, and MUST continue as if the "include" command had not been present.
On 05/07/2021 20:47, Oscar del Rio wrote:
On 2021-07-05 10:29 a.m., Tobias Leupold wrote:
require ["include"]; include :personal "some-script"; include :personal "some-other-script";
Now if I delete "some-script", it's actually deleted, but USER.sieve is not updated (and still contains 'include :personal "some-script";').
active-script.sieve.log:
sieve: info: started log at Jul 05 14:57:54. USER: line 12: error: included personal script 'some_script' does not exist. USER: error: validation failed.
So the question is now: Is this a KMail bug, a Doveceot bug, or is the server misconfigured?!
IMHO the client (KMail) should take care of it. Perhaps it could also add the "optional" flag in the "include" statement
include :personal :optional "some-script";
Yes, this is the correct answer. Dovecot is doing nothing wrong here.
3.2. Control Structure "include"
Usage: include [LOCATION] [":once"] [":optional"] <value: string> LOCATION = ":personal" / ":global"
The ":optional" parameter indicates that the script may be missing. Ordinarily, an implementation MUST generate an error during execution if an "include" command specifies a script that does not exist. When ":optional" is specified, implementations MUST NOT generate an error for a missing script, and MUST continue as if the "include" command had not been present.
participants (6)
-
Benny Pedersen
-
dovecot＠ptld.com
-
Oscar del Rio
-
Stephan Bosch
-
Tobias Leupold
-
Tobias Leupold