Spiegazione delle porte SMTP per la posta elettronica: 25, 465, 2525 e 587

Scopri quali porte SMTP utilizzare per la consegna delle email: 25, 465, 587 o 2525. La nostra guida ti aiuta a scegliere la porta giusta per garantire sicurezza e recapito.

Ogni giorno, oltre 370 miliardi di email vengono inviate attraverso Internet, ma solo una piccola percentuale di utenti comprende l'infrastruttura che rende tutto ciò possibile.

Al centro di questo enorme sistema di comunicazione globale c'è il Simple Mail Transfer Protocol (SMTP), lo standard che regola il modo in cui le e-mail vengono trasmesse dal mittente al destinatario.

Questo sistema è influenzato da numerosi fattori e componenti, uno dei quali è la porta SMTP, un elemento critico che influisce sulla sicurezza, sulla recapitabilità e sulle prestazioni della posta elettronica.

Che tu sia un amministratore IT che configura un server di posta elettronica, uno sviluppatore che integra funzionalità di posta elettronica in un'applicazione o semplicemente un utente curioso che configura un client di posta elettronica, comprendere le porte SMTP può fare la differenza tra una consegna di posta elettronica sicura e affidabile e messaggi che non raggiungono mai la destinazione.

Per aiutarti a comprendere e prendere le decisioni migliori, ci siamo presi il tempo di scrivere questa guida completa, incentrata specificamente sulle porte 25, 465, 587 e 2525. Non preoccuparti se non sai perché queste sono importanti: ne parleremo, oltre a:

• Come funziona SMTP e perché le porte sono importanti
• L'evoluzione della sicurezza della trasmissione della posta elettronica
• Analisi dettagliata delle caratteristiche di sicurezza di ogni porta (e perché sceglieresti ciascuna)
• Guida pratica su quale porto scegliere per le tue esigenze specifiche
• Problemi comuni e soluzioni per la risoluzione dei problemi

Tuffiamoci dentro

Comprensione dei fondamenti SMTP

Che cos'è SMTP e come funziona?

Simple Mail Transfer Protocol (SMTP) è lo standard Internet per la trasmissione della posta elettronica.

Sviluppato nei primi anni '1980, il protocollo SMTP costituisce la base per il trasferimento delle e-mail attraverso le reti, dal mittente al destinatario.

Immagina le funzioni di SMTP come una staffetta:

1. Composizione: scrivi un'e-mail nel tuo client (come Gmail, Outlook o Apple Mail)
2. Invio: il tuo client di posta elettronica invia il messaggio a un server SMTP
3. Relay: il server SMTP determina dove inviare il messaggio successivamente
4. Consegna: dopo aver potenzialmente attraversato diversi server SMTP, il messaggio arriva al server di posta del destinatario
5. Recupero: il destinatario accede al messaggio utilizzando protocolli come POP3 o IMAP

Un'illustrazione che mostra il semplice processo di invio di un'e-mail tramite Internet (Componi > Server SMTP > Invia al server di posta del destinatario, quindi Leggi)

Per visualizzare questo processo, immagina di inviare una lettera cartacea:

• Tu (client di posta elettronica) scrivi una lettera e la inserisci in una casella di posta (invio SMTP)
• Il servizio postale (SMTP relay) instrada la tua lettera attraverso vari centri di smistamento
• Alla fine, la lettera arriva all'ufficio postale locale del destinatario (server di posta in arrivo)
• Il destinatario controlla la sua casella di posta (POP3/IMAP) e recupera la tua lettera

L'evoluzione della sicurezza SMTP

Quando SMTP venne standardizzato per la prima volta nel 1982, la sicurezza della posta elettronica non era una preoccupazione primaria.

Internet era una rete molto più piccola e affidabile, utilizzata principalmente da istituti accademici e di ricerca.

Pertanto, la specifica SMTP originale non prevedeva meccanismi di sicurezza integrati: le e-mail venivano trasmesse come testo normale, senza crittografia o autenticazione robusta.

Tuttavia, questa mancanza di sicurezza è diventata problematica con la crescita di Internet e con la trasformazione della posta elettronica in uno strumento di comunicazione fondamentale per aziende e privati.

Ecco alcuni dei principali problemi di sicurezza con SMTP tradizionale:

• Trasmissione di testo normale: i messaggi potevano essere intercettati e letti
• Nessuna crittografia: i dati sensibili erano vulnerabili
• Autenticazione limitata: facile falsificare l'identità del mittente
• Potenziale di inoltro aperto: i server potrebbero essere sfruttati per inviare spam

Nel corso del tempo sono state sviluppate estensioni e miglioramenti a SMTP per risolvere queste carenze:

• SMTP AUTH: Meccanismi di autenticazione forniti
• STARTTLS: Aggiunto supporto per la crittografia a livello di trasporto
• SMTPS: crittografia SSL/TLS implementata durante la connessione

