Quale porta SMTP dovrebbe usare un'applicazione per le email?

Una porta SMTP seleziona un ruolo di protocollo e una modalità di connessione

Un numero di porta non è semplicemente un ingresso intercambiabile verso lo stesso servizio. Aiuta a capire quale ruolo SMTP offre il server e come inizia la connessione. La submission dei messaggi è il primo passaggio da un'applicazione o da uno user agent a un servizio di submission. Il relay è il trasferimento della posta tra server di posta. Gli standard separano questi compiti perché la submission può richiedere autenticazione, autorizzazione del mittente e controlli di policy sui messaggi che non si applicano allo stesso modo al relay pubblico. La porta può indicare anche se il client inizia con comandi SMTP ed esegue poi l'upgrade con STARTTLS, oppure se inizia subito con un handshake TLS. Tratta hostname, porta, modalità TLS e istruzioni di autenticazione del provider come un'unica configurazione. Copiare la porta di un provider non correlato, o cambiare solo la porta dopo un errore, può trasformare un problema di rete in un errore TLS o di autenticazione senza risolvere la causa originale.

La porta 25 serve principalmente al relay tra server di posta

La porta 25 è la porta convenzionale del relay SMTP, usata quando un Message Transfer Agent passa la posta a un altro. RFC 6409 mantiene il relay sulla porta 25 e sposta la submission dei nuovi messaggi sulla porta 587. Un'applicazione non dovrebbe quindi presumere che le connessioni dirette ai server di posta dei destinatari sulla porta 25 siano il modo normale di inviare email di prodotto. Il relay diretto richiede code, instradamento DNS, gestione dei bounce, controlli anti-abuso, gestione della reputazione e un comportamento di ritentativo conforme agli standard. Anche reti e provider di hosting possono limitare la porta 25 in uscita. AWS, per esempio, documenta che per impostazione predefinita limita il traffico email di Amazon EC2 sulla porta 25. La porta 25 può comunque essere un'opzione documentata presso un provider o all'interno di un'infrastruttura controllata, ma la sua disponibilità non la rende la scelta preferita per la submission. Usala solo quando il servizio responsabile documenta esplicitamente quell'endpoint, la modalità di sicurezza e il modello operativo.

La porta 587 è la porta standard per la submission dei messaggi

RFC 6409 riserva la porta 587 alla submission dei messaggi e descrive un servizio di submission che può rifiutare la posta non autorizzata, richiedere l'autenticazione e applicare policy prima di accettare un nuovo messaggio. Una tipica sessione sulla porta 587 inizia in SMTP, annuncia l'estensione STARTTLS dopo `EHLO`, esegue l'upgrade della connessione a TLS, ripete `EHLO`, si autentica e poi invia il messaggio. La parola tipica è importante: i meccanismi e i requisiti di autenticazione esatti dipendono dalla documentazione attuale del provider e dalle capacità del server. Un client sicuro dovrebbe pretendere l'upgrade TLS previsto e convalidare il certificato del server, invece di proseguire in chiaro dopo una negoziazione fallita. Non confondere un saluto iniziale del protocollo non cifrato con una sessione autenticata non protetta: STARTTLS è progettato per proteggere la connessione prima dell'invio di credenziali e dati del messaggio. La porta 587 identifica il servizio di submission, mentre l'effettiva imposizione del TLS dipende da una policy corretta del client.

La porta 465 usa il TLS implicito per la submission

La porta 465 è registrata per la submission dei messaggi su TLS implicito. Con il TLS implicito, il client esegue l'handshake TLS non appena si apre la connessione TCP e invia comandi SMTP solo all'interno del canale protetto. È diverso dalla porta 587 con STARTTLS, dove il client riceve prima un saluto SMTP e poi richiede l'upgrade. RFC 8314 raccomanda il TLS implicito per la submission, descrivendo però anche una fase di transizione in cui provider e client possono supportare sia la porta 465 con TLS implicito sia la porta 587 con STARTTLS. La RFC osserva che client e server implementati correttamente possono offrire una sicurezza sostanzialmente equivalente con entrambe le modalità, quando TLS è obbligatorio. La regola pratica è non dichiarare una porta universalmente corretta. Usa l'endpoint e la modalità esatti supportati dal provider. Configurare STARTTLS verso un listener a TLS implicito, o il TLS implicito verso un listener STARTTLS, di solito fallisce prima dell'autenticazione.

Le porte alternative specifiche di un provider sono contratti espliciti

Alcuni provider offrono porte alternative per aggirare le restrizioni di rete, ma quei numeri non sono standard SMTP universali validi per ogni servizio. Amazon SES documenta attualmente STARTTLS sulle porte 25, 587 e 2587 e TLS Wrapper, il suo termine per il TLS implicito, sulle porte 465 e 2465. SES richiede connessioni cifrate e pubblica endpoint SMTP specifici per regione. Questo mostra perché una porta va presa dalla documentazione del provider scelto e non da un elenco generico. La porta 2587 non significa STARTTLS ovunque, e la porta 2465 non identifica un servizio a TLS implicito su host arbitrari. Le porte alternative inoltre non aggirano la verifica del mittente, l'ambito delle credenziali, le quote o le policy del provider. Registra l'URL della fonte e la data di verifica insieme alla configurazione di produzione, così che un operatore possa distinguere un'impostazione intenzionale del provider da un numero magico inspiegabile copiato anni prima in una variabile d'ambiente.

Configura insieme hostname, porta, TLS e autenticazione

