Postfix 3.10: aggiornamenti, TLSRPT e il percorso verso la versione 3.11

Collocare correttamente nel tempo Postfix 3.10

Alla data della ricerca, il 20 ottobre 2026, Postfix 3.10 non è il ramo di sviluppo stabile attuale: tale ruolo spetta a Postfix 3.11. Il produttore indica la versione 3.10 come Ramo legacy, ma continua a fornirgli correzioni di bug e di sicurezza. Negli annunci ufficiali, Postfix 3.10.14 del 7 settembre 2026 è indicato come l'ultima versione disponibile per questo ramo.

Questa classificazione distingue due tipi diversi di aggiornamenti. Un aggiornamento di manutenzione, ad esempio dalla versione 3.10.8 a una patch più recente della serie 3.10, mantiene il ramo funzionale selezionato e ne applica le correzioni. Un upgrade alla versione 3.11, invece, comporta il passaggio a un ramo di sviluppo diverso e deve quindi essere verificato in termini di modifiche alle funzionalità, compatibilità di configurazione, estensioni e procedure operative. Il passaggio a un ramo principale e secondario superiore non è automaticamente la misura più adatta per ogni sistema produttivo.

Per i pacchetti Linux, oltre alla versione visibile di Postfix, controlla i metadati del pacchetto, il changelog e le note di sicurezza fornite dal fornitore del sistema operativo. Verifica quali correzioni contiene quel pacchetto specifico e se il fornitore documenta i backport. L’annuncio upstream, invece, descrive il rilascio di Postfix e non attesta alcuna politica generale di backport da parte di una distribuzione.

Per la pianificazione della manutenzione, ciò significa: documentare innanzitutto la versione del pacchetto installato, il canale del repository e le personalizzazioni locali. Successivamente, verificare quali correzioni siano state segnalate dal fornitore del sistema operativo per quel pacchetto. Solo questo confronto mostra se è presente un aggiornamento in sospeso Aggiornamento di Postfix se sia necessario passare alla versione 3.10 o se un passaggio pianificato alla versione 3.11 comporterebbe un ulteriore vantaggio tecnico. Il punto 3.10.14 costituisce in questo contesto un punto di riferimento a monte, non una guida all’installazione per un determinato sistema Linux.

Ruolo MTA, porte SMTP e limiti di sistema

Postfix è un Agente di trasferimento della posta (MTA). Accetta le e-mail tramite SMTP, decide in merito all’ulteriore elaborazione in base alla propria configurazione di routing e alle politiche applicate e inoltra i messaggi ad altri server di posta o a percorsi di consegna locali. Postfix costituisce quindi il livello di trasporto di un server di posta sotto Linux. La sua configurazione, tuttavia, non determina automaticamente il modo in cui gli utenti consultano le proprie caselle di posta né come vengono valutati i contenuti sospetti.

Un server IMAP o POP3 mette a disposizione caselle di posta per i programmi di posta elettronica ed è un componente distinto dal trasporto SMTP. Allo stesso modo, le funzioni di Postfix non sostituiscono una soluzione completa di filtraggio antispam o antivirus: tali sistemi devono essere opportunamente integrati, gestiti e monitorati, se necessario. Questa distinzione è rilevante dal punto di vista pratico, poiché un test SMTP riuscito non garantisce né il corretto recupero di una casella di posta né la qualità di un controllo dei contenuti.

La porta 25 è solitamente utilizzata per il traffico SMTP tra i server di posta e, di conseguenza, per il funzionamento pubblico degli MX. Le porte 587 e 465 sono invece destinate all'invio da parte dei client di posta, solitamente con autenticazione e una propria definizione di servizio. Postfix non solo gestisce questi ruoli in modo diverso dal punto di vista organizzativo: alcune impostazioni non possono o non dovrebbero essere applicate in modo generalizzato a tutti i servizi SMTP.