Cosa sono i porti e perché sono importanti?

Un'illustrazione delle icone che rappresentano le diverse porte di posta elettronica e perché dovresti usarle

Nelle reti, una porta è un punto logico finale per la comunicazione.

Si pensi alle porte come a porte di accesso specializzate a un sistema informatico, ciascuna delle quali gestisce un tipo specifico di traffico. Le porte sono identificate da numeri che vanno da 0 a 65535.

Per la comunicazione SMTP sono state designate porte specifiche:

• Porta 25: la porta SMTP originale
• Porta 465: inizialmente designata per SMTPS (SMTP su SSL)
• Porta 587: la porta moderna per l'invio dei messaggi
• Porta 2525: una porta alternativa utilizzata quando le porte standard sono bloccate

La scelta della porta influenza:

1. Sicurezza: diverse porte offrono diversi livelli di crittografia e autenticazione
2. Recapitabilità: gli ISP possono bloccare determinate porte per ridurre lo spam
3. Compatibilità: non tutti i servizi di posta elettronica supportano tutte le porte
4. Funzionalità: alcune porte sono progettate per scopi specifici nell'ecosistema della posta elettronica

Comprendere queste distinzioni è fondamentale per impostare sistemi di posta elettronica affidabili e sicuri.

Le principali porte SMTP: una prospettiva storica

Quindi, perché queste porte e perché ci sono differenze? Perché non avere una sola porta sicura specifica per la posta elettronica, utilizzata da tutti? Analizziamolo nel dettaglio.

Porta 25: lo standard originale

La porta 25 è stata stabilita come porta SMTP standard nel 1982, quando il protocollo è stato definito per la prima volta dall'Internet Engineering Task Force (IETF).

Per molti anni è stata la porta predefinita per tutto il traffico SMTP, sia per l'invio di e-mail dai client ai server sia per il relay da server a server.

L'implementazione della porta 25 ha avuto origine da una richiesta del 1982 presentata dall'Università della California del Sud all'Internet Engineering Task Force (IETF).

All'epoca, l'attenzione era rivolta alla creazione di un canale di comunicazione standardizzato per la trasmissione di posta elettronica, con una protezione di base contro gli attacchi, come l'intercettazione man-in-the-middle.

Oggi, il ruolo della Porta 25 si è notevolmente ridotto. La sua funzione primaria è ora limitata a:

• Comunicazione server-server: gli agenti di trasferimento posta (MTA) utilizzano la porta 25 per inoltrare i messaggi tra i server di posta
• Supporto per sistemi legacy: alcuni vecchi sistemi di posta elettronica si basano ancora sulla porta 25

Una semplice connessione telnet a un server SMTP sulla porta 25 potrebbe apparire così:

Notare la riga 250-STARTTLS, che indica che questo server supporta la crittografia tramite il comando STARTTLS, ma non è obbligatorio.

Tuttavia, tenendo presente questo, la porta 25 presenta diverse limitazioni di sicurezza significative:

• Nessuna crittografia richiesta: per impostazione predefinita, le comunicazioni sulla porta 25 non sono crittografate
• STARTTLS facoltativo: sebbene supportato, la crittografia non è obbligatoria
• Vulnerabile all'intercettazione: le comunicazioni in testo normale possono essere facilmente lette se intercettate
• Vettore spam: storicamente utilizzato per l'invio di e-mail spam

A causa di questi problemi, in particolare dello sfruttamento da parte degli spammer, molti provider di servizi Internet (ISP) e provider di cloud hosting ora bloccano il traffico in uscita sulla porta 25 dai propri clienti.

Questo blocco aiuta a impedire che i sistemi compromessi vengano utilizzati per distribuire spam.

Se riscontri problemi di connessione sulla porta 25, è probabile che il tuo ISP la stia bloccando. Con un semplice test, potresti vedere:

Questo blocco è così diffuso che la porta 25 non dovrebbe più essere utilizzata per l'invio di email ai client. Dovrebbe invece essere riservata esclusivamente alla comunicazione tra server.

Porta 465: porta di crittografia implicita SSL/TLS

La porta 465 ha forse la storia più contorta tra le porte SMTP.

A metà degli anni '1990, quando divenne evidente la necessità di crittografare la posta elettronica, l'Internet Assigned Numbers Authority (IANA) assegnò brevemente la porta 465 a "SMTPS", ovvero SMTP su SSL.

Tuttavia, questo incarico ebbe vita breve.

Intorno al 1997, l'IETF decise di adottare un approccio diverso per proteggere SMTP: aggiungere il comando STARTTLS al protocollo SMTP stesso, che avrebbe consentito di negoziare la crittografia sulle porte esistenti.

Di conseguenza, l'assegnazione ufficiale della porta 465 a SMTPS è stata revocata dopo appena un anno circa.

