[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/


        "name.surn...@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".





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
}
============


is to replace another server on top of an existing user base.


what about '*'?

a "\" precedes a ":".




this is interesting for people.

bye

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 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, If "name.surn...@domain" wants to be created, the administrator shall instead create the user "namesurn...@domain" and an alias "name.surn...@domain" pointing to it. This may be conceivable for new installations, but it is not for scenarios where dovecot 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, - 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 - 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

checkvpw-dovecot-wrapper.c
Description: Binary data