BIMI Draft -11 del 9 ottobre 2025: cosa cambia e come prepararsi

⚡TL;DR

TL;DR - 🗞️ Il draft BIMI -11 (pubblicato il 9 ottobre 2025) introduce ufficialmente i Local-Part Selectors (lps=) per pilotare il selector BIMI dall'indirizzo mittente, aggiorna la grammatica ABNF e il percorso di discovery, conferma che **l= deve servire un logo SVG/SVGZ via HTTPS e richiama i requisiti DMARC (mai p=none, pct=100 obbligatorio con p=quarantine).

🧩 BIMI in 1 minuto

BIMI (Brand Indicators for Message Identification) permette a un dominio di indicare nel DNS quale logo mostrare accanto a un'email autenticata. I ricevitori verificano la policy BIMI e il MUA decide se visualizzare il logo in base alla propria policy locale.

🗞️ Novità della revisione -11 (9 ottobre 2025)

• lps= (Local-Part Selectors): nuova etichetta opzionale nel BIMI Assertion Record che abilita una lookup basata sul local-part dell'indirizzo mittente; utile quando il header BIMI-Selector non può essere aggiunto sul MTA in uscita.
• ABNF aggiornata: il record cita esplicitamente il blocco local-part-selector e l'ordine dei componenti (tranne v=) diventa intercambiabile.
• Discovery arricchito: se lps= è presente, il ricevitore normalizza il local-part, prova una query con il selector derivato e ricade sul record originale se non trova risposta.
• Formati immagine: ad oggi sono ammessi solo SVG e SVGZ con un registro IANA "BIMI formats" che elenca i media supportati.
• Richiami sugli header: BIMI-Selector andrebbe firmato DKIM (allineato DMARC); BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference non vanno firmati e vanno rimossi se arrivano dall'esterno.

🔧 lps=: pilotare il selector dal local-part

Obiettivo: mostrare loghi diversi in base all'indirizzo di invio senza inserire BIMI-Selector. Il record di default può attivare lps= e reindirizzare la lookup verso <localpart>._bimi.<domain>.

Algoritmo di normalizzazione (-11):

1. Rimuovere il plus addressing (+...).
2. Sostituire _ e . con -, compattare i duplicati e rifilare i - iniziali/finali.
3. Consentire solo [A-Za-z0-9-], lunghezza ≤ 63.
4. Confronto del selector case-insensitive.

Esempi:

# Abilitare lps= ma rifiutare BIMI di default
default._bimi.example.org. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Due selector derivati dal local-part
brand-one-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-one.svg"
brand-two-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-two.svg; a=https://mva.example/vmc.pem"

🧪 Discovery, ABNF e struttura del record

Il BIMI Assertion Record resta un TXT sotto <selector>._bimi.<domain>. La grammatica ABNF (-11) ora ammette il blocco local-part-selector e ribadisce che l'ordine (eccetto v=) è libero.

Punti chiave:

• Fallback: con lps= si prova prima <localpart>._bimi.<domain> e poi si ritorna al selector originale.
• Rifiuto esplicito: v=BIMI1; l=; a=; disattiva BIMI per quel selector.
• IANA: un registro di formati definisce cosa può servire l= (oggi SVG/SVGZ).

🖼️ Loghi: formati e validazione

• l= deve essere un URI HTTPS.
• Formati consentiti: SVG e SVGZ (gzip).
• I ricevitori verificano dimensioni, profilo SVG e sicurezza prima del rendering.
• Con una evidence a= (es. VMC/CMC) il ricevitore può confrontare lo SVG servito da l= con quello contenuto nel certificato.

🔐 Requisiti di autenticazione e policy

• DMARC: il messaggio deve passare DMARC (o un equivalente locale).
• Policy: vietato p=none (sia sul dominio autore sia sull'organizzativo).
• Se p=quarantine, pct deve valere 100.
• I ricevitori possono usare metodi aggiuntivi (ad es. ARC attendibile) per considerare alcuni casi come "pass".

✉️ Header BIMI lato ricezione

• BIMI-Selector: se presente, andrebbe firmato DKIM (allineato DMARC). In caso contrario il ricevitore lo ignora.
• BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference: non firmarli mai e rimuovili se arrivano dall'esterno.

Esempio di Authentication-Results:

Authentication-Results: mx.example.org; dmarc=pass header.from=example.org;
  bimi=pass header.d=example.org header.selector=brand-one-noreply;
  policy.indicator-uri=https://cdn.example.org/logo-one.svg;
  policy.indicator-hash=1a2b3c4d

🗓️ Cronologia essenziale

• 2025-10-09 (-11): introduce lps=, aggiorna discovery/ABNF.
• 2025-06-16 (-10): consolidamento header, avp= (avatar preference), hash opzionale.
• 2025-05-01 (-09): iterazioni su discovery/evidence.
• 2024-11-04 (-08/-07): CMC affianca VMC.

ℹ️ Stato: Internet-Draft (work in progress); ogni MBP/MUA mantiene il pieno controllo della propria policy di visualizzazione.

✅ Checklist di implementazione

• DNS: definisci una strategia di selector (default, varianti di prodotto, lps= quando serve).
• Loghi: fornisci SVG/SVGZ puliti (profilo/peso) e versiona le URL.
• Evidence: pubblica a= (VMC/CMC) quando disponibile e mantieni la catena aggiornata.
• MTA in uscita: non aggiungere BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference; firma BIMI-Selector se lo imposti.
• Ricevitori: implementa la normalizzazione LPS, rimuovi gli header in ingresso e valuta se aggiungere policy.indicator-hash negli Authentication-Results.

🧭 Conclusione

BIMI -11 non stravolge il protocollo, ma sblocca un caso ricorrente (selector guidato dal local-part) e chiarisce discovery, formati e header. I domini che vogliono controllare nel dettaglio la resa del logo guadagnano flessibilità, purché mantengano una postura DMARC solida e SVG impeccabili.

Articolo informativo basato su un Internet-Draft soggetto a evoluzione; per i dettagli normativi fare riferimento al testo IETF.