[Dovecot] ManageSieve and invalid scriptname

Stephan Bosch stephan at rename-it.nl
Fri Nov 28 20:09:27 EET 2008

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 

> 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.


Stephan Bosch
stephan at rename-it.nl

More information about the dovecot mailing list