Prima di apportare modifiche, è necessario disporre dei diritti di amministratore, di un backup ripristinabile della configurazione di Postfix e di una finestra di manutenzione compatibile con la coda, i tempi di consegna e le applicazioni collegate. Inoltre, verifica se il server invia messaggi in uscita, riceve come MX pubblico o offre il servizio di consegna client. Questi cessazione dal servizio impedisce che una decisione in materia di protezione dei dati, opportuna ai fini della presentazione, modifichi inavvertitamente la porta 25 accessibile al pubblico.

TLSRPT garantisce una consegna sicura della posta

Postfix 3.10 offre il supporto opzionale per TLSRPT nel client SMTP. I domini possono pubblicare tramite DNS un destinatario per i rapporti TLS aggregati; la RFC 8460 consente l’uso di indirizzi e-mail e endpoint HTTPS. Postfix segnala solo il successo o il fallimento degli handshake TLS, al massimo uno stato finale per ogni connessione SMTP. I tentativi di connessione falliti e le interruzioni prima o dopo l'handshake TLS non vengono registrati.

Il numero di versione 3.10, tuttavia, non è di per sé sufficiente a dimostrare che un pacchetto Postfix installato sia effettivamente in grado di utilizzare TLSRPT. La funzionalità presuppone che Postfix sia configurato con una libreria client TLSRPT compatibile e l'opzione di compilazione USE_TLSRPT è stato creato. Prima di pianificare la configurazione, devi quindi verificare, sulla base della documentazione del pacchetto, delle caratteristiche di compilazione indicate e dei pacchetti aggiuntivi disponibili, se la tua distribuzione include tale supporto.

TLSRPT integra procedure che influenzano effettivamente la protezione TLS di una consegna. STARTTLS consente la negoziazione di una crittografia di trasporto. DANE utilizza le voci TLSA e presuppone il DNSSEC per i propri presupposti di sicurezza; MTA-STS pubblica una policy relativa alle caratteristiche TLS previste. Se un requisito DANE o MTA-STS vincolante non viene soddisfatto, TLSRPT può fornire indicazioni a valle su tali errori. Tuttavia, non attiva né la crittografia né la verifica dei certificati.

A tal proposito occorre distinguere due ruoli. Il dominio ricevente pubblica un punto finale rua e gestisce o affida a terzi la ricezione monitorata e l’analisi dei rapporti in arrivo. Un MTA segnalante, invece, necessita di un Postfix configurato e attivato in modo adeguato, nonché di un’infrastruttura separata che raccolga, recuperi, aggreghi gli eventi e invii i report. Queste due prospettive possono essere separate dal punto di vista organizzativo; un titolare di dominio che pubblica i report non è tenuto a generare i report TLSRPT direttamente sullo stesso sistema.

Un plugin per le politiche TLS non fa quindi parte, in generale, di ogni catena di report TLSRPT. Postfix supporta direttamente DANE. Un plugin adeguato diventa particolarmente rilevante quando l’MTA mittente invia informazioni sulle politiche MTA-STS tramite smtp_tls_policy_maps . Postfix 3.10 integra nelle risposte di tale plugin gli attributi relativi a TLSRPT; ciò non significa tuttavia né che ogni installazione richieda un plugin, né che TLSRPT sia integrato in ogni pacchetto 3.10.

Inoltre, TLSRPT non è un sistema di monitoraggio in tempo reale. La documentazione di Postfix indica una media di circa dodici ore prima che venga generato un messaggio di errore e, pertanto, distingue espressamente i report dal monitoraggio dei guasti in tempo reale. Per i problemi di consegna in corso rimangono necessari il controllo delle code, l’analisi dei log e gli avvisi. TLSRPT aiuta soprattutto a individuare modelli ricorrenti e problemi legati alle policy nel corso di numerosi tentativi di consegna.

Preparare l'aggiornamento di Postfix nel ramo 3.10

