SMTP: Come spediamo lettere digitali dal 1982

Se c’è una cosa che mi affascina terribilmente dell’informatica, non è l’ultimo framework JavaScript nato ieri notte e già obsoleto stamattina. No. È la persistenza. È la capacità di certe tecnologie di rimanere immobili mentre il mondo intorno a loro vortica impazzito.

Oggi parliamo di uno di questi monoliti. Parliamo di SMTP (Simple Mail Transfer Protocol).

Mentre noi ci preoccupiamo di interfacce grafiche, AI generative e assistenti vocali, là sotto, nelle fondamenta buie di Internet, c’è un protocollo scritto negli anni '80 che continua imperterrito a smistare miliardi di messaggi al giorno. È il postino instancabile del web e, sorprendentemente, funziona esattamente come funzionava quarant'anni fa.

In questo articolo, voglio smontare il giocattolo. Non ci limiteremo a dire "premi invio e parte". Andremo a vedere cosa succede quando inviando una mail un pacchetto di dati lascia il tuo computer, come naviga nella rete e perché, nonostante tutto, l'email resta l'unico vero protocollo decentralizzato che possediamo ancora.

L'architettura del servizio postale

Prima di sporcarci le mani con i comandi, dobbiamo capire chi sono gli attori in scena. Quando mandate una mail, non state lanciando un sasso direttamente nella finestra del destinatario. State affidando una lettera a una catena di montaggio ben definita, in cui ogni attore svolge un solo compito ma in sinergia con tutti gli altri.

Possiamo dividere il processo in tre attori fondamentali: MUA, MTA e MDA. Capiti questi, avete capito tutto il sistema di posta elettronica mondiale.

1) Mail User Agent (MUA)

Questo è il vostro software di posta elettronica. Outlook, Thunderbird, Apple Mail, o l'interfaccia web di Gmail. Il MUA è quello che vi permette di scrivere il testo della mail e premere invio. Il suo lavoro finisce quasi subito: formattare il messaggio e passarlo al livello successivo.

2) Mail Transfer Agent (MTA)

Qui entriamo nel regno dei server. L'MTA è il vero motore SMTP (software come Postfix, Exim, Sendmail o Microsoft Exchange). Quando il vostro MUA passa la mail al vostro MTA, questo si fa carico di trovare la strada verso il destinatario e recapitargli la mail. Se il destinatario è sullo stesso server, la consegna è locale e immediata. Se è altrove (tipo un indirizzo @gmail.com mentre voi siete su @hotmail.com), l'MTA deve uscire su Internet e cercare il server del destinatario.

3) Mail Delivery Agent (MDA)

È l'ultimo miglio. Una volta che la mail è arrivata al server di destinazione, l'MTA la passa all'MDA (software come Dovecot) che ha il compito di prendere quella mail e inserirla nella casella di posta del destinatario, in attesa che lui se la venga a leggere.

Un protocollo testuale

La bellezza di SMTP è che è un protocollo testuale. Non ci sono codici binari incomprensibili né handshake crittografici oscuri (almeno non nella versione base del protocollo).

Se osservaste i comandi scambiati tra gli attori coinvolti, potreste quasi letteralmente leggere i messaggi dei server in inglese.

Per vedere questo dialogo con i vostri occhi, possiamo usare uno strumento "antico" chiamato Telnet. Telnet è un protocollo di rete che permette di stabilire una connessione a riga di comando con un server remoto. Per dirla in maniera molto semplice, apre un canale diretto dove potete scrivere comandi di puro testo e vedere le risposte del server, senza nessuna interfaccia grafica in mezzo.

Immaginiamo di voler spedire una mail a mario@example.com partendo dal nostro server. Negli esempi seguenti S è il messaggio che ci invia il server del destinatario, mentre C è il nostro server (mittente). Ecco cosa succede, riga per riga, in una sessione simulata:

1

Il nostro server bussa alla porta del server di Mario.

S: 220 mail.example.com ESMTP Postfix

Il server di Mario risponde: "Ehilà, sono pronto. Sono il programma Postfix". Quel codice, 220, è il semaforo verde. "Servizio pronto".

2

Il nostro server deve presentarsi, e lo fa inviando il comando HELO seguito dal nome del server di posta.

C: EHLO mail.foo.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 8BITMIME

EHLO, scritto così, non è un errore ma è la versione "Extended" del vecchio comando HELO. Dicendo EHLO, il server remoto ci risponde con un elenco di funzionalità che supporta: "Accetto allegati grandi tot", "Parlo in maniera crittografata (STARTTLS)", ecc. Il codice 250 significa sempre "Tutto OK".

3

Ora dichiariamo il mittente della busta usando il comando MAIL FROM. Attenzione: questo è quello che c'è scritto sulla busta, non nella lettera. Sono due cose diverse (e vedremo dopo perché questo causa problemi di spam).

C: MAIL FROM:<riccardo@foo.com>
S: 250 2.1.0 Ok

Il server remoto segna: "Bene, questo messaggio arriva da riccardo@foo.com".

4

A chi è destinata la busta? Col comando RCPT TO specifichiamo il destinatario.

C: RCPT TO:<mario@example.com>
S: 250 2.1.5 Ok

Qui il server fa un primo controllo sulla validità dell'indirizzo di destinazione. L'utente Mario esiste? La sua casella è piena? Se Mario non esistesse, riceveremmo un 550 User unknown e la conversazione finirebbe qui. Invece, riceviamo un altro 250 OK, quindi procediamo.

5

Ora viene il bello. Diciamo al server che stiamo per dettare il contenuto della mail utilizzando il comando DATA.

C: DATA
S: 354 End data with <CR><LF>.<CR><LF>