Nonostante questa deprecazione ufficiale, molti servizi di posta elettronica avevano già implementato il supporto per la porta 465, che continuava a essere ampiamente utilizzata. Ciò creò una situazione in cui la porta 465 veniva utilizzata nella pratica, nonostante non fosse più ufficialmente designata per SMTP.

Funzionalità TLS implicita

La porta 465 utilizza il cosiddetto "TLS implicito" o "SSL implicito":

• La connessione inizia immediatamente con la negoziazione SSL/TLS
• Nessuna parte della comunicazione avviene in testo normale
• Se la negoziazione TLS fallisce, la connessione viene terminata
• Tutti i comandi SMTP successivi vengono inviati tramite il canale crittografato

Questo approccio è simile al funzionamento di HTTPS sul web: la connessione sicura viene stabilita prima che vengano trasmessi i dati dell'applicazione.

Ecco un flusso di comunicazione semplificato per la porta 465:

1. Il client avvia la connessione al server sulla porta 465
2. Si verifica l'handshake SSL/TLS
3. Dopo l'handshake riuscito, inizia la comunicazione SMTP
4. Tutti i comandi e i dati SMTP sono crittografati

Oggi la porta 465 si trova in uno stato curioso:

• Non è ufficialmente riconosciuto dall'IETF per SMTP
• È ampiamente supportato dai provider di servizi di posta elettronica
• È consigliato da alcuni provider di posta elettronica per i consumatori
• Fornisce una sicurezza elevata attraverso il suo approccio TLS implicito

La porta 465 è appropriata per:

• Sistemi legacy configurati per utilizzare SMTPS su questa porta
• Scenari in cui è richiesta la massima protezione contro gli attacchi di downgrade
• Situazioni in cui un provider di posta elettronica lo consiglia specificamente

L'Internet Assigned Numbers Authority ha ora riassegnato la porta 465 a un servizio diverso ("URL Rendezvous Directory for SSM"), anche se in pratica continua a essere utilizzata principalmente per SMTP sicuro.

Porta 587: la porta di invio moderna

Nel 1998, la RFC 2476 (successivamente sostituita dalla RFC 6409) introdusse il concetto di una porta dedicata per l'invio dei messaggi, separata dalla porta di inoltro SMTP. Questa separazione rispondeva alla crescente necessità di distinguere tra due diverse tipologie di traffico SMTP:

• Invio di messaggi: client di posta elettronica che inviano messaggi al proprio server di posta
• Relay di messaggi: server di posta che trasferiscono messaggi ad altri server di posta

La porta 587 è stata designata per questo ruolo di invio dei messaggi, creando una netta distinzione dalla funzione di relay della porta 25. Questa separazione ha consentito di applicare policy e requisiti di sicurezza diversi a ciascun tipo di traffico.

Funzionalità STARTTLS

La porta 587 utilizza "TLS esplicito" tramite il comando STARTTLS. Ecco come funziona:

1. Il client si connette al server sulla porta 587
2. Il server si identifica ed elenca le estensioni supportate
3. Il client emette il comando STARTTLS
4. Il server risponde e inizia la negoziazione TLS
5. Dopo la negoziazione riuscita, la sessione SMTP viene crittografata
6. Il client in genere si autentica tramite SMTP AUTH
7. L'invio dell'e-mail avviene all'interno del canale crittografato

Una tipica sessione SMTP che utilizza la porta 587 con STARTTLS potrebbe apparire così:

Si noti come la comunicazione SMTP inizi in testo normale ma passi alla crittografia TLS dopo l'emissione del comando STARTTLS.

Nella maggior parte dei casi, la porta scelta sarà la 587.

È emerso come lo standard consigliato per l'invio di e-mail per diverse valide ragioni:

1. Standard ufficiale: è riconosciuto dall'IETF come la porta corretta per l'invio dei messaggi
2. Ampio supporto: la maggior parte dei provider di posta elettronica moderni supporta la porta 587
3. Compatibilità ISP: è meno probabile che venga bloccata dagli ISP rispetto alla porta 25
4. Sicurezza con flessibilità: supporta una crittografia avanzata mantenendo la compatibilità con le versioni precedenti
5. Autenticazione richiesta: in genere applica SMTP AUTH, riducendo lo spam

Per la stragrande maggioranza degli utenti e delle organizzazioni che configurano nuovi sistemi di posta elettronica, la porta 587 dovrebbe essere la scelta predefinita per l'invio dei messaggi.

Porta 2525: l'opzione alternativa

La porta 2525 non è una porta SMTP ufficialmente designata né da IANA né da IETF. È invece emersa come alternativa pratica quando le porte standard (25, 465 e 587) sono bloccate dagli ISP o dalle reti aziendali.

Dal punto di vista funzionale, la porta 2525 in genere funziona in modo identico alla porta 587:

