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
[EMAIL PROTECTED]
