inventory system

You need to do two things, both of which vary somewhat depending on how you have your domain set up:

1) Add an MX entry to your DNS for your linode. Presumably, mail.mydomain.com already has one - if not, set up an MX for that first. Your backup configuration should have a highernumber_ for the MX value.

2) Set up mail on your linode so that it knows that it's supposed to act as a backup server.

I should point out one thing I've noticed with backup mail exchangers - spammers like to deliver to them in preference to the origin server… presumably because backup servers are less likely to be running the same spam rejection rules, or to have a full accurate username list to do an immediate bounce from.

In fact, if anyone else reading this knows how to create a rule/plugin for exim4 which could do an immediate pass through to at least test for final destination delivery, that'd be great. Obviously, it should still soft-fail if the final destination isn't online… but most of the time when the backup is being used, it is, because of these annoying spammers.

Thank you very much! It's very informative. I did a search for existing email backup server providers and just like what you saidk, the spammers are a major concern.

Spammers sending to the backup mx should not be a problem if things are set-up properly.

The idea is that the backup mx only stores and forwards mail.

If the backup mx gets some mail, it should forward it on to the primary mx when it becomes available.

This way it should hit the spam software.

A lot of people seem to be setting the backup MX as actual mail boxes.

The other problem is that people add the backup mx IP as a trusted mail source, so all mail coming from it bypasses the spam checkers.

Adam

I realize how backups are supposed to work - that doesn't, however, address my problem.

Spammers try to deliver a lot of messages that shouldn't be deliverable. Many SMTP servers implement various filtering at inbound connection time, which can be used to deny message acceptance right away. The most primitive of these, of course, is denying delivery for non-existant users. More sophisticated stuff might include checking RBL lists, or denying/throttling specific IPs which have been sending a lot of messages in a recent period of time.

It's hard do enforce those kinds of rules at the backup MX. My point is that you can fix this 3 ways -

1) Not have a backup MX. This leads to mail reliability problems, obviously.

2) Replicate the rules at the backup MX. This might be expensive, or even not possible. In my case, I run a different MTA on the backup than I do on the primary, so it would be very hard to have all of the same rules enforced at both.

3) My proposed soft-fail system, which attempts to contact the primary and use the primary's business logic when it's available, and does normal store-and-forward operations when it isn't.

What a lot of people seem to be doing, is this

mx 10 primary.com

mx 20 backup.com

mx 30 primary.com

Spammers usually go for the last one in the list, so they will hit the primary server.

If it is down they will hit the backup either way.

It is not the best option but one of the easiest.

Adam

@bpendleton:

I realize how backups are supposed to work - that doesn't, however, address my problem.

This thread wasnt started by you and isnt just about your problems

I wasn't aware that I had to "start" a thread to have meaningful discussion therein, possibly discussing a related issue. Chill out.

Anyway, thanks for the suggestion. It makes a lot of sense… I'll have to give it a try and see if that reduces the spam load on the backup. At least until the next acceleration of the spam arms race, that is…