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

[background01] description of idea and patch on qmail list

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

 - 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
is customized for my setup in web hosting. Each virtual domain user can
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
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
from) by looking at the TCPLOCALIP. (Each account has it's own ipaddr so
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
my site specific authentication/authorization code is in it's own c file)
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
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
also program in the pipe of logging info that sends a copy to smtp-poplock
pop/imap-before-relay authentication. It's a really sweet setup.

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
users use /var/spool/mail/$USER for perfect compatibility with pine/elm,
Well, what I'm really saying is that this patch would need to be tested
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
we can more forward. I'm just a little hesitant about how much of my time
will suck up. I'm really quite busy now and just writing this e-mail has
a good while.

 - David Harris
   Principal Engineer, DRH Internet Services

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