• Supporta STARTTLS per la crittografia
• Richiede l'autenticazione tramite SMTP AUTH
• Viene utilizzato per l'invio di messaggi, non per il relay

La differenza principale è semplicemente il numero di porta stesso, che aiuta a bypassare le restrizioni di rete.

La porta 2525 dovrebbe essere presa in considerazione in questi scenari:

1. Quando ci si connette da reti che bloccano le porte 25, 465 e 587
2. In ambienti aziendali con rigide politiche di firewall
3. Quando si utilizzano provider cloud che limitano le porte di posta elettronica standard
4. Se riscontri costantemente problemi di connessione con le porte standard

Molti provider di servizi di posta elettronica, tra cui Mailgun, SendGrid e altri, supportano la porta 2525 specificatamente per offrire questa opzione di fallback ai propri clienti.

Come scegliere la porta giusta dal punto di vista della sicurezza

Un'illustrazione di uno sviluppatore che pensa a quale porta di posta elettronica utilizzare nel proprio progetto

Parliamo di sicurezza perché, dal punto di vista di uno sviluppatore, questa è una delle considerazioni più importanti. Ci sono diverse opzioni.

STARTTLS (TLS esplicito)

STARTTLS, utilizzato principalmente sulle porte 25 e 587, fornisce una "crittografia opportunistica" attraverso questi passaggi:

1. La connessione inizia non crittografata
2. Il client emette il comando STARTTLS
3. Se il server lo supporta, la crittografia viene negoziata
4. La comunicazione continua crittografata

vantaggi:

• Compatibilità con le versioni precedenti dei server non TLS
• Funziona con porti e infrastrutture esistenti

svantaggi:

• La comunicazione iniziale non è crittografata
• Vulnerabile agli attacchi di downgrade in cui un aggressore impedisce il comando STARTTLS
• Non tutti i server richiedono TLS, consentendo il fallback in testo normale

TLS implicito

Il TLS implicito, utilizzato sulla porta 465, adotta un approccio diverso:

1. La connessione inizia immediatamente con la negoziazione TLS
2. Se la negoziazione TLS fallisce, la connessione viene terminata
3. Non si verifica mai alcuna comunicazione non crittografata

vantaggi:

• Nessuna comunicazione in testo normale in nessun momento
• Impossibile effettuare il downgrade alla connessione non crittografata
• Maggiore protezione contro gli attacchi man-in-the-middle

svantaggi:

• Non retrocompatibile con i server che non supportano TLS
• Non è l'approccio standard ufficiale dell'IETF

Requisiti di autenticazione

L'autenticazione è un componente di sicurezza fondamentale che verifica l'identità del client mittente. I requisiti di autenticazione variano in base alla porta:

Porta 25:

• L'autenticazione è spesso facoltativa
• Spesso consente il relay non autenticato tra i server
• Potrebbe consentire l'invio di messaggi anonimi su alcuni server

Porta 465:

• Autenticazione in genere richiesta
• Solitamente applicato dopo aver stabilito la crittografia TLS
• Raramente consente l'invio di messaggi anonimi

Porta 587:

• Autenticazione richiesta dallo standard
• Applicato dopo la crittografia STARTTLS
• Progettato specificamente per l'invio autenticato

Porta 2525:

• I requisiti di autenticazione corrispondono alla porta 587
• Richiede l'autenticazione per l'invio del messaggio

Vale la pena notare che i moderni server di posta elettronica dovrebbero sempre richiedere l'autenticazione per l'invio dei messaggi, indipendentemente dalla porta, per prevenire abusi.

Best Practice per la massima sicurezza della posta elettronica

Per garantire il massimo livello di sicurezza della posta elettronica durante la configurazione di SMTP:

1. Utilizzare sempre la crittografia:

• Configura i tuoi server in modo che richiedano TLS per tutte le connessioni
• Disabilita l'autenticazione in testo normale
• Utilizzare versioni TLS potenti (TLS 1.2 o superiore)

2. Implementa l'autenticazione forte:

• Richiedi SMTP AUTH per tutti gli invii di messaggi
• Utilizzare un archivio password sicuro (hashing con salt)
• Valutare l'implementazione dell'autenticazione a due fattori per gli account di posta elettronica

3. Rimani aggiornato con i certificati:

• Utilizzare certificati firmati da CA attendibili
• Rinnovare regolarmente i certificati SSL/TLS
• Monitorare le vulnerabilità dei certificati

4. Configurare le intestazioni e le policy appropriate:

• Implementare SPF, DKIM e DMARC per l'autenticazione
• Imposta le intestazioni HSTS appropriate
• Configurare i server di posta per rifiutare le connessioni non crittografate

5. Monitorare e verificare:

• Registra tutte le transazioni SMTP
• Esaminare regolarmente i registri per individuare attività sospette
• Testare periodicamente la configurazione della sicurezza della posta elettronica

