How to setup exim as a backup MX server

We're running several backup MX servers as a 'cluster', though not specifically designed for DirectAdmin. Backscatter is not much of an issue at the moment, but surely it is possible that we run into this later. We're using it as a frontend and fallback service for Exchange customers mainly. Some providers tend to block port 25 both ways, so we allow e-mail delivery on non-standard ports as well.

This setup uses SQL as it's main backend with replication on all servers. Not an ideal situation really, since both run on the same machine. But cost effective since we don't need 2 servers in every datacenter and fairly easy to extend to other servers as well.

It's possible to rewrite it so it could handle all domains from DirectAdmin automatically by letting domain_create_post.sh interact with SQL. Some of our customers use offsite Exchange servers though, so there has to be a way of using the right IP to forward e-mail to as well. In our situation we do this with a control panel, because it doesn't have to be automated for us. Exim might have a function for this though.

If DirectAdmin would have an option to store SpamAssassin configurations in SQL as well, you could have a pretty powerfull solution.

The only thing that hasn't been taken into account here, is the backscatter. That could be solved by using email_create_post.sh to write all addresses to SQL as well which would solve that issue.

I can't release our exim.conf here though, since it's one of our products of which we're still a little bit proud. Even though it's pretty easy to build, it has costed us a lot of time to figure everything out.

Let me know if you need some pointers though, but I think most of it is fairly easy for you Jeff. You probably know more than any of us about Exim configurations.
 
I got all the way through this most interesting post until I realized you were addressing it directly to me.

If anyone is expecting me to write a complex backulp MX solution soon, all I can say is don't. I just don't have the time.

For what it's worth, I'm proud of my exim.conf files as well; that's why I give them away.

Jeff
 
I got all the way through this most interesting post until I realized you were addressing it directly to me.

If anyone is expecting me to write a complex backulp MX solution soon, all I can say is don't. I just don't have the time.

For what it's worth, I'm proud of my exim.conf files as well; that's why I give them away.

Jeff

It wasn't, just the latter part about the pointers or more information. I just thought it would be interesting to share how our platform looks like and how it has been build, since your last post (on how to implement it). Not to release it publicly, but for your own use maybe.

By the way, I can't give away our exim.conf, because our configuration is part of a product we sell - it wouldn't make sense to publish it. I didn't put that into the right words in my previous post. It wasn't intented for you to write a configuration for public release either, you did a really great job on the current Exim file in DirectAdmin of which you indeed can and should be proud.
 
Last edited:
Has this been seen to yet?

We need to;

- Set-up a secondary server
- Add the domains it accepts mail for
- Retrieve the users and forwards (aliases, I believe they're called) so it can properly accept e-mail

-- Then that's it? Am I correct?

The rest such as SPAM can be dealt with later or can even be re-scanned when the primary e-mail server is backup?
 
In a perfect world, the real proper way to run a secondary MX would be to have a list of all valid recipients and to valid them against the given list. The only problem, the list needs to be up-to-date and it might be very complicate to maintain them for dozens of domains, hence the solution is not the best.

The second option that would be the easiest would be to accept any email as proposed in the Directadmin tutorial and pray that you have not been receiving too much spam by fake address from Yahoo! or other large email source as you may end-up blacklisted explaining that you have a proper infrastructure but poorly configured.

Finally, the best solution I believe is probably to assume on thing: the secondary MX (the one with the second highest MX value) should not be used as primary MX, however we know that in today’s email flux some does so. While we assume that the secondary is only a “fail-over” the best thing to do is simply to make sure your main MX is aware of that and do use a superstar feature of Exim called smtp-callout once the relay can take place and to simply freeze and do not send NDR/bounce email to those that does not resolve – thus it might break the RFC for non-bouncing unexisting emails, but it might also save you from being blacklisted.
 
Well DA already has a list of users for each domain so getting a list of valid accounts and alias' is not a problem. Nor is transfering this list to an exteranl server. However, the major problem is synchronising this data and how often.
 
Backup MX that only accepts when the primary is down

I wrote an Exim configuration for a backup MX that only kicks in when it detects that the primary mailserver is down, and otherwise tempfails the mail, instructing the sender to try again later.

This means that it works during an outage, but without increasing the amount of spam that you receive while your main mailserver is functioning normally. :) It also doesn't require any administration or synchronization of email account lists, and works with any kind of primary mail server that supports SMTP.
 
