Infrastruttura Email

L'email è uno dei protocolli più vecchi di Internet, ma la sua infrastruttura è sorprendentemente complessa. Questa nota copre tutti i componenti necessari per gestire un dominio email, dalla ricezione all'invio, dall'autenticazione alla sicurezza.

Protocolli fondamentali

SMTP (Simple Mail Transfer Protocol)

SMTP è il protocollo usato per inviare email tra server. Opera sulla porta 25 (server-to-server), 587 (submission con STARTTLS) o 465 (submission con TLS implicito).

Il flusso è:

  1. Il client si connette al server SMTP
  2. Si identifica con HELO/EHLO
  3. Specifica il mittente (MAIL FROM:) e il destinatario (RCPT TO:)
  4. Invia il corpo del messaggio (DATA)

Importante: SMTP distingue tra envelope (busta) e headers (intestazioni). L'envelope è quello che i server usano per il routing, gli headers sono quello che l'utente vede nel client email. Possono essere diversi, e questa distinzione è fondamentale per capire SPF e il forwarding.

IMAP e POP3

Sono i protocolli per ricevere/leggere email da una casella:

  • IMAP (porta 993): mantiene le email sul server, sincronizzazione multi-dispositivo
  • POP3 (porta 995): scarica le email localmente, tipicamente le rimuove dal server

In un'infrastruttura basata su forwarding (come SES → Gmail), questi protocolli non servono perché non c'è una casella locale — le email vengono inoltrate direttamente.

Record DNS per l'email

Il DNS è il fondamento di tutta l'infrastruttura email. Senza i record corretti, le email non arrivano e quelle inviate finiscono nello spam.

MX (Mail Exchange)

Il record MX dice al mondo quale server riceve le email per il tuo dominio.

safe.eu.    MX    10 inbound-smtp.eu-west-1.amazonaws.com

Il numero 10 è la priorità (più basso = più prioritario). Si possono avere più record MX per ridondanza:

safe.eu.    MX    10 server-primario.example.com
safe.eu.    MX    20 server-backup.example.com

Quando qualcuno invia un'email a hello@safe.eu, il suo server:

  1. Fa una query DNS per i record MX di safe.eu
  2. Si connette al server con priorità più alta
  3. Consegna l'email via SMTP

Custom MAIL FROM

Il MAIL FROM domain (anche detto "envelope sender domain" o "return-path domain") è il dominio usato nell'envelope SMTP. Di default, servizi come SES usano il proprio dominio (e.g. amazonses.com), ma configurare un custom MAIL FROM come mail.safe.eu migliora la deliverability perché SPF viene verificato contro il tuo dominio.

Richiede due record aggiuntivi:

mail.safe.eu.    MX     10 feedback-smtp.eu-west-1.amazonses.com
mail.safe.eu.    TXT    "v=spf1 include:amazonses.com ~all"

Autenticazione Email

Questi tre meccanismi lavorano insieme per prevenire lo spoofing e garantire che le email siano legittime. Sono correlati ai principi di Sicurezza delle reti — in particolare autenticazione e integrità.

SPF (Sender Policy Framework)

SPF è un record TXT nel DNS che elenca quali server sono autorizzati a inviare email per conto del tuo dominio.

safe.eu.    TXT    "v=spf1 include:amazonses.com ~all"

Questo dice: "solo i server di Amazon SES possono inviare come @safe.eu". Quando un server riceve un'email da @safe.eu, controlla:

  1. Da quale IP è arrivata l'email
  2. Se quell'IP è nell'elenco SPF di safe.eu
  3. Se non lo è, l'email è sospetta

I qualificatori:

  • ~all (softfail): le email non autorizzate vengono marcate ma non rifiutate
  • -all (hardfail): le email non autorizzate vengono rifiutate
  • ?all (neutral): nessuna policy

