ArchLinux Small Business Server (18) - Mail Server (3)

Ora abbiamo un mail server funzionante e stiamo ricevendo mail dal mondo. Putroppo in breve tempo una quantità incredibile della posta che riceviamo sarà inevitabilmente spazzatura non richiesta: Spam. Qualche mail conterrà pure virus e malware, e magari come mittente c'e' pure un vostro ignaro amico. Lo Spam e la posta infetta da virus sono una autentica epidemia. Un server di posta non protetto ha breve vita, presto saremo bannati come “cattivi” dalle liste pubbliche e non riusciremo più nemmeno ad inviare posta perchè respinti dagli altri server. Insomma, un disastro. Avendo un server personale per la posta è nostro compito, dunque, proteggerlo e vedremo qui in una serie di articoli come farlo.

Fortunatamente gli strumenti per combattere e limitare (non sconfiggere, badate bene) questo problema non mancano, come già detto nel predente articolo configureremo Postfix per un primo livello di controllo della posta, installeremo Postgrey che implementa il graylisting, Amavis-new che esplora le vostre mail e invoca altri pacchetti quali Spamassassin per proteggere il vostro server dallo spam e ClamAV per la scansione antivirus. Addirittura il nostro Shorewall ci darà una mano infine con una importante regola. Quello che dobbiamo fare è integrarli insieme.

Piccola nota: forse qualcino si domanderà perché mai debba proteggere Linux dai virus. Il motivo è semplice: nella nostra rete interna la maggior parte dei computer avrà sicuramente una qualche versione di Windows a bordo che è il bersaglio preferito dei virus e malware. Quindi meglio prevenire che curare cercando di far arrivare meno spazzatura possibile a questi umili e indifesi client :).

Iniziamo con Postfix.

Postfix

Il nostro MTA già di suo ci permette di limitare lo spam e di proteggere il nostro server. Editiamo il nostro file di configurazione:

sudo nano /etc/postfix/main.cf

Postfix generalmente scrive nel log il motivo di rifiuto di una mail, e settando smtpd_delay_reject = yes, mostra il mittente e la stringa HELO che ha causato il rifiuto. Andiamo in fondo al file e aggiungiamo :

smtpd_delay_reject = yes

Rifiutamo anche tutte le mail dai server che non identificano correttamente se stessi usando il comando HELO (o EHLO) come richiesto dallo standard SMTP RFC. Aggiungiamo :

smtpd_helo_required = yes

Ora impostiamo una serie di restrizioni da applicare. A chi non supera queste... "bye bye" prima ancora di entrare.

Restrizioni nei comandi HELO o EHLO

Sono usati dal mail server remoto per identificare se stesso. Le restrizioni sono analizzate in cascata una alla volta.

• permit_mynetworks: accetta le connessioni da qualsiasi mail server listato nel parametro mynetworks di main.cf
• reject_invalid_hostname: rifiuta connessioni da tutti i server che non identificano se stessi usando un nome host corretto (fully qualified hostname)
• permit: alla fine accetta le connessioni dai server che hanno passato i controlli precedenti.

smtpd_helo_restrictions =

         permit_mynetworks,

         reject_invalid_hostname,

         reject_non_fqdn_hostname,

         permit

Restrizioni a cui sono soggetti i server remoti per i comandi inviati

• reject_unauth_pipelining : impone al nostro server di rifiutare le connessioni dai server che inviano troppo velocemente i comandi. Molti spammers fanno questo per tentare di velocizzare la fase di invio mail spazzatura.
• permit : come sopra, accetta le connessioni se le precedenti restrizioni sono ok.

smtpd_data_restrictions =

         reject_unauth_pipelining,

         permit

Restrizioni sui mittenti delle mail che il server riceve

Viene usato il comando SMTP MAIL FROM per identificarli :

• permit_mynetworks : vedi sopra
• reject_non_fqdn_sender : rifiuta le mail da tutti i mittenti il cui nome non è specificato in modo esteso (sempre secondo quanto stabilisce il famoso "fully qualified host name"). Nota che gli host della nostra rete avranno probabilmente un nome host corto ma in questo caso sono già garantiti dalla regola precedente.
• reject_unknown_sender_domain : rifiuta le mail che provengono da domini sconosciuti
• permit : vedi sopra

smtpd_sender_restrictions =

         permit_mynetworks,

         reject_non_fqdn_sender,

         reject_unknown_sender_domain,

         permit