Un aggiornamento all’interno di Postfix 3.10 è un’operazione di manutenzione con una situazione di partenza chiara: si aggiorna un ramo legacy esistente allo stato delle patch fornite dalla propria distribuzione. Prima di procedere, è necessario eseguire il backup della configurazione di Postfix e pianificare una finestra di manutenzione. Verifica inoltre se il server gestisce invii in uscita, traffico MX o Submission, poiché da ciò dipendono il monitoraggio e il piano di ripristino.

Per prima cosa, individua la versione di Postfix installata o rilevata dal programma avviato e documentala esplicitamente in main.cf parametri impostati. I primi due comandi servono a effettuare un’analisi iniziale. postfix check Si tratta invece di un comando di manutenzione amministrativa: controlla in particolare i diritti di proprietà e di accesso a file e directory e può creare directory mancanti. Eseguilo quindi con i diritti amministrativi previsti e non partendo dal presupposto che il filesystem sia garantito inalterato.

postconf mail_version
postconf -n
postfix check

La pubblicazione di postconf mail_version indica la versione del core di Postfix in esecuzione. postconf -n mostra i parametri con valori espliciti name=value-Voci in main.cf. Tra queste possono figurare anche impostazioni il cui valore corrisponde all'impostazione predefinita attualmente in uso; l'output non costituisce quindi una prova certa di un'effettiva divergenza dall'impostazione predefinita. Inoltre, dopo un aggiornamento di versione, i valori predefiniti possono cambiare, mentre un'impostazione precedentemente configurata rimane invariata.

Anche postfix check non costituisce una convalida completa della configurazione del server di posta. Il comando può segnalare problemi relativi ai permessi delle directory o dei file e generare directory mancanti, ma non valuta in modo esaustivo la correttezza tecnica di tutti i parametri. Le catene di certificati, le mappe esterne, le dipendenze DNS, i filtri, l’autenticazione e l’integrazione dei servizi collegati devono essere verificati separatamente.

Per l'aggiornamento del pacchetto, utilizza il metodo di aggiornamento supportato dalla tua distribuzione. Verifica nei metadati del pacchetto, nel changelog e nelle note di sicurezza quali correzioni ed eventuali backport sono presenti nel pacchetto specifico. Confronta queste informazioni con gli annunci dell’upstream. Non dedurre la mancanza di una patch solo sulla base di una stringa di versione abbreviata.

L'obbligo specifico di aggiornamento del processo, documentato da Postfix, riguarda il passaggio da un ramo di sviluppo precedente a Postfix 3.10.0. A causa di una modifica del protocollo interno dell'agente di consegna, è quindi necessario almeno postfix reload oppure è necessario un arresto seguito da una ripartenza; in caso contrario, gli addetti alle consegne potrebbero trovarsi di fronte a un imprevisto smtputf8-Attributo "avviso". Questa motivazione non può essere applicata in modo generalizzato a ogni successivo aggiornamento di patch all'interno della versione 3.10.

In caso di aggiornamenti di manutenzione all’interno del ramo 3.10, verifica invece se lo strumento di gestione dei pacchetti ha già ricaricato o riavviato il servizio secondo le specifiche della distribuzione e se i processi in esecuzione corrispondono alla versione aggiornata. Se così non fosse, utilizza il comando di ricaricamento o riavvio previsto dalla distribuzione e dal pacchetto. Controlla quindi la coda e i log nella finestra di manutenzione, invece di presupporre un determinato comando di attivazione indipendentemente dal comportamento del pacchetto.

Pianificazione di TLSRPT con DNS e infrastruttura di reporting

In TLSRPT, il ruolo del dominio destinatario dei rapporti e quello di un MTA segnalante devono essere pianificati separatamente. Un dominio che desidera ricevere rapporti sulle consegne effettuate alla propria infrastruttura pubblica un punto finale rua nel DNS e garantisce che la ricezione, la protezione, l'archiviazione e l'analisi degli stessi siano gestite in modo vincolante. Il record TXT indica quindi a chi gli altri MTA mittenti devono indirizzare i propri rapporti aggregati.

