Setting Up Postfix As A Backup MX

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Thu, 2007-06-21 16:28. :: Email | Postfix

Setting Up Postfix As A Backup MX

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 06/06/2007

In this tutorial I will show how you can set up a Postfix mailserver as a backup mail exchanger for a domain so that it accepts mails for this domain in case the primary mail exchanger is down or unreachable, and passes the mails on to the primary MX once that one is up again.

I do not issue any guarantee that this will work for you!

 

1 Preliminary Note

I want to set up a backup MX for the domain example.com. In this example the primary MX for example.com is called mx1.example.com (IP address 1.2.3.4), so I call the backup MX mx2.example.com (IP address 1.2.3.5).

I have created MX records for example.com that look like this:

example.com.               86400   IN      MX      10 mx1.example.com.
example.com.               86400   IN      MX      20 mx2.example.com.

It's important that the primary MX has a lower number (10) and therefore a higher priority than the backup MX (20).

I'm assuming that the Postfix on mx2.example.com is already installed and working.

 

2 Configuring Postfix On mx2.example.com

To make mx2.example.com a backup MX for the domain example.com, all we have to do is change/add three lines to /etc/postfix/main.cf:

vi /etc/postfix/main.cf

First make sure that smtpd_recipient_restrictions contains permit_mynetworks and reject_unauth_destination, so something like this would be ok:

[...]
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
[...]

Then we must add example.com to the relay_domains paramater; if there's no relay_domains paramater yet in /etc/postfix/main.cf, the following will do:

[...]
relay_domains = $mydestination, example.com
[...]

And finally we add an empty relay_recipient_maps parameter to /etc/postfix/main.cf:

[...]
relay_recipient_maps =
[...]

(That way we don't have to specify a list of valid email addresses to back up, which might be a daunting task if you have to manage hundreds of email accounts.)

There's one important thing I have to add: You must not list example.com in the following parameters in /etc/postfix/main.cf:

  • mydestination
  • virtual_alias_domains
  • virtual_mailbox_domains

That's it already. All we have to do now is restart Postfix:

/etc/init.d/postfix restart

 

3 Testing

To test the new backup MX, we take down the MTA (Postfix, Sendmail, Exim, etc.) on mx1.example.com and send an email from some remote server to an example.com account (e.g. someuser@example.com).

If you have access to the mail log on the remote (sending) server, you should now find something like this in it:

Jun 6 18:29:16 mail postfix/smtp[17746]: AF814144146: to=<someuser@example.com>, relay=mx2.example.com[1.2.3.5], delay=1, status=sent (250 2.0.0 Ok: queued as DCA5A1BF40F)

As you see, the mail has been sent to mx2.example.com instead of mx1.example.com because mx1.example.com is unreachable. Now, let's take a look at the mail log of mx2.example.com:

Jun 6 18:29:16 mx2 postfix/qmgr[3049]: DCA5A1BF40F: from=<falko@blabla.tld>, size=892, nrcpt=1 (queue active)
Jun 6 18:29:16 mx2 postfix/smtpd[3051]: disconnect from mail.blabla.tld[1.2.3.6]
Jun 6 18:29:16 mx2 postfix/smtp[3057]: connect to mx1.test1.de[1.2.3.4]: Connection refused (port 25)
Jun 6 18:29:16 mx2 postfix/smtp[3057]: DCA5A1BF40F: to=<someuser@example.com>, relay=none, delay=0.07, delays=0.03/0.02/0.01/0, dsn=4.4.1, status=deferred (connect to mx1.test1.de[1.2.3.4]: Connection refused)

mx2.example.com has accepted the mail and tried to connect to mx1.example.com to deliver it to the primary MX. Because the primary MX is down, mx2.example.com cannot deliver the mail and keeps it in the mailqueue until mx1.example.com is available again.

Now we start the MTA on mx1.example.com again. The backup MX will not immediately deliver the queued mail, but after some minutes you should see something like this in the mail log of mx2.example.com:

Jun 6 18:56:44 mx2 postfix/qmgr[3080]: DCA5A1BF40F: from=<falko@blabla.tld>, size=892, nrcpt=1 (queue active)
Jun 6 18:56:45 mx2 postfix/smtp[3083]: DCA5A1BF40F: to=<someuser@example.com>, relay=mx1.example.com[1.2.3.4]:25, delay=1648, delays=1648/0.09/0.4/0.12, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 167995B0109)

