Inizia con un comportamento, non con un record sostitutivo
Una migrazione degli standard diventa gestibile quando ogni decisione di implementazione ha una specifica denominata e un proprietario responsabile. Un editor DNS , un allineamento il motore e un parser di report aggregati non eseguono lo stesso lavoro. Chiamandoli tutti e tre”DMARC support" nasconde le dipendenze che contano quando un componente cambia e un altro rimane su un'implementazione precedente. Il risultato pratico è una mappa componente-requisito, con versioni, interfacce e prove di accettazione conservate, piuttosto che una dichiarazione che l'intero patrimonio è stato aggiornato.
L'attuale set di documenti è stato pubblicato nel maggio 2026. RFC 9989 definisce il meccanismo principale ed è obsoleto RFC 7489 e RFC 9091 . RFC 9990 copre il reporting aggregato; RFC 9991 copre la segnalazione degli errori e aggiorna anche RFC 6591 . Identificazione dei nuovi record dell'editor RFC RFC 9989 E RFC 9990 come standard proposti. Il testo RFC 9991 pubblicato identifica la categoria Standards Track. Si tratta di specifiche pubblicate, non di bozze incomplete, ma la pubblicazione non stabilisce l'implementazione di un particolare destinatario.
Dai al motore principale un contratto preciso
Assegna l'analisi dei record, l'individuazione delle policy, l'individuazione del dominio organizzativo e l'allineamento degli identificatori a RFC 9989 sezioni 4.7–4.10. Il dominio dell'autore proviene da quello del messaggio RFC5322 .Da campo. Un dominio delle politiche scoperto può differire da quello dell'autore e dal dominio dominio organizzativo utilizzato per l'allineamento rilassato è un altro output esplicito. La perdita di queste distinzioni in un'interfaccia può far sì che un parser corretto alimenti un motore decisionale errato.
Il record DNS inizia ancora con v=DMARC1. “DMARCbis" è un nome per il lavoro sugli standard, non il permesso di inventare DMARC2. La scoperta attuale utilizza il percorso dell'albero DNS delimitato anziché trattare una lista di controllo storica dell'elenco dei suffissi pubblici come l'intero algoritmo. I tag psd, np e t richiedono una copertura decisionale separata. Il Registro IANA segna pct, rf e ri storici; non certifica se un prodotto distribuito li ignora, li interpreta o li espone.
Mantieni le distinzioni tra un normale errore DMARC , informazioni DNS non disponibili, una policy non valida e la disposizione finale del messaggio del destinatario. La sezione 4.10.1 RFC 9989 contiene una gestione speciale per i tag di policy non validi quando rimane un URI di report aggregato sintatticamente valido. Una regola semplicistica secondo cui “ogni politica mal formulata diventa nessuna” ne cancellerebbe le condizioni. Registra la sezione esatta accanto al caso del parser che la esercita.
Tratta il feedback aggregato come una propria implementazione
Mappare il produttore aggregato, il validatore XML, il consumatore di report, la gestione dei duplicati e l'integrazione della consegna RFC 9990 sezioni 3–4 e Appendice A. L'interfaccia di reporting necessita della politica effettivamente valutata, dei risultati dell'autenticazione, del conteggio dei messaggi e del contesto del periodo di reporting. Una dashboard che visualizza XML non è la prova che il destinatario a monte abbia selezionato la policy corretta o che ogni mittente rilevante sia apparso nei dati.
Le destinazioni dei report esterni meritano una riga di componenti separata. L'autorizzazione alla destinazione è un controllo tecnico antiabuso, non un consenso alla trasmissione di dati organizzativi arbitrari. Sottoponi la generazione di report, la verifica della destinazione e le decisioni di accesso/conservazione a criteri di accettazione distinti. La sezione 7 RFC 9990 riguarda la privacy, mentre la sezione 8 mette in guardia sui contenuti dei report dannosi o falsi. Il rafforzamento del parser e l'attendibilità della fonte appartengono quindi alla mappa insieme alla validità dello schema.
Non riutilizzare un parser aggregato per i report sugli errori
Il feedback sugli insuccessi è un canale diverso con diversi rischi di divulgazione. RFC 9991 ne regola la generazione e il formato, lavorando con le specifiche di segnalazione degli errori di autenticazione a cui si fa riferimento. La richiesta ruf e le condizioni fo non equivalgono all'aggregazione rua. Un ricevitore può rifiutare la segnalazione di guasti e l'assenza di a rapporto di fallimento non è la prova che tutti i messaggi siano passati.
Potrebbe verificarsi un'integrazione del rapporto di errore intestazioni dei messaggi o contenuti che una pipeline aggregata è progettata per non trasportare. Identificare chi può richiederlo, dove può essere inviato, come è contenuto il materiale in arrivo e quale controllo sulla privacy si applica. Non abilitarlo mai semplicemente per far sembrare completa una matrice di funzionalità. I requisiti fondamentali di partecipazione, la segnalazione facoltativa dei guasti e le capacità pubblicizzate di un prodotto commerciale sono affermazioni diverse che richiedono prove diverse.
Lavora attraverso un inventario di componenti fittizi
Consideriamo un servizio fittizio con sei moduli: decodificatore di policy, risolutore di rilevamento, valutatore di allineamento, generatore di aggregati, consumatore XML e raccoglitore di errori. I primi tre corrispondono a RFC 9989 . I due successivi si riferiscono principalmente a RFC 9990 . Il raccoglitore si associa principalmente a RFC 9991 . L'archiviazione condivisa e i controlli di sicurezza ereditano i requisiti da ogni percorso di reporting che gestiscono. Questo inventario è un esempio documentario originale, non un'asserzione sull'architettura di EmailAuth .
Per ciascun modulo, conservare l'identificatore di costruzione effettivo, le sezioni pertinenti, il contratto di input/output, il proprietario e l'apparecchiatura di accettazione. Un dispositivo di scoperta immaginario può passare una politica selezionata e il suo dominio di origine in un dispositivo aggregato immaginario; la riga di reporting dovrebbe preservare tale distinzione anziché sostituire silenziosamente il dominio Da visibile. Quindi introdurre una richiesta di segnalazione di errori e confermare che il progetto la instrada verso un percorso di elaborazione autorizzato separatamente. Si tratta di verifiche proposte, non di esecuzioni completate.
Mantieni separati lo stato, gli errata e la distribuzione
La commissione esatta è: mappare ogni componente di implementazione su RFC 9989 , 9990 o 9991 e controllare gli errata. Non è stata fornita la copertura effettiva dell'implementazione. Il recupero corrente degli errata non è riuscito ed è stato interrotto, quindi questa bozza non può affermare che i documenti non abbiano errata. La discussione della RFC 9989 sugli errata risolti RFC 7489 è un contesto storico, non un nuovo controllo degli errata per i tre nuovi documenti.
Prima del rilascio, il proprietario dell'implementazione deve riconciliare l'inventario effettivo, il proprietario degli standard deve risolvere gli errata correnti e il proprietario del test del ricevitore deve preservare le prove dell'interoperabilità a livello di versione. Rimangono aperte anche le revisioni specialistiche, i controlli sul percorso di produzione, l'accettazione visiva e l'approvazione della pubblicazione. Il risultato utile oggi è una mappa rivedibile che espone le prove mancanti senza trasformare uno standard aggiornato in una pretesa non supportata di implementazione universale.