Il percorso di un'email

Modulo 1: Come funziona la posta elettronica · Tempo di lettura: 9 minuti

Obiettivo della lezione: Dopo questa lezione sarà in grado di descrivere passo dopo passo come un'email arriva dal mittente al destinatario, indicando per ogni passaggio quale programma o quale server svolge il lavoro.

Concetti chiave: programma di posta (MUA), server di invio (MSA, submission), server di posta (MTA), record MX, coda, consegna (MDA), mailbox, recupero (IMAP/POP3), envelope, intestazioni

La posta elettronica è posta, non un messaggio di chat

Quando invia un messaggio di chat, questo passa attraverso un'unica azienda: l'app del mittente e l'app del destinatario parlano con gli stessi server. La posta elettronica funziona diversamente. Il mittente e il destinatario possono trovarsi presso aziende diverse: uno presso un'azienda di hosting, l'altro su Gmail, un terzo su Microsoft 365 o sul server della propria azienda. Eppure l'email arriva comunque a destinazione. Questo è possibile perché tutti i server di posta del mondo seguono le stesse regole.

Può paragonare bene l'email alla posta tradizionale. Lei scrive una lettera (il messaggio), la inserisce in una busta con un indirizzo (l'envelope), la porta alla buca delle lettere (il server di invio), l'azienda postale individua dove si trova l'indirizzo (la ricerca MX), trasporta la lettera al centro di smistamento corretto (il server di posta ricevente) e questo la deposita nella cassetta della posta del destinatario (la mailbox). Il destinatario la ritira quando gli fa comodo.

Le tappe in sequenza

Supponiamo che Anna invii un'email da anna@example.com a jan@example.net. Ecco cosa succede:

Presso i piccoli provider, l'MSA, l'MTA e l'MDA sono spesso un unico programma su un unico server. Presso i grandi provider si tratta di cluster separati. Per Lei questo fa poca differenza: sono ruoli, non apparecchi distinti.

Noti la differenza tra il passo 1 e il passo 4. Entrambi utilizzano SMTP, il Simple Mail Transfer Protocol (RFC 5321). Ma nel passo 1 Lei effettua l'accesso e utilizza la porta 587 o 465; questo si chiama submission (RFC 6409). Nel passo 4 due server comunicano tra loro sulla porta 25, senza effettuare l'accesso: il server ricevente accetta posta per i propri domini da chiunque. Nella lezione 1.4 vedrà perché esiste questa separazione.

Il passo 3 da vicino: la ricerca MX

Il server mittente non sa da solo dove example.net riceve la propria posta. Lo chiede al DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Il numero più basso ha la priorità. Il server prova prima mx1 e, se questo non risponde, mx2. Successivamente interroga l'indirizzo IP di quel nome (record A o AAAA) e si connette.

Due casi particolari che incontrerà nella pratica:

• Nessun record MX. In tal caso il mittente prova il record A o AAAA del dominio stesso (l'"MX implicito" dell'RFC 5321, paragrafo 5.1). Si tratta di un residuo del passato e non funziona in modo affidabile; ogni dominio che riceve posta dovrebbe avere un MX.
• Un null MX: 0 . Questo significa: "questo dominio non riceve mai posta" (RFC 7505). Il dominio example.com ne ha uno proprio così. Un mittente rinuncia immediatamente e invia subito un messaggio di errore, invece di continuare a provare per giorni.

Come funzionano esattamente i record MX e le priorità, lo legga nella lezione 4.1 del corso DNS.

La coda: la posta elettronica può richiedere un po' di tempo

Un'email non arriva sempre entro un secondo. Se il server ricevente non risponde, o dice "riprovi più tardi" (un codice che inizia con un 4), l'email resta nella coda del server di invio. Questo riprova più tardi, con intervalli di tempo sempre più lunghi. L'RFC 5321 (paragrafo 4.5.4.1) consiglia almeno 30 minuti tra un tentativo e l'altro e di rinunciare solo dopo 4 o 5 giorni. Molti server inviano già dopo poche ore un avviso ("delayed", non ancora consegnato) e dopo alcuni giorni il messaggio di errore definitivo.

Questo è un punto di forza della posta elettronica: se un server di posta è fuori servizio per un'ora, non si perde alcuna email. È anche il motivo per cui talvolta un'email arriva solo ore dopo. Nel modulo 6 vedrà come riconoscere un ritardo di questo tipo.

