Tratta la preparazione BIMI come diversi livelli di prova
A BIMI il controllore dovrebbe distinguere la pubblicazione DNS , la struttura del logo, il recupero HTTPS, la prova del certificato e l'idoneità del destinatario. Un record dall'aspetto valido non dimostra che il logo sia accettabile e un'immagine recuperata correttamente non garantisce che un provider di cassette postali la visualizzerà. L'output dovrebbe identificare quale livello è stato osservato, quale regola è stata applicata e cosa rimane non verificato anziché comprimere tutto il BIMI in un unico passaggio.
Il trattenuto Guida all'implementazione del Gruppo BIMI E Documentazione sulla configurazione di Google fornire materiale di partenza pratico con ambiti diversi. La guida del gruppo non afferma che BIMI è uno standard Internet e i requisiti di Google si applicano al comportamento documentato del destinatario di Google. Questo manoscritto propone i requisiti del controllo, non l'output EmailAuth implementato o una scansione completata.
Conserva l'identità e il selettore DNS
Registra l'esatto selettore e il nome del proprietario della polizza in fase di revisione, il tipo di record richiesto, il risolutore o la fonte autorevole e il tempo di osservazione. Il risultato di un selettore predefinito non dovrebbe sostituire silenziosamente un altro selettore. Il controllore deve identificare più record candidati e input non validi in base alle specifiche BIMI supportate o alle linee guida documentate, con la versione di origine visibile. Non dovrebbe dedurre quale logo sia stato selezionato per un messaggio reale senza la relativa prova del messaggio.
RFC 1035 fornisce il registrazione TXT struttura necessaria per preservare i confini dei record. Più stringhe all'interno di un record TXT differiscono da diversi record TXT dello stesso proprietario. Il risultato dovrebbe mantenere tali confini prima di interpretare i campi politici. Non è stata eseguita alcuna query sul dominio utente qui, quindi non è stata pubblicata alcuna effettiva Registro BIMI o il risultato del selettore in questa bozza.
Valuta il logo come una risorsa, non come uno screenshot
Guida SVG del Gruppo BIMI descrive i requisiti SVG Portable/Secure e spiega che il profilo è più rigido di SVG Tiny 1.2. Un logo che appare corretto in un browser può comunque contenere strutture, riferimenti o contenuti interattivi non supportati. Un controllore dovrebbe identificare la risorsa effettivamente recuperata e l'hash del suo contenuto, quindi riportare i risultati del profilo rispetto a un set di regole denominato.
Mantieni la revisione visiva separata dalla convalida strutturale. Un bene strutturalmente accettabile può essere ancora difficilmente riconoscibile anche se di piccole dimensioni o avere scarse caratteristiche di accessibilità. Un'immagine visivamente attraente potrebbe non soddisfare il profilo. Il controllore non dovrebbe chiamare una forma di revisione prova dell'altra. Questo manoscritto non ha ottenuto una risorsa candidata, non ha eseguito un validatore né ha visualizzato un logo; il relativo foglio di lavoro specifica le prove necessarie per una revisione autorizzata.
Separare il trasporto HTTPS dall'evidenza del marchio
La documentazione di Google richiede l'hosting HTTPS per i file BIMI e descrive i requisiti dei file di certificato supportati. Il certificato TLS che protegge la connessione di hosting è diverso da a VMC O CMC associato al logo. Un controllore dovrebbe etichettarli separatamente. Una connessione HTTPS valida non dimostra né l'idoneità per un certificato del marchio né la validità del documento di prova ospitato su quell'endpoint.
Per il recupero, registrare l'URL richiesto, l'endpoint finale ove applicabile, lo stato della risposta, il tipo di contenuto, i byte o l'hash, il tempo di connessione e il risultato della convalida del certificato. Se si verifica un reindirizzamento, conservare la catena osservata e valutarla rispetto ai requisiti effettivi della fonte anziché inventare una regola di reindirizzamento universale. Un endpoint privo di reindirizzamento può rappresentare una raccomandazione operativa senza essere etichettato erroneamente come requisito normativo universale.
Certificato di ambito e requisiti del ricevitore
Le linee guida per la configurazione conservate da Google indicano che Gmail richiede un VMC o CMC da emittenti supportati e distingue quelli relativi a VMC segno di spunta verificato. Ciò non significa che ogni destinatario richieda lo stesso certificato o visualizzi lo stesso indicatore. Il controllore dovrebbe identificare il destinatario previsto e le attuali regole di idoneità documentate prima di interpretare la prova del certificato mancante come un errore BIMI universale.
L’idoneità dell’emittente è un altro limite. Documentazione CMC di DigiCert descrive i requisiti di convalida e idoneità del certificato. Un controllore può indicare tale processo, ma non può effettuare una determinazione legale del marchio o certificare l'approvazione dell'emittente da un record DNS . Qui non si è verificata alcuna richiesta di certificato, rivendicazione di proprietà del logo o transazione dell'emittente.
Mantieni distinta la preparazione DMARC
L'idoneità BIMI documentata di Google include le condizioni relative a DMARC. Il controllore dovrebbe citare l’attuale requisito specifico del destinatario piuttosto che sostituirlo silenziosamente con la propria preferenza politica. A livello di protocollo, RFC 9989 definisce la corrente DMARC comportamento, comprese le modifiche rispetto alle convenzioni precedenti. Se le linee guida del fornitore e l'attuale vocabolario del protocollo differiscono, formulare la domanda sull'applicabilità anziché fingere che tutte le implementazioni siano cambiate insieme.
Una politica di applicazione pubblicata non dimostra che ciascun mittente legittimo sia allineato o che un particolare messaggio ricevuto soddisfi gli altri criteri del destinatario. Mantieni la disponibilità del mittente e l'osservazione del destinatario in campi di prova separati. La reputazione, il contesto del messaggio e la discrezione del destinatario possono influenzare la visualizzazione, quindi un controllore dovrebbe evitare una conclusione sulla visualizzazione garantita del logo basandosi solo sull'evidenza della configurazione.
Un foglio di lavoro per il controllo a più livelli
Crea righe per proprietario e selettore DNS , struttura TXT , URL del logo, risorsa recuperata, risultati del profilo SVG, connessione HTTPS, documento di prova del marchio e destinatario previsto. Ogni riga dovrebbe includere la regola di origine, il tempo di osservazione, il riferimento alle prove, lo stato e la limitazione. Utilizzare stati come osservato, fallito, non testato e non applicabile anziché forzare il superamento o il fallimento delle prove mancanti.
In caso di errore di convalida del certificato, conservare l'endpoint esatto, il nome host controllato, il tempo di connessione, la fase dell'errore e la prova del certificato sicuro necessari per riprodurre la diagnosi. Distinguere un certificato scaduto, una mancata corrispondenza del nome host, un errore di fiducia e un servizio irraggiungibile solo quando le prove effettive supportano la categoria. Il catalogo richiede specificamente prove di connessione TLS con timestamp che identifichino l'endpoint e l'errore; in questo lavoro non è stata tentata alcuna connessione del genere.
Diagnosi fittizia: il logo viene caricato ma l'idoneità non è risolta
Un team immaginario vede il proprio logo aperto in un browser e presuppone che un controllore debba dichiarare BIMI completo. La revisione proposta rileva che il rendering del browser non convalida il profilo SVG richiesto, stabilisce lo stato di prova del marchio o dimostra l'idoneità del destinatario. L'endpoint HTTPS potrebbe funzionare mentre uno degli altri livelli rimane non verificato.
Il team raccoglierebbe l'hash di una risorsa autorizzata, i risultati del validatore, le prove di connessione e i requisiti attuali del destinatario previsto. Non acquisterebbe un certificato, non caricherebbe un logo o non modificherebbe DNS semplicemente per soddisfare un'etichetta di controllo. Questo scenario è fittizio e non è stato osservato alcun logo reale, endpoint o risultato del ricevitore. Illustra perché ogni livello necessita del proprio risultato e della propria spiegazione.
Segnala la disponibilità senza una visualizzazione promettente
Un'utile conclusione del controllo descrive quali requisiti di configurazione e di asset sono stati dimostrati e quali condizioni specifiche del ricevitore rimangono aperte. Non dovrebbe convertire un recupero riuscito nella promessa che verrà visualizzato un logo per ogni destinatario. Il valore è una chiara azione successiva supportata da prove, non un distintivo di preparazione troppo sicuro.
La prova originale del fallimento TLS richiesta rimane aperta, insieme alla revisione specialistica umana, all'applicabilità della fonte, ai percorsi di produzione, all'accessibilità e al rilascio del proprietario. Questa bozza utilizza acquisizioni documentarie conservate con le relative date registrate e non contiene scansioni, caricamenti o pubblicazioni in tempo reale. Un esempio di strumento pubblicabile necessita di prove autorizzate effettive e di un risultato limitato all'endpoint testato e all'ambito del ricevitore.