Restrizioni nei destinatari finali delle mail che il nostro server riceve

Sono identificati usando il comando SMTP RCPT TO :

• reject_unverified_recipient : rifiuta a priori una mail verso un utente sconosciuto. Tuttavia ho notato che se il server destinatario implementa Postgrey questo parametro, di fatto, ci impedisce di mandargli mail a causa del rifiuto di validare l'utente imposto dal funzionamento stesso di Postgrey. Occhio ai log, ed eventualmente disabilitare la restrizione.
• permit_mynetworks : vedi sopra
• reject_unknown_recipient_domain : rifiuta le mail quando il nostro mail server non è la destinazione finale e la destinazione non è un dominio valido
• reject_unauth_destination : rifiuta le mail quando il dominio destinazione non è fra quelli serviti dal nostro server (definiti dal parametro mynetworks) oppure non è fra i domini definiti in relayhost. Questo impedisce che il nostro server venga utilizzato come open relay.
• check_policy_service : fa in modo che postfix usi un servizio esterno per controlli aggiuntivi. Nel nostro caso inet:127.0.0.1:10030 passa la palla a Postgrey per implementare le gray list. Lo vedremo nel prossimo articolo.
• permit : vedi sopra.

smtpd_recipient_restrictions =

         reject_unverified_recipient,

         permit_mynetworks,

         reject_unknown_recipient_domain,

         reject_unauth_destination,

         check_policy_service inet:127.0.0.1:10030

         permit

Bene, a questo punto il nostro server Postfix già respingerà autonomamente una parte delle mail non desiderate. Un'altra cosa che si potrebbe implementare è un check se il mittente è presente nelle liste pubbliche di spammer riconosciuti. Tuttavia secondo me gli svantaggi sono maggiori dei vantaggi: rallenta troppo il sistema e, peggio ancora, spesso le liste non sono precise. Con Postgrey nel fodero io preferisco non implementarlo.

Test delle restrizioni

Postfix fornisce vagonate di parametri, a volte è utile testare una restrizione prima di buttare alle ortiche delle mail. Vi segnalo un paio di parametri utili allo scopo.

soft_bounce

Aggiungiamolo con il comando postconf (ma naturalmente potremmo anche editare il file /etc/postfix/main.cf, è lo stesso) e riavviamo postfix:

sudo postconf -e "soft_bounce = yes"
sudo /etc/rc.d/postfix restart

N.B.: In alternativa al "restart" del servizio posso usare il comando postfix per rileggere la configurazione senza killare il processo, basta digitare : sudo postfix reload e le nuove impostazioni saranno operative.

Quando impostato a yes, le hard reject responses (5xx) sono convertite in soft reject responses (4xx). In questo modo il server mittente, dopo un intervallo di tempo, opera un nuovo tentativo.
Impostare questo parametro significa, in pratica, poter controllare il file di log e vedere cosa il vostro server rifiuta dandovi il tempo, se necessario, di aggiustare la configurazione in attesa del nuovo tentativo.
Una volta trovata la configurazione ottimale disabilitare soft_bounce e ricaricare postfix.

warn_if_reject

Facendo precedere questo parametro alle altre direttive si fà in modo che postfix anzichè rifiutare la mail segnali un warning nel log.
Se non si è sicuri di quali effetti possa avere una nuova restrizione, questo parametro, dunque, permette di controllare prima e poi eventualmente impostare la restrizione come effettiva.

Ad esempio :

smtpd_recipient_restrictions =

         reject_unverified_recipient,

         permit_mynetworks,

         warn_if_reject reject_invalid_hostname,

         reject_unknown_recipient_domain,

         reject_unauth_destination,

         check_policy_service inet:127.0.0.1:10030

         permit

Notate il warn_if_reject che precede la mia regola reject_invalid_hostname: se un client, dunque, usa un nome host HELO invalido quando ci invia un messaggio, rientra nella mia restrizione, ma con questo parametro impostato Postfix scrive nel log un warning e accetta la mail lo stesso.

Riavviamo Postfix e controlliamo non ci siano errori:

sudo /etc/rc.d/postfix restart

Ottimo! Il primo passo è stato compiuto, solo server apparentemente ufficiali ci possono inviare mail. Nel prossimo articolo vedremo Postgrey che da solo, con una "furbata" tanto ingegnosa quanto semplice, spazzerà via dal vostro server oltre il 95% dello Spam.

Per ora :)