Separare il protocollo dall'idoneità del ricevitore
BIMI l'idoneità non viene stabilita trovando la parola DMARC in un record DNS . L'operatore deve determinare la politica di autenticazione applicabile, se il messaggio effettivo supera i controlli richiesti e cosa richiede attualmente il destinatario previsto prima di visualizzare un logo. Queste sono domande correlate ma distinte. Una specifica di protocollo attuale e la pagina di aiuto operativo di un fornitore possono anche differire nella terminologia o nei tempi di migrazione, quindi le prove necessitano di date e ambito esplicito.
Questo articolo mette a confronto le fonti primarie conservate. La pagina di configurazione di Google è stata aggiornata il 26 ottobre; La pagina BIMI di Yahoo è stata recuperata senza una data di revisione visibile equivalente. RFC 9989 fornisce il contesto attuale del protocollo DMARC . L'articolo non verifica un tenant né deduce che un provider abbia implementato ogni aspetto della nuova RFC. BIMI rimane una bozza e la visualizzazione del ricevitore non è una garanzia del protocollo universale.
Registra le effettive condizioni pubblicate da Google
La pagina di configurazione BIMI di Google afferma che i messaggi devono essere autenticati da DMARC ed elenchi p=quarantine O p=reject, con pct=100. Richiede inoltre a VMC O CMC per il suo flusso di lavoro documentato supportato da certificato e non supporta la distribuzione autonoma solo di SVG in Gmail . Registra tali dichiarazioni come indicazioni di idoneità pubblicate da Google, non come una definizione completa di DMARC o come prova del risultato di un particolare messaggio. Requisiti di configurazione di Google
I suoi requisiti SVG e le istruzioni di hosting costituiscono porte aggiuntive. Una policy DMARC adeguata non rende idonea un'immagine non valida, non ottiene un certificato né rende il PEM accessibile al pubblico. Al contrario, un certificato valido non ripara l'autenticazione allineata del mittente non riuscita. Utilizza una lista di controllo con righe separate in modo che un team non possa accidentalmente contrassegnare l'intero progetto come pronto dopo aver completato solo la riga della politica DNS.
Emergere la discrepanza del PCT invece di nasconderla
RFC 9989 rende obsolete le precedenti specifiche DMARC e rimuove il tag pct. La sua appendice spiega il meccanismo storico della percentuale e introduce il tag di test t con valori y e n. Si tratta di una modifica significativa del protocollo, mentre la pagina BIMI di Google conservata menziona ancora esplicitamente pct=100. Entrambe le osservazioni dovrebbero essere preservate invece di riscrivere silenziosamente entrambe le fonti per farle apparire identiche. RFC 9989 , Appendice A.6
La risposta operativa è quella di confermare l’attuale applicabilità del ricevitore prima di modificare una politica di produzione sulla base di tale discrepanza. Non affermare che Google ignori, richieda in transito o traduca internamente un particolare tag a meno che le prove attuali non dimostrino tale comportamento. Non considerare t come un sostituto di idoneità BIMI universalmente provato per pct semplicemente perché la RFC spiega la loro relazione storica. L'implementazione e la documentazione del provider possono evolversi secondo pianificazioni diverse.
Un record di applicabilità della fonte dovrebbe quindi includere la versione RFC, la data della pagina del fornitore, l'esatta condizione contestata e la domanda irrisolta. Chiedere al revisore responsabile di risolverlo con le prove attuali del fornitore o con un'osservazione autorizzata e adeguatamente circoscritta. Questo articolo non esegue tale conferma. Il conflitto è un motivo per imporre una barriera, non un motivo per indebolire l’applicazione o improvvisare una richiesta di compatibilità.
Confronta in modo indipendente le condizioni indicate da Yahoo
La pagina BIMI di Yahoo richiede una policy DMARC di quarantena o di rifiuto, a Registro BIMI indicando un SVG valido, posta in blocco e reputazione e coinvolgimento sufficienti per l'indirizzo di invio. Dice che i VMC non sono attualmente richiesti, sebbene un VMC fornito informi l'idoneità generale. La sua pagina rispetta i record BIMI del sottodominio preferendo la configurazione del dominio organizzativo. Si tratta di dichiarazioni specifiche di Yahoo, non di prove che Gmail condivida lo stesso certificato o criterio di visualizzazione. Requisiti Yahoo BIMI
Non interpretare l'assenza di una condizione pct da parte Yahoo su quella pagina come prova di ogni possibile comportamento di gestione dei tag. Registra ciò che effettivamente afferma la fonte e ciò che lascia non specificato. Allo stesso modo, le sue condizioni di posta in massa e di reputazione significano che un singolo messaggio di prova personale potrebbe non rappresentare la popolazione documentata di display del logo. Non inventare una soglia numerica di invio quando la fonte esaminata non ne fornisce una.
Connetti la policy all'effettiva autenticazione del messaggio
DMARC valuta allineamento tra il dominio Da visibile e un passaggio SPF O DKIM identità secondo le sue regole. Una preferenza di applicazione pubblicata non obbliga tutti i mittenti legittimi a passare. Inventariare i servizi di invio e identificare quali identità autenticano prima di proporre un trattamento più rigoroso. Le modifiche alla politica possono influenzare i flussi di lavoro legittimi, quindi una scadenza per il logo non deve ignorare il processo di preparazione e approvazione del team di posta. Autenticazione e allineamento RFC 9989
Per un'osservazione controllata successiva, conservare il messaggio effettivamente ricevuto e i risultati dell'autenticazione attendibile. Non accettare un passaggio dichiarato da un'intestazione arbitraria senza identificare il sistema di produzione e il confine di fiducia. Mantenere l'individuazione delle policy, l'autenticazione dei messaggi e la visualizzazione del logo come risultati separati; un messaggio può superare l'autenticazione senza soddisfare le condizioni di visualizzazione aggiuntive del destinatario. Limite di attendibilità RFC 8601
Foglio di lavoro originale sull'idoneità del destinatario
Crea una riga per destinatario e flusso di posta. I seguenti campi proposti impediscono che un generico stato “ BIMI ready” nasconda differenze importanti. Non è stata valutata alcuna distribuzione reale con questo foglio di lavoro.
- Fonte: pagina del destinatario, data di recupero, data di revisione visibile e versione di riferimento del protocollo.
- Politica del dominio: record applicabile esatto e qualsiasi domanda organizzativa o di sottodominio.
- Mancata corrispondenza della documentazione: tag o condizione contestata, prova e titolare dell'applicabilità non risolta.
- Prova del messaggio: visibile da, identità autenticate, allineamento e fonte di risultati attendibile.
- Asset: versione SVG approvata, dimensioni del ricevitore e risultati strutturali.
- Certificato: categoria richiesta, stato dell'emittente e dipendenza PEM ospitata.
- Recupero e visualizzazione: prova dell'endpoint pubblico, client ricevente, tempo di osservazione e limiti.
- Decisione: idoneo, non idoneo o sconosciuto per questo streaming, con condizioni rimanenti.
Mantieni le decisioni di monitoraggio e applicazione separate dalla sperimentazione sulla visualizzazione. Se un mittente esistente non riesce ad allinearsi, risolvere la configurazione del mittente e l'impatto aziendale anziché modificare ripetutamente il file del logo. Se l'autenticazione viene superata ma non viene visualizzato alcun logo, esamina il certificato, l'hosting, il supporto e l'idoneità discrezionale senza dichiarare DMARC interrotto esclusivamente dall'immagine mancante.
Esempio fittizio: una lista di controllo nasconde due destinatari
L'immaginario Silver Orchard prepara una lista di controllo di lancio che dice "Pass DMARC , certificato opzionale". Questa dicitura unisce la posizione del certificato di Yahoo con il diverso flusso di lavoro documentato di Gmail . Un revisore nota inoltre che una vecchia guida interna tratta pct come un requisito di protocollo universale invariato, mentre RFC 9989 lo ha rimosso e la pagina attuale di Google elenca ancora pct=100. Il team ha due domande sulla documentazione, non la prova che uno dei ricevitori non funzioni correttamente.
Il passaggio successivo proposto è quello di suddividere la checklist in righe di ricevitori con data di origine e intensificare la questione sull'applicabilità dei tag prima di modificare DNS di produzione. Ogni flusso avrebbe bisogno di prove effettive del messaggio e di controlli propri su risorse e certificati. Nessun messaggio, record DNS o ricevitore Silver Orchard è stato testato. L'esempio illustra come una checklist generica possa nascondere ipotesi irrisolte.
Il catalogo richiede una matrice di idoneità specifica del destinatario e prove per l'autenticazione DNS , logo, certificato e messaggio. Questo manoscritto fornisce una matrice proposta e differenze documentate, non prove operative. Le prove originali, la PMI umana, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario rimangono tutti aperti. Non è implicita alcuna modifica alle politiche, test dal vivo o garanzia di idoneità.