L'aggiunta di una seconda destinazione rua può aiutare a confrontare i collezionisti o preservare una copia indipendente. Crea inoltre due percorsi di consegna ed elaborazione che possono non essere d'accordo. Definisci cosa dovrebbe dimostrare la seconda destinazione prima di trattare la sua dashboard come un backup della prima.
Comprendere la richiesta di consegna
Riferimenti: RFC 9990 §3.5, RFC 9990 §4.
RFC 9990 la sezione 3.5 richiede che un reporter valuti gli URI elencati in ordine e tenti la consegna agli URI validi rimanenti fino al limite supportato. Questa non è una promessa che ogni destinatario implementi la stessa capacità di destinazione o che ogni tentativo di consegna abbia successo. Controlla l'idoneità di ciascuna destinazione, inclusa l'autorizzazione per la destinazione esterna, ove applicabile.
Due destinazioni mailto nella stessa richiesta valida non costituiscono istruzioni per dividere tra loro il conteggio dei messaggi del report. Quando rapporti equivalenti raggiungono entrambi, i loro conteggi descrivono le stesse osservazioni. Sommando i totali di entrambi i raccoglitori è possibile raddoppiare il conteggio del traffico.
Preparare entrambi i percorsi di raccolta
Registra l'esatta richiesta pubblicata, l'instradamento della casella di posta, il proprietario della destinazione e i record di autorizzazione applicabili. Chiedi ai proprietari di verificare l'accettazione degli allegati, la capacità della casella di posta e il supporto del parser. L'aggiunta di una destinazione di terze parti aumenta anche gli utenti che ricevono i dati operativi, quindi approva lo scopo di accesso e conservazione prima di apportare la modifica.
Conservare il percorso di lavoro esistente durante un confronto controllato se autorizzato. Apporta solo la modifica alla destinazione prevista e preservane il valore precedente. Non modificare contemporaneamente la politica di applicazione e il parser se l'obiettivo è comprendere le differenze di raccolta.
Confronta i report prima delle dashboard
Riferimenti: RFC 9990 §3.5.1, RFC 9990 §3.5.4.
Costruisci un confronto basato su reporter, dominio politico, identità del report e intervallo di reporting. Conserva le impronte digitali degli allegati e i timestamp di arrivo. Controlla se una voce mancante del dashboard non è mai stata ricevuta, è stata filtrata, ha fallito l'analisi o è stata esclusa da un filtro di visualizzazione.
Caso illustrativo: il collettore A mostra 800 osservazioni mentre il collettore B ne mostra 600 per lo stesso giorno nominale. L'esame rileva un rapporto di 200 osservazioni nella quarantena di B. La discrepanza riguarda la raccolta; non è una prova di 200 messaggi aggiuntivi inviati tramite A. Se i file stessi differiscono, preservali entrambi e indaga invece di costringere i totali a corrispondere.
Definire i limiti del confronto
Riferimenti: RFC 9989 §5.3.8, RFC 9990 §3.5.
Un arrivo in coppia riuscito dimostra quelle particolari consegne. Non stabilisce una copertura completa del ricevitore né garantisce arrivi futuri identici. I report potrebbero essere ritardati, ritentati o eliminati quando la consegna non è disponibile. Anche diversi fusi orari del dashboard e regole di deduplicazione possono modificare i totali visualizzati.
Chiudere la migrazione solo dopo un periodo di osservazione rappresentativo, campioni di report abbinati e un elenco di eccezioni spiegato. Mantieni la vecchia destinazione finché non vengono soddisfatti i criteri di rimozione approvati. Se una discrepanza rimane inspiegabile, etichetta il confronto come incompleto anziché scegliere come verità la dashboard più grande.
Tieni un registro di confronto delle destinazioni
Per ogni destinazione, salva la revisione della richiesta, il controllo dell'autorizzazione, il primo arrivo corrispondente, l'ultimo intervallo corrispondente e le eccezioni non risolte. Confronta lo stesso set di report non elaborati prima di confrontare le categorie derivate di un fornitore. Un raccoglitore può classificare una fonte condivisa in modo diverso senza aver ricevuto XML diverso. Separare queste differenze interpretative dalle perdite di trasporto. Prima di rimuovere un indirizzo, verificarne le disposizioni contrattuali in materia di conservazione ed esportazione e ottenere l'approvazione per la rimozione. Conservare un'esportazione datata del confronto in modo che una modifica successiva possa essere distinta dalla decisione di migrazione originale.
Continua l'indagine
Usa il procedura dettagliata sul report aggregato per interpretare i campi sottostanti e il file guida alla diagnosi dell'allineamento quando un passaggio di autenticazione non elaborato non soddisfa DMARC.
Prove sintetiche eseguite
Quello che segue è un dispositivo sintetico offline riprodotto localmente, non un DNS in tempo reale, SMTP o un'osservazione del cliente. Il suo input XML è stato analizzato con la libreria standard di Python e le asserzioni hanno controllato i campi e i calcoli risultanti. Le fasi simulate DNS e della posta vengono fornite come input di test, non come prova che un destinatario reale abbia eseguito tali operazioni. La convalida completa dello schema e l'autenticazione dell'origine di produzione sono al di fuori di questo piccolo dispositivo; le prove dal vivo rimangono in sospeso.
La richiesta fornita è _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Si presuppone che questi domini di esempio riservati siano domini organizzativi separati nell'apparecchiatura. Le due risposte sintetiche di autorizzazione sono brand.example._report._dmarc.collector.example TXT "v=DMARC1" E brand.example._report._dmarc.archive.example TXT "v=DMARC1". Il modello locale corrisponde sia ai nomi dei proprietari di autorizzazione forniti sia ai relativi valori di versione in RFC 9990 §4. It does not execute DNS queries or the complete authorization algorithm. Un'implementazione di produzione deve eseguire la procedura completa di rilevamento e autorizzazione anziché assumere questi limiti di dominio.
Il report conservato ha ID R1, dominio policy brand.example , intervallo_date che inizia 1772409600 e termina 1772496000, IP di origine 192.0.2.10 e conteggio 100. La sua valutazione è allineata DKIM il risultato è superato e allineato SPF è fallire. Il risultato SPF grezzo è pass for vendor.example , illustrando perché il successo grezzo non è un successo allineato. Questi campi vengono analizzati da XML anziché dedotti da un dashboard.
Il test modella una ricevuta 250 riuscita in ciascuna destinazione e analizza lo stesso allegato in entrambe. Ciascun parser restituisce R1 e conta 100. Il confronto registra due arrivi ma un set di osservazioni di 100, non un volume combinato di 200. Ciò stabilisce solo l'aritmetica della copia duplicata dell'apparecchiatura. Per sostituire la simulazione con prove reali, conservare la ricerca effettiva della richiesta, la ricerca dell'autorizzazione, gli ID di ricevuta, gli hash degli allegati protetti e gli output del lavoro del parser per ciascuna destinazione. Se una ricevuta è assente, registra una consegna non osservata invece di fabbricare una copia corrispondente.
Mantenere il risultato nell'ambito del test
La dimostrazione locale fornita verifica solo il suo piccolo parser sintetico, gli input e i calcoli forniti sullo stage. No real DNS authorization, SMTP delivery, collector migration, provider participation or production database behavior was tested. Gli input originali rimangono archiviati e qualsiasi confronto dal vivo necessita di prove protette e di approvazione responsabile.