Web
Analytics Made Easy - StatCounter

Setup Postfix + Antispam as MX backup

mxbackup01

In mail-server architecture, MX backup is a solution that should be always implemented for redundancy and to avoid emails being returned with errors due to mail-server unavailability.

The working concept is pretty easy: when the mail-server is offline (failure or maintenance), incoming emails are collected and stored in the MX backup and released once the primary mail-server is back online again.

mxbackup02

 

DNS configuration

To work properly, system requires a second MX record in the DNS entry with a lower priority to properly deliver incoming email to MX backup while mail-server is offline.

Mail-server and MX backup public IPs have to be also set to reflect the designed architecture.

mxbackup03

 

Required packages installation

In order to use yum command to install all required packages, we need to add the RPMforge repository to our system.

# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm
# rpm -Uvh rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm

mxbackup04

In addition to Postfix, the installation process includes additional packages to protect the server from spamming: ClamAV, Spamassassin and Amavisd-new.

# yum install postfix spamassassin clamd clamav-db amavisd-new

mxbackup05

Because in this system we want to use only Postfix, if other packages are installed (Sendmail for instance) we need to set the correct MTA through the command alternatives selecting the right option.

# alternatives --config mta

mxbackup06

Because in this example only the package Postfix is installed, the number option to type is 1.

If Sendmail is installed in the system, remove it using the yum command.

# yum remove sendmail

 

ClamAV configuration

Edit the file /etc/clamd.conf and check that communication between Amavisd-new -> ClamAV is made through the local UNIX socket instead of TCP socket.

# vi /etc/clamd.conf

mxbackup07

Enable ClamAV option removing the #.

mxbackup08

 

Amavisd-new configuration

Edit configuiration file /etc/amavisd.conf and set the parameters with values that reflect your network environment.

# vi /etc/amavisd.conf

mxbackup09

 

Postfix configuration

Edit the file /etc/postfix/master.cf and add the following lines:

# vi /etc/postfix/master.cf

mxbackup10

Edit the file /etc/postfix/main.cf .

# vi /etc/postfix/main.cf

Add the following two lines:

mxbackup11

Change the configuration parameters with values that fit with your network environment.

mxbackup12

If the relay_recipient_maps parameter is left blank, all the emails are processed by the MX backup regardless if recipients exist or not in the mail-server with the risk of storing also “junk” emails. By creating the file /etc/postfix/relay_recipients with existing accounts, the problem is solved and only emails addresses to existing recipients are kept. Of course if you have a dynamic environment with thousand mailboxes, this approach is perhaps not the best option.

# vi /etc/postfix/ relay_recipients

Enable installed services to be processed during system startup.

# chkconfig postfix on
# chkconfig amavisd on
# chkconfig clamd on
# chkconfig spamassassin on

mxbackup13

Start the services following the correct sequence.

# service spamd restart
# service clamd restart
# service amavisd restart
# service postfix restart

mxbackup14

If a warning related to an outdated ClamAV database is shown, you can manually update the signature by using the command:

# /usr/bin/freshclam

mxbackup15

Signature is then updated to latest available release.

mxbackup16

 

System test

Once the configuration is completed, we need to test the system to verify its correct functionality checking if emails are properly processed.

Using the telnet command, we test first if Amavisd service is listening on 127.0.0.1:10024.

# telnet localhost 10024

mxbackup17

Next to test Postfix smtpd service is listening on 127.0.0.1:10025.

# telnet localhost 10025

mxbackup18

Using another computer, connect the MX backup via telnet. In yellow are shown the instructions to enter.

# telnet mail2.nolabnoparty.com 25

mxbackup19

If the message is delivered to the recipient, then the system is working properly.

mxbackup20

If the message is delivered to the recipient, then the system is working properly.

mxbackup21

Check Postfix logs activity to verify whether MX backup is processing messages or not.

# tail -f /var/log/maillog

mxbackup22

To check the MX backup emails queue, the command mailq shows the messages received so far.

# mailq

mxbackup23

On regular basis the system perform a flush action of queued messages based on the value specified in the  /etc/postfix/master.cf file (default 1000 seconds).

# vi /etc/postfix/mastercf

mxbackup24

If you don’t want to wait for next flush schedule, a manual flush can be performed using the command postqueue and checking with mailq the queue status.

# postqueue -f
# mailq

mxbackup25

When messages are released from the MX backup, if everything works as expected, emails are delivered to the email client.

mxbackup26

Instead of buying some cloud resources that could be quite expensive, in the market are available some providers that offer the MX backup service with interesting fees.

With this solution no emails will be lost in case of mail-server failure and scheduled maintenance can be performed taking all the necessary time.

mx backup 1