small logo

melfneerg.com

 - 'cos life is like that

[Blog]  [Pictures]  [Links]  [About] 
About the Author
Tudor Davies

author Tudor is a techie turned manager who fights like mad to keep his tech skills honed and relevant. Everything from web hosting, networking, *nix and the like. Constantly developing and co-ordinating with others to make the web a better (and easier to use) place.

Backup MX on RHEL/CentOS

Tuesday, 5th Oct 2010  Posted @ 08:56

Am reproducing this here in case the original page ever goes missing.
The reason: a customer wants to have a backup MX and hosting it in our environment is useless if the datacentre or the providers core goes down. The answer - do it somewhere else entirely (maybe even a VPS!)

How-To configure a Backup MX Server with RHEL
This post will explain how to configure a backup MX server for queuing mail for two (or more) domains if the primary mail server of those domains become unreachable.

I’ve tested this configuration for relaying mail to Microsoft Exchange, Postfix, QMail, Sendmail, Lotus Domino, Merak and other less common mail server without any kind of problems.

You could use Red Hat Enterprise Linux (RHEL) or CentOS without change an line of the following configuration, but with small adjustement you can use this how to to any linux distribution.

I’ve used Postfix as mail server, because for me it’s the best, and Amavisd-New, Clamd and SpamAssassin for checking Virus and Spam on relaying mail.

This post assume you have two queuing for two domains “yourdomain.com” and “yourdomain.net”.

This post assume that you have a primary mail server (MX with preference 10) for “yourdomain.com” with IP 111.111.111.111 and a primary mail server (MX with preference 10) for “yourdomain.com” with IP 111.222.222.222 and you want to use a server with IP 222.222.222.222 for queuing mail of both domains.

According to the assumption above you must have your DNS configured as follow :

root@linux:~# dig MX yourdomain.com @your.dns.server
yourdomain.com. 86400 IN MX 10 mail.yourdomain.com.
yourdomain.com. 86400 IN MX 20 mx2.yourdomain.com.
mail.yourdomain.com. 86400 IN A 111.111.111.111
mx2.yourdomain.com. 86400 IN A 222.222.222.222
root@linux:~# dig MX yourdomain.net @your.dns.server
yourdomain.com. 86400 IN MX 10 mail.yourdomain.net.
yourdomain.com. 86400 IN MX 20 mx2.yourdomain.com.
mail.yourdomain.net. 86400 IN A 111.222.222.222
mx2.yourdomain.com. 86400 IN A 222.222.222.222
The backup MX host must accept and queue mails, if the primary mailhost is down for a certain domain. To have a high degree of availability the backup MX host must be located outside the backed up domain. You can setup the backup MX host as a primary or secondary mx for a remote site, but in this example we have primary and backup MX on different networks for both domains.

The scenario will be the following :
The primary mailhost is down …
Email is delivered to the backup MX host and queued there ….
After the primary mailhost is up and running again, email is delivered from the backup MX host to the primary mailhost and stored in the local mailboxes.

After a standard Linux installation without any customization and a registration with a demo license key (only if you use RHEL), you must install the RPMFORGE packages from apt.sw.be to use some packages needed in the following steps.

For doing so you must use the following command :
rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
You could see http://dag.wieers.com for details about the package and the repository. If the installation gave you no problem, you can update your YUM database repository packages by running :
yum update -y
Running the above command will cause the complete update of your system.
After the upgrade, it will be better if you reboot your system, because it’s possible that you’ve updated some packages which need a reboot (i.e. Kernel) to work correctly.

After the reboot, you can proceed to install all the packages needed for our setup, by running the following command :
yum install -y postfix spamassassin clamd clamav-db amavisd-new
By default RHEL (and CentOS) use sendmail as default MTA, I’ve just said that for me postfix it the best, so run alternatives to choose
postfix as the default MTA and after this operation you culd definetely remove sendmail.
Configure your default MTA by running :
alternatives –config mta
and choose postfix (usually must type “2″).
Remove sendmail by running :
yum remove -y sendmail
The following is the configuration for postfix on mx2.yourdomain.com /etc/postfix/main.cf:
myhostname = mx2.yourdomain.com
mydomain = yourdomain.com
myorigin = $mydomain
mynetworks = 127.0.0.0/8 222.222.222.222/255.255.255.255
inet_interfaces = all
relay_domains = yourdomain.com, yourdomain.net
mydestination = $myhostname, localhost.$mydomain
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
relay_recipient_maps =
message_size_limit = 0
mailbox_size_limit = 0
maximal_queue_lifetime = 5d
There’s one important thing I have to add: You must NOT list yourdomain.com and/or yourdomain.net in the following parameters in /etc/postfix/main.cf:
* mydestination
* virtual_alias_domains
* virtual_mailbox_domains
Take care of spam!
If you compare the configuration above 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.
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).
For doing so, you should add :
/etc/postfix/main.cf:
#AMAVIS-D NEW
content_filter=amavisfeed:[127.0.0.1]:10024
/etc/postfix/master.cf
# AMAVISD-NEW
amavisfeed unix – – n – 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o smtp_tls_note_starttls_offer=no 127.0.0.1:10025 inet n – n – – smtpd
-o content_filter=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o local_header_rewrite_clients=
-o smtpd_milters=
-o local_recipient_maps=
-o relay_recipient_maps=
Then you must configure Amavisd-new according to your antiSPAM policy.
- Enable all services needed.
chkconfig postfix on
chkconfig amavisd on
chkconfig clamd on
chkconfig spamassassin on
- Restart all services in the following order :
service spamd restart
service clamd restart
service amavisd restart
service postfix restart
Reboot your server to check if all services works correctly and try to send some mail to yourdomain.com and yourdomain.net using your brand new server as relay to see if mail tranport works fine.
You’ve done !
Hope this help
Bye
Riccardo

[ no comments : Add ]

Tweet



layout and initial css based on the Qtractor page