Conserva il denominatore prima di confrontare il trend
Una tendenza all'adozione dell'autenticazione può cambiare perché i domini hanno cambiato configurazione, perché è cambiato il campione o perché è cambiato il metodo di misurazione. Tali spiegazioni non sono equivalenti. Un confronto longitudinale dovrebbe mantenere la popolazione, la definizione della metrica, il parser e la gestione degli errori per ogni periodo in modo che non si crei un miglioramento apparente rimuovendo silenziosamente casi difficili o aggiungendo un diverso mix di domini.
Questo articolo propone un metodo riproducibile e non presenta il risultato di uno studio. RFC 9989 definisce la corrente DMARC comportamento, mentre RFC 7208 definisce SPF pubblicazione e valutazione. Gli standard aiutano a specificare cosa significa una misurazione; non riforniscono la popolazione né giustificano un’interpretazione causale di una tendenza. Nessun dominio è stato interrogato per questo manoscritto.
Definire la proprietà e l'unità misurata
Indica se la metrica conta la presenza di record con nome esatto, policy applicabili valide, richieste di applicazione, messaggi allineati osservati o un'altra proprietà chiaramente definita. Un dominio configurato e un messaggio sono unità diverse e un dominio può supportare più flussi di lavoro di invio. Il denominatore deve corrispondere al numeratore. Una percentuale di passaggio dei messaggi osservati non può sostituire la quota di domini che pubblicano una policy senza modificare la domanda.
Registrare l'origine del campione, i criteri di inclusione e l'ambito previsto. I domini dei siti web, i domini dei clienti e le identità SMTP effettive possono produrre risultati diversi. Se lo studio utilizza un elenco di convenienza, mantenere tale limitazione. Evita di dire che Internet è migliorato quando le prove riguardano una coorte di clienti selezionata. Questa bozza non contiene alcun conteggio della popolazione o percentuale di adozione per generalizzare.
Tieni traccia dell'appartenenza come un set di dati di prima classe
Conserva una tabella di appartenenza con versione con l'identificatore stabile di ciascuna unità, il nome normalizzato, la data di ingresso, la data di uscita e il motivo dell'inclusione o dell'esclusione. Conserva le ridenominazioni dei domini, i cambiamenti di proprietà e le fusioni laddove influiscono sull'interpretazione. Non dare per scontato che la stessa etichetta di testo rappresenti la stessa relazione organizzativa in tutto lo studio. Un dominio può rimanere nel DNS mentre cambia il suo ruolo aziendale.
Scegli se l'analisi utilizza una coorte fissa, una sezione trasversale ripetuta o entrambi. Una coorte fissa può supportare il confronto tra le stesse unità ma può diventare meno rappresentativa nel tempo. Una sezione trasversale ripetuta può riflettere la popolazione attuale ma mescola il cambiamento dell'appartenenza con il cambiamento della configurazione. Riporta il disegno scelto e, dove utile, mostra entrambe le viste separatamente anziché nascondere i loro diversi denominatori.
Versione dell'implementazione della misurazione
Conserva il codice della query o la descrizione del metodo, la configurazione del sistema di risoluzione, i timeout, i tentativi, le regole di normalizzazione, la versione del parser e i riferimenti agli standard per ogni esecuzione. Un aggiornamento del parser può riclassificare lo stesso record grezzo anche se DNS non è cambiato. RFC 9989le attuali regole di rilevamento di , incluso il Passeggiata sull'albero DNS, illustrano perché un metodo basato su un diverso algoritmo di scoperta potrebbe non essere direttamente confrontabile senza analisi.
Se il metodo cambia, conservare i risultati precedenti e identificare un'interruzione nella serie. Laddove le prove grezze lo consentono, rielaborare le osservazioni precedenti con il nuovo parser e riportarle come serie comparabili separate. Non sovrascrivere silenziosamente le classificazioni storiche e presentare la tendenza rivista come misurazione originale. La rielaborazione non può ricostruire le risposte DNS che non sono mai state conservate.
Mantieni i fallimenti nella contabilità
Distinguere l'errore del nome, l'assenza di dati richiesti, il timeout, l'errore del server, la policy non valida e l'interpretazione non supportata. Una query non riuscita non dovrebbe diventare automaticamente assenza di distribuzione ed escludere tutti gli errori può aumentare il tasso di adozione apparente. Conservare le osservazioni tentate e spiegare il trattamento di ciascuna categoria di errore. Se un nuovo tentativo ha esito positivo, preservare sia il fallimento iniziale che la regola utilizzata per la classificazione finale.
RFC 1035 definisce la risposta DNS e le strutture dei record. Conserva i limiti dei record non elaborati prima dell'analisi del protocollo, soprattutto quando sono presenti più stringhe o record TXT . Un cambiamento nella gestione da parte del parser di stringhe divise o candidati duplicati può creare un falso trend se l'evidenza sottostante viene persa. La struttura dei record fa parte della riproducibilità, non semplicemente della formattazione della visualizzazione.
Indica esplicitamente ogni frazione
Per ciascun periodo, conservare il numero di unità selezionate, tentate, osservate con successo, classificate, escluse e irrisolte. Quindi definire il numeratore per la proprietà segnalata. L'adozione tra tutte le unità selezionate differisce dall'adozione tra le unità classificate con successo. Se entrambe le misure sono informative, segnalarle entrambe con le relative etichette e incertezze anziché presentare quella più favorevole.
Non inventare intervalli di confidenza, significatività statistica o copertura rappresentativa senza un modello di campionamento giustificato. Le osservazioni mancanti potrebbero non essere casuali e i domini che scadono possono differire sistematicamente da quelli che rispondono. Un confronto descrittivo trasparente può ancora essere utile senza affermazioni inferenziali non supportate. Questo manoscritto non fornisce stime numeriche o calcoli di incertezza fabbricati.
Separare la modifica della configurazione dai risultati del messaggio
Un dominio che si sposta da una politica non osservata a una politica osservata è un'osservazione di configurazione. Ciò non dimostra che tutti i messaggi legittimi siano ora allineati o che le frodi siano diminuite. RFC 8601 descrive prove attendibili dei risultati dell'autenticazione che potrebbero supportare l'analisi a livello di messaggio, ma tale analisi necessita di una propria popolazione e di osservazioni del destinatario conservate.
RFC 9990 definisce il reporting aggregato. Se i report contribuiscono a uno studio longitudinale, preservare la copertura del reporter, i periodi e le dimensioni del conteggio separatamente dalle osservazioni DNS . I cambiamenti nella copertura dei rapporti possono alterare le prestazioni apparenti dell'autenticazione anche senza modificare il comportamento del mittente. Non unire un trend di coorte DNS e un trend di conteggio dei report in un'unica metrica a meno che il metodo non spieghi le unità compatibili e le limitazioni.
Un foglio di lavoro per la riconciliazione longitudinale
Crea un foglio di lavoro con periodo, versione del campione, modifiche all'appartenenza, versione del metodo, riferimenti alla fonte, tentativi di conteggio, categorie di errore, esclusioni, conteggio classificato e numeratore della metrica. Aggiungere la regola utilizzata per ciascun denominatore e uno stato di confronto che indica se i periodi sono direttamente confrontabili, rielaborati o separati da un'interruzione del metodo. Conserva gli hash delle prove grezze e il registro degli errori/esclusioni.
La revisione dovrebbe chiedersi se viene data risposta alla stessa domanda in ciascun periodo. Se una nuova sorgente ricevente, regola parser o classe di dominio entra nello studio, documentarne l'effetto prima di interpretare la direzione del cambiamento. Chiedi a un analista indipendente di riprodurre una piccola serie di classificazioni e la contabilità aggregata quando i dati originali saranno disponibili. Nessuna riproduzione del genere è stata eseguita qui.
Diagnosi fittizia: una percentuale migliore dopo aver rimosso i fallimenti
Un team immaginario pubblica una percentuale di adozione più elevata nel secondo periodo. Il primo denominatore includeva ogni tentativo di dominio, mentre il secondo escludeva tutti i timeout e le risposte non valide. L’apparente miglioramento potrebbe quindi riflettere un cambiamento contabile piuttosto che un ulteriore dispiegamento. La revisione proposta ricostruisce entrambi i periodi utilizzando la stessa regola dichiarata e riporta separatamente i casi irrisolti.
Il team controllerà anche se l'appartenenza o il comportamento del parser sono cambiati. Non affermerebbe un miglioramento causale rispetto alle percentuali originali finché tali differenze non fossero state comprese. Questo esempio non fornisce conteggi, domini o osservazioni di studio effettivi. Si tratta di un esempio fittizio della deriva del denominatore e non di un risultato misurato su un ecosistema di autenticazione.
Pubblicare i limiti di comparabilità con il risultato
Un rapporto di tendenza difendibile indica la popolazione, le finestre temporali, le versioni di misurazione, il numeratore, il denominatore e gli errori. Spiega le modifiche al metodo e non converte silenziosamente le osservazioni sulla distribuzione in conformità dei messaggi, consegna o perdite evitate. Il lettore dovrebbe essere in grado di determinare cosa è cambiato nei sistemi misurati e cosa è cambiato solo nel processo di misurazione.
Il catalogo richiede un set di dati con versione, un metodo di query e un registro di errori/esclusioni che un altro analista può riprodurre. Quei manufatti originali rimangono aperti. Rimangono aperti anche la revisione da parte di specialisti umani, l’applicabilità della fonte, i percorsi di produzione, l’accessibilità e il rilascio del proprietario. Questa bozza fornisce un disegno metodologico e una diagnosi fittizia, non uno studio longitudinale eseguito o un'affermazione di miglioramento dell'adozione.