termine · protocollo SMTP

Che cos'è il protocollo SMTP e che impatto ha sulle email applicative?

SMTP, o Simple Mail Transfer Protocol, è il protocollo standard che i sistemi di posta usano per inviare, inoltrare tramite relay e consegnare le email in uscita. Di solito un'applicazione consegna un messaggio completo a un servizio di submission autenticato; i server di posta usano poi i comandi SMTP e l'instradamento DNS per portarlo verso ciascun destinatario. Le risposte SMTP rivelano se un determinato passaggio ha accettato o rifiutato un destinatario, ma l'accettazione non equivale all'arrivo in inbox. Le applicazioni hanno comunque bisogno di code persistenti, nuovi tentativi sicuri, identificatori dei messaggi, autenticazione ed elaborazione dei bounce.

SMTP trasferisce la posta tra sistemi responsabili

SMTP trasferisce la posta tra sistemi che se ne assumono la responsabilità

Submission e relay sono ruoli di protocollo diversi

L'RFC 6409 distingue la submission dei messaggi dal relay dei messaggi. La submission è il primo passaggio da un utente o un'applicazione autorizzati a un Message Submission Agent, di norma sulla porta 587. Il relay è il trasferimento tra Message Transfer Agent e usa per convenzione la porta 25. I servizi di submission possono richiedere l'autenticazione, convalidare o completare i campi del messaggio e applicare policy sui mittenti, perché sanno chi sta introducendo nuova posta. I server di relay pubblici devono interoperare con altri domini e seguono regole di fiducia diverse. Il codice applicativo dovrebbe quindi connettersi all'endpoint di submission documentato dal provider o usare la sua API HTTP, e non aprire connessioni arbitrarie sulla porta 25 verso i server di destinazione. Questa divisione chiarisce anche le credenziali: un nome utente o un token SMTP autorizza la submission a un determinato servizio, ma non conferisce autorità sul dominio di destinazione. Tieni le credenziali di submission lato server, limitane l'ambito al carico di invio quando il provider lo supporta e ruotale senza inserirle nel contenuto dei messaggi o nel software client.

La busta SMTP è diversa dalle intestazioni visibili del messaggio

Una transazione SMTP trasporta una busta con `MAIL FROM` e uno o più comandi `RCPT TO`. Il contenuto trasferito segue separatamente l'Internet Message Format definito dall'RFC 5322, con campi come From, To, Date, Subject e Message-ID più un body. Gli standard MIME estendono questo contenuto per HTML, parti alternative, allegati e dati non ASCII. Il mittente della busta è l'indirizzo usato per gli errori di trasporto e può essere diverso dall'autore visibile nel campo From. Anche i destinatari della busta possono essere diversi dai campi To e Cc visibili, come nel caso di Bcc. Non costruire queste strutture concatenando stringhe non attendibili. Usa una libreria di messaggi mantenuta, convalida gli indirizzi, blocca l'iniezione di caratteri di nuova riga nei campi di intestazione e conserva un Message-ID stabile. In fase di troubleshooting, esamina entrambi i livelli: un campo From visibile corretto non può rimediare a un'identità della busta non autorizzata, e una busta valida non fa visualizzare correttamente un MIME malformato.

Leggi la transazione come una macchina a stati

Una sessione Extended SMTP di base inizia con il saluto del server, poi con `EHLO`, così che il server possa annunciare le estensioni. Per la submission, il client può negoziare TLS e autenticazione. Una transazione di posta usa poi `MAIL FROM`, un `RCPT TO` per ogni destinazione, `DATA`, il messaggio completo terminato secondo il framing SMTP e `QUIT`. Non prendere l'esempio come un motivo per implementare manualmente il protocollo; le librerie SMTP mature gestiscono in modo più sicuro fine riga, dot transparency, negoziazione delle capacità, autenticazione e stato TLS. Strumenta la libreria a livello di categoria di comando e codice di risposta, senza registrare credenziali o body completi dei messaggi. Registra quale destinatario è fallito in quale fase e se il server aveva preso in carico il messaggio dopo i dati. Questo confine determina se un nuovo tentativo è appropriato, se è possibile un duplicato e se l'errore arriverà con una successiva notifica di stato di consegna invece che con una risposta immediata.

