Posta elettronica - SMTP POP3 IMAP MIME
Dal MUA all'MTA: come viaggia davvero un'email, perché servono tre protocolli diversi e cosa permette a un allegato PDF di arrivare intatto. Con porte, comandi reali e differenze tra POP3 e IMAP che escono all'orale.
1. Architettura: MUA, MTA, MDA e coda di posta
La posta elettronica è un servizio asincrono store-and-forward: il messaggio viene accodato, trasferito tra MTA via SMTP e conservato nella casella fino al recupero da parte del MUA del destinatario via IMAP o POP3.
Due categorie di software, tre ruoli sul server:
- MUA (Mail User Agent): il client che usi per scrivere e leggere. Es. Thunderbird, Outlook, app Gmail, Apple Mail. Parla SMTP per inviare e IMAP/POP3 per leggere.
- MTA (Mail Transfer Agent): il postino tra server. Es. Postfix, Sendmail, Exchange, Gmail MTA. Riceve da MUA, risolve MX con DNS, inoltra ad altro MTA.
- MDA (Mail Delivery Agent): consegna finale nella Mailbox del destinatario (es. Dovecot deliver, Procmail).
Mario da Thunderbird (MUA) invia mario@istituto.edu → oliver@gmail.com. Thunderbird contatta smtp.istituto.edu:587 autenticato. L'MTA istituto interroga DNS record MX di gmail.com → trova gmail-smtp-in.l.google.com, consegna via SMTP porta 25. Il server Gmail passa a MDA che scrive in /var/mail/oliver. Oliver apre Gmail (MUA webmail) o IMAP e vede il messaggio.
All'interrogazione: disegna MUA → MTA → MTA → MDA → Mailbox → MUA. Sottolinea che SMTP serve SOLO per l'invio. Se dici "scarico posta con SMTP" = errore grave.
2. SMTP e le tre porte: 25, 587, 465
Simple Mail Transfer Protocol - protocollo testuale client/server su TCP per trasferire email. Comandi: HELO/EHLO, MAIL FROM, RCPT TO, DATA, QUIT. Risposte 2xx OK, 4xx temporaneo, 5xx permanente.
SMTP nasceva senza autenticazione: oggi si distingue:
Porta 25
Relay MTA↔MTA. Plain o STARTTLS opportunistic. Bloccata spesso da ISP per client, per evitare spam.
Porta 587 (MSA)
Mail Submission Agent: client autenticato invia. Richiede AUTH + STARTTLS. Consigliata RFC 6409.
Porta 465
SMTPS: TLS implicito dal primo byte (ex deprecata, poi riabilitata). Alternativa a 587 quando firewall blocca STARTTLS.
Confondere MAIL FROM (busta SMTP, usata per bounce e SPF) con header From: (quello che vede l'utente). Possono essere diversi: è alla base di spoofing e phishing. SPF controlla proprio MAIL FROM / Return-Path.
Configurazione che dovresti sapere replicare: SMTP Server = smtp.istituto.edu, porta 587, STARTTLS, auth Normal password, user mario@istituto.edu. IMAP = imap.istituto.edu porta 993 SSL/TLS. Se metti 25 senza auth fallisce, se metti 465 con STARTTLS fallisce (465 vuole SSL/TLS implicito).
3. Formato del messaggio e MIME
Un'email RFC 5322 è sempre header + riga vuota + body. SMTP originariamente solo 7-bit ASCII, quindi:
Estende email a: testo non ASCII (UTF-8), allegati binari, HTML, multipart. Aggiunge header: MIME-Version, Content-Type, Content-Transfer-Encoding, Content-Disposition.
Tipo
text/plain, text/html, image/jpeg, application/pdf, multipart/alternative, multipart/mixed
Trasporto
7bit, 8bit, quoted-printable (testo accentato), base64 (binario = +33% size)
Ruolo
inline = mostra nel corpo (es. immagine in HTML) vs attachment = scarica
All'Esame di Stato: se ti chiedono "perché MIME?" rispondi: SMTP è 7-bit line-oriented; senza MIME non puoi inviare PDF/JPG/HTML. Base64 mappa 3 byte binari in 4 ASCII, quindi allegato pesa di più. Ricorda boundary univoco.
4. POP3 vs IMAP: ricezione e sincronizzazione
SMTP invia, ma non legge. Per leggere servono due protocolli distinti, entrambi su TCP, oggi quasi sempre su TLS:
| Caratteristica | POP3 (110 / 995 TLS) | IMAP (143 / 993 TLS) |
|---|---|---|
| Modello | Download & delete (offline) | Sincronizzazione server-centrica (online) |
| Messaggi sul server | Di default rimossi dopo download (opz. keep) | Restano sul server, flags sincronizzati |
| Multi-dispositivo | ❌ No - ogni dispositivo ha copia diversa | ✅ Sì - stesso INBOX su phone/PC/webmail |
| Cartelle | Solo INBOX | INBOX, Sent, Draft, custom, shared |
| Ricerca / partial fetch | Deve scaricare tutto | SEARCH, FETCH solo header, BODY.PEEK evita scarico allegati |
| Offline | Nativo, lavora senza rete | Possibile con cache, ma nasce online |
| Complessità | Semplice, pochi comandi | Più complesso, stato, UID |
Scenario A: PC fisso unico in ufficio, backup locale, linea lenta. POP3 con "lascia copia 7 giorni" può avere senso. Scenario B: studente con smartphone + tablet + PC + webmail Gmail = IMAP obbligatorio, altrimenti ogni device vede messaggi diversi e segnati letto/non letto non sincronizzati. Oggi 99% provider spingono IMAP.
Dire "IMAP è più sicuro di POP3". Falso: sicurezza dipende da TLS (995 vs 110, 993 vs 143) e auth, non dal protocollo. IMAP è più funzionale, non automaticamente più sicuro.
5. Flusso completo, DNS MX e sicurezza
Per consegnare, MTA deve trovare dove consegnare:
- Estrae dominio da RCPT TO:
oliver@gmail.com → gmail.com - Query DNS tipo MX (Mail eXchange) per
gmail.com→ lista priorità - Se manca MX, fallback su record A / AAAA
- Tenta connessione TCP porta 25 al MX con priorità minore, con retry e backoff
- Verifica SPF sul MAIL FROM, valida DKIM signature, applica DMARC
Sender Policy
Record TXT: quali IP possono inviare per quel dominio. Controlla MAIL FROM. Evita spoofing.
Firma
MTA firma header+body con chiave RSA. Destinatario verifica con chiave pubblica in DNS.
Policy e cifratura
DMARC dice cosa fare se SPF/DKIM falliscono. STARTTLS cifra tra MTA, ma opportunistic; MTA-STS forza TLS.
Collega DNS: senza MX non c'è posta. Se ti chiedono "cosa succede se MTA destinatario è spento?" → MTA mittente accoda e ritenta (4xx = temporaneo, riprova). Dopo giorni manda bounce DSN. Conosci codici 250, 354, 550 mailbox not found.
6. Verifica / Esercizio in classe
🔬 Attività - 30 minuti a coppie
Analizzi un caso reale e configuri un client. Rispondi sul quaderno, poi in Packet Tracer se disponibile.
- Mario invia a 2 destinatari, uno con dominio inesistente. Quali codici SMTP vedi? Distingui errore 4xx vs 5xx e cosa fa il server.
- Con Thunderbird imposti IMAP 143 senza TLS su WiFi pubblico. Cosa rischi? Proponi porta e modalità corretta.
- Hai allegato PDF da 5 MB. Perché su rete vedi ~6.8 MB? Spiega ruolo di base64 e Content-Type. Come calcoli overhead?
- Utente lamenta: "su telefono ho letto email, su PC risulta non letta". Sta usando POP3 o IMAP? Giustifica e proponi migrazione.
- Disegna header email con From, To, Subject, MIME-Version, Content-Type multipart/alternative con boundary. Dove finisce header e inizia body?
1) Valida: 250 2.1.5 Ok + queued. Inesistente: 550 5.1.1 User unknown o DNS MX NXDOMAIN → bounce immediato 5xx, non ritenta. 4xx tipo 451 Greylisted → MTA ritenta dopo minuti.
2) Su 143 plain intercettano password USER/PASS in chiaro + contenuto FETCH. Soluzione: 993 IMAP con SSL/TLS implicito o 143 + STARTTLS + CERT valido, disattiva login senza TLS.
3) Base64 codifica 3 byte → 4 char ASCII = overhead 33%. 5 MB × 4/3 ≈ 6.66 MB + header + boundary ≈ 6.8 MB. Content-Type: application/pdf; Content-Transfer-Encoding: base64.
4) POP3 scarica e segna locale, non propaga \Seen flag sul server. Server non sa che è stato letto. Soluzione: passa a IMAP, lascia messaggi sul server, sincronizza flags. Se vuole copia locale, usa client IMAP offline.
5) Header fino a riga vuota \r\n\r\n. Poi body. Es: Content-Type: multipart/alternative; boundary="abc" poi --abc part text/plain, poi --abc part text/html, poi --abc--. Ricorda Message-ID e Date obbligatori.
7. Riepilogo e concetti chiave
📚 Prossimo passo - FTP RTP e riepilogo protocolli
Chiudiamo il Modulo 1 con FTP per il trasferimento file (modalità attiva/passiva che appare alla maturità) e RTP per voce/video, poi mappa completa DNS-HTTP-SMTP-POP3-IMAP. Ripassa porte: 21, 25, 53, 80, 110, 143, 443, 465, 587, 993, 995.