Un MTA che debba generare autonomamente i rapporti TLSRPT necessita comunque di un pacchetto Postfix che includa una libreria client TLSRPT e USE_TLSRPT è stato compilato. L'indicazione "Postfix 3.10" conferma solo a partire da quale ramo sia disponibile l'integrazione; non attesta la caratteristica di compilazione di un pacchetto binario specifico. Verifica quindi la documentazione del pacchetto, le informazioni di compilazione e i pacchetti aggiuntivi disponibili nella tua distribuzione prima di pianificare l'utilizzo della funzione.

Su ogni sistema Postfix coinvolto viene eseguito un processo locale Collezionista gli eventi trasmessi dalla libreria TLSRPT integrata tramite un socket di dominio Unix locale. Indipendentemente da ciò, è possibile gestire il Fetcher, l’aggregazione centrale e il generatore di report: essi recuperano i dati raccolti, creano i riepiloghi previsti e inviano i report alle destinazioni pubblicate dai domini destinatari. Questi componenti a valle possono essere centralizzati su altri sistemi; ciò non sostituisce tuttavia il collector locale presente sul rispettivo sistema Postfix.

A Plugin per le politiche è richiesto solo in determinati scenari dal lato del mittente. Se l’MTA utilizza le informazioni relative alla policy MTA-STS tramite smtp_tls_policy_maps, il plugin utilizzato a tale scopo deve supportare gli attributi relativi a TLSRPT. DANE è supportato direttamente da Postfix. Né la voce DNS di un dominio destinatario né l'elaborazione dei rapporti da parte di un MTA opportunamente configurato richiedono quindi, in linea di massima, l'utilizzo di un plugin MTA-STS.

La voce seguente illustra esclusivamente la sintassi DNS per un destinatario del report. example.invalid non è intenzionalmente un dominio produttivo e non deve essere ripreso tal quale. Il tag v=TLSRPTv1 caratterizza il procedimento; rua qui si specifica una destinazione per i rapporti. L'RFC 8460 consente, oltre all'e-mail, anche endpoint HTTPS.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Per i report TLSRPT, Postfix 3.10 definisce l'intestazione TLS-Required: no, in modo che il rapporto possa ricorrere al livello di sicurezza TLS „may“ durante la trasmissione. Questa eccezione, strettamente limitata, impedisce che un rapporto di errore fallisca a causa di un requisito TLS troppo rigido. Non costituisce un'istruzione a ridurre i requisiti TLS per le e-mail aziendali o degli utenti regolari.

Proteggere i dati inviati, valutare in modo mirato le opzioni TLS

L'impostazione smtpd_hide_client_session Si applica all'invio autenticato da parte del client di posta. Se è attivata, il server SMTP genera l'intestazione "Received:" senza includere informazioni relative alla sessione del client. A seconda della sessione, è quindi possibile nascondere dall’intestazione, ad esempio, il nome host e l’indirizzo IP del client, i dati della sessione TLS, le informazioni di accesso SASL e i dettagli del log SMTP.

Mettile in ordine Funzione di protezione dei dati una definizione dedicata del servizio di invio per la porta 587 o 465, anziché impostarla in modo generico a livello globale in main.cf da attivare. L'MTA pubblico sulla porta 25 svolge un ruolo diverso nel trasporto da server a server. La documentazione di Postfix richiede in questo caso il valore predefinito, affinché siano rispettati i requisiti della RFC 5321.

La decisione non riguarda quindi solo la privacy, ma anche la tracciabilità e i limiti del servizio. Per i client autenticati, la riduzione dei metadati superflui può essere appropriata. Su un MX pubblico, tuttavia, la stessa impostazione violerebbe le aspettative documentate relative alle informazioni «Received:». Valuta quindi servizi separati, listener e i rispettivi parametri anziché una regola globale unica.

