Giles Lean <[EMAIL PROTECTED]> wrote:
giles> You've been referred to two programs that can write to maildirs.
giles> Writing to maildirs is trivial; you might as well make your own
giles> program that decides where the mail should go deliver it as well.
...
giles> The maildir format is documented at:
giles>
giles> http://www.pobox.com/~djb/proto/maildir.html
Actually that does look trivial. I guess this does show the virtue
of KISS. So I may just write my own and use the same uniquness
strategy I'm programming into a web site now, which is Julian Day
based and good to 19 Dec 22666.
Florian G. Pflug <[EMAIL PROTECTED]> wrote:
fgp> There is an explanation for virtualdomains/multiple users with signed system
fgp> user/uid on www.qmail.org.
I'm not sure I find this or not. I didn't find something literally that,
but I found many "virtual" things there. Part of the problem, I think, is
that there isn't a precise meaning for "virtual".
fgp> It is bases on the users/assign file (in /var/qmail/users/assign). This
fgp> files tells qmail where mail to a certain user shall be delivered too (thus
fgp> overiding /etc/passwd). This together with the virtualdomains files gives
fgp> you excellent support for a _lot_ of domains and a _lot_ of users. Note that
fgp> (as far as I remember) the user/assign file is _compiled_ into some sort of
fgp> binary file, so it should be fast also with a lot of entries.
If it uses /var/qmail/users/assign then it's not what I want, and not what I
call virtual. To me, one of the attributes of virtual is that there is no
table of mapping between a user e-mail address and where to deliver, but
instead, the determination of where to deliver is a functional relation to
the e-mail address.
I want the very minimum of administrative work to manage it. This will
require such things as automatically deriving the user authentication data
from the customer account database. I expect to write something that will
rebuild certain files (password CDB, rcpthosts, virtualdomains) from the
data obtained from the database.
fgp> I am using this setup, and things are quite fast. I still have a .qmail file
fgp> for each user in his directory (/home/popuser/$DOMAIN/$USER), because you
fgp> need this for forwarding, starting mail notifying scripts, etc. But if you
fgp> just want to deliver to his Maildir/Mailbox you don�t need those .qmail
fgp> files.
I don't want a .qmail file for each user (except for local host users). If
by leaving it out I can deliver to each users's maildir, that' what I want.
At the same time there may be a catch. The default delivery for the local
host (e.g. listed in locals, for users in /etc/passwd, with distinct uids),
is not maildir, but "./Mailbox". I need to be able to leave local users as
all "./Mailbox" by default (unless overridden in a .qmail file for each user
individually), yet have maildirs used for all the virtualdomains users without
creating zillions of .qmail files.
Local users will NOT (at least we do not need to offer) have their e-mail
available by POP3 (or IMAP4 when that gets added to the mix). If the address
identifies the local host name, it goes to the shell account only, for shells
on the same machine as the general POP3 service (these are just staff shells,
anyway, not customer shell accounts, which would be on a separate machine
with a more conventional non-virtual setup).
fgp> I have writting a small webinterface for the administration of this (you can
fgp> add domains, add users to domain, set their pop-password, add forwards to
fgp> users,...). It is a quick and dirty hack (it�s a bunch of shell scripts!),
fgp> but it works for me - you can have it, if you want to (maybe you want to do
fgp> the necesary perl rewrite?? ;-)))) )
We'll be doing the web interface for administration as an integral part of
the whole internet service administration, working through a central database
that records every service, not just e-mail. E-mail configuration will then
be derived from that database much like web configuration, DNS configuration,
and so forth. I will be able to add a new customer, specify domains, and
let them add their own users and subdomains, and it will automatically set
up their e-mail, radius for dialup, routing for dedicated DSL, web service,
and whatever else (the exact system hasn't been chosen, yet).
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
