[Dovecot] libsieve problems / wishes

[Stephan Bosch]

Hi Steffen,

Steffen Kaiser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> I'm trying libsieve (853:42e154b8792e) to cope with our current 
> installation, the following issues arise:
> 
> 1) vacation addresses are compared case-sensitivly, e.g.:
> 
> vacation :addresses [ "Steffen.Kaiser at example.com" ] "";
> 
> it won't match "steffen.kaiser at ...".
Hmm, not sure whether I should change this in general. For the domain 
part, yes, it is definitely a bug if it compares case-sensitively. 
However, to my knowledge, the local part of rfc822 addresses is usually 
considered case-sensitive. I'll give this a look tonight.

I could of make the case-sensitivity of local parts configurable. Timo, 
any ideas on this?

(...)
> Attached patch adds a "domainless" variant of :addresses arguments in 
> such way, that
> 
> vacation :addresses [ "Steffen.Kaiser" ] "";
> 
> matches any domain.
> 
> Ideally, it would be better to specify all valid domains, but perhaps one
> can leave that for another approach with a different syntax, e.g. with
> "@*" as domain? Maybe, there is a better approach.
> Now there is possibility that common local parts are matched from alien
> domains easily.
> 
> If to specify a set of "default" domains would be an option for libsieve,
> what is the suggested way:
> - - as user-option via dovecot.conf?
> - - as admin-enforced Sieve-script that sets some internal variables?
> aka using the multi-script capability
> - - ???
Hmm, I need to give this some more thought. I'd rather not introduce 
non-standard behavior that some users start depending on. Sieve is 
supposed to be portable. There is usually a reason why things are 
specified as they are. I could have a chat on this with a few of the RFC 
editors.

Are you trying to solve the situation where one user can have many 
(domain-)aliases on the local server? This could be solved (for the most 
part) by adding the user's local aliases using some sort of background 
configuration, e.g. returned from a userdb lookup. This avoids the need 
for each user to specify all its local aliases explicitly. Then, only 
externally forwarded mail addresses need to be specified explicitly in 
:addresses by the user, but those addresses should be no concern for the 
local Sieve administrator.

> 3) Because I try to migrate from cmusieve v1.0, I have a name issue
> with "imapflags".
> 
> README sec "* Supports all extensions provided by the original CMUSieve
> plugin:" and sec "Implementation Status" explains that "imapflags"
> is available.
Oh, it is mentioned in the wiki, but obviously I forgot to mention this 
in the package documentation.

> This is not true entirly: "imapflags" is not, lib-sieve uses the name
> "imap4flags" as defined by RFC.
> 
> So, it leaves me with two options:
> 3a) convert all user scripts and hack Horde-Ingo, or
> 3b) have libsieve accept the alias "imapflags" for the extension
> "imap4flags".
> 
> Would it be worhtwhile for libsieve to implement aliases for extensions,
> so that they are available in require by more than one name?
There is usually a good reason why the specification authors change an 
extension name like this. To my knowledge there are a few subtle but 
important differences between the specification that called this 
extension 'imapflags' and the latest RFC that now calls this imap4flags. 
I'll compare the specifications and try to find out whether I can 
quickly build a little brother to the imap4flags extension that 
implements the imapflags specification. This will not be enabled by 
default and thus needs to be configured explicitly using the 
sieve_extensions setting.

(Currently, the sieve_extensions setting is a bit annoying, because it 
requires you to specify every enabled extension. It would be nice if one
could alternatively specify which extensions should be added/removed 
from the default list. Ideas to do this cleanly are greatly appreciated.)

NB: Something similar is true for the (e)notify extension.

Regards,

Stephan