Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

email redundancy between two servers

Status
Not open for further replies.

edzillion

Programmer
Feb 20, 2004
8
IE
We have had some email outages in the last few months and my boss is asking is it worth going with one of those email redundancy/filtering sites. The thing is, we have a backup server on a remote location, so I am pretty sure we can set something up with what we have already.

At the moment I have the top MX record pointing to my in-house server and the next entry for our dedicated (off-site) server in a data center. I was thinking that instead, we should have the first record pointing to the off-site server, which would save all emails and then forward them on to the in-house server. That way we would have backups etc. In the event of that server going down the in-house one would take over. The off-site server is linux and the in-house is SBS.

Is this possible, and are there any resources out there to help me?
 
You've mixed questions in here... I'll tackle the MX records...

The MX records exist to tell sending mail servers how to get mail delivered into your domain(s). You put priority values (lower number, greater priority) with those MX records. The higher priority MX records are TRIED first. If the sender cannot reach a mail server at the highest priority, then the sender SHOULD continue trying at the next priority MX server and so on...

Therefore, having the two mail servers in your MX records with various priorities is a way to raise the odds of delivery.

I said the sender "SHOULD" continue trying because not all mail delivery agents abide by the same rules all the time. Some might pause trying if the first priority MX records don't and answer and will retry at another time against another MX or the same MX... That's the minor trouble.

If you feel that you have enough risk in the uptime of your highest priority MX server(s), you can obviously set the TTL on the MX records lower (i.e. expire more quickly) and make changes to your DNS MX priorities during times of crisis to aid in managing traffic flow. (This increases some DNS activity/load, having a lower TTL on MX records).

Another option you may wish to consider - depending upon your circumstances - is to get a third mail gateway from a VMWare slice/linux provider. Set that machine up to receive and forward all mail for your domains. Put it's MX priority lower than all your others.

You may notice that this third box might see a little traffic during normal operations, but it should be able to store and forward a decent amount of incoming traffic during an outage... thus raising your "uptime" on email from some points of view.

Could be done for $25-$50 USD a month.






D.E.R. Management - IT Project Management Consulting
 
So if I understand you correctly what you are saying is that unless I have a reason to think that both servers will be down for a significant amount of time (which I don't) - there is no good reason to get a third mail gateway?

Otherwise redundancy can be handled by editing the TTLs and backing up the exchange folders periodically ... ?
 
What was your failure?

If you changed it the other way, your mail traverses another hop (network, hit disk, network) along the way. I have always run it where the remote site is only a lower MX precedence store and forward. The reason is this allows external MTAs to deliver and not get the 4 hour "mail delayed" message on their end. But this does not address the problem when you have inbound network problems or server problems.
 
The failure, I think (I am new to all this) was due to the fact that the backup server was not set up correctly. Even though the MX records were set up, people who mailed when the first server was down recieved an 'address does not exist' reply.

If the 1st server was down and mails were deliverd to the 2nd, would that be considered a 'delivered mail'? Or would the 2nd server have to send the mails to the 1st before the delivery was completed?
 
Once the backup server got it, it is delivered as far as the remote MTAs are concerned. When your exchange site comes up, those emails will be delivered to your exchange server (because it has a higher precedence).

Now as far as "receipt requested mail", those are not "delivered" until Exchange/Mail server gets them.

I see, so I think the backup server thought it was the actual recipient (probably local-host-name) of the mail and not a store and forward. Yeah, that is not going to work very well.

We used Mimosa to manage our redundant Exchange mail (with redundant inbound mail gateways), but I believe this might be big bucks.

If the error is what you described, a correctly store and forward should suffice (and you should actually test it because it should not get ANY usage!) To test, you setup a direct send to the backup server with all your mail domains to a test account and see they actually delivered and by inspecting the headers know the mail traversed your backup store.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top