Il server ci dice: "Scrivi pure. Quando hai finito, metti un punto da solo su una riga nuova". Adesso quindi inseriamo gli Headers (l'intestazione della lettera vera e propria) e il Body del messaggio, seguiti da un punto singolo.

C: Subject: Greetings
C: To: Mario <mario@example.com>
C: From: Riccardo <riccardo@foo.com>
C: Date: Tue, 03 Jan 2026 10:00:00 +0100
C:
C: Hi Mario,
C: This is a message for you!
C: .

6

Il server remoto elabora il messaggio ricevuto, lo salva sul disco e ci dà la ricevuta.

S: 250 2.0.0 Ok: queued as 832A912F
C: QUIT
S: 221 2.0.0 Bye

Fatto. La mail è partita. Niente magia. Solo testo ASCII che viaggia su una connessione di rete.

Il DNS e i record MX

Ma facciamo un passo indietro. Come faceva il mio server a sapere a quale indirizzo IP bussare per trovare Mario? Io ho scritto solo mario@example.com.

Qui entra in gioco il DNS (Domain Name System). Di solito pensiamo al DNS come all'elenco telefonico di Internet che traduce nomi facili da ricordare (come google.com) in indirizzi IP numerici (Record A) necessari ai computer per comunicare o fare richieste. Ma per le mail non cerchiamo l'indirizzo generico del server web, cerchiamo l'indirizzo specifico dell'ufficio postale competente per quel dominio, ovvero il record MX (Mail eXchanger).

In pratica, quando invio una mail il mio server interroga il DNS: "Ehi, chi gestisce la posta per example.com?". Il DNS risponde con una lista prioritaria:

1. 10 mail.example.com
2. 20 backup.example.com

Il numero indica la priorità. Il mio server proverà a contattare il primo. Se non risponde (timeout, server giù, apocalisse zombie), proverà col secondo. Questa ridondanza intrinseca è uno dei motivi per cui le mail sono così resilienti. Se il server principale cade, la posta non si perde: o viene consegnata al server di backup, o rimane nella "coda" del mio server che riproverà a consegnarla a intervalli regolari per diversi giorni.

Spam e spoofing

Se avete letto attentamente questo articolo fino qui, avrete sicuramente notato una falla GIGANTESCA.

Nel comando MAIL FROM, io posso scrivere quello che voglio! Potrei connettermi al server del destinatario e dire MAIL FROM:<president@whitehouse.gov> in maniera totalmente legittima.

Nel 1982, questo non era un problema. Internet era un club di gentiluomini e accademici. Oggi è invece il Far West e questa vulnerabilità è la base dello Spoofing e del Phishing.

Per mettere una pezza a un protocollo nato troppo ingenuo non abbiamo modificato il protocollo SMTP, ma negli anni abbiamo costruito delle sovrastrutture di sicurezza. Oggi esistono metodi che riducono di parecchio la possibilità di manomissione delle mail:

1. SPF (Sender Policy Framework): È un record DNS che dice: "Gli unici IP autorizzati a spedire mail a nome di whitehouse.gov sono questi: 1.2.3.4". Se la mail arriva da un IP diverso, è un falso. È come un buttafuori con la lista degli invitati.
2. DKIM (DomainKeys Identified Mail): Qui usiamo la crittografia per firmare il messaggio. Il server del mittente appone una firma digitale all'intestazione della mail, scrivendo la chiave pubblica nel DNS. Il server del destinatario, ricevendo la mail, preleva dal DNS la chiave pubblica e con quella verifica la firma del messaggio. Se la mail è stata manomessa durante il viaggio, la firma salta.
3. DMARC: È il capo degli altri due. Dice al server del destinatario cosa fare se SPF o DKIM falliscono. "Se la firma non è valida, butta via tutto", oppure "Mettila in spam e inviami un report giornaliero".

Senza questi tre sistemi di sicurezza la vostra mail oggi non arriverebbe nemmeno nella cartella Spam di Gmail. Verrebbe respinta alla porta.

Perché allora non gestirsi un server di posta da soli?

Arriviamo alla nota dolente. La teoria è bellissima. Installare Postfix su una VPS Linux richiede 10 minuti e configurare Dovecot altri 10. In mezz'ora avete un server di posta funzionante.

Ma funzionante non significa affidabile.

Il vero problema oggi non è spedire la mail ma è convincere gli altri server ad accettarla perché i grandi player (Google, Microsoft, Yahoo) hanno alzato muri altissimi per proteggere i loro utenti dallo spam.

Se il vostro IP è nuovo e non ha "reputazione", le vostre mail verranno rifiutate o finiranno direttamente nello spam, e costruirsi una reputazione è un processo lento e doloroso.

Ecco perché, pur amando l'autonomia, spesso consiglio di usare relay esterni professionali (come SendGrid o AWS SES) per l'invio delle mail, magari mantenendo la gestione delle caselle in locale. Questo potrebbe essere il compromesso giusto tra sovranità dei dati e pragmatismo operativo.

Sopravvissuto

In conclusione possiamo tranquillamente affermare che SMTP è un sopravvissuto. È nato in un'epoca in cui la larghezza di banda era preziosa e la fiducia era implicita. Negli anni è stato abusato, rattoppato, esteso e blindato. Eppure, è ancora lì.

Ogni volta che sentite il suono di notifica sul telefono, ricordatevi che dietro c'è stato quel balletto di "HELO", "MAIL FROM", "RCPT TO" che avviene instancabile da più di quarant'anni.

In un mondo tecnologico che soffre di obsolescenza programmata, studiare SMTP è quasi archeologia digitale, ma è un'archeologia viva. Ci ricorda che le cose semplici (o meglio, le cose standard) sono quelle che durano. E forse, in questo, c'è una lezione anche per come dovremmo costruire il software di domani.