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