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:

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