Postfix 3.10.0 include inoltre un adattamento per OpenSSL 3.5 e la sua sintassi a gruppi per la crittografia post-quantistica. Se si desidera delegare completamente la selezione dei gruppi alla configurazione OpenSSL gestita a livello centrale, è necessario tls_eecdh_auto_curves e tls_ffdhe_auto_groups entrambi devono essere lasciati vuoti. Solo con questa impostazione comune OpenSSL può effettuare la scelta; Postfix non riproduce autonomamente la nuova sintassi di OpenSSL.

Lo svuotamento di entrambi i parametri automatici è un Caso particolare per impostazioni di crittografia gestite a livello centrale, nessuna raccomandazione generale in materia di hardening. È appropriato solo se la configurazione effettiva di OpenSSL è nota, versionata e testata. In assenza di tale controllo, il trasferimento della selezione potrebbe mascherare configurazioni errate o generare caratteristiche TLS inattese; in tal caso, le impostazioni esplicite di Postfix rimangono più tracciabili.

Verificare lo stato delle patch e i problemi noti

La sola indicazione della versione 3.10 non descrive uno stato tecnico uniforme. Sono determinanti la versione specifica della patch, le informazioni contenute nel changelog del pacchetto di distribuzione e, se del caso, le correzioni retroportate. Postfix 3.10.14 è stato annunciato il 7 settembre 2026 come versione legacy insieme ad altri rami ancora in manutenzione. Ciò non implica che ogni pacchetto Linux contenga già questo stato upstream.

Un esempio concreto è Postfix 3.10.6: questa versione ha risolto un problema relativo a TLS richiesto: no e la modalità wrapper TLS lato client. La precedente implementazione poteva compromettere tali connessioni; la correzione le gestisce con il livello di sicurezza „encrypt“. Chi utilizza la modalità wrapper SMTPS dovrebbe quindi verificare lo stato delle patch e il percorso di trasmissione effettivamente utilizzato, anziché dedurre lo stesso comportamento dalla versione «3.10».

L'annuncio relativo alla versione 3.10.14 menziona, tra le altre cose, correzioni e rafforzamenti per una configurazione di SMTP smuggling con smtpd_proxy_filter. Non si tratta di un'affermazione generica secondo cui tutti i server di posta sarebbero interessati: il parametro è disattivato per impostazione predefinita e la rilevanza dipende dalla configurazione locale e dall'architettura di filtraggio a monte o collegata. Verifica quindi innanzitutto se questa funzione viene effettivamente utilizzata.

In caso di consegna anomala, la procedura di ricerca degli errori segue un ordine logico: per prima cosa controlla le discrepanze effettive e la convalida della configurazione, poi verifica che il ricaricamento sia avvenuto correttamente dopo un aggiornamento. Successivamente, esamina la coda e i log alla ricerca di messaggi ricorrenti relativi a TLS, alla connessione o ai messaggi differiti. Una guida sistematica alla Analisi dei log di Postfix aiuta ad associare i singoli eventi a un ID coda e al relativo tentativo di consegna.

Avviso: Un cambio di versione non sostituisce un'analisi delle cause. Un ricaricamento non risolve né le catene di certificati non valide, né gli errori DNS, né le regole di routing errate. Al contrario, la mancata esecuzione di ricaricamenti dopo un aggiornamento può nascondere processi o configurazioni modificati durante il funzionamento. Documentare quindi insieme lo stato delle patch, la fonte del pacchetto, il momento dell’attivazione e i messaggi di log rilevati.

Valutare correttamente i rapporti TLSRPT durante il funzionamento