SPF controlla il dominio dell'envelope-from (Return-Path), NON l'header From che l'utente vede. Questa distinzione è cruciale per capire i problemi del forwarding.

DKIM (DomainKeys Identified Mail)

DKIM fornisce una firma crittografica su ogni email inviata. Funziona come una firma digitale classica (vedi Sicurezza delle reti):

  1. Il server mittente ha una chiave privata
  2. La chiave pubblica viene pubblicata nel DNS come record CNAME:
abc123._domainkey.safe.eu.    CNAME    abc123.dkim.amazonses.com
  1. Ogni email inviata include un header DKIM-Signature con l'hash firmato di headers e corpo
  2. Il server ricevente recupera la chiave pubblica dal DNS e verifica la firma

Se la firma è valida, il server sa che:

  • L'email proviene realmente da quel dominio (autenticazione)
  • Il contenuto non è stato modificato in transito (integrità)

SES genera 3 coppie di chiavi DKIM (rotazione), quindi servono 3 record CNAME.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC è la policy che dice ai server riceventi cosa fare quando SPF e DKIM falliscono. È il livello decisionale sopra SPF e DKIM.

_dmarc.safe.eu.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@safe.eu"

Componenti:

  • p=none: non fare nulla, solo report (monitoring)
  • p=quarantine: metti in spam
  • p=reject: rifiuta completamente l'email
  • rua=mailto:...: indirizzo dove ricevere i report aggregati sulle email che falliscono i controlli

DMARC richiede che almeno uno tra SPF o DKIM passi E sia allineato con il dominio nell'header From. "Allineato" significa che il dominio verificato da SPF/DKIM corrisponde al dominio nel From.

Come lavorano insieme

Email da alice@company.com → server safe.eu → Gmail

Gmail controlla:
1. SPF: l'IP del server è autorizzato per il dominio nel Return-Path? 
2. DKIM: la firma è valida e corrisponde al dominio?
3. DMARC: almeno uno è passato E allineato? Se no → applica la policy

Il problema del forwarding

Il forwarding email è sorprendentemente problematico per l'autenticazione. Quando hello@safe.eu viene inoltrato a tuo@gmail.com:

Cosa si rompe

  1. SPF fallisce: l'email originale da alice@company.com arriva al tuo server. Il tuo server la inoltra a Gmail. Gmail vede che l'IP del tuo server NON è autorizzato a inviare per company.com → SPF fail.

  2. DKIM può rompersi: se il forwarder modifica qualsiasi header o il corpo (anche solo aggiungendo un footer), la firma DKIM originale diventa invalida.

  3. DMARC fallisce: se sia SPF che DKIM falliscono, DMARC applica la policy del dominio mittente. Se company.com ha p=reject, l'email viene rifiutata.

Approccio semplice (Lambda rewrite)

Il metodo più semplice è riscrivere completamente gli headers:

  • Cambiare From: a noreply@safe.eu
  • Aggiungere Reply-To: con il mittente originale
  • Rimuovere DKIM-Signature originale
  • Firmare con il proprio DKIM

Funziona ma perde l'identità del mittente originale, e le email appaiono come "via safe.eu".

SRS (Sender Rewriting Scheme)

SRS risolve il problema SPF nel forwarding. Riscrive solo l'envelope-from (il Return-Path), non gli headers visibili.

Trasformazione:

Envelope-from originale: alice@company.com
Dopo SRS:               SRS0=hash=timestamp=company.com=alice@safe.eu

Ora quando Gmail controlla SPF, lo controlla contro safe.eu (il tuo dominio) → passa. L'header From: visibile resta alice@company.com.

Se l'email rimbalza (bounce), il bounce va al tuo server. Il tuo server decodifica l'indirizzo SRS e inoltra il bounce al mittente originale.

SRS è uno standard de facto per il forwarding trasparente, usato da servizi come Fastmail, Migadu, e molti server Postfix.

ARC (Authenticated Received Chain)

