Fallback

[PeterT]

We're currently setting up a server using DA, the 'old' server which ran the website(s) is running cPanel.
In cPanel its quite easy to setup fallback mx records, with the actual possibility of 1 cPanel server serving as fallback for the other and vice versa.
This can be done through editing /etc/remotedomains & /etc/secondarymx.

In DA I have yet to discover this option... anyone?

 

[Icheb]

It's possible in DA by editing some default settings, however it will create a few issues. Short said: our fallback uses spamblocker for all domains, because with fallback you'll most likely accept mail to all domains hosted, however it won't check if the accounts exist.

Don't really have time at the moment, but I'll try to write something by the end of the week.

 

[nobaloney]

I just want to add that you can set MX records; as many as you want, pointing to wherever you want, as long as you have "rights" to modify DNS.

Jeff

 

[PeterT]

I just want to add that you can set MX records; as many as you want, pointing to wherever you want, as long as you have "rights" to modify DNS.

Jeff

Setting the MX records isn't really the problem; configuring EXIM to function as fallback is

 

[nobaloney]

Let's wait for Icheb then .

If I like it, and if it's manageable, I might even add it to the SpamBlocker exim.conf file.

Jeff

 

[Icheb]

Let's wait for Icheb then .

If I like it, and if it's manageable, I might even add it to the SpamBlocker exim.conf file.

Jeff

I got 1/4th of the doc finished at the moment. It's in the exact same style as my dns replication script, so Jeff, you know what to expect.
I am still looking for a way to get all the virtual users included, so the system doesn't have to be 'catch all' and catch junk as well.

Also note that I'm using the SpamBlocker .conf as main template, to include RBL's .
However the config is stripped down a bit.

 

[nobaloney]

I'd suggest using separate files like I do for use_rbl_domains, so that eventually someone can write a plugin for it.

But I'm still not excited about using one DA system to do slave MX for another.