I rapporti TLSRPT sono in ritardo e non sostituiscono il monitoraggio in tempo reale. La documentazione di Postfix indica che in media occorrono circa dodici ore prima che arrivi un rapporto di errore. In Postfix, i risultati registrati si riferiscono agli handshake TLS; non vengono riportati gli errori di instaurazione della connessione né le interruzioni avvenute prima o dopo l’handshake. Per gli incidenti critici rimangono necessari il monitoraggio delle code, l’analisi dei log e la segnalazione degli allarmi.

Anche il riutilizzo limita il conteggio: una connessione SMTP riutilizzata non genera un ulteriore handshake TLS. Nel caso di sessioni TLS riprese, Postfix 3.10 salta per impostazione predefinita la registrazione; a tal fine è determinante l'opzione smtp_tlsrpt_skip_reused_handshakes. I dati aggregati dei report non rappresentano quindi né il numero completo di tutte le connessioni SMTP, né una percentuale di messaggi o di consegne. Valuta i tipi di errore, i domini dei destinatari, i periodi di tempo e i modelli ricorrenti insieme ai log del server.

La semplice trasmissione tecnica di un report non garantisce di per sé alcun vantaggio. Stabilisci in anticipo chi si occupa del destinatario RUA, chi riceve e archivia i report e per quanto tempo i dati vengono conservati. Poiché i report possono contenere informazioni relative alle sessioni TLS, il piano operativo deve includere i diritti di accesso, le linee guida sulla protezione dei dati e una procedura di cancellazione. Dovrebbe inoltre essere prevista una procedura di escalation per gli errori ricorrenti.

L'analisi combina quindi due livelli: TLSRPT mostra le tendenze sintetizzate su un determinato periodo, mentre i log dei server di posta forniscono il decorso concreto dei singoli tentativi di consegna. Per il monitoraggio continuo, il Guida pratica al monitoraggio dei log di Postfix i rapporti relativi ai metodi di classificazione dei messaggi di errore e delle code. Gli allarmi automatici dovrebbero reagire ai dati operativi in tempo reale, non solo agli aggregati TLSRPT ricevuti.

Se non sono previsti un destinatario responsabile, un archivio protetto e un’analisi periodica, la pubblicazione TLSRPT dovrebbe essere prima pianificata, anziché attivata in modo affrettato. Responsabilità in materia di rendicontazione fa parte della funzione di sicurezza: solo l’assegnazione di un errore a un’unità competente consente una reazione tracciabile, ad esempio in caso di scadenza di una policy MTA-STS o di problemi con i dati TLSA.

Effettuare la manutenzione del 3.10 o passare al 3.11

La scelta tra la gestione delle patch e il passaggio a un ramo diverso dipende dalla situazione iniziale e dagli obiettivi aziendali. Al momento della ricerca, Postfix 3.10 è un ramo legacy ancora supportato, mentre 3.11 è il ramo di sviluppo stabile. Le correzioni periodiche all’interno della versione 3.10 sono quindi utili per le installazioni esistenti; tuttavia, non sono equiparabili a un aggiornamento funzionale alla versione 3.11.

Il passaggio alla versione 3.11 è oggettivamente giustificato soprattutto se sono necessarie le sue funzionalità o gli obiettivi a lungo termine. REQUIRETLS e gli output JSON di determinati strumenti di amministrazione sono documentati come caratteristiche del ramo più recente e non devono essere considerati come funzionalità di Postfix 3.10. Prima di effettuare un cambio di ramo, è necessario verificare la compatibilità dei parametri di configurazione, dei filtri collegati, dell’autenticazione e dell’automazione.

Per un sistema 3.10 stabile che non richieda nuove funzionalità è aggiornamento continuo delle patch la misura più adeguata nell'immediato. Richiede tuttavia un processo controllato che preveda backup, verifica dei pacchetti, convalida, controllo dell'attivazione del processo e monitoraggio. Il passaggio a un altro settore, invece, richiede un motivo tecnico e una finestra di manutenzione pianificata; il solo numero di versione più alto non costituisce un criterio decisionale sufficiente.