Index: [thread] [date] [subject] [author]
  From: David Harris <>
  To  : <>
  Date: Tue, 11 Jan 2000 21:37:56 -0500

[background01] description of idea and patch on qmail list

Here is a post to the qmail list describing the original patch I created.

This is a re-post.. I screwed up the word wrapping on the last one.

 - David Harris
   Principal Engineer, DRH Internet Services

-----Original Message-----
From:	David Harris []
Sent:	Thursday, December 02, 1999 9:56 AM
To:	Thomas Neumann; Denis Voitenko
Cc:	Philip Gabbert; qmail
Subject:	RE: Any Decent IMAP server?

Thomas Neumann wrote:
> Ok, so what is necessary to make this really useful in the
> following scenario :
>  (a) Thousands of IMAP users spread accross hundreds of virtual
>  domains all running under a single UNIX user-id and using custom
>  authorization (i.e. not UNIX /etc/passwd or Kerberos but instead
>  something like a CDB File, an SQL backend database etc.), with IMAP
>  user-ids looking like 'user%dom.ain'
>  (b) As a consequence of (a), there are no "real" home directories per
>  ser [in the sense of getpwuid(UID)->pw_dir], therefore the Maildirs
>  are spread over some spool area that is based on whatever layout I
>  find most efficient for the job.
> Can I do this without doing some Major Hacking [TM] to the code?
> -t

You can't do this without Major Hacking [TM] to the imap/c-client code.
However, I have already done that Major Hacking [TM].

I have my own single-uid free-form-directory-structure-and-home-dir patch
that is customized for my setup in web hosting. Each virtual domain user can
create many e-mail only users. The e-mail only users, their (virtual) home
directories, and their unix_crypt_md5 encoded passwords are stored in a DB
File, one for each virtual domain. The virtual e-mail users have to specify
"+username" for their username (so we know they are e-mail only users, not
unix users). I then figure out which virtual domain the request is for
(which specifies which UNIX user to switch to and which DB File to read the
user list from) by looking at the TCPLOCALIP. (Each account has it's own
ipaddr so that effectively tells me which account the request is for.)

This is way too specific for general use, but hacking on top of my code (all
of my site specific authentication/authorization code is in it's own c file)
would probably be very easy. You see, the figuring how to tie my code into
UW-IMAP was the hard part - the specific authentication/authorization is
easy stuff.

If someone wants to hack in an interface to one of the virtual domain
packages or whatever, I think I could release the code to them. I just don't
want to release my specific authentication/authorization code (I think)
because it's way web hosting specific.

I also have another patch that makes UW-IMAP log to STDERR instead of
syslog. I then run it under tcpserver and use cyclog to manage the logging
info. There is also program in the pipe of logging info that sends a copy to
smtp-poplock for pop/imap-before-relay authentication. It's a really sweet

I should also note that I've switched mailbox formats from Maildir to MBX
(UW-IMAP's fastest local file driver which does not deal with NFS as I don't
use NFS.) (Well, actually, my virtual e-mail users are using MBX and the
UNIX users use /var/spool/mail/$USER for perfect compatibility with
pine/elm, etc.) Well, what I'm really saying is that this patch would need
to be tested along with the Maildir driver, but I see no reason why it
should not work.

Does this all sound okay? If people want this, I'll probably open-source it
and we can more forward. I'm just a little hesitant about how much of my
time this will suck up. I'm really quite busy now and just writing this
e-mail has taken a good while.

 - David Harris
   Principal Engineer, DRH Internet Services

Index: [thread] [date] [subject] [author]