The mail has been delivered to the primary MX where you can see this in the mail log:

Jun 6 18:56:45 mx1 postfix/local[4963]: 167995B0109: to=<someuser@server1.example.com>, orig_to=<someuser@example.com>, relay=local, delay=0.54, delays=0.08/0.02/0/0.43, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)

So no mails were lost while mx1.example.com was down, and users can continue to retrieve their mails from mx1.example.com.

 

4 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Shiva (not registered) on Wed, 2014-05-14 10:14.

 
Hi, 

  I have configured a backup mail server postfix for mass mailing.

  we are experiencing a problem while sending the E-Mail from Backup MX mail server its delivering as Spam, but when we are sending from main mail server its delivering as normal(not as Spam) can any one please suggest me what steps to be taken or it will be fixed by changing my IP ?

 

Thanking in advance

 Shiva

Submitted by pkaresz (registered user) on Fri, 2014-01-03 18:12.
Can anybody write a good description?It doesn't work and really old.Thanks!
Submitted by Anonymous (not registered) on Mon, 2009-11-09 23:37.
Running a backup mx is not as easy as it seems.  There is a lot of variables that go into making sure you aren't getting junk mail, making sure the messages get back to the primary ok, etc..  For that reason I simply use backup mx through http://www.mxsave.com/.
Submitted by Anonymous (not registered) on Thu, 2009-07-30 18:15.

This HOWTO misses out key elements.

 Postfix offers recipient address validation, where it will make a call-out to the primary server to check if an address exists. It will cache information about these addresses, so that it will be able to sensibly queue only emails to addresses that exist when the primary is down. Although you might want to ensure that it receives some email in normal operation to prime the cache (such as being listed as the first server to try for the domain).

See Postfix docs

The first question anyone should ask is do I need a backup MX? In the example described above there is nothing to cause the backup to flush its queue when the primary becomes available. So it may be that when the primary comes back email on this server will take longer to deliver than if no backup MX server had existed. Especially if there is no address validation being performed.

I agree about the spam issue in the first comment, the backup MX needs at least as good, or better spam filtering.

Submitted by AlArenal (registered user) on Sun, 2007-06-24 12:52.

Reading this tutorial I have to agree, that setting up a basic backup MX is indeed pretty easy. But problems are not too far away:

If you compare the configuration you are showing here with a typical modern anti-spam configuration almost everything is missing. This is what spammers like to see and that is the reason they like to send mail to lower priority MX servers, as they are more often than not not so well configured.

In my case using the herein described backup config in conjunction with my current primary MX setup this would lead to the following worst-case scenario:

My main MX server goes down. While our current mail server rejects well over 90% of the incoming mails (up to 50.000 per day over the last days) the backup MX would not. If the backup does not break under the heavy load our primary MX will, once it gets back online and the backup send it thousands of thousands of mails and none of them will get rejected and each and every mail will be virus and spam scanned.

It wouldn't take long until your primary mail server will shut down due to heavy load.

So, if you indeed intend to set up a backup mx, make sure it runs the same config in terms of spam rejection as your primary server. Otherwise you will notice an almost instant rise in spam mails that come through (relayed by your backup MX).

Submitted by wursti (not registered) on Thu, 2010-02-25 16:25.

The Spammer Trick with the lower prio MX is a thing that should be hard to work around, especially when ure recieving Mail for several Domains.Armoring the Backup MX the same way like the Primary would mean syncing Spamfilter Data. In my case (ASSP) sure possible but a thing that should be installed for every aditional domain.File Access / Cronjobs would be needed on the Primary System, there should be FTP/SSH etc for File Transfer in Backup System
Mine "simple dirty fix idea" would be now to let the backup only recieve in case the primary mail exchanger is down.A little php/perl script [e.g. fsockopen()] could do this monitoring, writing postix conf /restarting for the case the primary dont respond as it should.
The advantage would be that the relay stays up.So spammers would get a responding tcp 25 presented on the Backup MX Record, maybe theres a possibility to delay them (lame them in fact...)
Im running some M$ Exchange servers , they are mostly in Client Workplaces on  thin dynamic-addressed DSL lines. This Environments are screaming for a BackupMX, so it would be a rly nice to have...
however, im not registered here.if someone got the tune to make such running, contact my bnc quakenet (plz / #dswp)