Un messaggio firmato può comunque essere spam. Il suo dominio di firma può anche differire dall'indirizzo visualizzato dal destinatario.
Cosa copre una firma DKIM?
Una firma DKIM protegge i campi header selezionati e un hash del body.
Il tag h= elenca i campi header firmati. Il tag bh= contiene l'hash del body. Il server di invio produce la firma con la propria chiave privata. I destinatari la verificano con la chiave pubblica corrispondente.
Il destinatario ricalcola l'hash del body. Verifica inoltre la firma sugli header selezionati e sull'header della firma, che contiene quell'hash.
RFC 6376 richiede la firma dell'header From. Gli altri campi header possono restare non firmati. L'aggiunta di un Reply-To non firmato può quindi lasciare DKIM valida.
Gli header ripetuti richiedono un trattamento separato. Il firmatario può elencare un nome di header più volte di quante occorrenze esistano, per impedire che un'ulteriore occorrenza venga aggiunta senza essere rilevata.
Dove trova la chiave pubblica il destinatario?
Il destinatario localizza la chiave pubblica usando il dominio di firma e il selettore, il nome che identifica quella chiave. Il tag d= fornisce il dominio. Il tag s= fornisce il selettore.
Per d=example.com e s=foo.bar, il nome di lookup è foo.bar._domainkey.example.com. Il selettore consente chiavi diverse sotto lo stesso dominio di firma.
Durante la rotazione, pubblica la chiave sostitutiva prima di firmare con essa. Mantieni disponibile la vecchia chiave di verifica finché i messaggi firmati con essa sono ancora in transito. Rimuoverla prematuramente impedisce ai destinatari di verificare quei messaggi.
Perché le modifiche di formattazione possono invalidare una firma?
La canonicalizzazione, la normalizzazione applicata prima della firma e della verifica, determina quali modifiche di formattazione DKIM tollera.
Il tag c= sceglie algoritmi separati per header e body. In relaxed/relaxed entrambi usano la normalizzazione relaxed.
| Algoritmo | Comportamento header | Comportamento body |
|---|---|---|
simple | Preserva la formattazione degli header | Ignora le righe vuote alla fine |
relaxed | Normalizza maiuscole/minuscole, folding e spazi bianchi degli header | Normalizza spazi bianchi e righe vuote finali |
Un header con folding continua su un'altra riga. L'elaborazione relaxed degli header tollera quel folding. L'elaborazione simple può fallire dopo che un server ha riformattato lo stesso header.
Confronta il contenuto firmato prima e dopo il relay che ha fallito, perché una modifica di formattazione invisibile può spiegare il risultato.
Quali algoritmi di firma supporta DKIM?
DKIM supporta gli algoritmi di firma RSA ed Ed25519, entrambi combinati con SHA-256.
RSA ha una dimensione minima della chiave di 1024 bit secondo RFC 8301. Chiavi più corte offrono una resistenza insufficiente alla compromissione della chiave.
La dimensione RSA raccomandata è almeno 2048 bit, per una maggiore resistenza alla compromissione della chiave. Scegli questa dimensione se il tuo sistema di firma la supporta. La specifica vieta rsa-sha1 per la firma e la verifica.
RFC 8463 aggiunge ed25519-sha256. Un messaggio può portare sia firme RSA sia Ed25519 per compatibilità con destinatari che supportano algoritmi diversi.
Le indicazioni di Yahoo richiedono anch'esse una chiave DKIM di almeno 1024 bit.
Cosa succede quando una mailing list modifica il messaggio?
Una modifica può invalidare DKIM quando cambia il contenuto coperto dalla firma.
L'inoltro di per sé non modifica il contenuto firmato. Una firma intatta può sopravvivergli. Un footer aggiunto in coda può cambiare l'hash del body. Un Subject firmato riscritto può invalidare la firma degli header.
Il tag opzionale l= limita la copertura del body a un numero specificato di byte. Con l=100, il contenuto dopo i primi 100 byte normalizzati non è protetto. L'aggiunta di testo fuorviante può quindi lasciare la firma valida.
Evita quel limite quando hai bisogno che l'intero body sia protetto. ARC consente agli intermediari di conservare prove firmate dell'autenticazione prima delle loro modifiche.
Come si configura DKIM con Bird?
Pubblica il record DKIM restituito quando registri il tuo dominio di invio.
Il campo dkim.mode di API ha come valore predefinito txt. Con quella modalità, pubblica la chiave pubblica in un record TXT. Lo schema elenca anche delegated. Quel valore restituisce HTTP 422 quando registri un dominio di invio, quindi usa txt.
Bird crea una chiave e un selettore separati per ogni organizzazione che usa un dominio di invio. Le organizzazioni che usano lo stesso dominio non devono condividere una chiave di firma.
La guida all'autenticazione spiega il record restituito.
Una firma valida dimostra che il messaggio è sicuro?
Una firma valida stabilisce la responsabilità per il contenuto firmato. Non stabilisce se il messaggio è desiderato o affidabile.
Non richiede nemmeno che il dominio di firma corrisponda al dominio From visibile. DMARC fornisce quella regola di corrispondenza tramite l'allineamento. La reputazione del mittente, la valutazione del traffico di un mittente da parte del destinatario, resta una considerazione separata.
In breve
Solo il contenuto selezionato è protetto.
DKIM copre i campi header elencati e un hash del body. Il contenuto non protetto può cambiare senza invalidare la firma.
I selettori localizzano le chiavi di verifica.
Il selettore e il dominio di firma identificano il record DNS che contiene la chiave pubblica.
La normalizzazione influisce sulla verifica.
Gli algoritmi simple e relaxed trattano le modifiche di formattazione in modo diverso.
L'inoltro non garantisce un esito positivo.
Una firma intatta può sopravvivere all'inoltro, ma le modifiche al contenuto firmato possono invalidarla.