Classifica i codici di risposta prima di decidere se ritentare

Le classi di risposta SMTP indicano un'azione. Una risposta 2xx indica il completamento riuscito di quel comando. Una risposta 4xx è un completamento negativo transitorio, quindi un mittente con una coda può ritentare dopo un ritardo. Una risposta 5xx è un completamento negativo permanente per il comando tentato e di norma richiede una correzione, una soppressione o un'indagine manuale invece di tentativi ripetuti. I codici di stato estesi aggiungono una diagnosi strutturata `X.Y.Z` per condizioni di indirizzo, casella, sistema, instradamento, protocollo, contenuto o sicurezza e policy. Conserva sia il codice numerico sia il testo del server, perché entrambi possono aggiungere valore diagnostico, ma non esporre ampiamente le risposte raw che contengono dati dei destinatari. Applica agli errori transitori un backoff esponenziale con jitter e una durata massima in coda. Non ritentare mai in modo così aggressivo da trasformare un problema temporaneo della destinazione in traffico abusivo. In caso di errore permanente dell'indirizzo, interrompi gli invii automatici verso quella destinazione e aggiorna lo stato di soppressione. In caso di errore di policy o di autenticazione, correggi identità, DNS, credenziali o contenuto prima di un altro tentativo.

Usa una submission cifrata e autenticata

SMTP è nato come protocollo di trasporto tra reti con presupposti di fiducia diversi, quindi una submission sicura dipende dalle estensioni e dalle policy di deployment. STARTTLS aggiorna una connessione SMTP a TLS, dopodiché il client deve scartare le capacità apprese prima dell'handshake e inviare di nuovo `EHLO`. L'RFC 8314 aggiorna le indicazioni sulla submission considerando obsoleti l'accesso e la submission in chiaro e descrivendo il TLS implicito per la submission. SMTP AUTH, standardizzato nell'RFC 4954, permette a un server di submission di autenticare un client tramite i meccanismi annunciati. Usa hostname, porta, modalità TLS e istruzioni di autenticazione attuali del provider invece di indovinare una combinazione. Convalida il certificato del server e non ripiegare silenziosamente sul testo in chiaro quando il carico richiede una submission protetta. Conserva password o token in un secret manager, usa credenziali separate per ambiente e disabilita i meccanismi di autenticazione obsoleti. TLS protegge un singolo passaggio della connessione: non autentica l'autore del messaggio verso ogni ricevente a valle e non sostituisce l'allineamento delle identità SPF, DKIM e DMARC.

Diagnostica un errore delle email applicative passaggio per passaggio

Parti dal record persistente in uscita dell'applicazione: l'evento di prodotto era autorizzato e un solo job in coda lo ha preso in carico? Poi esamina la submission: risoluzione DNS, connessione TCP, negoziazione TLS, convalida del certificato, autenticazione, autorizzazione del mittente della busta, risposte per destinatario e risposta finale a DATA. Se il servizio di submission ha accettato il messaggio, smetti di riproporre la richiesta alla cieca e segui il suo identificatore del messaggio e il flusso di eventi. Distingui uno stato elaborato dal provider dall'accettazione da parte del server ricevente. Un bounce successivo può comunque segnalare un errore permanente dopo l'accettazione iniziale. Se il server ricevente ha accettato il messaggio, indaga su risultati dell'autenticazione, reputazione, policy del destinatario, contenuto e classificazione nella casella, invece di parlare di errore di trasporto SMTP. Controlla sia le identità della busta sia quelle delle intestazioni e conserva timestamp, codici di risposta, numero di tentativi in coda e identificatori del provider. Per i test usa destinatari controllati. Non incollare mai credenziali SMTP di produzione o messaggi completi dei clienti in ticket, prompt, cronologia del terminale o strumenti diagnostici pubblici.

Distingui accettazione, consegna e arrivo in inbox