Una configurazione SMTP solida è un insieme: hostname del provider, porta, modalità di sicurezza del trasporto, policy di convalida dei certificati, meccanismo di autenticazione, nome utente, segreto, timeout di connessione e identità di invio. L'hostname conta perché il certificato TLS viene convalidato rispetto a esso e perché i provider possono esporre endpoint regionali diversi. Porta e modalità TLS devono essere coerenti. L'autenticazione dovrebbe avvenire solo dopo che il canale protetto previsto è stato stabilito, e i segreti dovrebbero restare in un secret manager, non nel codice sorgente, nei bundle del browser, nei log o nell'output diagnostico. Separa credenziali e configurazione per ambiente, così che un test locale non possa inviare per errore tramite la produzione. Imposta timeout finiti per connessione e comandi, ma lascia che sia una coda applicativa persistente a gestire i nuovi tentativi dei messaggi. Un'opzione di libreria chiamata `secure` può significare TLS implicito in un SDK e semplicemente richiedere STARTTLS in un altro: verifica quindi la definizione della libreria e testa il comportamento effettivamente negoziato, invece di fidarti del nome dell'opzione.

Testa la connessione per livelli senza esporre segreti

Inizia dalla risoluzione DNS e dalla raggiungibilità TCP dalla stessa rete di esecuzione dell'applicazione. Un timeout prima della connessione fa pensare a instradamento, firewall, policy di uscita del provider, hostname errato o porta chiusa. Poi testa la modalità TLS prevista. Con il TLS implicito, un client TLS dovrebbe ricevere un certificato e poi un saluto SMTP. Con STARTTLS, un client che parla SMTP dovrebbe ricevere il saluto, inviare `EHLO`, vedere STARTTLS tra le estensioni annunciate, richiedere l'upgrade, convalidare il certificato e inviare di nuovo `EHLO` dopo TLS. RFC 3207 richiede che client e server scartino le informazioni ottenute prima dell'handshake, ed è per questo che il secondo `EHLO` è importante. Solo a quel punto testa l'autenticazione con un account controllato. Oscura nomi utente, token, indirizzi dei destinatari, trascrizioni complete del server e contenuti dei messaggi prima di condividere i log. Una verifica di connettività non richiede un invio di produzione né l'indirizzo di un cliente reale.

Classifica gli errori in base alla fase effettivamente fallita

Una connessione rifiutata significa che la destinazione TCP ha attivamente rifiutato la connessione; un timeout significa che non è arrivata alcuna risposta utilizzabile entro il limite. Un errore di handshake TLS indica una modalità non corrispondente, un problema di certificato, un'incompatibilità di protocollo, un'intercettazione o un endpoint errato. Un errore di autenticazione si verifica più avanti e va analizzato come problema di configurazione di credenziali, meccanismo, account o autorizzazione, non risolto cambiando porta a caso. I codici di risposta SMTP durante `MAIL FROM`, `RCPT TO` o `DATA` descrivono decisioni di policy e sul messaggio ancora successive. Conserva fase, timestamp, endpoint, numero di tentativi, codice di risposta numerico e una risposta filtrata per la privacy. Una risposta SMTP 4xx è di norma temporanea e una 5xx è di norma permanente per il comando tentato, ma i nuovi tentativi devono essere limitati e tenere conto del destinatario. Se il provider ha accettato i dati del messaggio, non inviare alla cieca un duplicato solo perché una richiesta applicativa successiva è andata in timeout; riconcilia usando l'identificatore del provider e la cronologia degli eventi.

Una porta funzionante non significa consegna né arrivo in inbox

Una connessione TCP riuscita dimostra solo che un listener ha risposto. Un handshake TLS riuscito dimostra una connessione protetta verso l'endpoint autenticato, se la convalida del certificato va a buon fine. L'autenticazione dimostra che il server ha accettato l'identità del client presentata per quella sessione. Una risposta SMTP `250` dopo i dati del messaggio significa che il server che ha risposto si è assunto la responsabilità secondo il protocollo, non che una persona abbia ricevuto o letto il messaggio. Un relay successivo può ancora fallire, e un sistema destinatario può accettare la posta classificandola fuori dalla inbox principale. Mantieni questi stati separati nei record applicativi e nel monitoraggio. Disponibilità di rete, negoziazione TLS, autenticazione, accettazione da parte del provider, accettazione da parte del server di destinazione, bounce, segnalazione di spam ed engagement sono osservazioni diverse. Questa separazione evita che una verifica della porta venga riportata erroneamente come test di consegna e che un messaggio accettato venga ritentato solo perché l'arrivo in inbox non si può dimostrare.

Scegli consapevolmente tra submission SMTP e API email

Usa la submission SMTP quando un sistema dispone già di un client SMTP maturo, quando una piattaforma richiesta espone SMTP come integrazione supportata o quando sono specificamente necessari controlli a livello di protocollo. Un'API email HTTPS può essere un confine applicativo migliore quando richieste strutturate, token con ambito limitato, idempotenza, risorse batch e record di eventi leggibili dalla macchina si adattano al carico di lavoro. Il provider può comunque usare SMTP a valle per raggiungere i sistemi di posta dei destinatari, quindi un'API non elimina il trasporto della posta. Sposta la responsabilità di porta, TLS, autenticazione e nuovi tentativi per il passaggio rivolto al provider fuori dalla configurazione SMTP dell'applicazione.

Domande frequenti

Fonti

• RFC 6409: Message Submission for Mail — RFC Editor
• RFC 8314: Il testo in chiaro è considerato obsoleto: uso di Transport Layer Security (TLS) per submission e accesso email — RFC Editor
• RFC 3207: estensione del servizio SMTP per SMTP sicuro su TLS — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — RFC Editor
• Connessione a un endpoint SMTP di Amazon SES — Amazon Web Services