I codici di risposta SMTP spiegati per chi invia email

In breve#

Ogni volta che un server di posta parla con un altro, risponde a ogni comando con un codice di tre cifre. La prima cifra indica la categoria (2xx successo, 4xx errore temporaneo, 5xx errore permanente) e per la deliverability dice quasi tutto. Un verificatore di email legge questi stessi codici durante il suo test, senza mai inviare un messaggio, per stabilire se una casella è recapitabile, non recapitabile o non determinabile. Questa è la guida pratica ai codici che incontrerai davvero e all'esito che ciascuno produce.

Come leggere un codice di risposta#

I codici SMTP seguono una grammatica coerente. La prima cifra è la classe del risultato:

• 2xx: successo. Il comando ha funzionato. 250 ("requested action completed") è quello che vuoi vedere.
• 4xx: errore temporaneo. Qualcosa è andato storto, ma potrebbe funzionare se riprovi più tardi. È un rinvio, non un rifiuto.
• 5xx: errore permanente. Il server rifiuta, e riprovare non serve.

Molti server inviano anche un codice di stato avanzato: un secondo numero con i punti, come 5.1.1, definito dalla RFC 3463. La cifra centrale precisa il motivo: x.1.x riguarda l'indirizzo, x.2.x la casella, x.7.x la sicurezza o la policy. Proprio la classe x.7.x permette a un verificatore di distinguere un blocco per reputazione ("stiamo rifiutando te") da una semplice casella inesistente, anche quando il testo leggibile è vago.

Per la verifica, la corrispondenza è piacevolmente lineare:

I codici che incontrerai davvero#

250: OK#

Il destinatario è stato accettato. In un test di verifica è il segnale positivo più forte, ma va letto nel contesto: su un dominio catch-all il server restituisce 250 per ogni indirizzo, reale o no, quindi lì un 250 ha valore solo se un test parallelo su un indirizzo senza senso viene rifiutato.

421: servizio non disponibile#

Il server sta chiudendo la connessione, spesso perché è sovraccarico o ti sta limitando. Per classe è temporaneo: un verificatore lo tratta come un rinvio e riprova, poi segnala unknown se persiste.

450 / 451: casella non disponibile / errore locale, riprova#

Le classiche risposte del greylisting. Il server rifiuta temporaneamente un mittente sconosciuto e lo invita a riprovare. Un vero server di posta riprova in automatico; un verificatore riprova entro il suo tempo a disposizione e ripiega su unknown se il rinvio dura di più. Il testo di un 451 contiene spesso "greylisted, please try again later".

452: spazio di sistema insufficiente / troppi destinatari#

Spesso significa che la casella è piena. La casella esiste, ed è per questo che Qualisend tratta un segnale di casella piena come risky (low_deliverability) e non come non recapitabile: ora la posta può rimbalzare, ma l'indirizzo non è morto, e le caselle piene spesso tornano a funzionare.

550: casella non disponibile / utente sconosciuto#

Il rifiuto per eccellenza. L'indirizzo non esiste, oppure il server rifiuta il recapito in modo permanente. Esito: undeliverable / rejected_email. Se il codice avanzato è 5.1.1, si tratta nello specifico di "bad destination mailbox": un "no such user" netto e inequivocabile.

551 / 553: utente non locale / nome casella non consentito#

Rifiuti permanenti meno comuni: il server non inoltra per quel destinatario, oppure la forma dell'indirizzo non è accettabile. Entrambi sono undeliverable.

554: transazione fallita#

Un errore permanente generico, usato spesso per i blocchi di policy: "transaction failed", "message refused" o un rifiuto antispam. Se abbinato a un codice avanzato 5.7.x o a parole chiave di blacklist, segnala che il server sta rifiutando il tuo mittente, senza giudicare la casella: una distinzione che un buon verificatore registra a parte, così un problema di reputazione non viene scambiato per un indirizzo morto.

Il resto della conversazione#

La risposta a RCPT TO determina l'esito, ma lungo il percorso un test di verifica legge diversi altri codici, e riconoscerli aiuta quando hai davanti un log SMTP grezzo o un messaggio di bounce:

• 220: servizio pronto. Il saluto che il server invia quando ti connetti. Nessun 220 significa che non sei mai entrato: spesso è un blocco a livello di connessione, che un verificatore registra come unavailable_smtp.
• 250 dopo HELO/EHLO e MAIL FROM. Ogni passaggio dell'handshake riceve il suo 250. Un rifiuto prima di RCPT TO, per esempio a MAIL FROM, di solito significa che il server sta rifiutando il tuo mittente, non giudicando il destinatario.
• 354: inizia l'invio. Il server ti invita a inviare il corpo del messaggio. Un verificatore non ci arriva mai di proposito: si ferma a RCPT e si disconnette, quindi il messaggio non viene mai trasmesso.
• 221: chiusura della connessione. Il saluto cortese dopo QUIT.
• 501/502/503: errori di sintassi o di sequenza. I comandi sono arrivati malformati o fuori ordine. Riguardano la conversazione, non l'indirizzo, e un verificatore robusto li gestisce senza scambiarli per un esito sulla casella.

Il punto pratico: non tutto ciò che non è 250 è una casella morta. Un rifiuto nel passaggio sbagliato della conversazione di solito riguarda il tuo mittente o la connessione, e capire quale passaggio è fallito è il modo in cui un verificatore evita di dare al destinatario la colpa dell'umore del server.

Permanente, temporaneo e un onesto "sconosciuto"#

La decisione più importante di un verificatore è come trattare i 4xx. Un 5xx permanente è facile: l'indirizzo è sbagliato, sopprimilo. Anche un 250 è facile: è recapitabile (a parte le riserve sui catch-all). Ma un 4xx è il server che rifiuta esplicitamente di rispondere per ora, e la reazione onesta è riprovare, poi segnalare unknown se il rinvio persiste, mai tirare a indovinare.

È anche per questo che lo stesso indirizzo può restituire esiti diversi in esecuzioni diverse senza che alcuno strumento menta: la casella è deterministica, ma il codice che produce dipende dall'umore del server (greylisting al primo tentativo, 250 al successivo). I codici sono una conversazione dal vivo, non la consultazione di un database.

Dove la verifica legge questi codici#

Nella pipeline di verifica, i codici di risposta sono la materia prima della fase 6, il test SMTP della casella. Il verificatore esegue la conversazione di recapito (HELO, MAIL FROM, RCPT TO), legge il codice di RCPT e si disconnette prima di DATA, quindi il titolare della casella non riceve mai nulla. Tutto quanto sopra spiega come quel singolo codice RCPT diventa uno stato su cui puoi agire.