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 at rename-it.nl