As some of us already know, I'm not too excited about using slave MX, because if one system is down the other system has no way to know which users are "real" for the domain it's accepting email for, which results in a lot of email accepted that eventually must be discarded (it's not safe to return accepted mail because you could be just adding to a spam problem).

Even our (in progress, at least a year away from being finished) separate-server anti-spam solution, won't accept any email for a domain if it can't figure out who the users are.

Jeff

 

[PeterT]

As some of us already know, I'm not too excited about using slave MX, because if one system is down the other system has no way to know which users are "real" for the domain it's accepting email for, which results in a lot of email accepted that eventually must be discarded (it's not safe to return accepted mail because you could be just adding to a spam problem).

Not quite true.
In cPanel you have to specify which domains to accept mail for, and I'm quite sure, seeing as DA can also present a list of all domains on a server, that list can be synced every night (or hour if you must) to the allowed relay list.

 

[nobaloney]

I believe you misunderstand me; perhaps I wasn't as clear as I might have been.

I'm not writing about "domains" but rather the users at the domains.

Are you anticipating a system that would keep complete user lists for all users on all domains, and keep it current? Interesting project.

Jeff

 

[PeterT]

Actually I'm not anticipating the 'main' server to go down too often, which would erase the need for the extensive user checking. So basically domain checking would suffice.

If however, for whichever reason, you expect your servers to go down often, well then yes, you might have a use for all users

 

[nobaloney]

If you don't expect your main server to go down too often, then why do you need redundant MX at all, since mail is quite resilient and designed to kepe trying.

Even one term of downtime will result in possibly thousands of emails bouncing around your servers once your main server comes back up.

I've discussed this at some lengh on various mail forums, and current attitude appears to be "build a good main server" and don't use fallback MX.

Your mileage may certainly vary.

Jeff

 

[PeterT]

Take a look here:

http://greylisting.org/whitelisting.shtml

Those are some of the companies which maintain MTA's which do not retry.
Hence, for mission critical domains, fallback MX isn't as much of an option as it is a necessity.

I don't quite see how you imagine 'thousands of emails bouncing around your servers', as the way we have implemented it (currently), is that 1 server serves as fallback for the other.
Both use EXIM, which, as you might know, tries to send it to the main server, if it however does not get a response on from the destination SMTP, it will keep it in queue until the SMTP comes back online - in other words: no bouncing around.

 

[nobaloney]

Interesting link.

As they themselves note, servers that don't retry are in violation of RFCs. Many of us (not me) actually block servers in violation of RFCs; the thought being that so doing is the best way to get their admins to fix them.

While I'm not that extreme, I will point out that the servers most likely to not retry are the spammers' servers.

Really.

If you need to build redendant MX, then go for, and live with the consequences that have caused most of us to decide to not do so.

I don't see anything in this thread where I've encouraged Icheb to not do it.

In fact I thought I was fairly encouraging. In fact if he manages to solve the problem I could be very interested in his solution, as could tends of thousands of email admins worldwide.

Jeff

 

[PeterT]

Interesting link.

As they themselves note, servers that don't retry are in violation of RFCs. Many of us (not me) actually block servers in violation of RFCs; the thought being that so doing is the best way to get their admins to fix them.

Agreed, except for the small fact that a couple of mid-sized companies aren't really going to make them change their policies.
If however a collective, and/or several big (US) providers would do so, then it might have a chance, till then, nothing can be done about it.

If you need to build redendant MX, then go for, and live with the consequences that have caused most of us to decide to not do so.

Actually I see quite a lot of providers out there who do offer it, not that many who don't.

I don't see anything in this thread where I've encouraged Icheb to not do it.

In fact I thought I was fairly encouraging.

Truth be told: you didn't

 

[nobaloney]

Actually I see quite a lot of providers out there who do offer it, not that many who don't.

I find that hard to believe; my searches have shown up the opposite.

For example, run some google searches:

web hosting: 102,000,000 matches

web hosting redundant mx: 287 returns

web hosting backup mx: 8,890 returns

web hosting fallback mx: 421 returns

How do you intend to solve the problem of having accepting email for nonexistent users?

Jeff

 

[PeterT]

I don't mean that they offer it as a service, but check out providers as earthlink, roadrunner.
Look at bigger sites like google, amazon.. etc.
Hosting 1and1.com, ev1servers.net, and more..

Again: I don't intend to solve the problem where you accept mail for nonexistant users, as I don't expect the main server to be down that often.

 

[Icheb]

As I already mentioned, it's a basic backup MX solution, not really fancy.
However, after keeping an test server up for about half a month I currently have about 264 mails that are frozen in queue as the real server doesn't accept them because it's spam/virii or a combination, and they just time out...
However, most of them are actually spam that's not being accepted due to wrong virtual users. If I would create a script that's able to parse the users/domains to create a user@domain syntax, it might be quite possible to use a whitelist solution to do it, and blacklist everything else automatically.

This does mean I have to dive into the Exim configs a bit more. 264 mails isn't really a problem, however the test was only with 25% of the domains we host, so I guess after we turn that up to 100%, it's gonna get worse.

PeterT: you're forgetting something important, some spammers actually target the secundairy MX, due to it being MX backup, so it just accepts all for the domains in question, which means they load up your mailserver with all kind of crap/spam.

Jeff, my idea for solving it:
Create a list of domains, which can be used as a template, if not existant, deny.
Than create a list with username@domain and virtualuser@domain. This won't work if you're using catch alls, however I thought * was a wildcard, so the script has to parse the aliasses config created by DA, and if it detects an catchall, just do the exact same thing.
The rest of the special messages won't be needed (forwards, mailing list stuff), as they are handled when the primary server comes back online.
Please note: this idea is NOT the idea I've begun to publish, this would be the 2.0 version of the idea .

edit: corrected a few typo's, a few is ok, however this was too much.

 

[PeterT]

Sebastian, iirc you can make exim drop messages after a certain amount of days, that could perhaps be a temp. solution.

You're right about the secondary mx targetting, didn't think of that one.

 

[Icheb]

Sebastian, iirc you can make exim drop messages after a certain amount of days, that could perhaps be a temp. solution.

True, at the moment it waits about a week until it drops it. But not really a real solution I guess. Got plenty of space and bandwidth, so I don't mind, but it's ugly.

 

[nobaloney]

]I don't mean that they offer it as a service, but check out providers as earthlink, roadrunner.
Look at bigger sites like google, amazon.. etc.
Hosting 1and1.com, ev1servers.net, and more..

Those big guys need multiple servers to handle their load, not for mx backup.

For example, earthlink.net returns 14 mail server mx records, and 12 of them have the same priority, which is a round-robin setup.

Roadrunner uses two mailservers, both of them with the same priority, again a round-robin setup.

My guess is they use a database to store their user information, perhaps on a replicated database server. You can do that as well, but not with DA out of the box.

Again: I don't intend to solve the problem where you accept mail for nonexistant users, as I don't expect the main server to be down that often.

Since a backup mx server (one with a lower priority) is only used when the higher priority one can't be reached, I don't understand your point.

Note that if a high priority server is overloaded and bounces messages, backup mx will NOT get the mail; once the server has been reached, the mail will only go to that server.

So I don't see any advantage.

Jeff