How to setup exim as a backup MX server

This will certainly allow exim on your DA server to accept email for these domains, but it won't check to make sure the mailboxes really exist.

I believe that this may, in the case of a dictionary spam attack, cause a lot of collateral spam as your server attempts to send notices back to senders who never sent it.

I've written John and have asked him to comment on what he feels the ramifications may be.

Jeff
 
But spam is only going to be an issue if your primary MX is not able to be reached? So only during an outage?
 
Ok, I agree. Isn't that the only time it's important for a backup MX? Personally I won't run any kind of backup MX that doesn't properly handle spam. If you want to, then tell me what you plan on doing with it if you collect it on your backup MX server for users that don't exist. Are you going to try to return it? (Warning, if you do, you'll end up on blocklists rather quickly), or are you going to throw it away (in which case you're in violation of RFCs)?

To me these are important issues; they may not be to you.

Jeff
 
hmm.. True. I have not set up a backup MX before, so its all new for me.

Care to detail your setup? My second server is a non-DA box.

I am unclear on how disgarding a non valid user on your backup MX is going to violate any RFC's :confused:
 
I don't use backup mx servers. Since according to RFCs you get up to four days of delivery attempts before undeliverable mail is returned, and since I've never had a mailserver down nearly that long, I just don't see the reason.

No, it's not against the RFCs to disregard the non-valid user. Not when you accept the mail.

But once you accept the mail you're responsible for either delivering it or returning it.

So once your main server comes back up and you deliver the email to the main server, if the user doesn't exist, then it won't accept the email. Now you've got a piece of mail you can't deliver. Can you return it? Sure. But if it's spam, it came from a forged address. So when you think you're returning it, what you're really doing is called spamming the innocent user who had the misfortune of having his email address forged.

When you do that to us and lots of admins like us, who take spam seriously, you get into several blocklists very quickly, because that's the second largest source of spam on the Internet.

Jeff
 
OK, that is making more sense to me now. I appreciate the info :)
 
Very interesting discussion. I understand exactly what jlasman is saying here and his points are dead on. None the less, I have a situation where I think that a backup mx is required for at least a short period of time during a migration from one service to another.

Will the exim setting "require_verify" help with this situation at all j? I am so new to exim I don't know where this test is taking place in the process or how dependable it is :)

Thanks!
Dan Ellison,
Concepte of Illinois
 
sender verify will drop a percentage of the spam, however like Jeff said, spammers can use valid forged email addresses, there for, once your backup mx delivers the mail to your primary mx and your primary mx, says undeliverable, it will then spam that persons email address, which your secondary mx said was actually valid.

The best, safe and only way this should really be implemented is with a list of email addresses that you will only accept email for on your seconday mx which are valid on your primary


danellison said:
Very interesting discussion. I understand exactly what jlasman is saying here and his points are dead on. None the less, I have a situation where I think that a backup mx is required for at least a short period of time during a migration from one service to another.

Will the exim setting "require_verify" help with this situation at all j? I am so new to exim I don't know where this test is taking place in the process or how dependable it is :)

Thanks!
Dan Ellison,
Concepte of Illinois
Click to expand...
 
h2d said:
sender verify will drop a percentage of the spam, however like Jeff said, spammers can use valid forged email addresses, there for, once your backup mx delivers the mail to your primary mx and your primary mx, says undeliverable, it will then spam that persons email address, which your secondary mx said was actually valid.

The best, safe and only way this should really be implemented is with a list of email addresses that you will only accept email for on your seconday mx which are valid on your primary
Click to expand...

Correct me if I am wrong, but is this not what already happens? Primary MX bounces the forged email? So if the backup MX forwards a forged email to the primary once it is back on line, then it still happens?
 