Does it accept all email for each domain? If so, then what does it do when it tries to deliver the email after the outage, if the user doesn't exist?

Jeff
 
I wrote an Exim configuration for a backup MX that only kicks in when it detects that the primary mailserver is down, and otherwise tempfails the mail, instructing the sender to try again later.

This means that it works during an outage, but without increasing the amount of spam that you receive while your main mailserver is functioning normally. :) It also doesn't require any administration or synchronization of email account lists, and works with any kind of primary mail server that supports SMTP.

Where is it getting its list of allowed domains from? How is it going to stay in sync with the primary servers list of domains?
 
scsi and others:

Whenever I see a post such as this as a first time post I look at it very carefully to make sure it's not some kind of spam attempt. I don't think this is. What I think it is, is automatic posting to game google.

Since there's some good information in the link, I've left it. However my response, and yours, are both important. The presentation in the poster's link doesn't answer your questions or mine.

So I strongly urge others not to use it until/unless the original poster comes back and responds. Which frankly, I no longer expect will happen.

Should I remove the thread?

If not then I urge anyone who follows it to be very careful of the issues we've raised.

Jeff
 
Jeff,

I would leave the message as it with your warning. In some way it brings part of the answer to the MX discussion.

My 2 cent.
 
Actually as I read it it MUST delay 30 minutes before it tries again. Please post the RFC number of the RFC you're writing about.

I'm tired of explaining the problem with this kind of setup, so I'm going to keep it short.

When your main mailserver starts working again the following is going to happen:

SpamBlocker won't block anything because all the email is coming from your main server.

You're going to get an awful lot of undeliverable email addressed to your domains, because your postfix is accepting all mail for the domain, not just for real email addresses. A lot of this email is going to be from spoofed addresses, so you're going to send back a lot of spam to a lot of innocent bystanders.

The bottom line is if you don't mind getting a lot of spam and if you don't mind sending a lot of spam, then this may work for you.

Jeff
 
Actually as I read it it MUST delay 30 minutes before it tries again. Please post the RFC number of the RFC you're writing about.

I'm tired of explaining the problem with this kind of setup, so I'm going to keep it short.

When your main mailserver starts working again the following is going to happen:

SpamBlocker won't block anything because all the email is coming from your main server.

You're going to get an awful lot of undeliverable email addressed to your domains, because your postfix is accepting all mail for the domain, not just for real email addresses. A lot of this email is going to be from spoofed addresses, so you're going to send back a lot of spam to a lot of innocent bystanders.

The bottom line is if you don't mind getting a lot of spam and if you don't mind sending a lot of spam, then this may work for you.

Jeff

jeff, and all others ofcourse :)

dont want to repeat the whole subject again, but i want to summerize, and make sure what the real options are now..... to get a good fallback smtp!
what would be the best way

- for most setups no smtp backup is needed, because it will resend if the server it actually down.
- if the server is partially refusing or not working, my experience is that it can deny the message, so its an instant fail.. (things like spamfilter not working or you clamav is crapping out.. still hev a post about this somewere here.)
- if you do configure an fallback smtp, because you fallback is accepted instantly you will have a lot of mail in your queue, and your server is busy there.
- i found also that many mail systems send roundrobin to the mx records, so one time it first at the fallback and then at the primary. so if defined an fallback, then you end up with a lot of spam,
-syncing the aliases and or account is the only way?
- can´t you check for spam in a proper way, without to verify if the user exsits. or will stil happen allready?

- purhaps an idea to place the accepted useraccounts/aliases also in a dns server/zone as they do with spam dns blacklists. an easy way to sync just the accounts :)

any more idea's?
 
Last edited:
- i found also that many mail systems send roundrobin to the mx records, so one time it first at the fallback and then at the primary. so if defined an fallback, then you end up with a lot of spam,
This is incorrect behavior. Mail servers should send to the lowest cost mx record, and only send to the next higher cost mx record if the lower cost record doesn't respond.

Jeff
 
I know this is an old topic, but it can be very handy.

Maybe you could combine this with the recent released 3rd part software DNS master2slave.
 
Back
Top