Configurare Postfix + Antispam come MX backup

In un’architettura mail-server, dovrebbe essere sempre presente il servizio MX backup per motivi di ridondanza e per evitare che le email vengano ritornate con un errore mentre il mail-server è offline.

Il principio di funzionamento è molto semplice: quando il mail-server primario è offline (failure o manutenzione), le email vengono raccolte e conservate dall’MX backup che le trattiene fino a quando il server primario ritorna nuovamente online.

 

Configurazione DNS

Per poter funzionare correttamente, il sistema richiede l’aggiunta di un secondo record MX nel DNS con una priorità più bassa in modo da instradare le email all’MX backup solo nel caso il mail-server è offline.

mail.domain.com  MX  10 
mail2.domain.com MX  20

Inoltre devono essere configurati correttamente anche gli IP pubblici dei mail-server associati.

 

Installazione dei package richiesti

Per utilizzare il comando yum per effettuare l’installazione di tutti i package richiesti, aggiungere al sistema il repository RPMforge.

# 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

Oltre a Postfix, l’installazione prevede dei package aggiuntivi per proteggere il server dallo spamming: ClamAV, Spamassassin e Amavisd-new.

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

Poichè lo scopo è di utilizzare solo Postfix, se nel sistema sono presenti altri package (Sendmail ad esempio) è necessario configurare correttamente l'MTA tramite il comando alternatives selezionando l'opzione desiderata.

# alternatives --config mta

Poichè nell’esempio è installato il solo package Postfix, il numero da digitare è 1.

Se nel sistema è presente anche Sendmail, rimuoverlo tramite il comando yum.

# yum remove sendmail

 

Configurazione ClamAV

Editare il file /etc/clamd.conf e verificare che la comunicazione tra Amavisd-new -> ClamAV avvenga tramite il local UNIX socket e non tramite TCP socket.

LocalSocket /var/run/clamav/clamd.sock 
#TCPSocket  3310

# vi /etc/clamd.conf

Abilitare ClamAV rimuovendo il commento #.

['ClamAV-clamd', 
   \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"], 
   qr/\bOK$/m, qr/\bFOUND$/m, 
   qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],

 

Configurazione Amavisd-new

Editare il file di configurazione /etc/amavisd.conf ed impostare i vari parametri con i valori che rispecchiano la propria rete.

$mydomain = 'nolabnoparty.com';            # domain.com 
$MYHOME = '/var/amavis'; 
$helpers_home = "$MYHOME/var"; 
$lock_file = "$MYHOME/var/amavisd.lock"; 
$pid_file = "$MYHOME/var/amavisd.pid"; 
$myhostname = 'mail2.nolabnoparty.com';    # hostname.domain.com

# vi /etc/amavisd.conf

 

Configurazione Postfix

Editare il file /etc/postfix/master.cf ed aggiungere le seguenti linee:

# ========================================================================== 
# service type  private  unpriv  chroot  wakeup  maxproc  command + args 
#               (yes)    (yes)   (yes)   (never) (100) 
# ========================================================================== 
amavisfeed unix    -       -       n       -       2       lmtp 
    -o lmtp_data_done_timeout=1200 
    -o lmtp_send_xforward_command=yes 
    -o disable_dns_lookups=yes 
    -o max_use=20

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,no_address_mappings 
    -o local_header_rewrite_clients= 
    -o smtpd_milters=  
    -o local_recipient_maps= 
    -o relay_recipient_maps=

# vi /etc/postfix/master.cf

Editare il file /etc/postfix/main.cf .

# vi /etc/postfix/main.cf

Aggiungere le righe:

#AMAVISD-NEW 
content_filter=amavisfeed:[127.0.0.1]:10024

Modificare i parametri di configurazione inserendo i valori appropriati alla rete in uso.