Una guida pratica all'implementazione delle porte SMTP

Illustrazione di uno sviluppatore che riflette sul modo migliore per impostare le porte SMTP per l'invio delle email.

Ora, scegli le porte più adatte al tuo progetto. Possiamo suddividerle in base al caso d'uso, così potrai trovare la soluzione più adatta.

Per singoli utenti e client di posta elettronica

Se stai configurando un client di posta elettronica come Outlook, Apple Mail o Thunderbird:

1. Prima scelta: Porta 587 con STARTTLS

• Ampiamente supportato e con meno probabilità di essere bloccato
• Esempio di configurazione per Gmail in Outlook:
• Server di posta in uscita: smtp.gmail.com
• Porto: 587
• Crittografia: STARTTLS
• Autenticazione: Sì, con nome utente e password

2. Seconda scelta: Porta 465 con SSL/TLS

• Se il tuo fornitore lo consiglia espressamente
• Esempio di configurazione per Yahoo Mail:
• Server di posta in uscita: smtp.mail.yahoo.com
• Porto: 465
• Crittografia: SSL/TLS
• Autenticazione: Sì, con nome utente e password

3. Ultima risorsa: porta 2525 con STARTTLS

• Solo se le porte 587 e 465 sono bloccate
• Non tutti i provider supportano questa porta, quindi controlla la documentazione

Per applicazioni aziendali e mittenti ad alto volume

Per le applicazioni che inviano e-mail transazionali o di marketing:

Consigliato: Porta 587

• Il miglior equilibrio tra recapito e sicurezza
• Supportato da tutti i principali provider di servizi di posta elettronica
• Esempio di un'applicazione Node.js che utilizza Nodemailer:

Alternativa: Porta 465

• Per i fornitori che lo consigliano espressamente
• Esempio in PHP utilizzando PHPMailer:

Opzione di backup: Porta 2525

• Quando si distribuisce su piattaforme che bloccano le porte standard
• Esempio in Python usando smtplib:

Per la comunicazione server-server

Per la configurazione del server di posta che gestisce il traffico relay:

Standard: Porta 25

• Utilizzato per la comunicazione MTA-MTA
• Dovrebbe essere configurato con STARTTLS quando possibile
• Esempio di configurazione di Postfix in /etc/postfix/main.cf:

Alternativa se la porta 25 è bloccata: configurazione personalizzata

• Alcuni provider consentono il relay su porte alternative
• Esempio:

Esempi di configurazione per server di posta elettronica comuni

Configurazione Postfix (Linux)

Per configurare Postfix per proteggere l'invio SMTP sulla porta 587:

1. Modifica /etc/postfix/master.cf:

2. Modificare /etc/postfix/main.cf per configurare TLS:

3. Riavvia Postfix:

Microsoft Exchange Server

Per configurare Exchange Server per l'invio SMTP sicuro:

1. Aprire l'Exchange Admin Center
2. Vai a Flusso di posta > Connettori di ricezione
3. Crea o modifica un connettore per l'invio del client
4. Configurare il connettore per:

• Ascolta sulla porta 587
• Richiede crittografia TLS
• Richiedi autenticazione
• Imposta gruppi di autorizzazioni appropriati (in genere "Utenti di Exchange")

Test di connettività delle porte e risoluzione dei problemi

Per testare la connettività a un server SMTP su una porta specifica, è possibile utilizzare semplici strumenti da riga di comando:

Problemi comuni relativi alla porta SMTP e relative soluzioni

Timeout di connessione e fallimenti di autenticazione

Problema: timeout di connessione

sintomi:

• Impossibile stabilire una connessione al server SMTP
• Il client segnala errori di "connessione scaduta"
• L'invio delle e-mail sembra bloccarsi indefinitamente

Cause possibili:

1. ISP o rete che blocca la porta
2. Restrizioni del firewall
3. Il server è inattivo o irraggiungibile
4. Indirizzo del server errato

Soluzioni:

1. Prova una porta alternativa (587, 465 o 2525)
2. Controllare le impostazioni del firewall e le policy di rete
3. Verifica che l'indirizzo del server sia corretto
4. Eseguire il test su una rete diversa per isolare i problemi di blocco dell'ISP
5. Aumenta le impostazioni di timeout della connessione nel tuo client di posta elettronica

Problema: errori di autenticazione

sintomi:

• Connessione stabilita ma autenticazione fallita
• Messaggi di errore come "535 Autenticazione fallita" o "Nome utente/password non validi"
• Impossibile inviare la posta nonostante la connessione sia riuscita

Cause possibili:

1. nome utente o password errati
2. Mancata corrispondenza del metodo di autenticazione
3. Restrizioni dell'account o policy di sicurezza
4. Requisiti TLS/SSL non soddisfatti prima dell'autenticazione

