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@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:
compile and install: # cc -O2 -Wall -o checkvpw-dovecot-wrapper checkvpw-dovecot-wrapper.c # install -s -o root checkvpw-dovecot-wrapper /usr/local/bin
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@domain" wants to be created, the administrator shall
instead create
the user "namesurname@domain" and an alias "name.surname@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