> >2) Are there any drawbacks to the single-uid/virtualdomains approach?
>
> Users can't manage their own virtual domains without elaborate,
> privileged, homegrown web-sql-telnet-gui interfaces.
>
> -Dave
This is true. I find that the .qmail prepend notion is very powerful. Each
user has his/her own way of creating "new" mail addresses, especially new
mailinglists with ezmlm.
But there is also the value of 1 administrator handling the mail accounts of
many users. For example, if I give a create a domain
warrenjuniorhighschool.org it might make sense to have one or a few trusted
administrators handling the creation and administration of all these email
addresses.
So the question is:
Can QMail be configured to use both approaches, the single-uid virtual
domain approach and the many UID - independent user approach?
Alex Miller
> -----Original Message-----
> From: Dave Sill [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 22, 1999 3:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Implementation of Virtual Domains
>
>
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> >
> >Regarding the below instructions, I realize that the use of
> .qmail-* files
> >is how Qmail was "designed". But I find them to be rather clumsy.
>
> First, qmail wasn't "designed", it was designed.
>
> Second, you're entitled to your opinions, of course. I find them
> pretty elegant, myself.
>
> >For example, what if you have mail coming in to
> >
> > .qmail-name1
> > .qmail-name2
> > .qmail-name3
> >
> >Unless most of them are forwarding, aren't we going to have to create
> >multiple stores, as in ./Maildir1, ./Maildir2, ... in the users home
> >directory?
>
> No. You can either save them to a common store, or individual
> stores. It's up to the user to decide. Want them all to go to
> ~/Maildir? Put "~/Maildir/" in all three files. Want them to go to
> ~MaildirN? Put "~/Maildir1/" in .qmail-name1, "~/Maildir2/" in
> .qmail-name2, etc.
>
> >(I'm assuming that the entry in "assign" is a wildcard, as:
> >
> > +domain.com:popuser:888:888:/usr/qmail/popboxes/domain.com:-::)
> >
> >The implementation I prefer is specifying EVERY domain in
> "virtualdomains",
> >such as:
> >
> > domain1.com:domain1.com
> > domain2.com:domain2.com
> >
> >Then every user gets a private home directory and .qmail file (for
> >convenience, organized by domain):
> >
> > /usr/qmail/popboxes/domain1.com/name1/.qmail
> > /usr/qmail/popboxes/domain1.com/name1/Maildir/
> >
> >and there is a separate "assign" entry for each recipient of each domain:
> >
> >
> =domain1.com-name1:popuser:888:888:/usr/qmail/popboxes/domain1.com/name
> >1:-::
> >
> =domain1.com-name2:popuser:888:888:/usr/qmail/popboxes/domain1.com/name
> >2:-::
> >
> =domain2.com-name1:popuser:888:888:/usr/qmail/popboxes/domain1.com/name
> >1:-::
>
> YUCK. So every time Podunk, Inc., wants to add a new user, you have to
> update users/assign and rebuild users/cdb? What about wildcards?
>
> >We're an ISP, and it seems that Qmail was designed for a system with a
> >bunch of local users and that we're sort of having to "coerce"
> Qmail into
> >serving our needs.
>
> Not at all. qmail is designed to allow user-administered virtual
> domains and mailing lists. This is ISP-friendly behavior...unless
> you've got lots of spare time for handling petty user requests like
> this or automating the process.
>
> >I realize that the .qmail-* approach makes sense from a Unix
> point of view,
> >allowing all maildrops for that "user"
>
> "domain administrator"
>
> >to reside in a common directory. But
> >that implementation doesn't seem like it would scale well to
> large systems
> >with many domains as does the single-uid/virtualdomains approach.
>
> Why not? Where does it break down?
>
> >(Keep in
> >mind that we have automated the creation, deletion, forwarding,
> passwords,
> >etc of all accounts via a Telnet interface which we have linked
> through a
> >Visual Basic gui [coupled via a Sql Server database] that all our phone
> >reps can access, and we plan to put support for all these
> services on a web
> >page soon).
>
> If it's all automated, how does diddling users/assign and various
> .qmail files scale better than just diddling various .qmail files?
>
> >With the single-uid/virtualdomains approach, every mail drop
> >can be manipulated with the same, automated interface.
>
> I fail to see where the "single-box domains" approach, as you call it,
> prevents that.
>
> >2) Are there any drawbacks to the single-uid/virtualdomains approach?
>
> Users can't manage their own virtual domains without elaborate,
> privileged, homegrown web-sql-telnet-gui interfaces.
>
> -Dave
>
