Et resultatmærke er ikke en diagnose
Permerror indikerer en permanent fejl i SPF evaluering, men den identificerer ikke en unik defekt. En forkert udvalgt politik, flere gældende SPF optager, en manglende rekursiv politik eller en overskredet evalueringsgrænse kan give dette resultat gennem forskellige regler. Et supportsvar, der oversætter enhver permerror til "for mange DNS opslag", kan sende en administrator til den forkerte reparation og potentielt beskadige gyldig afsenderautorisation.
Start med at bevare identiteten og input, der bruges til evaluering. Optag tilslutningsadressen, HELO eller MAIL FRA kontekst, vurderet domæne, afsenderargument og tid. Bevar derefter det faktiske DNS svar og den valgte SPF politik. Uden disse input kan to forskellige rapporter omhandle forskellige identiteter eller forskellige øjebliksbilleder i stedet for at være uenige om den samme politik. RFC 7208 , afsnit 2.3, 2.4 og 8.7
Tjek først postvalg og syntaks
SPF politikvalg har specifikke regler. Flere udvalgte SPF poster forårsager permerror ; de er ikke slået sammen til en større politik og bør ikke behandles som en bekvem måde at opdele leverandører på. TXT tegnstrenge i én post er en anden sag end flere uafhængige poster. Bevar registreringsgrænser, så anmelderen kan skelne en præsentationsdetalje fra et reelt udvælgelsesproblem.
Syntaks skal også gennemgås fuldstændigt. RFC 7208 kræver syntakskontrol før mekanismeevaluering; en ugyldig mekanisme kan derfor have betydning, selvom nogen forventer, at en tidligere mekanisme matcher. Ikke-genkendte mekanismer og ignorerede ikke-genkendte modifikatorer er ikke udskiftelige kategorier. Undgå vag vejledning for at slette alle ukendte tokens. Bestem dens grammatiske rolle og standardens håndtering, før du beslutter, om det er en fejl. RFC 7208 , afsnit 3.2, 4.5, 4.6 og 6
Klassificer derefter evaluerings-budgetfejl
For det overordnede DNS-forårsagende-term-budget, inkluderer, a, mx, ptr, eksisterer og omdirigere tæller under evaluering. Grænsen er ti, og overskridelse af den skal producere permerror . Dette er ikke blot antallet af DNS pakker, antallet af inkluderede topniveauer eller antallet af unikke leverandører. Recursion deler budgettet, og caching fjerner ikke logisk evaluerede termer.
Andre grænser har brug for deres egne etiketter. Ugyldige svar har en BØR-niveaugrænse på to, med tilladt konfiguration og en anbefalet standard på to, når de kan konfigureres; overskridelse af den gældende grænse giver permerror . MX -behandling har yderligere obligatoriske begrænsninger. En erklæring om, at "posten kun har ni inkluderer" udelukker ikke disse andre årsager, og et højt antal råpakker beviser ikke i sig selv, at den samlede ti-term grænse blev overskredet. RFC 7208 , afsnit 4.6.4
Adskil fejlresultater fra autorisationsresultater
Fail hævder, at klienten ikke er autoriseret til den vurderede identitet. Permerror betyder, at evalueringen ikke kunne give det tilsigtede godkendelsesresultat på grund af en permanent fejl. Temperror repræsenterer en forbigående fejl. Ingen er også et distinkt resultat, med speciel kortlægning, når det stødes på gennem inkludere eller omdirigere. Disse etiketter bør ikke klappes sammen i en enkelt " SPF mislykket"-spand, når en korrigerende handling forklares.
Modtageren bestemmer stadig, hvordan resultaterne skal håndteres i henhold til sin egen politik. En afvist meddelelse fastslår ikke, hvilken SPF defekt der forårsagede afvisningen, medmindre beviset understøtter dette link. På samme måde beviser accepteret post ikke, at politikken var gyldig. Opbevar godkendelsesdiagnosen og leveringsdispositionen i separate felter, og undgå at love, at én DNS reparation vil løse alle leveringsproblemer. RFC 7208 , afsnit 5.2, 6.1 og 8
Triage regneark med eksplicitte stopårsager
Brug et regneark opdelt i udvælgelse, parsing og evaluering. Ved udvælgelse skal du beholde forespørgselsnavnet, svaret, TXT post grænser og antal af udvalgte SPF poster. Ved parsing skal du beholde den nøjagtige sammenkædede posttekst, parserversion, eventuelt stødende token og reglen overtrådt. Normaliser ikke fejlen, før du har bevaret det originale bevis.
Ved evaluering skal du registrere hver nået mekanisme eller modifikator, nuværende domæne, udvidet mål, kumulativt termantal, svarklassifikation, rekursivt underordnet resultat og fortsættelsesbeslutning. Hold ugyldige totaler og supplerende grænser adskilt. Marker den første understøttede stopårsag. Hvis parseren afviste politikken før evaluering, skal du ikke opfinde en sti, som evaluatoren aldrig udførte, blot for at demonstrere et andet muligt problem.
En foreslået rettelse bør nævne den defekt, den adresserer, ejeren, der bekræfter den påtænkte tilladelse, og de ruter, der stadig skal fungere. Registrer uløste sekundære fund separat. En forkert udformet politik kan også indeholde en graf for overdreven afhængighed, men investigator bør forklare, hvilken konklusion der observeres, og hvilken forbliver en statisk bekymring, indtil en gyldig evaluering.
Fiktiv diagnose: to identiske etiketter, forskellige reparationer
I fiktivt tilfælde A udgiver et domæne to separate TXT poster, der begge kvalificerer som SPF politikker. Den nyttige diagnose er en registreringsudvælgelsesfejl, ikke et for stort opslagstal. En foreslået reparation vil kræve afstemning af den påtænkte autorisation i én understøttet politik efter bekræftelse af alle lovlige ruter. Sletning af en vilkårlig post kan fjerne en påkrævet tjeneste uden at være. Der blev ikke indsamlet noget reelt DNS svar eller korrektion for denne sag.
I fiktivt tilfælde B følger én syntaktisk gyldig politik en indlejret rute, der forsøger en ellevte talt DNS-forårsagende term før ethvert match. Den nyttige diagnose er det overskredet samlede budget. Kombination af TXT strenge ville ikke løse det problem, fordi politikken allerede er én valgt post. Anmeldelsen har i stedet brug for den nøjagtige afhængighedssti og et understøttet redesign, der bevarer afsenderdækningen.
En tredje fiktiv rapport siger kun " permerror " og indeholder ikke noget øjebliksbillede eller spor. Det korrekte resultat er utilstrækkelig evidens, ikke et gæt mellem A og B. Bed om et minimalt diagnostisk bundt gennem en autoriseret kanal, med privat beskedindhold og unødvendige adresser udelukket. Disse scenarier er konceptuelle sammenligninger, ikke udførte fixtures, modtagerresultater eller bevis på, at en navngiven udbyder er forkert konfigureret.
Accept- og frigivelseskriterier
Et reparationskrav skal være snævrere end " SPF er fast." Angiv, om postvalg, syntaks, en bestemt evalueringssti eller en specifik leverandørafhængighed blev korrigeret, og hvilke beviser der understøtter denne påstand. Bekræft, at den foreslåede ændring ikke autoriserer utilsigtede afsendere eller udelukker legitime afsendere. Hold modtagerens endelige leveringsresultat uden for kravet, medmindre det overholdes særskilt.
For dette udkast forbliver den påkrævede kommenterede sti, der viser hver talte term og den nøjagtige fejlende gren, udestående. Hvis det faktiske problem er parsing eller udvælgelse, skal du også beholde det primære bevis og få en menneskelig gennemgang af, hvordan det opfylder artiklens tilsigtede omfang. Fremstil ikke en evalueret sti for en fejl, der stopper, før mekanismer behandles.
Ingen scanninger, parser-udførelser, DNS ændringer eller meddelelsestests blev udført her. Originale beviser, menneskelig gennemgang, kildeanvendelighed, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver åbne. Manuskriptet giver en triageramme og fiktive ræsonnementeksempler, mens det eksplicit tilbageholder enhver påstand om en afsluttet operationsdiagnose.