-----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 ...". attached patch makes a first shot about that problem, leaving: 1a) maybe one should lower-case :addresses argument at compile time and my_address at run-time and then use strcmp() again. 1b) duplicate checks are case-sensitive, too. This is probably no big issue, because if the same person uses different variants of his/her mail address for sending, s/he does not deserve better. 1c) Suppression of replies to own mails are case-sensitive, too. Well, many people I know test that "it just works" by sending themselves a mail. I would disable this check. 2) we have about 157 ways to write the domain part. Not all accounts are available in all of them, but it's close to it. The old vacation program we used prior to "cmusieve" didn't care about the domain unless explicitly given. It was quite painful. 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 - - ??? 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. 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? About Horde-Ingo, maybe they have an update to use "imap4flags", too, but it looks like that I upgrade Dovecot before Horde. Bye, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSYccg3WSIuGy1ktrAQLlaQf+NHtyBxMb3aqnaw58zapo3/5kgqMM4GA+ 68el9d1CK4URjuk9io3MBsSzEJ4lRy6VFHNLw0jyNEnZp7l0vv5UoiK/+af7LCW5 H2T/qYL+lG/ul870t0/3q5wHmtrriAGQqE215C1u5/trJRX/sQLzDq1tbOtV4/vQ xUa8P0TXvCsgGSzCCmNiU0AenTIRGnxo+sCiyxnDKhgmWph/t06GYHX77CKwumK8 O57rh3RD9hA5yjicTbEZVLzeDDPEmCFliiSR6qMukfxOwX6LIxqhfw8n3cmSm8+X QyK6d/pBxy6EC14XhRQ7Jjtse+gWraiVJ/kcXKuW8sNPphtrGM1fdQ==uuB6 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: libsieve-patches2.tgz Type: application/x-gtar Size: 1009 bytes Desc: URL: <http://dovecot.org/pipermail/dovecot/attachments/20090202/9740ff7c/attachment-0002.gtar>
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
Steffen Kaiser wrote:> 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. > > This is not true entirly: "imapflags" is not, lib-sieve uses the name > "imap4flags" as defined by RFC.Documentation fixed.> 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?Ok, I've checked the specifications. It would in fact not be much of a problem to have an alias called 'imapflags' for the imap4flags extension, but only if your clients do not use the obsolete mark/unmark commands. Could you confirm this for me? Check this for documentation on that these commands did: http://tools.ietf.org/draft/draft-melnikov-sieve-imapflags/draft-melnikov-sieve-imapflags-03.txt This specification is almost nine years old. :) Regards, -- Stephan Bosch stephan at rename-it.nl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 3 Feb 2009, Stephan Bosch wrote:> only if your clients do not use the obsolete mark/unmark commands. Could you > confirm this for me?Horde and all my users manually wrote Sieve scripts use addflag / removeflag only. It seems that some people use (their own) Avelsieve, no mark either. I never noticed the mark command myself ... . Maybe you offer a compile-time option to put the load of "no 100% conformance to imapflags" on the admin? I would take it :) Thanks, - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSYlNg3WSIuGy1ktrAQJZEwf+Jw4kQLKwOejemiIJA/MwOCT8tDF2XBOa QyzHWlGshTxsJS7vV6KfEWpa8onDilFcBrF1NS1Fxn1vqLlo1nU4cJYYoQqU0qUm C9LIiUFY6PoMlS+pq/6Rb46Ryt4DjdPV9vMrGJimIeQaZqjdHGN8GplMvYkTgd75 jPf+J882+1T6KcH+zWoc3GII2q2gcIa3bTL+36GKg8tixoXuC+IjeKNResxs730V 6tvSNSjlccilKmgbssCn2NYMq7gQbtucrKCZUKHow76fmKCx7+tGR6DjOnffS1j5 2sTYVXKE5HT+aEpBk7UDFPDcosixCxh9iHzuuhv+v3hPNTGBH5KZyA==GsDF -----END PGP SIGNATURE-----