ARC risolve il problema DMARC nel forwarding. Quando il tuo server riceve un'email e vuole inoltrarla, aggiunge tre headers:

  1. ARC-Authentication-Results: "quando ho ricevuto questa email, ecco cosa è passato"

    ARC-Authentication-Results: i=1; safe.eu;
  dkim=pass header.d=company.com;
  spf=pass smtp.mailfrom=alice@company.com

  2. ARC-Message-Signature: firma il contenuto del messaggio

    ARC-Message-Signature: i=1; d=safe.eu; s=selector; ...

  3. ARC-Seal: firma l'intera catena ARC per impedire manomissioni

    ARC-Seal: i=1; d=safe.eu; s=selector; cv=none; ...

Il campo i= è un contatore incrementale: se l'email passa per più forwarder, ognuno aggiunge il proprio set di headers ARC con i incrementato.

Gmail e i principali provider si fidano della catena ARC da forwarder affidabili. Anche se DKIM e SPF originali falliscono, vedono: "il server safe.eu ha verificato l'autenticazione quando ha ricevuto il messaggio, e noi ci fidiamo di safe.eu" → email accettata.

Riepilogo soluzioni forwarding

ApproccioSPFDKIMDMARCComplessità
Lambda rewrite✅ (nuovo From)✅ (nuovo DKIM)✅Bassa
SRS + preserva DKIM✅ (SRS)✅ (originale)✅Media
SRS + ARC✅ (SRS)Può rompersi✅ (ARC)Alta

Il primo perde l'identità del mittente originale. Gli altri due la preservano ma richiedono un MTA reale (Postfix, OpenSMTPD) invece di una Lambda.

Architettura pratica con AWS SES

Un'architettura serverless per email su dominio custom:

                    ┌──────────────┐
   Email in ──MX──→ │   AWS SES    │
                    │  (receiving) │
                    └──────┬───────┘
                           │
                    ┌──────▼───────┐     ┌──────────────┐
                    │   S3 Bucket  │────→│    Lambda     │──→ Gmail (forward)
                    │  (storage)   │     │  (forwarder)  │
                    └──────────────┘     └──────────────┘

                    ┌──────────────┐
   Email out ◄───── │   AWS SES    │ ◄── Bot/Gmail "Send as"
                    │  (sending)   │     (via SMTP credentials)
                    └──────────────┘

Componenti:

  • SES receiving: riceve email (MX punta a SES)
  • S3: archivia le email raw per elaborazione bot
  • Lambda: inoltra le email a caselle esistenti (Gmail, etc.)
  • SES sending: il bot e Gmail "Send as" inviano tramite SMTP
  • IAM: credenziali SMTP per-indirizzo, revocabili indipendentemente

Costo stimato: ~0.10/1000 email, Lambda nel free tier).

Sicurezza e considerazioni operative

SES Sandbox

SES parte in modalità sandbox: puoi inviare solo a indirizzi verificati. Per inviare a chiunque, devi richiedere l'accesso alla produzione tramite la console AWS.

Separazione delle credenziali

Ogni indirizzo sender dovrebbe avere credenziali SMTP dedicate (IAM user separato), così:

  • Se una credenziale viene compromessa, si revoca solo quella
  • Ogni IAM user ha una policy che permette di inviare solo dal proprio indirizzo
  • Il principio del minimo privilegio viene rispettato

Forward mapping e privacy

Il mapping tra indirizzi pubblici (hello@safe.eu) e indirizzi privati (tuo@gmail.com) è informazione sensibile:

  • Rivela il collegamento tra identità (dominio professionale → casella personale)
  • Permette di bypassare filtri sul dominio inviando direttamente alla casella reale
  • Può essere usato per enumerazione (quali indirizzi sono reali)

Questo mapping non dovrebbe mai essere committato in un repository, nemmeno privato (i repo possono diventare pubblici, essere accessibili da CI, collaboratori, etc.).