hello

some times ago I posted some patches to workaround vmailmgr not fitting into dovecot's passdb-checkpassword authentication module.

Yesterday I spent some spare time for carrying out a cleaner solution for this problem. Check out these patches. If you're not interested in merging them, I will make them available at the same page I used for the former solution [ http://mij.oltrelinux.com/net/dovecot-qmail-vmailmgr ]; there were some 20 people/month that checked it out.

This is a brief explanation of the patches:

The root of all evil is that the checkpassword interface [ http://cr.yp.to/checkpwd/interface.html ] leaves room to
interpretation when the scope is not system login. Vmailmgr and vpopmail, for example, collapse many mail users on the same system account. So, what "home" is here is not specified. In the case of vmailmgr, it's "checkvpw" sets HOME to the system user's home, and returns the path of the actual mail user differently.

The solution I applied for this problem is to generalize the process that fetches authentication data (what currently is "checkpassword- reply"). I was set up for a specific passdb-vmailmgr module, but this would have seen a lot of code replication. Similarly (but I did not inspect
further), I guess vpopmail can fit in this solution as well.

So

1. provide a module "vmailmgr-reply", with the same behavior as checkpassword-reply, that's aware of the way checkvpw returns accounting information and pass this back to dovecot transparently

so, this patch ships vmailmgr-reply along with checkpassword-reply (name them "fetcher"s for brevity)

The idea is that every checkpassword-compatible module may have its own fetcher for passing correct info back to dovecot. Now with this generalization, the user must be able to specify if its
checkpassword module needs a custom fetcher, and if it does, what's its path. So 2) modify auth/passdb-checkpassword.c and pump "args =". By default
it takes the path of the checkpassword module (e.g. "checkvpw"), now it can be
appended another field, that is the path of the custom fetcher. If this
optional is omitted, the default checkpassword-reply will be used, and the cp module is
supposed to behave like dovecot expects from it. Otherwise, a comma appear after
the first path. e.g.

passdb checkpassword { args = /xyz/checkvpw,/libexec/vmailmgr-reply }

if one needs to specify paths with commas in the first one, commas
can be escaped with
(eg args=first\,path,second_path)

Last but not least, the patch addresses again the problem with colons
in paths. Currently, dovecot dictates no colons can exist in mailbox path
names. In UNIX, no such constraint exist. Moreover, paths with colons are common when
working specifically with qmail (see dot-qmail). When dovecot encounters ':', it truncates the path. This way, for example, if the authentication module returned home "/ path/name:surname", dovecot will truncante it to "/path/name". If name exist,
name:surname will browse his mail without effort. All this comes from dovecot parsing params on MAIL environment
(INDEX, INBOX, CONTROL), but it also happens if none of them was actually specified.

So 3) modify lib-storage/index/maildir/maildir-storage.c for fixing the
parsing problem with the mail environment. [ I did not provide the same fix for the
remaining storages, but this can easily be done by copy/paste if convenient ]. For
simplification and without loss of generality, this fix mandates ":INBOX=", ":INDEX=" and
":CONTROL=" params to follow in this order, if they appear.

[ a minor patch agains auth/Makefile.am is provided for including
vmailmgr-reply when building the rest of the auth stuff ]

Any comment on this is welcome for discussion.

bye