[Dovecot] Annoying "feature" in dovecot/pidgeonhole - include depth limitation
Hi all,
I'm using dovecot 2.0.14 build on Debian.
The maintainers obviously patch the dovecot source so that it uses the pidgeonhole sieve system.
Today I ran into a very annoying issue: I created several sieve scripts and interlinked via the include command, only to find dovecot spewing this error message at me: SWREG Newsletter: line 14: error: cannot nest includes deeper than 10 levels.
As far as I could see this limitation is hardcoded to a depth of 10 and can only be changed at compile time.
Why is it in place? I understand that you CAN create loops via the include command and limiting the inclusion depth is a way to circumvent loops - but ten is a very low value and the fact that you can't change it via a config file or sorta is even worse.
My "fix" so far has been ignoring this, i.e. not returning false. I'm pretty sure that's not the best way to do it but it seems to be working so far.
I'd really like to hear your opinion on this issue.
Best regards,
Mihai **
On 9/10/2011 4:36 AM, Mihai Moldovan wrote:
Hi all,
I'm using dovecot 2.0.14 build on Debian.
The maintainers obviously patch the dovecot source so that it uses the pidgeonhole sieve system.
Today I ran into a very annoying issue: I created several sieve scripts and interlinked via the include command, only to find dovecot spewing this error message at me: SWREG Newsletter: line 14: error: cannot nest includes deeper than 10 levels.
As far as I could see this limitation is hardcoded to a depth of 10 and can only be changed at compile time.
Yes, it is.
Why is it in place? I understand that you CAN create loops via the include command and limiting the inclusion depth is a way to circumvent loops - but ten is a very low value and the fact that you can't change it via a config file or sorta is even worse.
True. This is one of those typical 'this aught to be enough for every one' issues. Up until now, this was true :)
My "fix" so far has been ignoring this, i.e. not returning false. I'm pretty sure that's not the best way to do it but it seems to be working so far.
I'd really like to hear your opinion on this issue.
I've made the limits for the include extension configurable now. This will be included in the next release.
Regards,
Stephan.
On 11.9.2011, at 13.01, Stephan Bosch wrote:
I've made the limits for the include extension configurable now. This will be included in the next release.
Is there really a need for such a limit? Isn't it mainly to avoid infinite loops, which could also be detected by seeing if there are any actual include loops?
On 9/11/2011 12:07 PM, Timo Sirainen wrote:
On 11.9.2011, at 13.01, Stephan Bosch wrote:
I've made the limits for the include extension configurable now. This will be included in the next release. Is there really a need for such a limit? Isn't it mainly to avoid infinite loops, which could also be detected by seeing if there are any actual include loops?
The detection of actual include loops is already in place, so the depth limit could be a bit of overkill indeed. The existence of this limit probably has something to do with the fact that code generation for the include extension is still a recursive process (whereas runtime interpretation is not). This means that (very) deep nesting could cause stack overflow at compile time. Once the include extension goes RFC I'll fix this along with implementing the new :optional tag.
Regards,
Stephan.
participants (3)
-
Mihai Moldovan
-
Stephan Bosch
-
Timo Sirainen