No, in a properly configured exim server (in other words if you're using any of the exim.conf files we've delivered within the past several years, we don't bounce forged email; we check to see if the user exists, and if not, we don't accept the mail.

Subtle difference? Maybe to you, but to the Internet it saves tens of millions of spams daily from being sent.

Jeff
 
OK, been digging around and found some info that might be helpful

Inevitably spam messages will arrive at the secondary MX for non-existent users. The secondary server has no idea what users are valid on the primary mail server. Thus it will accept the message and attempt to relay it. But the primary mail server will reject it and the message will remain in the secondary server's queue. A simple solution is for the secondary server to attempt to see if relaying to that user is possible before accepting the message. (Results will be cached to reduce the performance hit.)

Create /etc/exim4/local_rcpt_callout and list, one per line, each relay domain.
Edit conf.d/acl/30_exim4-config_check_rcp and replace !verify = recipient/callout with !verify = recipient/callout=10s,defer_ok to accept messages if the callout fails.
Note that call-outs only check addresses and don't prevent frozen messages from piling up that were rejected at RCPT time due to their contents. Installing the same spam filters on the secondary mail server will help mitigate this.
Click to expand...

Found at this URL:

EximSecondary

I think that is getting closer to what I am looking for (and maybe others)
 
First: this suggestion will only work as written if you're using the exim files supplied by Debian. You're not, even if you've got a debian server. DirectAdmin uses it's own modified version of exim so as to deal with DirectAdmin's various features including multiple virtual domains.

Second: this really doesn't do much. Do you know the purpose of the local_rcpt_callout file? If not, look here.

Then look here for an explanation of the purpose of recipient callout (scroll down and look for Recipient Callout Verification).

The purpose of recipient callout verification is to make sure that an eventual recipient (i.e., for a forwarded email) is available so you don't end up freezing lots of messages in your queue. When your eventual recipient server is down the code you've suggested will simply delay the receipt of the message.

In the case of a backup server, it won't even be used unless the recipient server is down. So all incoming email will be delayed, and after four hours a message will be sent to the sender letting him/her know that the mail is being delayed. It will be tried for up to four days and then returned to the sender.

Which is exactly what a normally functioning server does now if you don't have a backup mx server.

I still don't see any reason to have a backup mx server.

And in case you were wondering, we don't implement this code in DA to help in it's original purpose because of the complexity in keeping up with all the various forwarding addresses; it works best in a small single-domain environment where the sysadmin keeps track of all email addresses on the server.

Jeff
 
I still don't see any reason to have a backup mx server.
Click to expand...

Thanks again for submitting your opinion. Just because you don't see the value, doesn't mean a) there is no value b) that others don't

Thanks.
 
You're absolutely right.

But what exactly is the value of a backup MX server that's going to do exactly the same thing as not having it is going to do:

Email will be delayed for up to four hours by the backup server, because it doesn't know if the email address is valid on the main server. After that four hours the sender is going to be notified daily for up to four days. After four days, the email is going to be delayed forever with a notice to the original sender every 24 hours.

And the advantage of this is?

Thanks.

Jeff
 
I know you don't see the value, so why continue posting to prove *your* opinion and point?

Thanks
 
Personally, assuming that every other mail server is "doing the right thing" is a foolish stance to take. I know many mail server do _not_ spool undeliverable email for 4 days, like during an outage. I recently had a 16 hour outage and can state as a matter of fact that many emails were being returned to the senders after just 2 hours, by various ISPs.

To many people, email is business and business is money. Investigating methods to ensure that my customers get their email is all I am doing here.

Again, I know your opinion differs.
 
Thanks! Exactly what I was looking for!

I was having the problem where I was being unable to verify recipients for the machines I was doing secondary MX for and was therefore generating backscatter.... thanks to all; this exim config worked exactly right for me.
 
mjk,

Now, a year later, I see some value in backup MX, but I still don't know how to easily implement it.

wmjosiah,

Do you avoid generating backscatter, and still get proper delivery, even when those primary MX servers are down?

If so, are you running DirectAdmin?

Thanks.

Jeff
 
You must log in or register to reply here.
Back
Top