En resultatetikett er ikke en diagnose
Permerror indikerer en permanent feil i SPF evaluering, men den identifiserer ikke en unik defekt. En feilaktig valgt policy, flere gjelder SPF poster, en manglende rekursiv policy eller en overskredet evalueringsgrense kan gi dette resultatet gjennom forskjellige regler. Et støttesvar som oversetter hver permerror til "for mange DNS oppslag" kan sende en administrator til feil reparasjon og potensielt skade gyldig avsenderautorisasjon.
Start med å ta vare på identiteten og inndataene som brukes til evaluering. Registrer tilkoblingsadressen, HELO eller POST FRA kontekst, evaluert domene, avsenderargument og tid. Bevar deretter det faktiske DNS svaret og den valgte SPF policyen. Uten disse inndataene kan to forskjellige rapporter omhandle forskjellige identiteter eller forskjellige øyeblikksbilder i stedet for å være uenige om den samme policyen. RFC 7208 , avsnitt 2.3, 2.4 og 8.7
Sjekk postvalg og syntaks først
SPF -policyvalg har spesifikke regler. Flere valgte SPF poster forårsaker permerror ; de er ikke slått sammen til en større policy og bør ikke behandles som en praktisk måte å dele leverandører på. TXT tegnstrenger i én post er en annen sak enn flere uavhengige poster. Behold postgrenser slik at anmelderen kan skille en presentasjonsdetalj fra et reelt utvalgsproblem.
Syntaks trenger også en fullstendig gjennomgang av retningslinjer. RFC 7208 krever syntakssjekk før mekanismeevaluering; en ugyldig mekanisme kan derfor ha betydning selv om noen forventer at en tidligere mekanisme skal matche. Ukjente mekanismer og ignorerte ukjente modifikatorer er ikke utskiftbare kategorier. Unngå vag veiledning for å slette alle ukjente tokener. Bestem dens grammatiske rolle og standardens håndtering før du avgjør om det er en feil. RFC 7208 , avsnitt 3.2, 4.5, 4.6 og 6
Deretter klassifiser evaluering-budsjettfeil
For det overordnede DNS-forårsakende tidsbudsjettet, inkluderer, a, mx, ptr, exists og omdirigeringstall under evaluering. Grensen er ti, og overskridelse av den må gi permerror . Dette er ikke bare antall DNS pakker, antall inkluderte toppnivåer eller antall unike leverandører. Recursion deler budsjettet, og bufring fjerner ikke logisk evaluerte termer.
Andre grenser trenger egne etiketter. Ugyldige svar har en BØR-nivågrense på to, med tillatt konfigurasjon og en anbefalt standard på to når de kan konfigureres; overskridelse av gjeldende grense gir permerror . MX -behandling har ytterligere obligatoriske begrensninger. En uttalelse om at "posten har bare ni inkluderer" utelukker ikke disse andre årsakene, og et høyt antall råpakker beviser ikke i seg selv at den totale ti-term grensen ble overskredet. RFC 7208 , avsnitt 4.6.4
Skill feilresultater fra autorisasjonsresultater
Fail hevder at klienten ikke er autorisert for den evaluerte identiteten. Permerror betyr at evalueringen ikke kunne gi det tiltenkte autorisasjonsresultatet på grunn av en permanent feil. Temperror representerer en forbigående feil. Ingen er også et distinkt resultat, med spesiell tilordning når de oppdages gjennom inkludere eller omdirigere. Disse etikettene skal ikke skjules i en enkelt " SPF mislyktes"-bøtte når de forklarer en korrigerende handling.
Mottakeren bestemmer fortsatt hvordan resultatene skal håndteres under sin egen policy. En avvist melding fastslår ikke hvilken SPF defekt som forårsaket avvisning med mindre bevisene støtter den koblingen. På samme måte beviser ikke akseptert e-post at policyen var gyldig. Oppbevar autentiseringsdiagnosen og leveringsdisponeringen i separate felt, og unngå å love at én DNS reparasjon vil fikse alle leveringsproblemer. RFC 7208 , avsnitt 5.2, 6.1 og 8
Triage-regneark med eksplisitte stoppgrunner
Bruk et regneark delt inn i utvalg, parsing og evaluering. I valget beholder du søkenavnet, svaret, TXT post grenser og antall utvalgte SPF poster. Ved parsing, behold den eksakte sammenkjedede postteksten, parserversjonen, støtende token hvis noen og regelen er brutt. Ikke normaliser bort feilen før du tar vare på det originale beviset.
I evalueringen registrerer du hver nådd mekanisme eller modifikator, gjeldende domene, utvidet mål, kumulativ termintelling, responsklassifisering, rekursivt underordnet resultat og fortsettelsesbeslutning. Hold ugyldige totaler og tilleggsgrenser adskilt. Merk den første støttede stoppårsaken. Hvis parseren avviste policyen før evaluering, ikke oppfinn en bane som evaluatoren aldri utførte bare for å demonstrere et annet mulig problem.
En foreslått retting bør navngi feilen den adresserer, eieren som bekrefter den tiltenkte autorisasjonen, og rutene som fortsatt må fungere. Registrer uløste sekundære funn separat. En misformet policy kan også inneholde en graf for overdreven avhengighet, men etterforskeren bør forklare hvilken konklusjon som er observert og som forblir en statisk bekymring i påvente av gyldig evaluering.
Fiktiv diagnose: to identiske etiketter, forskjellige reparasjoner
I fiktivt tilfelle A publiserer et domene to separate TXT poster som begge kvalifiserer som SPF policyer. Den nyttige diagnosen er en postvalgsfeil, ikke et for stort oppslagstall. En foreslått reparasjon vil kreve å forene den tiltenkte autorisasjonen i én støttet policy, etter å ha bekreftet alle legitime ruter. Sletting av en vilkårlig post kan fjerne en nødvendig tjeneste stille. Ingen reelle DNS -svar eller rettelser ble samlet inn for denne saken.
I fiktivt tilfelle B følger en syntaktisk gyldig policy en nestet rute som forsøker en ellevte talt DNS-forårsakende term før en kamp. Den nyttige diagnosen er overskredet totalbudsjett. Å kombinere TXT strenger vil ikke løse det problemet fordi policyen allerede er én valgt post. Gjennomgangen trenger i stedet den eksakte avhengighetsbanen og et støttet redesign som bevarer avsenderdekning.
En tredje fiktiv rapport sier bare " permerror " og inneholder ingen rekordbilde eller spor. Det riktige resultatet er utilstrekkelig bevis, ikke en gjetning mellom A og B. Be om en minimal diagnosepakke gjennom en autorisert kanal, med privat meldingsinnhold og unødvendige adresser ekskludert. Disse scenariene er konseptuelle sammenligninger, ikke utførte inventar, mottakerresultater eller bevis på at en navngitt leverandør er feilkonfigurert.
Aksept- og utgivelseskriterier
Et reparasjonskrav bør være smalere enn « SPF er løst». Oppgi om postvalg, syntaks, en bestemt evalueringsbane eller en spesifikk leverandøravhengighet ble korrigert og hvilke bevis som støtter den påstanden. Bekreft at den foreslåtte endringen ikke autoriserer utilsiktede avsendere eller ekskluderer legitime avsendere. Hold mottakerens endelige leveringsresultat utenfor kravet med mindre det observeres separat.
For dette utkastet forblir den påkrevde kommenterte banen som viser hver talte term og den eksakte feilende grenen utestående. Hvis det faktiske problemet er analysering eller utvelgelse, må du beholde det primære beviset også og få en menneskelig vurdering av hvordan det tilfredsstiller artikkelens tiltenkte omfang. Ikke lag en evaluert bane for en feil som stopper før mekanismer er behandlet.
Ingen skanninger, parser-kjøringer, DNS modifikasjoner eller meldingstester ble utført her. Originale bevis, menneskelig gjennomgang, kildeanvendbarhet, produksjonsruter, visuell tilgjengelighet og eierutgivelse forblir åpne. Manuskriptet gir et triage-rammeverk og fiktive resonnementeksempler, mens det eksplisitt tilbakeholder enhver påstand om en fullført operasjonsdiagnose.