Difference between revisions of "Small Business Server (Italiano)/Mail Server"

From ArchWiki
Jump to: navigation, search
Line 167: Line 167:
  
 
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.
 
Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.
 +
= Filtraggio della posta =
 +
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 più avanti.
 +
* ''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.

Revision as of 10:01, 30 January 2008

Ad un SBS che si rispetti non può certo mancare un servizio di posta elettronica, anche considerando il fatto che ancor oggi è il servizio internet più usato. E noi da bravi andiamo a configurarne uno semplice ma abbastanza completo. Questa parte è abbastanza articolata, facciamo una piccola premessa ed installiamo il software necessario.

Premessa

Il mail server che andremo ad implementare è un mail server ufficiale. Questo significa che :

  1. Il nostro ipotetico dominio mede.it deve essere pubblicamente registrato
  2. L'interfaccia eth0 che si collega al mondo esterno deve avere un indirizzo ip fisso
  3. Il maintainer del nostro dominio, se gestisce anche il DNS "pubblico" di mede.t, deve avere un record MX che punta al nostro server per informare il mondo che il server di posta "ufficiale" di mede.it siamo noi.

Se non disponiamo di un indirizzo ip fisso esiste anche una seconda possibilità. Possiamo configurare il server in modalità relay. Senza perderci in troppe ciance diciamo che in questa modalità il nostro server non contatta direttamente i server SMTP destinatari, ma "passa" la posta al nostro server "ufficiale" (che presumibilmente stà dal nostro provider) che si occuperà del resto. I messaggi di posta interna all'azienda (ad esempio antonio@mede.it che scrive a lucia@mede.it) non usciranno all'esterno ma verranno trattati completamente dal nostro server. Il problema qui è che poi dobbiamo andarci a prendere la posta in arrivo dal server del provider se vogliamo distribuirla ai nostri utenti. Magari faremo un articoletto anche su questo.

Un lavoro di squadra

La complessità di questa parte non è tanto il server SMTP/POP3 in sè da implementare (cosa relativamente banale) ma il ping pong dei diversi servizi coinvolti in un moderno Mail Server. Purtroppo dobbiamo cercare di difenderci da virus e spam se vogliamo dare un servizio decente e far sopravvivere il nostro server per più di qualche giorno prima di venire bannati dagli altri. Il nostro MTA non fà tutto da solo, bisogna mettere in scena un coretto a 6 voci, dove 5 si passano la patata bollente l'un l'altro per convalidare una mail in arrivo. La 6° (dovecot) recapita la mail all'utente finale quando ne fà richiesta. Vediamo quali sono i nostri interpreti:

  1. Postfix : Il nostro MTA che implementa il server SMTP della nostra azienda
  2. Postgrey : Servizio che implementa il greylisting
  3. Clamav : L'antivirus usato da amavis-new per scanarizzare le mail
  4. Spamassassin : Usato da amavis-new per individuare lo spam
  5. Amavis-new : Il content filter che analizza le mail con Clamav e SpamAssassin
  6. Dovecot : IMAP e POP3 server per permettere ai nostri utenti di scaricare le mail dal server

Un bel coretto non c'è che dire ...

Installazione

Iniziamo con l'installazione dei servizi, poi andremo a configurarli uno ad uno.

Postfix

sudo pacman -S postfix

controlliamo ora che il file /etc/passwd contenga :

postfix:x:73:73::/var/spool/postfix:/bin/false

e che /etc/group contenga :

postdrop:x:75:
postfix:x:73:

Postgrey

Postgrey non è presente nei repo standard, lo dobbiamo prelevare da AUR. Prima installamo i moduli perl necessari :

sudo pacman -S perl-net-server perl-berkeleydb perl-io-multiplex 

e ora il pacchetto da AUR

yaourt -S postgrey

N.B. La prima volta che l'ho installato ho dovuto modificare il PKGBUILD perchè puntasse ai sorgente esatti. Ora sembra ok, ma comunque occhio all'output di yaourt.

Clamav

sudo pacman -S clamav

Spamassassin

sudo pacman -S spamassassin

Amavis-new

Nemmeno Amavis è nei repo. Per fortuna, ancora una volta, ci aiuta AUR. Assicuriamoci di avere i pacchetti "make" e "patch" installati :

sudo pacman -S make patch

E procediamo con Amavis, operazione lunga perchè richiede numerose librerie perl da installare.

yaourt -S amavisd-new

Alla fine rientra in gioco il mio repository radioattivo.

pacman -Sf  stenoweb/perl-file-temp

