Definire l'adozione e la disponibilità come misure separate
MTA-STS l'adozione può fare riferimento alla scoperta DNS , al recupero di una policy sintatticamente valida, alla pubblicazione di una modalità di applicazione o alla compatibilità osservata con il percorso MX di ricezione del dominio. La disponibilità dell'host della politica è un'altra proprietà: riguarda se l'endpoint HTTPS era raggiungibile e valido al momento dell'osservazione. Uno studio dovrebbe definire queste misure separatamente invece di considerare un recupero riuscito come un’adozione completa della sicurezza dei trasporti.
RFC 8461 definisce il rilevamento MTA-STS , il recupero delle policy, la convalida e la memorizzazione nella cache. Supporta un progetto di misurazione riproducibile, non un'asserzione sull'esistenza di un set di dati. Questo articolo non contiene scansioni di domini, percentuali di disponibilità, test di connessione o risultati longitudinali. Tutti gli esempi sono esplicitamente ipotetici.
Stabilire la popolazione del dominio ricevente
MTA-STS riguarda il percorso della posta del dominio ricevente. Un elenco di siti Web, marchi di mittenti in uscita o organizzazioni di clienti non è automaticamente un elenco appropriato di domini riceventi. Definire l'unità, il metodo di selezione e le esclusioni prima del ritiro. Registra se il campione include domini senza un percorso di posta utilizzabile e in che modo questi casi influenzano ogni metrica anziché eliminarli silenziosamente.
Blocca l'elenco di input e preservane l'origine, la data, le regole di normalizzazione e l'hash. Se l'elenco cambia tra un'esecuzione e l'altra, conserva la cronologia dei membri. Un dominio che entra o esce dal campione può alterare l'apparente adozione senza alcuna modifica alla sua politica. Non chiamare un campione di convenienza una stima globale a meno che il disegno di campionamento non supporti tale inferenza. Questo manoscritto non fornisce tale stima.
Separare il rilevamento DNS dal recupero HTTPS
RFC 8461 definisce il record di rilevamento nel proprietario _mta-sts e la posizione di recupero della policy nell'host mta-sts nel percorso noto. L'identificatore di rilevamento segnala i cambiamenti delle politiche; non è un'impronta digitale del certificato o una prova che l'endpoint attualmente funziona. Registra la risposta DNS , il proprietario, il risolutore e l'ora indipendentemente dalla successiva osservazione HTTPS.
Lo standard richiede HTTP 200 OK per il recupero della policy e afferma che i mittenti non devono seguire i reindirizzamenti HTTP in tale procedura di recupero. Dice inoltre che i mittenti non devono utilizzare la memorizzazione nella cache HTTP per il recupero delle policy, distinta dalla memorizzazione nella cache delle policy MTA-STS . Il metodo dovrebbe preservare lo stato della risposta e il comportamento di reindirizzamento anziché accettare qualsiasi destinazione del browser dall'aspetto positivo. Nessun endpoint è stato recuperato o reindirizzato seguito durante questo lavoro.
Convalidare la politica e la connessione secondo le regole stabilite
La policy contiene versione, modalità, modelli MX e età massima secondo la sintassi RFC 8461 . Conserva i byte effettivi e la versione del parser. Una policy che utilizza la modalità di test non rientra nella stessa categoria misurata della modalità di applicazione. Una politica “nessuna” è un altro stato che dovrebbe essere nominato piuttosto che collassare in un conteggio di adozione generico. Segnala la gestione del tipo di contenuto con la forza dei requisiti dello standard: i mittenti dovrebbero convalidare testo/semplice, piuttosto che inventare un requisito universale più forte.
La convalida del certificato HTTPS è un'osservazione separata. Registra il nome host, l'endpoint, l'ora e il risultato effettivo della convalida richiesti. Un errore di rete, un errore di certificato, uno stato imprevisto e una policy non valida hanno significati diversi e dovrebbero rimanere separati nel registro degli errori. Non dedurre che una politica sia assente semplicemente perché un luogo di osservazione non è riuscito a raggiungerla e non ignorare gli errori di connessione per produrre un numeratore di adozione più ampio.
Confronta i modelli di policy con il percorso MX previsto
Una politica sintatticamente valida può comunque descrivere gli host riceventi errati. RFC 8461 definisce la corrispondenza dei nomi host MX esatti e dei modelli di caratteri jolly. Un carattere jolly non è un glob illimitato in qualsiasi punto di un nome; il metodo deve implementare la sintassi e la corrispondenza definite dallo standard. Conserva le osservazioni MX e la decisione di corrispondenza per ciascun host nell'ambito misurato.
Un recupero HTTPS da solo non stabilisce che ogni endpoint MX offra un servizio TLS valido corrispondente alla policy. Se lo studio non effettua osservazioni SMTP autorizzate, dichiarare che la compatibilità delle rotte non è misurata. Se i test successivi vengono approvati, mantieni le prove di connessione e la popolazione separate dalla disponibilità dell'host della policy. Non pretendere l'applicazione end-to-end solo da DNS e HTTP.
Tenere conto del comportamento dei criteri memorizzati nella cache
I mittenti possono mantenere una policy MTA-STS per la sua età massima prevista dal protocollo. Un'interruzione temporanea dell'host della policy può quindi influenzare un mittente con una policy memorizzata nella cache utilizzabile in modo diverso da un mittente che scopre il dominio per la prima volta. Una sonda di misurazione esterna generalmente non conosce lo stato della cache di ogni mittente. Lo studio non deve tradurre i tempi di inattività degli endpoint direttamente in un periodo universale di posta non protetta.
Allo stesso modo, l'identificatore di rilevamento e la versione della policy osservata necessitano di un record temporale. Se una policy cambia durante la raccolta, preserva la sequenza anziché unire la vecchia osservazione DNS a un nuovo corpo senza spiegazione. Le misurazioni ripetute dovrebbero registrare lo stato della sonda e qualsiasi trattamento intenzionale della cache. Il metodo deve distinguere il suo comportamento di misurazione da un invio completo MTA implementazione.
Progetta il programma di disponibilità prima del ritiro
Definire in anticipo posizioni delle sonde, cadenza, timeout, criteri di ripetizione e regole di classificazione. Un endpoint che fallisce una volta e riesce dopo un nuovo tentativo non dovrebbe scomparire dal record di errori. Riportare le osservazioni tentate, le osservazioni riuscite e le categorie di fallimento utilizzando un denominatore chiaro. Se vengono esclusi finestre di manutenzione o punti panoramici irraggiungibili, conserva le motivazioni e mostra come le esclusioni modificano il risultato.
Nessun obiettivo di cadenza o livello di servizio è imposto universalmente da questo articolo. Scegli un programma adatto alla domanda di ricerca e all'autorizzazione, evitando un carico eccessivo. Documentare la versione degli strumenti e le dipendenze in modo che un altro analista possa riprodurre il metodo. Le conclusioni sulla disponibilità effettiva richiedono la raccolta dei dati; un programma proposto non costituisce la prova che un servizio abbia raggiunto o mancato un obiettivo.
Un foglio di lavoro del set di dati con versione
Crea campi per versione di esempio, dominio di ricezione, tempo di osservazione, risultato del rilevamento DNS , identificatore di policy, endpoint HTTPS, stato, risultato del certificato, tipo di contenuto, hash del corpo, modalità analizzata, modelli MX ed età massima. Aggiungi riferimenti all'osservazione MX , risultati corrispondenti, categoria di errore, cronologia dei tentativi e motivo di esclusione. Conservare le prove grezze separatamente dalle classificazioni normalizzate.
RFC 8460 definisce il reporting SMTP TLS , che può fornire un'altra prospettiva quando legittimamente disponibile. Tali report non equivalgono a un'indagine di disponibilità esterna e non coprono automaticamente tutti i mittenti. Se inclusi, documentarne la fonte e l'ambito separatamente. Questa bozza non raccoglie né indagini né rapporti e non implica un'esatta correlazione tra loro.
Diagnosi fittizia: l'interruzione dell'endpoint diventa una richiesta di esecuzione
Uno studio fittizio osserva un recupero HTTPS non riuscito ed etichetta il dominio ricevente come privo di protezione MTA-STS per l'intera giornata. La revisione proposta identifica le prove mancanti: l’osservazione ha riguardato un momento e un punto di osservazione, e i mittenti potrebbero aver memorizzato nella cache le policy. La conclusione corretta è più ristretta e descrive il recupero non riuscito e la relativa categoria di errore all'interno della pianificazione misurata.
Il team conserverebbe le osservazioni successive e riporterebbe il denominatore anziché cancellare l'errore o estrapolarlo in un comportamento postale universale. Questo è un esempio metodologico fittizio, non un'interruzione osservata o un'affermazione relativa a un dominio denominato. Non è stato eseguito alcun sondaggio di rete o test di consegna della posta elettronica.
Rilasciare solo risultati riproducibili
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 di studio e una diagnosi fittizia, non il conteggio delle adozioni, i risultati della disponibilità o una valutazione end-to-end della sicurezza dei trasporti.