Nelle interfacce di prodotto la precisione del protocollo conta. Accettazione da parte dell'applicazione significa che il sistema locale ha registrato una richiesta. Accettazione della submission significa che il primo servizio di posta ha preso in carico l'elaborazione. Consegna al server ricevente significa che il server SMTP di destinazione ha restituito un esito positivo per il passaggio. L'arrivo in inbox è una decisione successiva di policy e classificazione all'interno dell'ambiente ricevente. Un messaggio può superare uno stato e fallire, o essere classificato diversamente, in quello successivo. SMTP fornisce prove dirette sulla transazione in corso e può produrre successive notifiche di stato di consegna, ma non espone la cartella finale del destinatario. Memorizza questi stati in modo indipendente invece di etichettare ogni risposta 250 come consegna in inbox. Un evento del provider che include la risposta SMTP positiva della destinazione può supportare lo stato "consegnato al server". Un bounce supporta la gestione dell'errore o della soppressione. Nessuno dei due permette promesse su visibilità, lettura o engagement. Questo modello mantiene veritiero lo stato ed evita nuovi tentativi non sicuri dopo che la responsabilità è già stata trasferita.

Usa l'API documentata di SendHQ

I dettagli SMTP di Office 365 non consistono in un unico host e un'unica password universali. Microsoft documenta diversi modelli per applicazioni e dispositivi, tra cui submission del client autenticata tramite smtp.office365.com, relay SMTP basato su connettore tramite l'endpoint MX del tenant e Direct Send a destinatari Microsoft 365 interni. Differiscono per autenticazione, TLS, porte, identità del mittente, supporto di destinatari esterni, licenze, limiti e configurazione amministrativa. Scegli il modello in base al carico di lavoro e al confine di fiducia, usa OAuth dove si applica la submission del client, mantieni SMTP AUTH abilitato in modo restrittivo, testa le identità esatte della busta e From e tratta l'accettazione del relay separatamente dalla consegna finale o dall'arrivo in inbox.

Domande frequenti

Cosa significa SMTP?

SMTP sta per Simple Mail Transfer Protocol. Definisce come client e server di posta inviano e trasferiscono i messaggi in uscita tramite comandi, risposte, buste, dati del messaggio ed estensioni per funzionalità come autenticazione e TLS.

SMTP si usa per leggere le email da una inbox?

No. SMTP serve principalmente per inviare e trasferire la posta in uscita. L'accesso alla inbox usa altre interfacce come IMAP, POP, un'API della casella specifica del provider o un'API email applicativa che espone i messaggi in entrata memorizzati.

Che differenza c'è tra le porte 25, 587 e 465?

La porta 25 è usata per convenzione per il relay tra server. La porta 587 è il servizio standard di submission dei messaggi e di solito negozia TLS. La porta 465 è registrata per la submission su TLS implicito. Segui l'endpoint e la modalità di sicurezza documentati dal provider invece di cambiare porta per tentativi.

Un esito SMTP positivo dimostra che l'email è arrivata in inbox?

No. Una risposta positiva dimostra solo che il server SMTP che ha risposto ha accettato il comando o la presa in carico del messaggio. Il sistema ricevente può comunque applicare policy successive, generare un errore ritardato o classificare la posta accettata fuori dalla inbox principale.

Un'applicazione dovrebbe ritentare ogni risposta SMTP 4xx?

Un codice 4xx indica un risultato negativo transitorio, ma i nuovi tentativi dovrebbero usare una coda persistente, un backoff esponenziale con jitter, una durata finita e limiti di tentativi per destinatario. Indaga sugli errori temporanei ripetuti invece di ritentare all'infinito.

Un'API email HTTP sostituisce SMTP?

Può sostituire SMTP nel codice applicativo, ma di norma il provider usa comunque SMTP per comunicare con i sistemi di posta dei destinatari. Un'API aggiunge autenticazione strutturata, payload, ambito delle risorse, identificatori e gestione degli eventi sopra il livello di trasporto.

Fonti

Continua ad approfondire

Guida all'implementazione di un'API email per team di prodottoProgetta un'integrazione API email sicura con domini verificati, invii in coda, identificatori stabili, nuovi tentativi controllati, eventi di consegna, soppressione e isolamento dei tenant.