Soluzioni:

1. Verificare che le credenziali siano corrette e aggiornate
2. Controlla quali metodi di autenticazione supporta il server (PLAIN, LOGIN, CRAM-MD5)
3. Assicurarsi che la crittografia sia configurata correttamente prima dell'autenticazione
4. Per gli account Google e Microsoft, potrebbe essere necessaria una password specifica per l'app o per abilitare app meno sicure
5. Verificare le restrizioni dell'account o le limitazioni IP

Blocco delle porte da parte di ISP e reti

Il blocco delle porte è sempre più comune, soprattutto per la porta 25:

Identificazione del blocco delle porte

Segnali che indicano un blocco delle porte:

• Si verificano costantemente timeout di connessione
• Altri servizi Internet funzionano normalmente
• Il problema persiste su diversi client di posta elettronica
• I problemi si verificano su una rete ma non su altre

Test per il blocco delle porte:

Soluzioni per il blocco delle porte

1. Passare a una porta alternativa:

• Prova la porta 587 per l'invio del messaggio
• Se fallisce, prova la porta 465
• Come ultima risorsa, prova la porta 2525

2. Utilizzare una VPN o una rete diversa:

• Le reti mobili potrebbero avere politiche diverse rispetto agli ISP domestici
• Le reti aziendali possono essere instradate tramite uno smart host

3. Contatta il tuo ISP:

• Alcuni ISP sbloccheranno la porta 25 per i clienti aziendali
• Sii pronto a spiegare la tua legittima necessità

4. Utilizzare uno smart host o un relay:

• Configura il tuo server di posta per inoltrare tramite il server SMTP del tuo ISP
• Utilizzare un servizio di consegna e-mail di terze parti

Problemi di negoziazione TLS

I problemi TLS possono essere sottili e difficili da risolvere:

Problemi comuni di TLS

1. Errori di convalida del certificato:

• Il certificato del server è scaduto
• Il certificato non proviene da un'autorità attendibile
• Il nome host del certificato non corrisponde al nome del server
• Il client e il server non riescono a concordare sulle suite di cifratura

2. Discordanze nella versione del protocollo:

• Il client utilizza una versione TLS più recente di quella supportata dal server
• Il server richiede una versione TLS più recente di quella supportata dal client
• Implementazioni TLS obsolete con vulnerabilità

Diagnosi dei problemi TLS

Utilizzare OpenSSL per ispezionare l'handshake TLS:

Risoluzione dei problemi TLS

1. Soluzioni lato server:

• Aggiorna i certificati SSL/TLS
• Configurare le catene di certificati appropriate
• Supporta le versioni moderne di TLS (1.2, 1.3)
• Disabilitare le suite di cifratura non sicure

2. Soluzioni lato client:

• Aggiorna il client di posta elettronica o le librerie per supportare il moderno TLS
• Configurare il client in modo che si fidi dell'autorità di certificazione del server
• Se necessario, regolare le impostazioni di sicurezza TLS

3. Soluzioni temporanee (da usare con cautela):

• Disabilita la convalida del certificato solo per i test
• Prova diverse versioni di TLS per isolare i problemi di compatibilità

Oltre SMTP: protocolli di posta elettronica correlati

Qualcuno è seduto davanti a un computer con delle frecce che puntano alle icone SMTP, IMAP e POP3

SMTP non è l'unico sistema correlato alla posta elettronica, ed è importante comprendere il resto del sistema per poter creare sistemi che funzionino in modo efficace, sostenibile ed efficiente. Ecco una guida rapida ad alcuni degli altri fattori che è necessario conoscere.

Mentre SMTP gestisce l'invio di e-mail, la ricezione di e-mail richiede protocolli diversi:

POP3 (Post Office Protocol versione 3)

POP3 è uno dei protocolli di recupero della posta elettronica più vecchi:

• Funzione: scarica i messaggi dal server al client
• Porte predefinite: 110 (non crittografata) e 995 (SSL/TLS)
• Comportamento: in genere rimuove i messaggi dal server dopo il download
• Ideale per: accesso a un singolo dispositivo con spazio di archiviazione limitato sul server

Una semplice sessione POP3 potrebbe apparire così:

IMAP (protocollo di accesso ai messaggi Internet)

IMAP è un protocollo più sofisticato per l'accesso alle caselle di posta:

• Funzione: sincronizza i messaggi tra server e client
• Porte predefinite: 143 (non crittografata) e 993 (SSL/TLS)
• Comportamento: mantiene i messaggi sul server, consentendo l'accesso a più dispositivi
• Ideale per: più dispositivi che accedono alla stessa casella di posta

Una sessione IMAP potrebbe iniziare:

Come questi protocolli interagiscono con SMTP

Il percorso end-to-end della posta elettronica prevede l'interazione di più protocolli:

1. Composizione e invio (SMTP):