myhostname = mail2.nolabnoparty.com        # hostname.domain.com 
mydomain = nolabnoparty.com                # domain.com 
myorigin = $mydomain 
mydestination = $myhostname, localhost.$mydomain 
mynetworks = 127.0.0.0/8, 192.168.20.2     # IP MX backup host 
relay_domains = nolabnoparty.com           # target domain 
inet_interfaces = all 
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination 
relay_recipient_maps = 
message_size_limit = 0 
mailbox_size_limit = 0 
maximal_queue_lifetime = 5d

Se il parametro relay_recipient_maps è lasciato vuoto, tutte le email sono processate dall’MX backup senza verificare se i recipient destinatari sono presenti nel mail-server con il rischio di conservare tantissime email “junk”. Creando invece il file /etc/postfix/relay_recipients inserendo gli account esistenti il problema si risolve. Naturalmente in un ambiente dinamico con centinaia di mailbox questa soluzione non è probabilmente molto pratica.

# vi /etc/postfix/ relay_recipients

# Accounts configured in mail-server 
angus.young@nolabnoparty.com 
malcolm.young@nolabnoparty.com 
bon.scott@nolabnoparty.com 
brian.johnson@nolabnoparty.com 
cliff.williams@nolabnoparty.com 
phil.rudd@nolabnoparty.com

Abilitare i servizi installati per essere avviati durante il boot del sistema.

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

Avviare i servizi effettuando il restart nella sequenza illustrata.

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

Se compare la notifica di warning relativa al database di ClamAV, l’aggiornamento manuale della signature viene effettuata tramite il comando:

# /usr/bin/freshclam

La signature viene aggiornata all’ultima release disponibile.

 

Test del sistema

Terminata la configurazione non rimane che testare la funzionalità del sistema verificando se le email sono processate correttamente.

Tramite il comando telnet, verificare se il servizio Amavisd risponde sulla porta 127.0.0.1:10024.

# telnet localhost 10024

ehlo localhost 
quit

Testare successivamente Postfix smtpd per verificare la risposta sulla porta 127.0.0.1:10025.

# telnet localhost 10025

ehlo localhost 
quit

Tramite un altro computer, connettersi in telnet all’MX backup configurato. Le parti evidenziate sono le varie istruzioni da digitare.

telnet MX_backup.domain.com 25

# telnet mail2.nolabnoparty.com 25

ehlo www.nolabnoparty.com 
mail from:<bon.scott@nolabnoparty.com> 
rcpt to:<bon.scott@nolabnoparty.com> 
data 
Subject: test backup mx 
sending message to test backup mx 
. 
quit

Se il messaggio email viene recapitato, il sistema funziona correttamente.

Per effettuare un test simulando uno scenario reale, mettere offline il mail-server e provare ad inviare alcuni messaggi email tramite un qualunque client di posta esterno alla rete.

Effettuare l’analisi del log di Postfix per verificare se l’MX backup sta processando i messaggi.

# tail -f /var/log/maillog

Per verificare quali messaggi sono effettivamente nella coda dell’MX backup, il comando mailq visualizza i messaggi processati.

# mailq

Il sistema periodicamente effettua l’operazione di flush delle email in coda in base al valore specificato nel file /etc/postfix/master.cf (default 1000 secondi).

# vi /etc/postfix/mastercf

Senza attendere la normale schedulazione, è possibile effettuare un flush manuale tramite il comando postqueue verificando con mailq lo stato della coda.

# postqueue -f
# mailq

Rilasciati i messaggi dall’MX backup, se tutto funziona come ci si aspetta, le email vengono recapitate al client di posta.

Poichè i costi per avere delle risorse nel cloud potrebbero risultare eccessivi per questo tipo di soluzione, nel mercato sono presenti alcuni provider che offrono a prezzi contenuti il servizio MX backup.

• mxsave.com
• backupmx.it
• dyn.com
• noip.com
• …

Implementando questa soluzione nessuna email verrà persa in caso di failure del mail-server e le attività di manutenzione possono essere effettuate con una relativa calma.