One thing that could be convenient to is make a hostname that map's to multiple
IP's, if you have for instance smtp.mydomain.com which has IP 192.168.1.1 and IP
192.168.1.2 in DNS, the machine that send's to smtp.mydomain.com would send it
to the first given IP unless it's not availlable end sends it to the other IP,
another way is to have some cisco router having this smtp.mydomain.com name and
forwards the received packets for the smtp port to a list of IP's, if one isn't
availlable it simply forwards to the other queue;
One disadvantage is that you'll end up with message's for the same user on
multiple machine's, however i'm sure that there is some kind of method for that
(Maildir's via NFS for instance...)
Regards,
Jeroen.
Greg Owen wrote:
> 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]