Envelope e intestazioni: due indirizzi

Come per la posta tradizionale, un'email ha due tipi di indirizzi:

• L'envelope. Sono gli indirizzi che i server si scambiano tra loro nella conversazione SMTP: MAIL FROM (il mittente per i messaggi di errore, visibile poi come Return-Path) e RCPT TO (il destinatario). I server consegnano in base all'envelope.
• Le intestazioni (header). È ciò che è scritto nella lettera stessa: From:, To:, Cc:, Subject:, Date:. Il Suo programma di posta le mostra.

Di solito coincidono, ma non sempre. Un destinatario in CCN compare nell'envelope, ma non nelle intestazioni; per questo gli altri non lo vedono. Un servizio di newsletter inserisce il proprio indirizzo come mittente dell'envelope, in modo che i messaggi di errore arrivino al servizio, mentre nel campo From: compare il Suo indirizzo. E un truffatore può scrivere nel campo From: quello che vuole.

Perché questo è importante: l'SPF controlla il mittente dell'envelope, l'utente vede il campo From:. Per questo esiste il DMARC, che collega i due tra loro (modulo 4).

Dove può andare storto

Con questo schema in mente, davanti a ogni problema può chiedersi: a quale tappa si è verificato l'errore?

• L'invio non riesce (messaggio di errore immediato nel Suo programma): passo 1 o 2. Quasi sempre impostazioni: porta, accesso, password (modulo 2).
• Riceve un bounce: passo 4 o 5. Il server ricevente ha rifiutato l'email, oppure l'indirizzo non esiste (modulo 6).
• L'email arriva, ma nella cartella spam: passo 5. Il destinatario non si fida dell'email (moduli 4 e 5).
• Il destinatario non vede nulla e Lei non riceve alcun messaggio di errore: l'email è forse ancora in una coda, oppure è stata filtrata silenziosamente presso il destinatario. Qui sono utili i registri (log) del server di invio (modulo 6).
• Non arriva alcuna email per il Suo dominio: passo 3. I record MX non sono corretti, ad esempio dopo un trasloco (modulo 8).

Nella pratica: ecco come si presenta con un pacchetto di hosting

Con un pacchetto di hosting di WebOké, un unico server per pacchetto svolge tutti i ruoli: il Suo programma di posta consegna l'email a quel server (passo 1 e 2), il server la invia verso l'esterno (passo 3 e 4) e riceve posta per il Suo dominio (passo 5). In DirectAdmin può vedere, con Tracciamento Email, se un messaggio è stato consegnato. Presso altri provider funziona in modo simile; lì una funzione di questo tipo si chiama ad esempio "tracciamento messaggi" o "mail log".

Riepilogo

• Un'email va dal Suo programma di posta (MUA) attraverso il server di invio (MSA/MTA) al server ricevente (MTA/MDA) e da lì al programma di posta del destinatario.
• L'invio dal Suo programma è SMTP-submission con accesso (587/465); i server comunicano tra loro tramite SMTP sulla porta 25; il recupero avviene tramite IMAP o POP3.
• Il server mittente cerca i record MX del dominio dopo la @. Un null MX (0 .) significa: questo dominio non riceve posta.
• Un'email che non può essere consegnata subito resta nella coda e viene riprovata per giorni.
• Envelope (Return-Path) e intestazioni (From) sono due mittenti diversi. L'SPF controlla il primo, l'utente il secondo.

Quiz

Esercizio

Esercizio Z1.1: Trovare il primo server di posta. Cerchi i record MX di gmail.com (oppure del Suo dominio). Indichi quale server viene provato per primo, con il suo numero di priorità, e un indirizzo IP (IPv4 o IPv6) di quel server. Il programma interroga in tempo reale gli stessi dati e li verifica.

Per saperne di più

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri provider il funzionamento è simile.

• Come funziona l'invio delle e-mail / SMTP
• Guida DirectAdmin 8.7: IMAP o POP3: qual è la differenza?
• Corso gratuito DNS 4.1: Record MX e priorità
• RFC 5321 (SMTP), paragrafo 5.1 (MX e MX implicito) e 4.5.4.1 (nuovi tentativi); RFC 7505 (null MX)