SPF, DKIM e DMARC sono stati pensati per un percorso semplice: il mittente invia, il destinatario riceve. Nella realtà molti messaggi fanno un giro più lungo. Un utente inoltra automaticamente la posta di un vecchio indirizzo verso la casella nuova; un'associazione usa un alias che distribuisce i messaggi a più persone; una mailing list riceve un messaggio e lo rispedisce a tutti gli iscritti, magari aggiungendo un piè di pagina. Ogni intermediario può rompere uno o più meccanismi di autenticazione, e capire come aiuta a non scambiare un problema di percorso per un attacco.
Cosa si rompe con un inoltro semplice
Immagina un messaggio inviato da example.com a un indirizzo su un dominio universitario, che lo inoltra automaticamente a una casella personale presso un grande provider.
| Meccanismo | Dopo l'inoltro | Perché |
|---|---|---|
| SPF | fallisce | il provider finale vede l'IP del server che inoltra, non autorizzato da example.com |
| DKIM | di solito passa | la firma viaggia con il messaggio e resta valida se il contenuto non cambia |
| DMARC | passa se DKIM è allineato | basta uno dei due meccanismi allineati |
È la ragione principale per cui DKIM allineato è indispensabile: è l'unico meccanismo che sopravvive a un inoltro semplice. Un dominio che si affida solo a SPF, con una policy DMARC restrittiva, perde posta ogni volta che un destinatario inoltra i messaggi.
SRS: riscrivere il mittente della busta
Il server che inoltra ha anche un problema proprio. Se rispedisce il messaggio lasciando invariato il mittente della busta, cioè il Return-Path di example.com, sta di fatto inviando posta a nome di un dominio che non lo autorizza. Il controllo SPF fallisce e, se il messaggio non può essere consegnato, l'avviso di mancata consegna torna al mittente originale da un server che non conosce.
SRS, Sender Rewriting Scheme, risolve questo aspetto: il server che inoltra riscrive il mittente della busta con un indirizzo del proprio dominio, che contiene in forma codificata l'indirizzo originale e una piccola firma con scadenza. Un indirizzo riscritto ha questo aspetto:
SRS0=HHH=TT=example.com=mario@inoltro.example.net
In questo modo SPF viene verificato sul dominio di chi inoltra, che è autorizzato, e gli eventuali rimbalzi tornano al server di inoltro, che li sa ricondurre al mittente originale.
È importante capire il limite: SRS rende SPF valido, ma non allineato con il From. Per DMARC, quindi, SRS non basta. Serve a far funzionare l'inoltro senza che il server intermedio sembri uno spammer, mentre l'allineamento continua a dipendere dalla firma DKIM originale.
Mailing list: quando si rompe anche DKIM
Le mailing list tradizionali spesso modificano il messaggio: aggiungono un prefisso all'oggetto, come [soci], o un piè di pagina con le istruzioni per la disiscrizione. Basta una di queste modifiche per invalidare la firma DKIM originale. A quel punto SPF fallisce, DKIM fallisce, e un dominio con p=reject vede i propri messaggi rifiutati dai destinatari della lista.
Molti gestori di mailing list hanno adottato una soluzione pratica: quando il dominio del mittente ha una policy DMARC restrittiva, la lista riscrive il From con un proprio indirizzo, per esempio «Mario Rossi tramite Soci», e mette l'indirizzo originale nel Reply-To. Il messaggio diventa così un messaggio della lista, autenticato dal dominio della lista.
ARC: conservare la catena di fiducia
ARC, Authenticated Received Chain, affronta il problema da un altro lato. Ogni intermediario che lo supporta, al momento della ricezione, registra in intestazioni firmate i risultati dell'autenticazione che ha osservato, prima di modificare o inoltrare il messaggio. Il destinatario finale può così vedere che, quando il messaggio è arrivato alla lista, SPF e DKIM erano validi.
Un set ARC è composto da tre intestazioni:
ARC-Authentication-Results: i risultati osservati da quell'intermediario;ARC-Message-Signature: una firma del messaggio simile a DKIM;ARC-Seal: una firma che sigilla la catena delle intestazioni ARC precedenti.
ARC non impone nulla. Il destinatario decide se fidarsi della catena, e lo fa di solito solo se conosce e stima gli intermediari che l'hanno firmata. Per questo ARC aiuta soprattutto quando gli intermediari sono grandi servizi riconosciuti.
Cosa fare in pratica
Per chi invia:
- firmare sempre con DKIM allineato, perché è ciò che sopravvive agli inoltri;
- nei report DMARC, non scambiare per spoofing i casi con SPF fallito e DKIM valido da server di inoltro noti;
- prima di passare a
p=reject, verificare se dipendenti o clienti scrivono spesso a mailing list.
Per chi gestisce un server che inoltra o una lista:
- attivare SRS sugli inoltri;
- evitare modifiche al messaggio quando non servono;
- riscrivere il From per i domini con policy restrittive;
- firmare con ARC, se il software lo supporta.
In sintesi
- Un inoltro semplice rompe SPF ma di solito lascia valido DKIM.
- DKIM allineato è il meccanismo che permette a DMARC di sopravvivere agli inoltri.
- SRS riscrive il mittente della busta e rende valido SPF, ma non allineato.
- Le mailing list che modificano i messaggi rompono anche DKIM e spesso riscrivono il From.
- ARC registra i risultati dell'autenticazione lungo il percorso, a beneficio del destinatario finale.
