I want to throw something out here and I'd value the insight from you guys.
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.
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? (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:-::
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. But I would think that even many small businesses have
to use multiple domains, and would find the above approach more orderly,
systematic, and natural.
I realize that the .qmail-* approach makes sense from a Unix point of view,
allowing all maildrops for that "user" 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. (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). With the single-uid/virtualdomains approach, every mail drop
can be manipulated with the same, automated interface. (Yes, we also have
support for "single-box domains", where all mail to "your-domain.com" gets
delivered to a "default" user, and then they use ETRN or pullmail retrieval
and remote parsing).
So, I'd value your input here. Let me help to focus what I'm looking for:
1) Is anything I'm saying valid?
2) Are there any drawbacks to the single-uid/virtualdomains approach?
3) Why do you use the implementation *you* use?
Thanks in advance!
Dave
On Monday, June 21, 1999 10:55 AM, Simon Woodward [SMTP:[EMAIL PROTECTED]]
wrote:
> All you have to do is to set up a user in virtualdomains
>
> some.domain.com:someuser
>
> then in someuser's home dir create lots of .qmail- files, ie
>
> .qmail-someone
>
> containing nothing else but
>
> [EMAIL PROTECTED]
...
