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-0002.obj>
-------------- next part --------------