• L'utente scrive un'e-mail
• Il client di posta elettronica invia tramite SMTP al server di invio
• Il messaggio viene inoltrato tramite SMTP al server di posta del destinatario

2. Archiviazione e recupero (POP3/IMAP):

• Il server del destinatario memorizza il messaggio in arrivo
• Il destinatario si connette tramite POP3 o IMAP per accedere alla propria casella di posta
• I messaggi vengono scaricati (POP3) o sincronizzati (IMAP)

3. Risposta (di nuovo SMTP):

• Il destinatario risponde al messaggio
• Il loro cliente invia la risposta tramite SMTP
• Il ciclo continua

Configurazioni delle porte per un sistema di posta elettronica completo

Una configurazione completa del server di posta elettronica richiede più porte:

Per configurare un server di posta elettronica completo è necessario configurare tutte queste porte in modo appropriato, sia per la funzionalità di invio che di ricezione.

Tendenze e considerazioni future sulle porte SMTP e sulla sicurezza della posta elettronica

Illustrazione di uno sviluppatore che riflette sulle tendenze future della posta elettronica.

Con l'evoluzione della tecnologia, si evolveranno anche i sistemi di posta elettronica. Rimanere al passo con questi cambiamenti è fondamentale per garantire che i sistemi di posta elettronica funzionino in modo efficace, sia dal punto di vista tecnico che in linea con le normative moderne.

Dato che la situazione è in continua evoluzione, è fondamentale rimanere informati e rimanere al passo con i tempi. Tra le risorse migliori ci sono:

• IETF (Internet Engineering Task Force) – Segui gli RFC e i gruppi di lavoro correlati alla posta elettronica
• M3AAWG – Sicurezza della messaggistica e best practice anti-abuso
• Bollettini di sicurezza US-CERT – Avvisi di sicurezza dell'infrastruttura via e-mail
• Parola al saggio: il blog autorevole di Laura Atkins sulla consegna delle e-mail
• Guida alla recapitabilità di Postmark: approfondimenti tecnici sull'infrastruttura della posta elettronica
• Blog Email on Acid – Approfondimenti tecnici sul rendering e la recapitabilità delle e-mail
• Community Slack di Email Geeks: discussioni attive tramite una community Slack tra professionisti della posta elettronica
• r/emailmarketing – Community di Reddit per discussioni sulla tecnologia della posta elettronica
• MXToolbox – Diagnostica e monitoraggio completi delle e-mail
• CheckTLS – Testa le capacità e la sicurezza SMTP TLS
• DMARC Analyzer – Monitoraggio e reporting dell'autenticazione

Tuttavia, come linea guida sui cambiamenti a cui prestare attenzione, potresti prendere in considerazione:

Standard emergenti e miglioramenti della sicurezza

Il panorama della posta elettronica continua a evolversi con diversi sviluppi promettenti:

MTA-STS (SMTP Strict Transport Security)

MTA-STS è uno standard relativamente nuovo (definito in RFC 8461) che aiuta a proteggere la consegna delle e-mail:

• Consente ai proprietari di domini di specificare i requisiti per la crittografia TLS
• I clienti possono scoprire queste policy tramite DNS e HTTPS
• Fornisce protezione contro gli attacchi di downgrade e man-in-the-middle
• Migliora la sicurezza delle connessioni SMTP tra i server

Esempio di implementazione: pubblicazione di una policy MTA-STS:

Crea un record DNS:

DANE (autenticazione basata su DNS di entità denominate)

DANE (specificato in RFC 7672) fornisce un ulteriore livello di sicurezza:

• Utilizza DNSSEC per associare i server SMTP ai loro certificati TLS
• Previene gli attacchi di spoofing dei certificati
• Riduce la dipendenza dalle autorità di certificazione di terze parti
• Aggiunge una convalida più forte per le connessioni SMTP

Esempio di record DANE:

TLS 1.3 e oltre

Lo stesso TLS continua a migliorare:

• TLS 1.3 (la versione più recente) fornisce:

• Stabilimento di connessione più veloce
• Sicurezza migliorata rimuovendo le funzionalità vulnerabili
• Segretezza in avanti per tutte le connessioni
• Negoziazione semplificata della suite di cifratura

• I futuri miglioramenti di TLS si concentreranno probabilmente su:

• Crittografia quantistica resistente
• Ulteriori ottimizzazioni delle prestazioni
• Meccanismi di autenticazione più robusti

Le migliori pratiche per rimanere aggiornati

Per mantenere la sicurezza della posta elettronica nel tempo:

1. Aggiornamenti regolari:

• Mantenere aggiornato il software del server di posta
• Aggiorna le librerie e i certificati TLS
• Rivedere e aggiornare periodicamente le policy di sicurezza

2. Monitorare gli annunci di sicurezza:

• Iscriviti ai bollettini sulla sicurezza per il tuo software di posta elettronica
• Segui organizzazioni come US-CERT e IETF
• Partecipare alle comunità degli operatori di posta elettronica

3. Implementare gli standard emergenti:

• Aggiungi MTA-STS quando il tuo software di posta lo supporta
• Considera DANE per una maggiore sicurezza
• Distribuisci DMARC, SPF e DKIM per l'autenticazione

4. Test e convalida:

• Testare regolarmente la sicurezza della propria infrastruttura di posta elettronica
• Usa strumenti come Labs SSL or CheckTLS
• Condurre controlli di sicurezza periodici

Cosa aspettarsi dalla sicurezza della trasmissione di posta elettronica

Guardando al futuro, è probabile che diverse tendenze influenzeranno la sicurezza della posta elettronica:

1. Maggiore enfasi sulla crittografia:

• La trasmissione di e-mail in testo normale diventerà sempre più rara
• Altri provider richiederanno TLS per tutte le connessioni
• La porta 25 potrebbe eventualmente essere utilizzata esclusivamente con la crittografia

2. Consolidamento della standardizzazione:

• L'utilizzo delle porte potrebbe semplificarsi nel tempo
• Emergeranno nuovi standard per affrontare le vulnerabilità rimanenti
• L'attuazione delle misure di sicurezza diventerà più coerente

3. Autenticazione avanzata:

• L'autenticazione a più fattori diventerà più comune
• Metodi migliorati per convalidare i server di invio
• Migliori difese contro lo spoofing e il phishing

4. Integrazione con architetture moderne:

• Le API completeranno sempre di più il tradizionale SMTP
• Le architetture di posta elettronica basate sui microservizi cresceranno
• Le soluzioni di posta elettronica cloud-native si espanderanno

Concludendo

Dopo aver esplorato le complessità delle porte SMTP, emergono alcune linee guida chiare:

1. La porta 587 rimane lo standard consigliato per l'invio di e-mail:

• Fornisce una trasmissione sicura tramite STARTTLS
• È ampiamente supportato e meno frequentemente bloccato
• Segue gli standard IETF stabiliti

2. La porta 25 dovrebbe essere riservata esclusivamente alla comunicazione tra server:

• È spesso bloccato per le connessioni client
• Manca la sicurezza obbligatoria in molte implementazioni
• È la porta standard per il trasferimento della posta tra server

3. La porta 465 funge da alternativa per l'invio sicuro:

• Offre TLS implicito che impedisce gli attacchi di downgrade
• Potrebbe essere necessario per i sistemi legacy
• Fornisce una buona sicurezza ma non è lo standard IETF

4. La porta 2525 funziona come opzione di fallback:

• Bypassa i blocchi delle porte comuni
• Non è standardizzato ma è ampiamente supportato
• Dovrebbe essere utilizzato solo quando le porte standard non sono disponibili

Per i diversi utenti di posta elettronica, le porte che consigliamo sono:

Per gli utenti individuali:

• Configurare i client di posta elettronica per utilizzare la porta 587 con STARTTLS
• Assicurarsi che sia abilitata l'autenticazione corretta
• Utilizzare la porta 465 solo se specificamente consigliato dal tuo provider di posta elettronica

Per gli amministratori di posta elettronica aziendale:

• Configurare i server di posta per accettare invii sulla porta 587
• Richiede crittografia e autenticazione TLS
• Utilizzare la porta 25 solo per il relay server-to-server con TLS abilitato
• Mantenere aggiornate tutte le misure di sicurezza e i certificati

Per gli sviluppatori che integrano la funzionalità di posta elettronica:

• Implementa la porta 587 come porta SMTP predefinita
• Includere opzioni di fallback su altre porte (465, 2525)
• Utilizzare sempre l'autenticazione e la crittografia
• Rimani aggiornato sulle migliori pratiche di sicurezza

Per i provider di servizi di posta elettronica:

• Supporta entrambe le porte 587 e 465 per la massima compatibilità
• Offrire la porta 2525 come opzione di fallback
• Implementare una sicurezza avanzata su tutte le porte
• Rimani al passo con gli standard emergenti e le pratiche di sicurezza

Seguendo queste best practice e restando informato, puoi garantire che la tua infrastruttura di posta elettronica rimanga sicura e affidabile, recapitando correttamente i messaggi e proteggendo al contempo le informazioni sensibili da intercettazioni o compromissioni.

La posta elettronica rimane uno degli strumenti di comunicazione più importanti e comprendere le sfumature delle porte SMTP è essenziale per chiunque gestisca sistemi di posta elettronica.

I protocolli e le porte che abbiamo esplorato rappresentano decenni di evoluzione degli standard Internet, adattandosi alle crescenti minacce alla sicurezza e mantenendo al contempo l'interoperabilità che rende la posta elettronica così universale.