Skriv akseptkontrakten
Et proof of concept bør svare på et konkret operasjonelt spørsmål, for eksempel om den foreslåtte arbeidsflyten kan skille ut justert e-post, ujusterte legitime tjenester og uløste kilder samtidig som bevis bevares. Definer testet populasjon, tillatte handlinger, inndataversjon og ansvarlig operatør. Sett suksesskriterier før demonstrasjonen, inkludert hvordan ufullstendige observasjoner og avbrutte oppgaver telles.
Ikke la en leverandør velge kun gunstige tilfeller etter å ha sett resultater. Frys en liten representativ pakke og behold en tilbakeholdt negativ kontroll hvis det er aktuelt. Spesifiser om målet er dokumentargjennomgang, lokal simulering eller utførelse i en autorisert leietaker. Hver modus beviser forskjellige ting. Mangel på leietakertilgang er en begrensning av utførelsesbevis, ikke en automatisk svikt i en dokumentert funksjon.
Mål hele arbeidsflyten
Registrer forventet tolkning, observert tolkning, beviseksport og operatørinnsats separat. En korrekt autentiseringsetikett fullfører ikke en undersøkelse hvis eieren av avsenderen forblir ukjent. Tid brukt på å rense innganger, be om tilgang eller korrigere en import bør inkluderes i en operasjonell arbeidsbelastningsmåling i stedet for å fjernes som oppsettstøy uten forklaring.
En nyttig foreslått godkjenningspakke inkluderer én fastsatt justert identitet, én ujustert sak om legitim tjeneste og én sak med utilstrekkelig identitetsbevis. Behold den siste saken som ukjent. Bevisst ommerking av den som justert må mislykkes i evalueringen selv om eksporten fortsatt åpner. Dette er en foreslått negativ kontroll, ikke en observert produktsvikt.
Lukk med en ansvarlig beslutning
For hvert mislykkede kriterium må du registrere om problemet er en produktdefekt, ikke-støttet funksjon, testdesignfeil eller manglende tilgang. Tillat en korrigert omkjøring under en ny versjon uten å slette det første resultatet. Hvis kriteriene endres, forklar hvorfor og kjør berørte saker på nytt; ikke flytt porten bare for å oppnå en gunstig poengsum.
Sett et utgangsmøte som gjennomgår rå bevis, uløste risikoer, beholdt intern innsats og endre autoritet. Avgjørelsen kan være å fortsette, fortsette innenfor et smalere omfang, forlenge en spesifikk test eller stoppe. RFC 9989 og RFC 9990 gi grunnlag for protokoll og rapportering, men definer ikke en terskel for kjøpsgodkjenning. Tersklene i denne veiledningen er foreslåtte evalueringskontroller. En bestått simulering kan ikke autorisere produksjons- DNS endringer eller etablere levering, lovlig overholdelse eller garantert innboksplassering.
Bruk en eksplisitt godkjenningsbok
For hver sakspostversjon, forventet etikett, observert etikett, neste bevisforespørsel, nødvendig eier, endre tillatelse og eksportsted. En korrekt ukjent etikett paret med en automatisk DNS endring oppfyller fortsatt ikke autorisasjonskriteriet. En eksport som dropper den ukjente raden mislykkes med bevisbevaring. En manglende leietakerforbindelse lar dette utførelseskriteriet være uprøvd, ikke bestått eller diagnostisert som en produktfeil.
Anta at alle klassifiseringskontroller består, men den eksporterte filen utelater inndatareferansene. Hold bevis-eksportkriteriet, behold den første kjøringen og test den korrigerte versjonen på nytt. Ikke snitt bort den mislykkede obligatoriske porten med høy presentasjonsscore. Akseptkontrakten må identifisere hvilke kriterier som er obligatoriske og hvilke som tillater et omfangsrikt unntak. Ingen lokal arbeidsflyt, leietakerprøve eller mutert utførelse ble kjørt for dette skriftlige eksemplet.
Protokollomfang og evalueringsgrenser
RFC 9989 avsnitt 4.4, 5.3.5 og 5.4 skille autentiserte identifikatorer, justering og mottakerhåndtering. En gyldig signatur alene er ikke en fullstendig DMARC dom, og et pass validerer ikke forretningsinnhold. RFC 9990 seksjoner 3.1, 3.5.1, 3.5.4 og 7 beskrive samlet bevis, rapportidentitet, duplikater og personvern. Foreslått kommersiell evaluering, bemanning og autoritetsporter her er redaksjonelle anbefalinger, ikke RFC-pålagte produktfunksjoner. Ingen fraværende kjørbare tillegg er nødvendig for å lese disse skriftlige eksemplene; driftskrav krever separat autoriserte observerte tester.