Sostituisci la promessa percentuale con una decisione esplicita
Un piano di implementazione che dice "applica il rifiuto al 10% dei messaggi non inviati" necessita di revisione prima di essere riutilizzato con la versione aggiornata DMARC specifica. RFC 9989 rimuove il meccanismo pct e definisce un segnale di test chiamato t. Si tratta di un cambiamento nel linguaggio politico disponibile, non di una prova che ogni destinatario abbia cambiato il proprio software. Il compito pratico è identificare ciò che il piano esistente intendeva proteggere, quindi confrontare tale intenzione con la semantica attuale e il comportamento legacy osservato.
Non tradurre meccanicamente una percentuale in un valore di prova. Un piano percentuale cerca di limitare la quantità di traffico che riceve un trattamento. Un segnale di test modifica il trattamento richiesto e può attivare una gestione speciale. Questi sono controlli diversi. Gli imprenditori dovrebbero decidere quali percorsi legittimi devono essere rappresentati nel confronto, quale impatto di fallimento è accettabile e quali prove consentirebbero il successivo cambiamento di politica.
Comprendere cosa richiede la specifica attuale
RFC 9989 Appendice A.6 spiega che il comportamento storico di pct era incoerente al di fuori dei suoi endpoint e che pct=0 aveva acquisito utili significati di gestione speciale. Il meccanismo aggiornato preserva un concetto di test piuttosto che una percentuale generale selettore. La versione del record rimane v=DMARC1; non è previsto il passaggio DNS a una stringa di versione denominata DMARC2.
Sotto sezione 4.7, t il valore predefinito è n. Con t=y, il trattamento dei messaggi di errore specificato è un livello inferiore rispetto alla policy selezionata: il rifiuto diventa quarantena e la quarantena diventa nessuno. Una policy selezionata di none non viene influenzata. Il segnale può anche richiedere una gestione speciale da parte dell'attore valutatore e non modifica la generazione dei report DMARC . Si tratta di una semantica specifica, non di una garanzia della cartella finale, della risposta di rifiuto o dell'esito della consegna a ogni destinatario.
Mantieni la policy p, sp o np selezionata nella valutazione. Il test non è limitato alla stringa di policy che un operatore vede per prima in una dashboard. Il dominio e il percorso di rilevamento determinano quale policy applicare. Una spiegazione corretta di t non può compensare un'indagine che ha controllato un dominio diverso dall'autore effettivo del messaggio.
Identificare il rischio di implementazione mista
Un destinatario che non riconosce t può ignorarlo e continuare a utilizzare la logica della policy supportata. Al contrario, un’implementazione della specifica aggiornata non ottiene una regola di implementazione percentuale da un vecchio valore pct. Un record contenere entrambi i tag non è quindi un modo portabile per richiedere un esperimento uniforme su tutti i ricevitori.
Tratta lo stato di implementazione come una proprietà misurata di un ambiente e una configurazione denominati. L'annuncio del fornitore, il formato del report o il logo del prodotto da soli non dimostrano come è stato elaborato un particolare messaggio. Laddove un ricevitore non possa essere ispezionato, preservare l'incertezza ed evitare di attribuire la sua azione finale esclusivamente a un tag. La gestione locale del destinatario rimane una fase separata RFC 9989 sezione 5.4.
Rivedi anche i presupposti nascosti del vecchio piano. La percentuale aveva lo scopo di limitare la perdita di posta legittima, valutare l'inoltro, stimare il volume degli errori o testare il servizio di reporting? Ogni scopo necessita di osservazioni diverse. Ridurre il trattamento per tutti i messaggi falliti non è la stessa cosa che applicare un trattamento più forte a un sottoinsieme selezionato, anche se entrambi i piani sono descritti informalmente come un’implementazione graduale.
Scrivi i criteri di accettazione prima di modificare DNS
Preparare un confronto mittente per mittente che includa volumi ridotti e percorsi legittimi periodici. Conservare l'esatto record corrente, la differenza proposta, le identità applicabili e i casi di messaggio rappresentativi. Registrare l'autenticazione ordinaria e allineamento risultati separatamente dalla politica selezionata, dallo stato di test, dalle sostituzioni locali e dalla disposizione finale. Definire le condizioni che impediscono l'implementazione, inclusa la mancanza di copertura o errori legittimi inspiegabili.
Utilizzare con attenzione le prove aggregate. RFC 9990 sezione 3.3 spiega che un periodo di riferimento può coincidere con cambiamenti politici e contenere osservazioni contrastanti. L'etichetta del giorno su un report non è la prova che una policy governasse ogni messaggio conteggiato. Conserva il periodo del report, la politica osservata e i tempi di implementazione anziché confrontare due percentuali senza etichetta.
La modifica proposta dovrebbe avere un proprietario responsabile e una base di riferimento recuperabile. La rimozione di pct da un piano legacy può rimuovere un vincolo utilizzato da un'implementazione precedente. L'aggiunta di t non dimostra che il vincolo sia stato sostituito lì. Un rollback modifica anche lo stato pubblicato anziché riscrivere istantaneamente tutte le osservazioni memorizzate nella cache, quindi le prove di recupero necessitano di tempi e ambito propri.
Esempio immaginario funzionante di una traduzione rifiutata
In questa recensione fittizia, Esempio di produzione ha un vecchio foglio di lavoro contenente p=reject e pct=10. Un redattore propone di sostituire la percentuale con t=y e di definire il risultato “lo stesso pilota del dieci per cento”. Il revisore rifiuta questa descrizione: la semantica di test attuale richiede la quarantena per i messaggi non riusciti in base a una politica di rifiuto selezionata, anziché selezionare il dieci per cento per il rifiuto.
La matrice proposta contiene una colonna di semantica corrente, una colonna di implementazione legacy e una colonna di osservazione. La prima può essere compilata a partire dal capitolato; le altre colonne richiedono implementazioni identificate e test autorizzati. Rimangono non eseguiti in questo esempio. Nessun record DNS è stato pubblicato, nessun destinatario interrogato o messaggio consegnato per l'esercizio.
La prossima decisione è quella di concordare l’esperimento vero e proprio, come testare la gestione specifica osservando flussi rappresentativi e legittimi, invece di preservare un’etichetta imprecisa. L'organizzazione deve quindi raccogliere le prove a supporto di tale esperimento prima di approvare una transizione di produzione.
Mantenere visibili i cancelli delle prove
L'esatto requisito originale rimane aperto: confrontare un vecchio piano basato su PCT con la semantica di test attuale e le osservazioni del ricevitore legacy/attuale. Il foglio di lavoro fittizio non fornisce osservazioni distribuite e non può soddisfare tale requisito. Anche la fase di messa in servizio rimane visibile: convalidare le specifiche primarie attuali e conservare un esempio pratico prima della stesura. Sono stati mantenuti il testo principale e un esercizio di fantasia pre-bozza; l’applicabilità dell’implementazione, l’approvazione delle PMI umane e qualsiasi rilascio operativo rimangono irrisolti. Nessuna pubblicazione o modifica della politica è autorizzata da questo manoscritto.