Miguel Filho schreef:
Hello there,
I have been using pysieved and avelsieve and it has been working great. I decided to do test with the ManageSieve patch and got this problem:
Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using active sieve script path: ~/.dovecot.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using sieve script storage directory: ~/.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: relative path to sieve storage in active link: .sieve/ Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: Active sieve script symlink /home/admsis/miguel/.dovecot.sieve is broken: invalid scriptname (points to .sieve/phpscript).
Well as you can see, a file without the .sieve is not welcome :-( That is correct.
I checked the RFC and there is no requirement for a .sieve file extension when considering scriptnames. True, but the ManageSieve server will not use the .sieve extension in the communication with the client. So, as far as the client is concerned, the script is called "phpscript". The client can still choose any script name it wants, it is only stored a little differently on the filesystem, which is an implementation concern and has nothing to do with the protocol RFC.
http://tools.ietf.org/html/draft-martin-managesieve-12#section-1.6
Is this a misplaced restriction or it really should be enforced for any reason? The .sieve extension is merely added for storage in the file system to distinguish it from other types of files that may reside in the same directory. Otherwise, "LISTSCRIPTS" would for instance list any file in the storage directory, e.g. also compiled binaries that result from command line execution of sievec. Also note that the .sieve extension itself is not my own invention, because it is specified in section 7 of RFC 5228.
As shown recently, this also has a limiting effect on the scope of security holes that involve accessing inappropriate directories. If I had not made this design choice, the recently discovered security hole would have given any user the ability to access any file that is accessible from the uid the server is running with. GETSCRIPT "../victim/mail/inbox.mbox" would for instance have been possible with virtual users.
So, at all times, only regular files ending with .sieve are considered to be valid sieve scripts. This is also true for the symbolic link that points to the active script. If it points to something else, it is considered to be invalid and no active script is reported in LISTSCRIPTS (a situation that is fixed automatically when a proper script is activated).
I hope that this can be tolerable, or I will have to rename a lot of scripts and remove all hardcoded "phpscript" strings from avelsieve :-( Good news and bad news here. The good news is that you will not need to change Avelsieve in any way. The ManageSieve script name "phpscript" is implicitly stored as "phpscript.sieve". And the other way around: if a script file called "phpscript.sieve" resides in the sieve storage directory it is reported to Avelsieve as "phpscript". That's where the bad news comes in: you still need to rename all existing script files from "phpscript" to "phpscript.sieve" for the Dovecot ManageSieve server to notice them. After that, you can reactivate all scripts (Avelsieve should do this implicitly) and all should work.
Hmm, maybe I should write a short migration manual.
Regards,
-- Stephan Bosch stephan@rename-it.nl