Amavis vuole "espressamente" la versione 0.19 di perl-file-temp. Noi siamo gentili e gliela forniamo.

Dovecot

sudo pacman -S dovecot

Il giochino delle parti

Bene, ora il software necessario è installato. Come funzionarà il tutto ? E' un bel balletto, vediamolo a grandi linee. Quando un messaggio arriva al nostro MTA succederà questo:

  1. Postfix controlla che mittente e destinatario soddisfino le sue impostazioni di sicurezza. Se non le soddisfano Postfix respinge la mail, se le soddisfano passa la palla a Postgrey
  2. Postgrey analizza il mittente e risponde a Postfix con un esito positivo o negativo
  3. Se la risposta di Postgrey è negativa Postfix respinge la mail, se è positiva passa la palla ad Amavis
  4. Amavis chiama Clamav per il controllo antivirus. Se Clamav trova un virus Amavis dà esito negativo a Postfix che respinge la mail, altrimenti, sempre Amavis, chiama Spamassassin per il controllo antispam.
  5. Se Spamassassin giudica la mail come Spam, Amavis risponde con esito negativo a Postfix che respinge la mail.
  6. Se Amavis dopo il controlli antivirus e antispam dà esito positivo, Postfix recapita la mail sulla mailbox dell'utente destinatario.

Uff, un bel giro in giostra fà la nostra mail ! Tutto questo ha un costo in performance, ma per evitare il più possibile spazzatura o infezioni ne vale la pena... IL termina "respinge" che ho usato è generico, in realtà la mail può venire anche archiviata e segnalata, oppure recapitata lo stesso all'utente finale con una avviso. Stà a noi decidere il comportamento che più ci soddisfa.

Configurazione

Postfix

Iniziamo la configurazione del nostro Mail Server. Il primo tassello è senza dubbio Postfix il nostro (mio?) MTA preferito. Forse il fatto che ci sia IBM all'origine ha per me il suo peso ? Bando alle ciance e via con i lavori ...

Postfix è un popolare, scalabile e sicuro MTA scritto da Witse Venema mentre lavorava in IBM. Postfix era originariamente noto come VMailer ed è stato anche commercializzato da IBM come Secure Mailer. Nel 1999, il suo nome è diventato Postfix, e il resto è storia. In questa guida l'ho scelto perchè è affidabile, veloce e (relativamente) facile da gestire. Il suo file di configurazione è facile da leggere e modificare, anche se ovviamente è utile conoscere le diverse opzioni che è possibile impostare e tutti i loro valori possibili (o almeno i principali vista la mole degli stessi...). Sono stati scritti libri interi su Postfix, quindi inutile sottolineare che questo è solo un buon punto di partenza.

Parametri di configurazione

Abbiamo già installato Postfix, ora procediamo con la configurazione base che si ottiene modificando il file /etc/postfix/main.cf , iniziamo da qui :

sudo nano /etc/postfix/main.cf

con questi parametri :

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix

myhostname e mydomain

Definiamo il nome host internet del nostro server, di default il primo è il valore ritornato da gethostbyname() , il secondo il nome del dominio :

myhostname = archi.mede.it
mydomain = mede.it

myorigin

Questo identifica i nomi di dominio da cui si assume che le mail locali arrivino e sono inviate. E' più difficile da spiegare che da scrivere :). Dal momento che noi non abbiamo bisogno di domini multipli, impostiamo questo parametro uguale a mydomain.

myorigin = $mydomain

mydestination

La lista dei domini verso i quali le mail sono inviate localmente. Insomma, per queste destinazioni le mail vengono considerate locali e trasferite alle caselle di posta locali.

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

mynetworks

Questo identifica le reti (o gli specifici host), che invieranno posta da questo server. Di default Postfix riceve le mail da tutte le interfacce di rete installate, ma permette di inviare solo dalla interfaccia di loopback (127.0.0.1) che, nel nostro caso, non và ovviamente bene. Il valore del parametro mynetworks può essere un singolo host, un indirizzo IP e la maschera di rete per indicare un range di host o di una sottorete, o qualsiasi numero di host separati da virgola o indirizzo IP e associati netmasks. Questo parametro è molto importante, deve essere presente e deve contenere SOLO la rete o gli host autorizzati, altrimenti il vostro server si trasforma in un open relay, ovvero un server attraverso cui chiunque può inviare mail. Gli open relay sono il bersaglio preferito dagli spammers, e sono, per fortuna, una razza quasi estinta (gli OpenRelay, non gli Spammers ...). Nel nostro caso il mail server permetterà alla rete interna 192.168.20.* di inviare mail attraverso di esso:

