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