Due parti costituiscono il rapporto di reporting
Pubblicazione di una destinazione di reporting in un dominio DMARC La policy esprime la richiesta del proprietario del dominio. Non è necessario che una destinazione non correlata accetti unilateralmente i rapporti risultanti. Verifica della destinazione esterna protegge i destinatari dall'essere selezionati come destinatari involontari del report. La parte ricevente pubblica l'autorizzazione tramite DNS , mentre la parte segnalante controlla tale autorizzazione prima di utilizzare la destinazione esterna.
RFC 9990 applica la sua procedura di verifica quando pertinente Dominio organizzativo il confronto mostra una destinazione esterna per il reporting aggregato. Non sostituire questa regola con un test semplicistico per verificare che le stringhe nell'indirizzo del mittente e nell'indirizzo del rapporto differiscano. Il dominio delle politiche, l'host di destinazione e il contesto del dominio organizzativo scoperti devono essere conservati in modo che la decisione di eseguire la verifica sia riproducibile. RFC 9990 , sezione 4
Costruisci il nome del proprietario nell'ordine corretto
Estrai l'host di destinazione dall'URI di reporting. Anteporre _report. _dmarc , quindi anteponi il nome di dominio da cui è stata recuperata la policy, convertendo quel dominio in un'etichetta A, se necessario. Il proprietario DNS risultante ha il formato policy-domain._report. _dmarc.destination-host. Viene interrogato Record TXT. Se il nome costruito supera i limiti DNS , non è possibile effettuare una determinazione positiva dell'autorizzazione.
Questa costruzione utilizza il dominio effettivo da cui è stata recuperata la policy. Non abbreviarlo con un genitore familiare semplicemente perché quel genitore assomiglia al marchio dell'organizzazione. Allo stesso modo, la parte locale di un indirizzo mailto non viene inserita nel nome del proprietario DNS . Conserva l'URI originale e l'host di destinazione analizzato in modo che i revisori possano vedere come il nome costruito segue dagli input. RFC 9990 , sezione 4
Convalida la risposta anziché riconoscere una stringa familiare
I record restituiti vengono analizzati come elenchi di valori di tag. Il tag obbligatorio v=DMARC1 deve essere visualizzato per primo e il punto e virgola finale è facoltativo. I record che non superano il test di analisi specificato vengono eliminati. Almeno un record qualificante rimanente stabilisce l'accordo di reporting esterno nell'ambito della procedura. Una risposta vuota, un valore TXT non correlato o un record con il posizionamento della versione errato non viene stabilita l'autorizzazione.
Il valore della versione DMARC fa distinzione tra maiuscole e minuscole: DMARC1 è il valore richiesto, non un'approssimazione in lettere minuscole o una versione del protocollo appena inventata. Le regole di confronto dei nomi DNS non devono essere confuse con il requisito delle maiuscole e minuscole del valore della versione. Una revisione dovrebbe preservare gli esatti byte di risposta e i limiti dei record invece di normalizzare i dettagli prima della convalida. RFC 9990 , sezione 4; RFC 9989 , sezione 4.7 e 4.8
Rispettare il comportamento di override e di errore
Un record di autorizzazione può fornire una destinazione di reporting sostitutiva nell'ambito della procedura. L'URI sovrascritto deve utilizzare lo stesso host di destinazione estratto all'inizio. Questa restrizione impedisce a una risposta di autorizzazione di reindirizzare il processo in una catena di destinatari non correlati. Se la conferma contiene una sostituzione con un host diverso, il generatore di report non deve generare un report né sull'URI originale né su quello di sostituzione.
Se la verifica non conferma l'autorizzazione, l'URI esterno deve essere ignorato. Un errore DNS temporaneo ha il suo trattamento: il destinatario può scegliere di fallire temporaneamente la consegna in modo che il test di verifica possa essere ripetuto in seguito. Conserva tale autorizzazione come MAGGIO, non una garanzia universale di nuovi tentativi o una descrizione di un'implementazione testata. Un controllo DNS riuscito non dimostra ancora che la casella di posta di destinazione esiste, accetta la dimensione del report o alimenta la dashboard del cliente previsto. RFC 9990 , sezione 4
Distinguere le richieste di report aggregati e di errore
Per rapporti aggregati, la procedura è associata a rua. La segnalazione dei guasti è specificata separatamente in RFC 9991. Per le destinazioni esterne di segnalazione di guasto, quel documento richiede la stessa procedura di verifica esterna con ruf sostituito ovunque appaia rua. Non considerare la segnalazione degli errori come abilitata automaticamente solo perché i report aggregati stanno fluendo o copiare la gestione della destinazione aggregata senza riconoscere il tipo di report separato.
Rapporti di fallimento sollevano ulteriori preoccupazioni sull’esposizione dei dati perché il loro contenuto può essere più dettagliato delle sintesi aggregate. Un record di autorizzazione DNS corretto non sostituisce la decisione di un'organizzazione su quali dati possono essere condivisi, con chi e per quale scopo. Questo manoscritto non fornisce alcun permesso per richiedere, trasmettere o caricare resoconti effettivi. Qualsiasi configurazione reale deve soddisfare le approvazioni applicabili in materia di privacy, destinatario e operazioni. RFC 9991 , sezioni 5 e 7
Foglio di lavoro immaginario per la costruzione e l'accettazione
Supponiamo che una policy fittizia sia stata recuperata da blue.example.com e richieda report aggregati a mailto:reports@red.example.net. Il proprietario dell'autorizzazione costruita è blue.example.com._report._dmarc.red.example.net . Un'ipotetica risposta TXT il cui valore completo è v=DMARC1; soddisfa il requisito della prima versione illustrata. Non è stata eseguita alcuna query DNS e questo esempio non afferma che i nomi abbiano record pubblicati.
Il foglio di lavoro deve conservare il risultato della ricerca delle policy, il dominio delle policy scoperto, l'URI di reporting originale, l'host di destinazione, il confronto del dominio organizzativo, il proprietario costruito, il tipo di query, il timestamp, i record esatti restituiti e il risultato dell'analisi. Aggiungi un campo separato per qualsiasi sostituzione e conferma la restrizione dell'host. Un revisore dovrebbe essere in grado di ricostruire il nome senza fare affidamento sullo screenshot del provider o sulla visualizzazione abbreviata di un editor DNS .
Utilizzare una seconda sezione di accettazione per la raccolta: account previsto, casella di posta di destinazione, tipo di report autorizzato e proprietario della pipeline. Questi campi descrivono un flusso di lavoro di verifica pianificato, non prove di importazione completate. Mantenere il risultato della relazione DNS distinto dalla ricezione, dall'analisi, dall'attribuzione del tenant e dalla presentazione del dashboard. Un controllo delle autorizzazioni può avere esito positivo mentre un'altra parte del percorso di raccolta rimane irrisolta.
La pubblicazione e l'implementazione restano valide
Il catalogo richiede la costruzione dell'esatta ricerca dell'autorizzazione dai domini di origine e di destinazione e la verifica della sua risposta. Questa bozza fornisce solo una costruzione fittizia. La risposta effettiva, la trascrizione della query originale e l'implementazione del dominio ricevente rimangono aperte. Non è stato pubblicato alcun record DNS , non è stato effettuato l'accesso a nessuna casella di posta e non è stato trasmesso alcun report.
Prima del rilascio come procedura dettagliata operativa, ottenere prove autorizzate per l'esatta relazione di produzione e chiedere a un revisore qualificato di confermare il contesto di rilevamento delle policy, l'analisi della versione e la gestione dell'override. Conserva la data di origine e distingui i requisiti degli standard dall'onboarding dell'account specifico del fornitore. Tutti e sei i cancelli di rilascio rimangono aperti, comprese le prove originali, la revisione umana, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario.
Una modifica successiva alla destinazione o al dominio di individuazione delle policy può modificare il proprietario dell'autorizzazione richiesta. Trattatela come una nuova relazione con ambito da verificare anziché presupporre che un vecchio controllo positivo copra ogni indirizzo di reporting futuro. Il risultato utile è una catena di autorizzazioni verificabile, non semplicemente un valore TXT copiato.