Riportare quanto osservato prima di definirlo sano
A DMARC il controllore può osservare le informazioni sulla politica DNS e valutare parti della sua sintassi o comportamento di rilevamento. Ciò non stabilisce che ogni servizio di invio legittimo si autentichi correttamente, che tutti i destinatari applichino la stessa implementazione o che un particolare messaggio abbia raggiunto una casella di posta. Un utile risultato del controllo dovrebbe identificare i suoi input esatti, il contesto del risolutore, il tempo di osservazione, il metodo di scoperta e le limitazioni prima di presentare una conclusione.
RFC 9989 definisce l'attuale meccanismo DMARC , inclusa la policy discovery e allineamento. Questo articolo descrive i requisiti di prova proposti per un controllore; non afferma che EmailAuth li implementi o che qualsiasi dominio sia stato scansionato. Non è stata eseguita alcuna query autorevole o ricorsiva per un dominio utente e non è stato raccolto alcun campione di messaggi ricevuti.
Distinguere una ricerca esatta dall'individuazione delle policy
Una query per un particolare nome del proprietario _dmarc è un'osservazione su quel nome. La determinazione della politica applicabile può richiedere il processo di scoperta dello standard attuale, incluso il suo Passeggiata sull'albero DNS regole. Il verificatore dovrebbe indicare se visualizza semplicemente una risposta TXT esatta o implementa un algoritmo di rilevamento definito. Non dovrebbe nominare un record mancante come prova che non esiste alcuna politica applicabile senza valutarne l'ambito rilevante.
Registra il nome di ciascun proprietario, il tipo di query, la risposta e il ramo utilizzato dal processo di rilevamento implementato. L'output dovrebbe distinguere una policy valida, nessuna policy applicabile, un candidato non valido e un errore DNS in base all'algoritmo supportato. Non inventare una scorciatoia basata solo su un elenco di domini organizzativi familiari mentre si rivendica il comportamento standard attuale. La versione del prodotto e il riferimento agli standard devono essere conservati insieme al risultato.
Preservare prospettive autorevoli e ricorsive
Una risposta autorevole e una risposta del risolutore ricorsivo possono differire a causa della memorizzazione nella cache, dello stato della delega, della tempistica o dell'errore di risoluzione. Registra quale server o risolutore ha fornito ciascuna risposta e quando è stata raccolta. Una dashboard non dovrebbe fonderli in un unico valore apparentemente senza tempo. Se un verificatore offre solo prove ricorsive, ditelo invece di lasciare intendere che la configurazione autorevole sia stata verificata in modo indipendente.
RFC 1035 definisce le strutture dei messaggi DNS e dei record di risorse, inclusi Record TXT. Conserva i codici di risposta e la struttura dei record invece di visualizzare solo una stringa di criteri appiattita. Più stringhe di caratteri all'interno di un record TXT non equivalgono a più record TXT . Questa distinzione è importante quando si determina se la risposta contiene record di policy DMARC concorrenti o semplicemente un record rappresentato in più stringhe.
Interpretare la sintassi con lo standard attuale
RFC 9989 specifica DMARC1 come valore di versione con distinzione tra maiuscole e minuscole e richiede il tag di versione nella posizione definita. Un controllore dovrebbe identificare il motivo esatto per cui un candidato non è una politica valida piuttosto che sostituire ogni problema con un generico avvertimento rosso. Dovrebbe inoltre distinguere i candidati politici duplicati dai dati TXT non correlati. La procedura di rilevamento applicabile determina il modo in cui i record dei candidati vengono selezionati e gestiti.
I tag sconosciuti non sono automaticamente un errore politico fatale: la definizione formale della RFC dice che i tag sconosciuti devono essere ignorati. Un controllore può comunque avvisare che un tag non è supportato dal proprio parser o è assente dal registro corrente, ma non dovrebbe confondere quell'avviso con una regola di rifiuto normativo. Al contrario, un tag riconosciuto con un valore problematico necessita della gestione dello standard pertinente, non di una risposta universale inventata a tutti gli errori di sintassi.
Implementazione statale e limiti di compatibilità
L'attuale RFC rimuove pct e introduce il tag testing t, come spiegato nell'Appendice A.6. Un controllore dovrebbe identificare quale standard e registro dei tag segue la sua interpretazione ed evitare di implicare che ogni ricevitore esterno si comporti in modo identico. Non dovrebbe suggerire una migrazione meccanica da percentuali storiche arbitrarie senza una revisione della preparazione. Le regole di ammissibilità specifiche del fornitore potrebbero richiedere una documentazione corrente separata.
Una politica DNS sintatticamente accettabile rappresenta ancora solo una parte del quadro operativo. Il controllore non ha stabilito l'elenco dei mittenti legittimi, il loro allineamento o l'effetto di una modifica della politica. Mantieni le raccomandazioni condizionate agli input mancanti. Una policy che richiede l'applicazione può essere pubblicata correttamente mentre i flussi di lavoro legittimi rimangono configurati in modo errato; un controllo DNS da solo non può certificare che l'applicazione sia sicura per l'azienda.
Connetti la prova DNS a un esempio di messaggio attendibile
RFC 8601 spiega il confine di fiducia per Authentication-Results campi. Un campione di messaggio ricevuto dovrebbe identificare il destinatario che ha prodotto il risultato e preservare le pertinenti identità visibili, della busta e della firma. Una riga copiata contenente pass non è sufficiente per stabilire che il destinatario previsto abbia valutato il flusso di lavoro effettivo. Il campione deve essere autorizzato e redatto senza distruggere le relazioni di dominio necessarie per l'analisi.
Confronta il tempo e le identità del campione con le osservazioni DNS , ma non pretendere che un campione copra ogni mittente o destinatario. Una policy potrebbe essere cambiata tra l'invio e il controllo e le cache ricorsive potrebbero riflettere stati diversi. Indicare cosa dimostra il campione e cosa rimane sconosciuto. Questo articolo non contiene esempi di messaggi e non afferma che una politica reale corrisponda a un risultato reale ricevuto.
Un foglio di lavoro per l'accettazione dell'output del controllore
Crea un foglio di lavoro con il dominio richiesto, i nomi esatti dei proprietari, il risolutore o la fonte autorevole, i timestamp, i codici di risposta, le trascrizioni conservate e la struttura dei record dei candidati. Aggiungi l'algoritmo di rilevamento implementato, la versione del parser, la policy selezionata, gli avvisi e l'incertezza esplicita. La sezione del messaggio dovrebbe registrare il flusso di lavoro autorizzato, il destinatario attendibile, le identità rilevanti, il risultato osservato e le limitazioni di collegamento.
Utilizza le strutture proposte per una policy valida, record del nome esatto mancante con rilevamento di livello superiore applicabile, candidati duplicati, tag non supportati e DNS non disponibile. Separare il comportamento previsto dalla normativa dalla presentazione specifica del prodotto. Un test dovrebbe verificare le prove e le spiegazioni conservate, non solo un'icona verde. Qui non è stata eseguita alcuna operazione e negli esempi non è rappresentata alcuna risposta DNS reale.
Diagnosi fittizia: un record verde con un mittente in errore
Un team immaginario vede un controllore visualizzare una politica di applicazione valida e conclude che il suo servizio di fatturazione è pronto. Un campione di messaggio ricevuto autorizzato, se raccolto successivamente, potrebbe mostrare che il servizio utilizza un percorso non allineato. L'osservazione DNS e l'errore del messaggio non si contraddicono a vicenda: uno descrive la pubblicazione, mentre l'altro descrive un flusso di lavoro di invio.
L'indagine proposta preserverebbe entrambe le osservazioni, identificherebbe il proprietario del flusso di lavoro e rivedrebbe il percorso allineato previsto prima di modificare la politica o aggiungere autorizzazioni. Non dichiarerebbe il dominio sicuro semplicemente perché il record viene analizzato. Si tratta di un esercizio fittizio, non di un vero errore del servizio di fatturazione, di una scansione DNS o di un risultato del ricevitore. Il suo scopo è mantenere visibile il confine dell'evidenza del controllore.
Mantieni la conclusione finale proporzionale
Una conclusione utile per il controllo può dire che una politica specifica è stata osservata e interpretata secondo un algoritmo specificato in un momento stabilito. Non dovrebbe promettere la consegna universale, l'adozione completa del destinatario o la protezione contro qualsiasi imitazione. Il risultato è più efficace quando rende facile vedere le prove operative mancanti.
Il catalogo richiede trascrizioni di ricerca autorevoli e ricorsive, timestamp e un esempio di messaggio ricevuto corrispondente. 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 modello di prova proposto, non scansioni eseguite o funzionalità di controllo EmailAuth verificate.