Indice dei contenuti dell'articolo:
Perché parlare di Postscreen quando si usa Postfix?
Postfix è uno degli MTA più solidi, diffusi e apprezzati in ambito Linux. È stabile, modulare, performante e adatto sia a piccoli server mail aziendali sia a infrastrutture di posta più complesse. Tuttavia, un server Postfix esposto su Internet, soprattutto sulla porta SMTP 25, non dialoga solo con mail server legittimi. Dialoga anche con botnet, zombie host, scanner automatici, client SMTP mal configurati e sistemi compromessi che tentano continuamente di inviare spam, testare relay aperti o saturare le risorse del servizio.
In una configurazione “nuda e cruda”, Postfix riceve la connessione direttamente tramite il demone smtpd. Questo approccio funziona, ma significa che ogni client remoto arriva subito al cuore del servizio SMTP. Anche quando il client è palesemente malevolo o non conforme al protocollo, Postfix deve comunque impegnare processi, memoria, lookup DNS, controlli sulle restriction class, eventuali policy service e, nei casi peggiori, filtri antispam più pesanti.
Postscreen nasce proprio per risolvere questo problema: mettere davanti a Postfix un filtro leggero, specifico per la porta 25, capace di distinguere rapidamente i client SMTP legittimi dai client sospetti, prima che questi possano occupare risorse preziose del vero servizio smtpd.
Che cos’è Postscreen
Postscreen è un componente di Postfix progettato per agire come prima linea di difesa SMTP. Non sostituisce SpamAssassin, Rspamd, Amavis, ClamAV o le normali regole antispam; lavora prima. Il suo scopo non è analizzare il contenuto delle email, ma valutare il comportamento del client che si connette.
La logica è semplice: molti spam bot non si comportano come un vero mail server. Alcuni inviano comandi prima ancora di ricevere il banner SMTP, altri ignorano i tempi corretti del protocollo, altri provengono da IP con pessima reputazione o presenti in DNSBL note. Postscreen sfrutta queste anomalie per bloccare o ritardare i client sospetti, lasciando passare verso smtpd solo quelli che superano i controlli.
Il vantaggio è evidente: il server SMTP vero e proprio viene coinvolto solo quando necessario. Questo riduce il carico, migliora la resilienza del servizio e permette al sistema di reggere meglio picchi di connessioni indesiderate.
Come funziona rispetto a un Postfix tradizionale
Con Postfix configurato in modo tradizionale, il flusso tipico è questo: un client remoto si connette alla porta 25, Postfix risponde con il banner SMTP, il client invia HELO o EHLO, poi procede con MAIL FROM, RCPT TO e il resto della sessione. Durante questa fase vengono applicate le restrizioni configurate in main.cf, come controlli su mittente, destinatario, HELO, relay, reverse DNS, RBL e così via.
Il problema è che, anche quando la connessione arriva da un bot grossolano, Postfix deve comunque avviare una sessione smtpd. Se le connessioni sono poche, il problema è marginale. Se invece il server è bersagliato da migliaia di tentativi al giorno, o da picchi improvvisi di connessioni parallele, questo comportamento può diventare costoso.
Con Postscreen il flusso cambia. Il servizio esposto sulla porta 25 diventa postscreen, mentre smtpd rimane dietro le quinte. Quando un client si collega, Postscreen effettua una serie di test preliminari. Se il client si comporta correttamente e non risulta sospetto, viene passato al vero demone SMTP. Se invece fallisce i controlli, può essere rifiutato, temporaneamente respinto o semplicemente ignorato in base alla configurazione.
In pratica, Postscreen funziona come un buttafuori SMTP: non giudica il contenuto del messaggio, ma decide chi può entrare nella sala dove lavora Postfix.
I problemi concreti che Postscreen risolve
Il primo problema è il consumo inutile di processi smtpd. Ogni connessione gestita direttamente da smtpd ha un costo. In presenza di spam bot, questo costo non produce alcun beneficio, perché molte connessioni verranno comunque rifiutate. Postscreen riduce il numero di sessioni che arrivano a smtpd, mantenendo più risorse disponibili per i server legittimi.
Il secondo problema è il rischio di sovraccarico SMTP. Durante campagne massive di spam, il server può trovarsi con molti processi occupati da client lenti, aggressivi o volutamente malformati. Postscreen è pensato proprio per ritardare l’insorgenza di condizioni di overload, filtrando prima i client meno affidabili.
Potete vedere nel grafico sopra, una riduzione di circa il 70% di carico di CPU solo passando da postfix classico a Postscreen più postfix, per un mail server che gestisce circa 6000 caselle di posta attive.
Il terzo problema riguarda i bot che non rispettano il protocollo SMTP. Un mail server legittimo attende il banner prima di inviare comandi. Molti bot, invece, inviano subito dati appena aperta la connessione. Questo comportamento, noto come pregreet, è un segnale forte di automazione scadente o software malevolo. Postscreen può rilevarlo e bloccare il client.
Il quarto problema è l’abuso delle DNSBL direttamente dentro smtpd. Anche Postfix può fare controlli RBL nelle restrizioni SMTP, ma eseguirli dentro la sessione smtpd significa coinvolgere comunque il demone principale. Postscreen permette di anticipare questi controlli, usando pesi e soglie per decidere se un IP è sufficientemente sospetto da essere respinto prima.
I principali controlli di Postscreen
Postscreen applica diversi test, alcuni prima del banner SMTP e altri dopo. Tra i più importanti troviamo il pregreet test, che verifica se il client invia comandi troppo presto. Un client conforme deve attendere il saluto del server. Chi parla prima del tempo viene considerato sospetto.
Un altro controllo fondamentale è l’integrazione con le DNSBL. È possibile configurare una o più blacklist DNS, assegnare pesi diversi e definire una soglia oltre la quale il client viene rifiutato. Questo consente un approccio più flessibile rispetto al semplice “presente/non presente in blacklist”. Ad esempio, si può dare più peso a una lista molto affidabile e meno peso a una lista più aggressiva.
Postscreen può inoltre verificare comportamenti come pipelining improprio e comandi non SMTP. Anche in questo caso, l’obiettivo non è penalizzare i mail server corretti, ma intercettare client automatici che tentano di accelerare la sessione ignorando le regole del protocollo.
Un elemento importante è la cache. Quando un client supera i test, Postscreen può ricordarlo per un certo periodo. Questo evita di ripetere continuamente gli stessi controlli su IP già considerati affidabili, riducendo ulteriore latenza e carico operativo.
I vantaggi principali di Postscreen
Il primo vantaggio è la riduzione del carico sul servizio SMTP. Meno bot arrivano a smtpd, meno processi vengono impegnati, meno risorse vengono consumate per connessioni inutili. Su server ad alto traffico, questa differenza può essere significativa.
Il secondo vantaggio è una migliore resistenza agli attacchi volumetrici di basso livello. Postscreen non è un sistema anti-DDoS in senso stretto, ma aiuta molto contro ondate di connessioni SMTP generate da spam bot e host compromessi.
Il terzo vantaggio è la pulizia dei log e del flusso antispam. Bloccando prima i client peggiori, si riduce la quantità di messaggi che arrivano ai livelli successivi. Questo rende più efficiente anche l’analisi da parte di Rspamd, SpamAssassin o altri filtri.
Il quarto vantaggio è la possibilità di adottare una logica più intelligente sulle blacklist. Non è necessario bloccare in modo cieco appena un IP compare in una singola lista: si possono combinare punteggi, soglie e azioni, ottenendo un equilibrio migliore tra protezione e riduzione dei falsi positivi.
Infine, Postscreen è integrato in Postfix. Non richiede un proxy esterno complesso, non introduce architetture inutilmente pesanti e si configura con i normali file master.cf e main.cf.
Un esempio di configurazione
Una configurazione tipica prevede che la porta 25 venga gestita da Postscreen e che il demone smtpd sia richiamato solo dopo il superamento dei controlli.
# Estratto esemplificativo di master.cf smtp inet n - y - 1 postscreen smtpd pass - - y - - smtpd dnsblog unix - - y - 0 dnsblog tlsproxy unix - - y - 0 tlsproxy
Nel file main.cf si possono poi definire i controlli principali:
# Estratto esemplificativo di main.cf postscreen_greet_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net*2 postscreen_dnsbl_threshold = 3 postscreen_dnsbl_action = enforce postscreen_cache_map = btree:$data_directory/postscreen_cache
Questo esempio va considerato una base di partenza, non una configurazione universale. La scelta delle DNSBL, dei pesi, delle soglie e delle azioni deve essere fatta in base al volume di posta, alla criticità del dominio, alla qualità dei mittenti abituali e alla tolleranza verso eventuali falsi positivi.
Postscreen non sostituisce un antispam
È importante chiarire un punto: Postscreen non analizza il contenuto delle email. Non valuta allegati, URL, reputazione del dominio mittente, firme DKIM, SPF, DMARC o pattern testuali. Per questi aspetti servono strumenti dedicati come Rspamd, SpamAssassin, Amavis, ClamAV e policy specifiche.
Postscreen lavora prima. Il suo compito è ridurre il rumore alla porta, impedendo che client palesemente inaffidabili arrivino agli strati successivi. In una buona architettura mail, Postscreen è quindi il primo livello di una difesa più ampia: dopo di lui ci sono le restriction di Postfix, i controlli SPF/DKIM/DMARC, l’antivirus, l’antispam bayesiano o statistico, le policy aziendali e l’eventuale quarantena.
Attenzione a dove viene usato
Postscreen è pensato per la posta in ingresso sulla porta 25, cioè per il traffico tra mail server. Non va usato in modo indiscriminato sulle porte di submission, come 587 o 465, dove si collegano client autenticati, applicazioni, gestionali, CRM o dispositivi aziendali. In quei casi il comportamento SMTP può essere diverso e l’obiettivo non è filtrare server remoti sconosciuti, ma accettare utenti autenticati in modo sicuro.
Questo è un punto essenziale in ambienti hosting e managed: una configurazione errata può causare problemi ai clienti legittimi. Postscreen deve proteggere l’MX pubblico, non complicare la vita agli utenti che inviano posta tramite autenticazione SMTP.
Pro e contro di Postscreen
Tra i pro troviamo sicuramente la leggerezza, l’integrazione nativa con Postfix, la capacità di filtrare prima del demone smtpd, la gestione dei test comportamentali e l’uso intelligente delle DNSBL. Per molti server mail, abilitarlo correttamente significa ridurre in modo netto il numero di connessioni inutili e migliorare la stabilità generale del servizio.
Il principale contro è che richiede attenzione. Una configurazione troppo aggressiva può respingere mittenti legittimi, soprattutto se si usano DNSBL non affidabili o soglie troppo basse. Inoltre, in ambienti con grandi volumi di traffico, è opportuno usare resolver DNS locali e cache efficaci, perché i controlli DNSBL dipendono dalla qualità e dalla rapidità delle risoluzioni DNS.
Un altro limite è che Postscreen non risolve problemi di reputazione del dominio, compromissione di account SMTP, abuso da parte di utenti autenticati o spam generato internamente. Per questi scenari servono logiche differenti: rate limit, controlli sulle autenticazioni, analisi outbound, monitoraggio delle code e policy di sicurezza applicate agli account.
Perché è utile in un’infrastruttura managed
In un contesto professionale, specialmente su server mail gestiti, VPS, hosting dedicati o infrastrutture multi-dominio, Postscreen offre un vantaggio operativo molto concreto: riduce il lavoro inutile prima che diventi un problema. Questo si traduce in meno processi occupati, meno pressione sui filtri antispam, tempi di risposta più stabili e maggiore capacità di assorbire traffico indesiderato.
Dal punto di vista sistemistico, è uno di quegli interventi che non fanno “magia”, ma migliorano la qualità complessiva del servizio. Non basta abilitarlo: va monitorato, calibrato, testato sui log e adattato al traffico reale. Quando configurato correttamente, però, diventa un componente estremamente efficace nella protezione SMTP.
Conclusione
Postfix, anche da solo, è un MTA eccellente. Ma un Postfix esposto direttamente su Internet senza un filtro preliminare deve spendere risorse anche per client che non meritano di arrivare alla sessione SMTP vera e propria. Postscreen risolve questo problema introducendo un livello di selezione iniziale, leggero e specializzato.
Rispetto a un Postfix “nudo e crudo”, Postscreen permette di bloccare prima molti spam bot, ridurre il carico su smtpd, migliorare la resilienza del server e rendere più efficiente tutta la catena antispam. Non sostituisce i filtri di contenuto e non elimina la necessità di una configurazione mail completa, ma rappresenta una delle migliori pratiche per proteggere la porta 25.
Per chi gestisce server Linux, infrastrutture mail e ambienti hosting professionali, Postscreen è un alleato prezioso: semplice nel concetto, potente negli effetti e perfettamente coerente con una filosofia di amministrazione orientata a sicurezza, performance e continuità del servizio.
