Invio di e-mail tramite un relay: verificare TLS e autenticazione

Molte applicazioni non inviano direttamente le e-mail su Internet, ma le consegnano a un relay interno: l’ERP le conferme d’ordine, il monitoraggio gli allarmi, il sistema di ticketing le notifiche. Il relay è gestito dal team e-mail; dal lato dell’applicazione è responsabile l’Application Manager. In caso di audit o analisi del fabbisogno di protezione, la domanda arriva quindi a lui: l’applicazione si collega al relay in modo cifrato e si autentica correttamente?

La risposta si trova in due punti per i quali non sono necessari né uno strumento e-mail né l’accesso al relay: nella configurazione SMTP della propria applicazione e nell’header di una singola e-mail di test. Il team e-mail è responsabile di ciò che offre il relay e di come cifra ulteriormente le e-mail fino al destinatario; dal lato dell’applicazione è sufficiente documentare il proprio tratto.

Dove si trovano le impostazioni

A seconda dell’applicazione, la configurazione SMTP si trova in uno di tre punti: nell’interfaccia di amministrazione (solitamente in «E-mail», «Notifiche», «SMTP» o «Server in uscita»), in un file di configurazione oppure nelle variabili d’ambiente del deployment (tipicamente SMTP_HOST, SMTP_PORT, SMTP_USER e varianti). Le informazioni cercate sono sempre le stesse: nome del server, porta, un’opzione di crittografia e le credenziali.

Le tre impostazioni che contano

Primo: porta e modalità TLS. Entrambe devono corrispondere, poiché dietro i valori selezionabili si celano due procedure diverse: con STARTTLS la connessione inizia in chiaro e passa poi a TLS; con TLS implicito (nelle schermate solitamente chiamato «SSL/TLS» o «SSL») è cifrata fin dall’inizio.

Una combinazione errata (ad esempio «SSL/TLS» sulla porta 587) provoca interruzioni della connessione, non testo in chiaro inosservato. Le impostazioni rischiose sono le ultime due righe della tabella, poiché in questi casi l’applicazione invia senza crittografia e senza messaggi di errore.

Secondo: la verifica del certificato. Molte applicazioni offrono un’opzione come «Non verificare il certificato», «Allow insecure» oppure verify=false, che viene spesso impostata nei progetti di introduzione perché il relay utilizza un certificato interno. La connessione rimane così cifrata, ma l’applicazione accetta qualsiasi controparte. Se l’opzione è impostata, va riportata come riscontro nel rapporto; la soluzione corretta consiste nel considerare attendibile la CA interna anziché disattivare la verifica.

Terzo: l’autenticazione. I relay conoscono due modelli: SMTP AUTH con nome utente e password oppure un’abilitazione IP senza account. La variante applicabile è indicata nell’abilitazione del relay fornita dal team e-mail. Per SMTP AUTH, tre punti devono figurare nella checklist: l’autenticazione avviene tramite un account di servizio dedicato dell’applicazione (non tramite un account personale che verrà disattivato alla prossima uscita), la password è memorizzata come segreto anziché in chiaro in un file di configurazione e l’opzione TLS è attiva, poiché le procedure comuni PLAIN e LOGIN altrimenti trasmettono le credenziali in chiaro.

Come si chiamano le impostazioni negli ambienti comuni

Per esperienza, due aspetti di questa tabella sono i riscontri più frequenti: in Java, starttls.enable da solo attiva soltanto TLS opportunistico; solo starttls.required impedisce il fallback al testo in chiaro. In Nodemailer, secure:false non significa «non cifrato», bensì «nessun TLS implicito»; senza requireTLS:true, tuttavia, anche STARTTLS rimane opportunistico.

Controprova: un’e-mail di test e il suo header Received

La configurazione indica lo stato desiderato, ma non dimostra ciò che avviene sul collegamento. La prova si trova nell’header Received che il relay inserisce alla ricezione di ogni e-mail. È sufficiente inviare un’e-mail di test dall’applicazione alla propria casella di posta; quindi visualizzare l’header del messaggio (Outlook: File, Proprietà, Intestazioni Internet; Gmail: Mostra originale) e leggere la riga Received più in basso, poiché gli header crescono dal basso verso l’alto:

Received: from app01.example.com (app01.example.com [10.1.2.3])
        by relay.example.com (Postfix) with ESMTPSA id 4XyZk12Fzq
        (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
        Thu, 28 Aug 2026 09:15:04 +0200

La parola chiave dopo with è la sintesi del risultato della verifica. Le sigle sono standardizzate (registro IANA «Mail Transmission Types»):

Postfix ed Exchange aggiungono tra parentesi la versione TLS e il cipher, consentendo di riconoscere anche versioni di protocollo obsolete. Per analizzare header più lunghi con più stazioni, il Mail Header Analyzer su questo sito evita il lavoro manuale; funziona interamente in locale nel browser e l’header non lascia il computer.

Se l’header rimane poco chiaro o un load balancer a monte modifica la marcatura della connessione, è il momento di rivolgersi al team e-mail: il log del relay registra per ogni consegna se TLS è stato negoziato e con quale account l’applicazione si è autenticata.

Breve checklist per il rapporto di verifica

1. Configurazione SMTP dell’applicazione individuata (interfaccia, file di configurazione o variabili d’ambiente) e documentata.
2. Porta e modalità TLS corrispondono (587/STARTTLS oppure 465/SSL-TLS); nessuna impostazione «Nessuno» o «TLS, se disponibile».
3. Verifica del certificato attiva; l’eventuale impostazione «Non verificare il certificato» è registrata come riscontro.
4. Modello di autenticazione chiarito: SMTP AUTH con account di servizio e archiviazione del segreto, oppure abilitazione IP secondo l’abilitazione del relay.
5. L’header Received dell’e-mail di test mostra ESMTPSA (con account) oppure ESMTPS (con abilitazione IP); ESMTPA e ESMTP sono riscontri.
6. Se è richiesta la crittografia fino al destinatario: inoltrata come requisito al team e-mail, poiché il tratto a partire dal relay è al di fuori dell’applicazione.