I'm on the list, no need to Cc me.
Michael Boman wrote:
> What I want is to be able to share the queue between n+2
> servers on each loocation
Qmail's design specifically precludes putting the queue on a network
filesystem, so you can't share it that way. One alternative is to set up
something like N+1 host PCs connected to a SCSI disk array that allows
multiple hosts, and to somehow configure all but one of the hosts as a
failover. Perhaps even a NAS technology like GFS
(http://www.globalfilesystem.org/) would work (but not definitely).
However, I've never heard of anyone doing so, so you'd be forging into new
ground. Note that in particular, you'd have to have the 2nd to Nth servers
lying dormant until the 1st server is believed to be dead, because multiple
instances of qmail can't be processing one queue at the same time.
No mail system I know of supports this kind of setup by design, and
I'm not sure it is easily possible under any of them. There's a reason for
that. It isn't worth the trouble. Most people who are concerned about
reliability and losing mail run N+1 independent servers, put the mail queue
on RAID, and if one machine dies try to manually recover the mail on their
second server.
Your problem seems to be that you don't have local resources that
can administer these machines if something goes wrong. If that's your
problem, what you should do is buy a server with serious redundancy. Compaq
(among others, I'm sure) makes servers with redundant power, disk, memory,
and CPU. You're safe from pretty much anything except a fried motherboard.
You can go a lot further with seriously redundant server hardware than you
will with some homegrown shared server approach, especially where it looks
like load is not your reason for multiple servers. Then just make sure you
get notified when a power supply dies so you can get a new one out while the
second is still working.
> as well as be able to split a single domain's mailstorage
> so each users doesn't need to download his/hers email from
> the other end of the world.
One way is to break down users into subdomains for delivery. I.e.,
given the email domain "bigdomain.com," with a primary MX server physically
located in Singapore, and users in Singapore, Tokyo, and Hong Kong:
You would need to set up forwarding on a user-by-user basis. User
joe lives in Singapore? Then [EMAIL PROTECTED] should be forwarded to
[EMAIL PROTECTED], and delivered locally there. User jane lives
in Tokyo? [EMAIL PROTECTED] User josh lives in Hong Kong?
[EMAIL PROTECTED] As long as their mail clients correctly send
as "[EMAIL PROTECTED]," the illusion of a single domain is retained. You
may or may not have to do some header rewriting on final delivery so that
they don't end including [EMAIL PROTECTED] in their "Reply
to..." mail messages.
This is not a hard problem, it just doesn't have an elegant
solution. If you need to do it that badly, then you can justify the added
busy work.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
