Backup Mail Spool - not fully redundant server (I agree with Jeff)

netdynamix

Verified User
Joined
May 20, 2008
Messages
31
Location
Johannesburg, South Africa
Hi,

I have a second server doing nothing and I wanted to find out if anybody would point me in the right direction to get a mail spooling or backup spool setup as follows:

Server1 is expected to be online permanently.
Server2 is a backup server (offsite) which we FTP user data to for storage purposes, but other than that it doesnt do much else.

I don't want to go through the headaches of replicating user data into a live state on Server2 because of many reasons, mainly Jeff's (NoBalony) experienced opinions. I happen to agree with him on all parts.

Server2 is however setup and running DA and is setup in Multi Server Mode to receive DNS entries.

What I would like to do is IF Server1 had to go offline for a period of time (even if it was brief) that Server2 would spool or receive emails and keep them in a delivery "pool" (for lack of a better word, probably due to my inexperience) and wait for Server1 to become live again. When Server1 does come back online, then Server2 would pass on all mails received during the outage to Server1 for delivery into the users mailbox.

I hope that I have explained the above adequately.

Thanks in advance for any help that you guys can give.

ND
 
The sending servers will do the same thing. It will be kept in their spool usually for several days.
 
I've not yet changed my opinion on using a spooling (backup) MX server. Once the new exim.conf file comes out of beta, I'm willing to work with one client (do not write me and ask to be you) at no charge to create a backup MX solution.

If it works, it could help me change my mind.

Note that if you write me to apply, either on the forums, through PM, or by email, you'll automatically be excluded from the possibility of selection.

Jeff
 
@floyd:

True, but a lot of corporates don't like it if their clients receive the "temporary failure" messages. They want a "squeaky clean" approach to redundant mail delivery to their mailbox.

In this situation I see the only "sensible" way to run a backup MX is to have it aware of all the mailboxes that it will be serving. That way it can still handle delivery failures to unknown mailboxes.

We've being playing around with Directory-based email using LDAP, and had some success. We've had to look at this because we have multiple mail servers - and we needed a "global" backup MX solution - but we didn't want a standard backup mx that just allowed anything for a certain domain (a spammers paradise).

You can setup postfix, qmail and exim (also sendmail) to use LDAP-based lookups - quite easy. However, the tricky part is to setup your DA servers to use LDAP.

I think this is a great topic - and will be watching it with interest to see what other people here have implemented.

We're even looking at a MYSQL implementation - which also looks promising.
 
In my opinion... both LDAP and MySQL are a bit overkill.

I'm going to look at a script (run it as often as you want) on your DirectAdmin server, to get all the mailboxes, forwards, etc., by [email protected] into one file, and then pass it to the secondary MX server.

Then run another script on the secondary MX server to merge them all into one file.

Where they can be accepted or refused.

This may result in a delay of up to five to ten minutes or so; my original thought is that five to ten minutes or so is acceptable.

Of course the slave server will have to run a special version of the exim.conf file; it should be a separate server (vps?).

And it will need to run continually, because of the nature of MX; it may get emails even when the main MX is running.

Any comments/questions?

@ranz, call me if you have a moment.

Jeff
 
@floyd:

True, but a lot of corporates don't like it if their clients receive the "temporary failure" messages. They want a "squeaky clean" approach to redundant mail delivery to their mailbox.

From what I have experienced you only get a temp failure message after several hours usually 4 hours. I realize mailservers could be configured differently but I thought that was a standard.

If the above is true then it just seems like a lot of work for little benefit. I prefer to focus my time effort to just keep the server running instead.
 
I agree with your theory too (as it is sensible) - but our clients pay for our existence - so we tend to listen to their needs.
 
The easy way to do it is to set up a secondary MX server to hold all mail that comes in for all your domains if the primary MX server isn't running. Set it to hold all the mail, and then to try to deliver it once the primary MX comes back up.

Unfortunately, there will be a lot of undeliverable mail because of spammers who use dictionary attacks.

When your secondary server can't send it on to your primary server it will attempt to return it. Often to nonexistent senders. Which will get you a reputation as a spammer.

Even if you never use the secondary MX to send mail, so you don't care if it gets blocklisted, it will give you and your company a bad reputation, and will most likely put you in trouble with your upstream or hosting company for the secondary MX.

So most of us aren't willing to do it the easy way.s

Jeff
 
@floyd:
True, but a lot of corporates don't like it if their clients receive the "temporary failure" messages. They want a "squeaky clean" approach to redundant mail delivery to their mailbox.
It's worse if you just store the message to be delivered later. The sender will assume that your client got the message and may ring him later to ask him about it. Needless to say that the client won't be very happy and will give you a ring right away.
In case of temporary failure, one can take actions like sending the documents to a gmail address.

The only real solution imho would be to have at least one server that stores the messages and that never goes offline. You can then have as many MX servers as you want, they will all store their messages on the same server.
 
You can setup the secondary servers to fail delivery after a certain time.
Which is exactly what you don't want to do. Because then you have to do something with the mail, and you don't want to send it back because there's a good chance it's going to be spam (over 90% of the email on the 'net is spam) and it's going to go to someone who never sent it.

Jeff
 
From what I have experienced you only get a temp failure message after several hours usually 4 hours. I realize mailservers could be configured differently but I thought that was a standard.

If the above is true then it just seems like a lot of work for little benefit. I prefer to focus my time effort to just keep the server running instead.

From my experiences over the years, how other e-mail servers on the internet are supposed to work, and how they actually work are two VERY different things.

Notoriously bad are big ISP's e-mail servers. (Such as comcast/verizon/etc)
 
Well just remember too that mail server failures should not be confused with dns server failures. Most of the time if a mail server does not continue to try to send the mail its because its a dns server failure not because of a misconfigured mail server.
 
See the exim configuration item delay_warning on this page (exim.org). We don't include it in our file, so we use the defaults as shown. I'm probably going to include it in the final release so admins will know its there and will consider changing it.

Jeff
 
Back
Top