Scrivere il contratto di accettazione
Una prova di concetto dovrebbe rispondere a una domanda operativa concreta, ad esempio se il flusso di lavoro proposto può distinguere la posta allineata, i servizi legittimi non allineati e le fonti irrisolte preservando le prove. Definire la popolazione testata, le azioni consentite, la versione di input e l'operatore responsabile. Stabilisci i criteri di successo prima della dimostrazione, compreso il modo in cui vengono conteggiate le osservazioni incomplete e le attività interrotte.
Non lasciare che un fornitore selezioni solo i casi favorevoli dopo aver visto i risultati. Congelare una piccola confezione rappresentativa e conservare un controllo negativo trattenuto, se appropriato. Specificare se l'obiettivo è la revisione documentale, la simulazione locale o l'esecuzione all'interno di un locatario autorizzato. Ogni modalità dimostra cose diverse. La mancanza di accesso del tenant è una limitazione delle prove di esecuzione, non un fallimento automatico di una funzionalità documentata.
Misura l'intero flusso di lavoro
Registrare separatamente l'interpretazione prevista, l'interpretazione osservata, l'esportazione delle prove e lo sforzo dell'operatore. Un'etichetta di autenticazione corretta non completa un'indagine se il proprietario del mittente rimane sconosciuto. Il tempo impiegato per pulire gli input, richiedere l'accesso o correggere un'importazione dovrebbe essere incluso in una misurazione del carico di lavoro operativo anziché rimosso come rumore di configurazione senza spiegazione.
Un utile pacchetto di accettazione proposto include un'identità allineata stipulata, un caso di servizio legittimo non allineato e un caso con prove di identità insufficienti. Conserva l'ultimo caso come sconosciuto. Rietichettarlo deliberatamente come allineato deve fallire la valutazione anche se l'esportazione è ancora aperta. Si tratta di una proposta di controllo negativo, non di un guasto osservato del prodotto.
Concludere con una decisione responsabile
Per ogni criterio non superato, registrare se il problema è un difetto del prodotto, una funzionalità non supportata, un errore di progettazione del test o un accesso mancante. Consenti una riesecuzione corretta in una nuova versione senza eliminare il primo risultato. Se i criteri cambiano, spiegare il motivo e rieseguire i casi interessati; non muovere il cancello solo per ottenere un punteggio favorevole.
Organizza una riunione di uscita che esamini le prove grezze, i rischi irrisolti, l'impegno interno mantenuto e l'autorità del cambiamento. La decisione può essere procedere, procedere in un ambito più ristretto, estendere un test specifico o interromperlo. RFC 9989 E RFC 9990 fornire protocolli e basi di reporting, ma non definire una soglia di accettazione degli acquisti. Le soglie presenti in questa guida rappresentano i controlli di valutazione proposti. Una simulazione di successo non può autorizzare modifiche DNS di produzione o stabilire la consegna, la conformità legale o il posizionamento garantito della casella di posta.
Utilizzare un registro di accettazione esplicita
Per ogni caso, registra la versione di input, l'etichetta prevista, l'etichetta osservata, la richiesta di prova successiva, il proprietario richiesto, l'autorizzazione di modifica e la posizione di esportazione. Un'etichetta sconosciuta corretta abbinata a una modifica DNS automatica non soddisfa ancora il criterio di autorità. Un'esportazione che elimina la riga sconosciuta non riesce a conservare le prove. Una connessione tenant mancante lascia il criterio di esecuzione non testato, non superato o diagnosticato come difetto del prodotto.
Supponiamo che tutti i controlli di classificazione vengano superati ma che il file esportato ometta i riferimenti di input. Mantieni il criterio di esportazione delle prove, conserva la prima esecuzione e riprova la versione corretta. Non calcolare la media del cancello obbligatorio fallito con un punteggio di presentazione elevato. Il contratto di accettazione deve identificare quali criteri sono obbligatori e quali consentono un'eccezione mirata. Per questo esempio scritto non è stato eseguito alcun flusso di lavoro locale, prova del tenant o esecuzione modificata.
Scopo del protocollo e limiti di valutazione
RFC 9989 Sezioni 4.4, 5.3.5 e 5.4 distinguere gli identificatori autenticati, allineamento e gestione del ricevitore. Una firma valida da sola non è completa DMARC verdetto e un passaggio non convalida il contenuto aziendale. RFC 9990 Sezioni 3.1, 3.5.1, 3.5.4 e 7 descrivere prove aggregate, segnalare identità, duplicati e privacy. La valutazione commerciale proposta, il personale e i limiti di autorità qui sono raccomandazioni editoriali, non caratteristiche del prodotto imposte dalla RFC. Per leggere questi esempi scritti non è richiesto alcun supplemento eseguibile assente; le affermazioni operative richiedono test osservati autorizzati separatamente.