mynetworks = 127.0.0.0/8, 192.168.20.0/24

masquerade_domains

Ora i nostri utenti di rete invieranno mail ma molti client di posta inviano la mail usando il fully qualified domain name dell'host da cui inviano la mail. Per capirci meglio: se il mio host si chiama mybox e il mio utente steno chi riceve le mail che spedisco vede il mittente nella forma steno@mybox.mede.it che non è esattamente quello che voglio. Probabilmente non ho nemmeno un utente in quell'host e non riusciranno a rispondere alle mie mail. Risolviamo questo problema con il parametro masquerade_domains. Postfix sostitusce la parte domain con quanto specificato qui.

masquerade_domains = mede.it

Ora tutti gli host della mia rete possono inviare mail attraverso Posfix senza che venga identificato il nome dello specifico host che ha originato la mail. Le mail inviate dal mio host di esempio avranno come mittente steno@mede.it.

alias_maps e alias_database

Generalmente coincidono e indicano l'organizzazione e il nome del file contenenti gli alias locali: un elenco di equivalenze che permettono di attribuire più indirizzi a un unico utente

alias_maps = hash:/etc/postfix/aliases
alias_database = $alias_maps

mailbox_size_limit

Massima dimensione delle mailbox. In questo caso 0 (zero) specifica nessun limite.

mailbox_size_limit = 0

home_mailbox

Specifica dove verrà salvata la posta dell'utente relativamente alla propria home. Se non specifico nulla viene usato il formato mbox e salvato un file con il nome utente in /var/spool/mail. Io preferisco il formato Maildir, e specificando il seguente parametro ogni mail ricevuta crea un file in /home/nomeutente/Maildir

home_mailbox = Maildir/

Maggiori informazioni le trovate sul sito di postfix.

Testare Postfix

Avviamo postfix per fare un test se tutto funziona regolarmente :

sudo /etc/rc.d/postfix start

Installiamo telnet e colleghiamoci con sulla porta 25

sudo pacman -S netkit-telnet
telnet localhost 25

Dovrei ottenere la risposta:

Trying 127.0.0.1...
Connected to archi.
Escape character is '^]'.
220 archi.mede.it ESMTP Postfix

Ora iniziamo il colloquio :

helo 192.168.20.10

Postfix risponde:

250 archi.mede.it

Continuiamo a scrivere (dopo ogni riga premete invio) :

mail from:test@gmail.com
rcpt to: admin@mede.it
data
subject: Mail di prova
Salve, ti mando una mail di prova
.

Dopo il "." Postfix dovrebbe rispondermi con qualcosa di simile:

250 2.0.0 Ok: queued as 13BF410D898D

Il numerone 13BF410D898D è un numero random che cambia ogni volta. Ora digitando:

quit

Si esce. Se non avete ricevuto errori siete a posto. Magari guardiamo se admin ha ricevuto la mail, per ora ci accontentiamo di guardare il file con il nostro editor. Andiamo in /home/admin/Maildir/new e dovrei vedere un file di testo che posso editare e/o visualizzare. Ad esempio :

sudo nano /home/admin/Maildir/new/1198938050.V803I22110bM48209.archi

E' la mail che avete appena inviato ? :)

Aliases

Abbiamo configurato postfix perchè usi il file /etc/postfix/aliases per gli alias, facciamo una piccola modifica al file perchè mandi le mail di sistema al nostro utente admin anzichè al predefinito (che abbiamo disabilitato) root.

sudo nano /etc/postfix/aliases

All'inizio del file dovrei vedere una cosa del genere (se non c'e' basta aggiungerla) :

#Person who should get root's mail. Don't receive mail as root!
#root:          you

Togliamo il commento dalla seconda riga a mettiamo admin:

root:          admin

Usciamo dall'editor e digitiamo:

newaliases

Ora le mail dirette a root verranno girate al nostro utente admin.

Avvio del servizio

Come al solito includiamo postfix dell'array DAEMONS in /etc/rc.conf :

DAEMONS=(... ... ... ... ... postfix ... ... ...)

Tutto qua ?

Ora il nostro server può inviare mail dalla nostra rete. Tutto qua ? Eh eh, magari. Diciamo che già funziona, e in un mondo perfetto di sole persone oneste potremmo fermarci qua. Peccato non sia così e che dobbiamo difenderci dai rompic... che popolano la rete e che vogliono magari venderci pillole blu anche a Natale...

Meglio rimboccarci le maniche e vedere come possiamo almeno rendere loro la vita un po' più difficile.

Filtraggio della posta

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 più avanti.
  • 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.