[Dovecot] dovecot and vmailmgr/qmail mailboxes

[Mij]

Hello folks,

Time ago I worked on a patch for dovecot to work with vmailmgr

http://mij.oltrelinux.com/net/dovecot-qmail-vmailmgr/

The patch was required because, despite vmailmgr complies with the  
checkpassword
interface supported by dovecot, dovecot snips the mailbox directory  
returned by the
authentication module at colon characters ':'. Incidentally, vmailmgr  
maps any
	"name.surname at domain"
to
	"~domain/users/name:surname"

(a standard practice in the qmail world, see eg
	http://www.qmail.org/man/man5/dot-qmail.html at "For security")

This path dovecot would then parse as "~domain/users/name".

An authentication module can't do anything about it, as this is due to  
dovecot collecting
accounting information in one common buffer, tokenized by ':'  
separators. I soon stopped
updating the patch because I didn't see much point in running  
indefinitely after releases.


However, a bunch of people wrote me over the last years asking for  
details or updates.
Partially for having a similar requirement myself, partially drafted  
by such feedback, I recently
wrote a "compromise" wrapper solution (attached). It does not require  
patching dovecot
(external module) and it's thus (supposedly) durable across dovecot  
releases; however,
it cannot help with the colon problem.

The wrapper works as follows:

1) compile and install:
	# cc -O2 -Wall -o checkvpw-dovecot-wrapper checkvpw-dovecot-wrapper.c
	# install -s -o root checkvpw-dovecot-wrapper /usr/local/bin

2) edit dovecot.conf, setup the auth section as follows:
============
auth default {
mechanism = plain
passdb checkpassword {
    args = /usr/local/bin/checkvpw-dovecot-wrapper
}
userdb prefetch {
}
user = root
}
============

If "name.surname at domain" wants to be created, the administrator shall  
instead create
the user "namesurname at domain" and an alias "name.surname at domain"  
pointing to it.
This may be conceivable for new installations, but it is not for  
scenarios where dovecot
is to replace another server on top of an existing user base.

Of course, it's very desirable to support "." users too. I see that it  
would require several
changes in the code, but I'd like to hear your opinion on this. What  
about
- using a different separator than ":", less common and safer. Could  
'\0' be one? If not,
what about '*'?
- as a quicker & dirtier solution, what about allowing escaping? One  
can modify the
auth module to replace ":" with "\:", if dovecot is instructed to  
avoid tokenizing when
a "\" precedes a ":".
- as an alternative, dovecot may require the module to chdir() to the  
mailbox directory
instead of returning its path as a string, and subsequently operate  
locally on
mailbox-relative paths. I can't guess how compatible this is with the  
current design.


In the next days, I will publish such wrapper to the webpage. For your  
convenience, I will
invite interested users to show up on this thread; this should help  
you in assessing how
this is interesting for people.

bye


-------------- next part --------------
A non-text attachment was scrubbed...
Name: checkvpw-dovecot-wrapper.c
Type: application/octet-stream
Size: 6278 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20090616/73b7b79f/attachment.obj 
-------------- next part --------------