Postfix Spam Filter · 13 min read · Nov 14, 2025
Filtro Spam Postfix utilizzando Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC e ClamAV - Pagina 3
2.3 Impostazioni Anti-Spam di Postfix
Note preliminari:
Quando un client (un computer che cerca di inviarci posta) si connette a Postfix e inizia una sessione di comunicazione, Postfix registra informazioni su quella sessione. Prima del punto in cui Postfix accetta la posta da quella sessione per la consegna, abbiamo la possibilità di valutare la sessione e rifiutare la posta impostando alcune restrizioni in main.cf. Questo link illustra cosa succede durante una tipica sessione SMTP: http://helpdesk.islandnet.com/pep/smtp.php. Le restrizioni di seguito aiutano a respingere un po’ di spam e a prevenire che il nostro sistema diventi un relay aperto. Queste restrizioni fanno sì che alcune email vengano rifiutate da Postfix proprio alla “porta d’ingresso”. Questo farà risparmiare risorse di sistema perché la posta non entrerà nel nostro sistema e quindi non verrà scansionata da MailScanner (e successivamente da SpamAssassin). Questo è sia positivo che negativo. Risparmia risorse di sistema, ma non ti permette nemmeno di vedere la posta rifiutata. Tutto ciò che vedrai è una o due voci di log da Postfix che dicono essenzialmente “Ehi, un server di posta chiamato “xxxxxxxx” all’indirizzo IP X.X.X.X ha provato a inviare della posta, ma ha infranto la regola XYZ, quindi l’ho rifiutata”. Ora, questo potrebbe essere stato spam (gli spammer spesso non seguono intenzionalmente le RFC per raggiungere i loro obiettivi), ma se si trattava di una posta “legittima”, ad esempio da un cliente il cui dipartimento IT ha semplicemente configurato male il proprio server di posta (può succedere), potresti dover affrontare qualche malinteso.
Se desideri consentire a TUTTA la posta indirizzata a noi di entrare dalla porta principale, e quindi consentire a MailScanner/SpamAssassin di gestire tutto il controllo dello spam all’interno del sistema, dovresti modificare un paio delle impostazioni di seguito. Personalmente trovo che una combinazione di controllo anti-spam di Postfix e SpamAssassin sia la migliore. Almeno devi assicurarti di non disabilitare il controllo anti-relay predefinito integrato in Postfix ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
La configurazione di seguito è in realtà molto conservativa, consentendo alla maggior parte delle email di entrare dalla porta principale in modo che MailScanner e SpamAssassin possano fare il loro lavoro. Per me rifiuta (in modo sicuro) circa il 35% delle email destinate ai miei utenti, quindi penso che queste impostazioni siano piuttosto preziose. Raccomando questo approccio per iniziare. Aggiungere ulteriori restrizioni aumenterà la probabilità di rifiutare email valide da computer configurati in modo errato. Se decidi di aggiungere/rimuovere permessi/restrizioni in futuro, fallo uno alla volta e concediti ampio tempo per valutare l’effetto della modifica. Ti consiglio vivamente di avere una buona comprensione di come funzionano queste restrizioni prima di apportare modifiche alle voci di seguito. Tra le altre cose, sbagliare queste impostazioni potrebbe rifiutare posta legittima e/o farci diventare un relay aperto. Nota che le restrizioni non sempre limitano, alcune consentono anche.
Se desideri ottenere una migliore comprensione di queste impostazioni, buone risorse sono http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, il datato (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt, e questo eccellente libro. Noterai che utilizzo solo un paio delle stesse impostazioni di queste, quindi questa configurazione non è affatto così restrittiva. Tieni presente che SpamAssassin e MailScanner entreranno in gioco tra un po’, e ci forniranno opzioni molto più flessibili e configurabili per riconoscere e manipolare lo spam.
2.3.1 smtpd_helo_required
Fai in modo che qualsiasi server di posta connesso esegua un corretto “handshake” smtp e annunci il proprio nome. Le RFC di Internet richiedono questo, quindi lo facciamo anche noi.
postconf -e "smtpd_helo_required = yes"Prefazione: Le fasi di restrizione di Postfix sono le seguenti e vengono elaborate nel seguente ordine:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictionsPosizioneremo solo voci nelle ultime tre fasi di restrizione. Le fasi di restrizione vengono elaborate in questo ordine indipendentemente dall’ordine elencato in main.cf.
2.3.2 smtpd_sender_restrictions
Questa fase di restrizione limita quali indirizzi del mittente questo sistema accetta nei comandi MAIL FROM: (il mittente della busta). Posizioneremo tre test (restrizioni) in questa fase di restrizione.
Una fase di restrizione contiene un elenco di restrizioni (test). Tipicamente, i test valutano a DUNNO, REJECT o OK. DUNNO significa “Non so cosa fare, lascia decidere il test successivo”. REJECT rifiuta semplicemente la posta. OK significa che non vengono eseguiti ulteriori test in questa fase di restrizione, i test continuano con la fase successiva (se presente). I test di tipo Reject* valutano tipicamente a REJECT o DUNNO. I test di tipo Permit valutano tipicamente a OK o DUNNO, e i test di tipo check__access possono eseguire una varietà di azioni. L’illustrazione mostra la logica di base.
Sessione SMTP
|
V
fase di restrizione-------------
test ---------------REJECT->
| \
| DUNNO
| \
| V
| test successivo------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
fase di restrizione successiva------->2.3.2.1 check_sender_access
Vedi http://www.postfix.org/access.5.html. Qui chiediamo a Postfix di confrontare il mittente della busta con le voci in un database /etc/postfix/sender_access e agire su quelle voci se viene trovata una corrispondenza. Definiamo anche quale azione viene intrapresa lì (OK, DUNNO, REJECT, ecc.) su base mittente per mittente. Se il mittente non è elencato nel file, il test valuta a DUNNO e viene eseguito il test successivo. Fornirò esempi un po’ più tardi. Un uso di questo file è quello di inserire un elenco di mittenti (indirizzi email, domini, indirizzi di rete, ecc.) dai quali non desideriamo ricevere posta (metterli nella blacklist). Avremo anche la possibilità di mettere in blacklist i mittenti in MailScanner e SpamAssassin, ma risparmierà risorse se li mettiamo in blacklist qui. Utilizzeremo anche questo file per consentire a specifici mittenti di bypassare i successivi due test in questa fase di restrizione. Se diamo loro un OK qui, non vengono eseguiti ulteriori test in questa fase di restrizione, i test continuano nella fase di restrizione successiva ( smtpd_recipient_restrictions). Nota che se dovessimo posizionare questa impostazione nella fase di restrizione smtpd_recipient_restrictions prima del test reject_unauth_destination, e dovessimo dare a qualcuno l’OK lì, il test reject_unauth_destination situato lì verrebbe bypassato. Questo sarebbe negativo perché chiunque avesse ricevuto l’OK potrebbe quindi utilizzare il nostro server come un relay aperto. Le restrizioni di accesso vengono valutate nell’ordine in cui le elenchiamo, e se viene trovata una corrispondenza influenzerà come (se) vengono valutate ulteriori restrizioni.
2.3.2.2 reject_non_fqdn_sender
Rifiuta quando l’indirizzo email del mittente della busta non è nel formato corretto. Ricorda, il “mittente della busta” è ciò che il server di posta mittente fornisce nella riga “MAIL FROM:” durante la sessione SMTP, non la riga “From:” dell’intestazione. “Joe” non è autorizzato a inviarci posta (perché non possiamo rispondere a “Joe”), ma “[email protected]” è almeno un indirizzo email. Se il mittente non viene rifiutato a questo punto, questo test valuta a “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Rifiuta quando la parte del dominio del mittente della busta dell’indirizzo email non ha alcun record DNS “A” o “MX”. Questa impostazione respinge circa il 35% della posta in arrivo al mio server di posta. È comune per gli spammer utilizzare un nome di dominio falso in modo da non dover affrontare le conseguenze della posta rifiutata. È anche importante per noi non riempire la nostra coda con avvisi di rimbalzo che non possono mai essere consegnati a causa del fatto che il dominio del mittente non esiste nemmeno. Se il dominio del mittente ha un record “A” o “MX”, questo test valuterà anche a “DUNNO”. Di tanto in tanto, vedrai in un rapporto che qualcuno da cui desideri ricevere posta è stato rifiutato da questa impostazione. Una possibile causa di questo è quando mittenti legittimi usano deliberatamente nomi di dominio falsi in modo che tu non possa rispondere a loro. Qui entra in gioco l’elenco di accesso del mittente. Puoi dare loro un OK lì, e questo test verrà bypassato.
Ora per implementare queste tre restrizioni:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
Le restrizioni di accesso che il server SMTP di Postfix applica nel contesto del comando RCPT TO:. Questo si riferisce al “mittente della busta” che è ciò che il client ha fornito nella riga “RCPT TO:” durante la sessione SMTP, non la riga “To:” dell’intestazione. smtpdrecipient_restrictions è un’altra fase di restrizione che contiene un elenco di restrizioni specifiche. Altre fasi di restrizione che vengono valutate prima di smtpd_recipient_restrictions sono smtpd_client_restrictions, smtpd_helo_restrictions e smtpd_sender_restrictions (in quest’ordine). Le restrizioni che normalmente andrebbero in queste fasi di restrizione precedenti possono alternativamente essere posizionate in smtpd_recipient_restrictions. Pertanto, alcune persone preferiscono posizionare tutte le smtpd*_restrictions che normalmente andrebbero nelle fasi di restrizione precedenti in smtpd_recipient_restrictions (nell’ordine corretto) e lasciare le fasi precedenti non configurate (vuote). Nel nostro caso è più sicuro utilizzare smtpd_sender_restrictions e smtpd_recipient_restrictions. Diamo un’occhiata a quelle restrizioni specifiche (test) che posizioniamo in smtpd_recipient_restrictions:
2.3.3.1 permit_mynetworks
Consente alle macchine elencate in “mynetworks” di saltare il resto dei test in questa fase di restrizione (permit = OK). In altre parole, esce da questa fase e viene testato nella fase successiva (smtpd_data_restrictions). Poiché permit_mynetworks è posizionato davanti a reject_unauth_destination, questo significa che le macchine in $mynetworks sono autorizzate a inoltrare posta a qualsiasi dominio. Senza questo, potremmo inviare posta solo ai nostri domini. Se l’indirizzo IP del mittente non è elencato in $mynetworks, il test valuta a “DUNNO” e continua al test successivo (reject_unauth_destination).
2.3.3.2 reject_unauth_destination
Questo, insieme a permit_mynetworks, è utilizzato per il controllo del relay. Questa impostazione, in sostanza, significa che la posta destinata a qualsiasi dominio per il quale non abbiamo configurato la nostra macchina per accettare posta verrà rifiutata. Nel nostro caso, Postfix utilizzerà l’impostazione (o tabella) relay_domains che abbiamo configurato in precedenza per determinare quali sono quei domini. Vedi http://www.postfix.org/postconf.5.html#reject_unauth_destination per ulteriori dettagli. Se il dominio è elencato in relay_domains, questo test valuta a “DUNNO” e la sessione è autorizzata a proseguire al test successivo (se presente). Proprio come “mynetworks”, questa impostazione è estremamente critica. Posizionando permit_mynetworks direttamente davanti a reject_unauth_destination, siamo certi di poter inviare posta a domini diversi dai nostri, ma accetteremo solo posta indirizzata a noi da computer esterni alla nostra rete, quindi permit_mynetworks e reject_unauth_destination lavorano come una squadra.
2.3.3.3 reject_unauth_pipelining
Rifiuta i mittenti di massa che tentano di utilizzare il pipelining per accelerare la consegna, senza controllare prima se è supportato (non RFC, comune tra gli spammer).
Ora per implementare queste tre restrizioni:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Restrizioni di accesso opzionali che il server SMTP di Postfix applica nel contesto del comando SMTP DATA:. Come smtpd_recipient_restrictions, questa è una fase di restrizione.
2.3.4.1 reject_unauth_pipelining
Ripeto questa impostazione in smtpd_data_restrictions poiché non è sempre efficace quando posizionata in smtpd_recipient_restrictions. La includo in smtpd_recipient_restrictions poiché mi piace posizionarla prima di qualsiasi server di policy. Nota che ci sono solo un paio di restrizioni che fanno buon uso di smtpd_data_restrictions.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 File di controllo del filtro dei contenuti di Postfix:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks e /etc/postfix/body_checks
Questi file elencheranno alcune “stringhe” di testo e diranno a Postfix cosa fare con la posta se incontra queste stringhe nelle intestazioni delle email o nel corpo del messaggio. I file di esempio sono già stati creati per noi, con commenti che spiegano cosa inserire in essi. Puoi modificarli a tuo piacimento. Nota che questi file richiedono l’uso del “formato di espressione regolare”. “regexp” è qualcosa che vorrai imparare per vivere nel mondo *nix. Prendi un libro o fai ricerche su di esso su Internet qualche volta. Per un esempio di un elaborato file header_checks da qualcuno con un atteggiamento, dai un’occhiata a http://www.geekounet.org/filters/header_checks. Ma non seguire ciecamente questo, è solo un esempio! Ecco un esempio di un file body_checks: http://www.securitysage.com/files/body_checks. Varrebbe la pena controllare http://www.securitysage.com/guides/postfix_uce.html quando hai un momento di svago. Specificamente http://www.securitysage.com/antispam/hedchek.html e http://www.securitysage.com/antispam/bodchek.html. Raccomando di non apportare un gran numero di modifiche a qualsiasi parte di Postfix senza concederti ampio tempo per valutare gli effetti. Come una tartaruga, vai piano, vivi a lungo.
2.3.5.1 header_checks & body_checks
Procediamo a inserire questi due in main.cf. header_checks è necessario perché ci consente di trattenere tutte le email in arrivo affinché MailScanner faccia il suo lavoro:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Modifica header_checks:
vi /etc/postfix/header_checksAggiungi questa riga al file header_checks, senza di essa MailScanner non funzionerà:
/^Received:/ HOLDNota che non dobbiamo postmap le tabelle di tipo pcre. Rimangono testo semplice e Postfix le utilizza “così come sono”.
Puoi anche configurare mime_header_checks e nested_header_checks insieme a header_checks e body_checks. Se diventi troppo creativo con il filtraggio dei contenuti in Postfix (utilizzando header_checks e body_checks), può avere un impatto significativo sulle prestazioni.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Abbiamo fatto riferimento a questo file in smtpd_sender_restrictions. Utilizziamo questo file per controllare il mittente proprio alla porta d’ingresso. In questo file, elencheremo alcuni mittenti/domini/intervalli di indirizzi IP per un trattamento speciale. Di seguito ci sono esempi falsi, crea i tuoi come meglio credi. Si prega di leggere /etc/postfix/sender_access per ulteriori informazioni. Anche se potresti utilizzare questo file per vari scopi, considerando il modo in cui lo abbiamo impostato in smtpd_sender_restrictions, suggerisco di utilizzarlo per mettere in blacklist i mittenti o consentire a determinati mittenti di bypassare i restanti test in smtpd_sender_restrictions.
vi /etc/postfix/sender_access#File di esempio per la mappa di accesso del mittente
[email protected] 550 No MLM grazie
allspam.tld 550 Lo spam non è accettato qui
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKPoiché questa è una tabella hash, devi postmaparla come al solito:
postmap /etc/postfix/sender_access2.3.6 Ultima occhiata all’installazione di Postfix
Rivedi le modifiche:
less /etc/postfix/main.cfControlla il contenuto del file per errori e ripara se necessario. Avvia Postfix:
postfix startControlla che Postfix risponda:
telnet 127.0.0.1 25Dovresti vedere:
220 [yourFQDNhere] ESMTP Postfix (Ubuntu)premi [invio] un paio di volte; quindi digita quit per uscire.
Se non risponde in questo modo, apri un’altra finestra del terminale e ferma Postfix postfix stop. Assicurati di aver eseguito newaliases e tutti i comandi postmap sopra. Controlla tutte le impostazioni in main.cf e master.cf. C’è un bel documento sulla risoluzione dei problemi di Postfix su http://www.postfix-book.com/debugging.html ma tieni presente che il nostro sistema non è pronto per inoltrare posta a questo punto (finirà nella coda).
Ogni volta che apporti modifiche a master.cf o main.cf o alle tabelle di dati, la maggior parte (non tutte) delle volte, è necessario ricaricare Postfix con:
postfix reloadOra che abbiamo una configurazione di base di Postfix, http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall e http://www.postfix.org/BASIC_CONFIGURATION_README.html sono buoni posti per ottenere una migliore comprensione di alcune delle impostazioni che abbiamo utilizzato e a questo punto questi README avranno più senso.
Per impostazione predefinita, il nostro Postfix viene eseguito in chroot. Se non sai cosa significa, non avrà molta importanza a questo punto. Lascio a te il compito di ricercare cosa significa chroot in un secondo momento. Alcuni dei file di sistema di cui Postfix ha bisogno per funzionare correttamente sono stati copiati nella prigione chroot di Postfix ( /var/spool/postfix) durante l’installazione. Di tanto in tanto, i file originali verranno modificati e Postfix si lamenterà che la copia che ha non è la stessa dell’originale. Quando ciò accade, puoi copiare manualmente il file(i) di cui Postfix si è lamentato nella prigione chroot, oppure possiamo semplicemente eseguire uno script fornito con il codice sorgente di Postfix (chiamato LINUX2) che copierà di nuovo tutti i file di cui Postfix ha bisogno dove ne ha bisogno.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkQuesto rende lo script LINUX2 eseguibile, lo copia in una directory nel nostro percorso, quindi lo esegue. LINUX2 risolverà solitamente eventuali problemi o difficoltà con Postfix se vedi errori nei log con Postfix che accede a file o directory di configurazione.
Ricevi i nuovi post nella tua casella di posta.
Nessuno spam. Disiscriviti in qualsiasi momento.