Vurder en bane, ikke en dekorativ oppslagsscore
SPF Evalueringen avhenger av den koblede IP-adressen, den relevante SMTP identiteten og DNS tilstanden som oppstår langs den evaluerte banen. En kontrollør som viser bare et statisk antall synlige inkluderer-termer, kan gå glipp av nestede avhengigheter, tidlige treff, feil og omdirigeringsatferd. Et nyttig utdata bør vise inputene, den bestilte evalueringen og årsaken til resultatet samtidig som den skiller en observert kjøring fra en hypotetisk worst-case-analyse.
RFC 7208 definerer SPF og dens check_host-evaluering. Denne artikkelen foreslår brikkekrav og defensive kamper. Den hevder ikke at EmailAuth implementerer dem eller at noen reell avsender ble testet. Ingen brukerdomene DNS spørringer, SMTP tilkoblinger eller testmeldinger ble utført. Den beholdte standarden er dokumentasjon, ikke en henrettelsesutskrift.
Registrer identiteten og tilkoblingsinngangene
Regnearket skal identifisere IP-adressen, domene- og senderinndataene som ble levert til evalueringen, med SMTP konteksten som er nødvendig for å tolke dem. SPF vurderer det aktuelle POST FRA identitet og har spesifisert HELO oppførsel, inkludert null omvendt bane-tilfelle. Den autentiserer ikke direkte det menneskelesbare visningsnavnet eller beviser at innholdet i en melding er legitimt. Hold disse grensene synlige før du tolker pass som et bredere tillitssignal.
RFC 9989 legger til en justering forhold til det synlige Fra-domenet når SPF bidrar til DMARC. En vellykket SPF -evaluering for et annet domene er ikke automatisk et justert DMARC pass. Kontrolløren bør bevare den faktiske evaluerte identiteten slik at nedstrømsanalyse kan vurdere forholdet uten å gjette. Ingen eksempler på mottatt melding er tilgjengelig i dette manuskriptet for å etablere et faktisk justeringsresultat.
Vis ordnede mekanismer og avhengighetsresultater
RFC 7208 evaluerer mekanismer i rekkefølge, med resultatet avhengig av kamper og feil. En tidlig match kan bety at senere mekanismer ikke blir evaluert for det innspillet. Kontrolløren bør derfor vise hvilke vilkår som ble nådd, hvilke som ikke ble nådd og hvorfor behandlingen ble avsluttet. Hvis den også beregner en avhengighetsbeholdning eller mulig bane som ikke samsvarer, merk det som en annen analyse i stedet for å presentere den som den utførte banen.
En inkludering er ikke bare tekst limt inn i den overordnede posten. Dens refererte evaluering har definert resultathåndtering: et referert pass gir en match for inkluderingen, mens andre resultater følger standardens kartlegging. Omdirigering er en modifikator som evalueres under sine egne regler etter at ingen mekanisme samsvarer, og alle mekanismer fører til at omdirigering ignoreres. Disse forskjellene betyr noe når man forklarer hvorfor to overfladisk like poster oppfører seg forskjellig.
Bruk ti-terminsgrensen nøyaktig
Avsnitt 4.6.4 begrenser det totale antallet evaluerte DNS-spørring-forårsakende termer til ti: include, a, mx, ptr, exists and redirect er de listede mekanismene eller modifikatoren. Overskridelse av denne grensen krever permerror. Alle-, ip4- og ip6-mekanismene og exp-modifikatoren er ikke underlagt den samme grensen; exp kan forårsake et senere oppslag. Grensen er ikke et enkelt maksimalt antall TXT poster eller rå DNS pakker observert på ledningen.
Nestede evalueringer bidrar til det relevante samlede evalueringsbudsjettet. Ytterligere grenser gjelder for adresseoppslag knyttet til mx- og ptr-behandling, med ulik foreskrevet håndtering. En kontrollør bør implementere og rapportere disse detaljene i stedet for å flate dem ut til et ukvalifisert ti DNS -spørringsslagord. Den bør også skille mellom bufret oppløsningsaktivitet fra de logiske termene som er evaluert: færre nettverkspakker tillater ikke å ignorere protokollens evalueringsgrenser.
Skille ugyldige svar fra midlertidige feil
RFC 7208 beskriver ugyldige oppslag som positive DNS svar uten svar eller navnefeilsvar. Implementeringer bør begrense disse til to, kan gjøre grensen konfigurerbar, og anbefales å standard til to når den kan konfigureres. Overskridelse av gjeldende tomromsgrense gir permerror . Dette er en anbefaling på BØR-nivå med konfigurerbar atferd, ikke en universell påstand om at hver implementering alltid håndhever en identisk fast grense.
En DNS tidsavbrudd eller serverfeil er ikke bare et annet ugyldig svar. De relevante SPF feilreglene kan produsere temperror, mens permanente evalueringsproblemer produserer permerror . Registrer det faktiske DNS -svaret eller feilen og regelen som brukes til å tolke den. Ikke gjør en utilgjengelig avhengighet til en gjettet ikke-match eller en ren pasning. Kontrolløren bør avsløre usikkerhet og bevare nok bevis til å gjengi skillet senere.
Representer sykluser og misdannede poster ærlig
Sykliske avhengigheter kan gjentatte ganger forbruke evalueringsressurser og nå definerte grenser; de skal ikke representeres som en ufarlig deduplisert graf som garanterer et vellykket resultat. En kontrollør kan oppdage og forklare en syklus, men dens rapporterte protokollutfall må samsvare med den implementerte standarden og input. Behold kjeden av refererte navn og punktet der behandlingen stoppet uten å utføre ukontrollerte forsøk.
Registrer valg og syntaksmateriale før baneevaluering. Flere SPF poster på samme identitet er ikke en gyldig måte å slå sammen avsendere og produsere permerror under standarden. Ukjente mekanismer og ukjente modifikatorer har ulik behandling; en ukjent mekanisme ignoreres ikke trygt bare fordi ukjente modifikatorer kan ignoreres. Testplanen bør dekke disse distinksjonene i stedet for å behandle hvert element som ikke støttes som én generisk advarsel.
Et regneark for avhengighetsbane
Lag et regneark med evalueringsinnganger, implementeringsversjon, DNS observasjonstider, valgt SPF post, bestilte termer, nestede avhengigheter, terminbudsjett og ugyldig antall. For hvert trinn, registrer responsstatus, samsvar eller ikke samsvar, feiltilordning og stoppårsak. Legg til en egen kolonne for ikke-evaluerte avhengigheter slik at leseren kan skille faktiske banebevis fra inventar. Bevar resolverkonteksten og eventuelle konfigurerbare grenser.
Foreslåtte inventar bør inkludere en representativ matchende bane, en ikke-matchende bane som når senere avhengigheter, en syklus, ugyldige svar og utilgjengelig DNS . Bruk kontrollerte syntetiske DNS -armaturer i stedet for å spørre etter en kundes infrastruktur uten autorisasjon. Forventede resultater bør sitere den relevante standarddelen og identifisere implementeringskonfigurerbar atferd. Ingen inventar ble kjørt her, så regnearket inneholder krav i stedet for fabrikkerte transkripsjoner.
Fiktiv diagnose: en kort journal med lang vei
En fiktiv operatør ser bare noen få inkludere termer i en post på toppnivå og antar at oppslagsbudsjettet er trygt. En foreslått kampgjennomgang avslører at hvert begrep kan føre til ytterligere avhengighet av den ikke-matchende banen. En annen inndata kan matche tidlig og aldri nå disse senere termene. De to banene kan derfor bruke ulike logiske budsjetter selv om den publiserte toppnivåteksten er identisk.
Teamet vil beholde de faktiske evalueringsinndataene og banen før de anbefaler en endring. Det ville ikke blindt flate leverandørposter ut til statiske IP-områder, fordi det kan flytte oppdateringsansvaret og bli foreldet. Dette scenariet er fiktivt: ingen leverandøravhengighet, adresseområde eller reell post ble forespurt eller endret. Det illustrerer hvorfor en kontrollør må forklare banen i stedet for å vise bare et antall.
Hold konklusjonen begrenset
Et nyttig resultat sier hvilken identitet og IP som ble evaluert, under hvilken DNS tilstand og implementeringsatferd, og hvorfor resultatet oppsto. Det lover ikke at hver avsender vil bestå eller at et pass etablerer forretningslegitimitet. En avhengighetsbeholdning er verdifull, men den må ikke forveksles med en utført SPF evaluering.
Katalogen krever representative samsvarende, ikke-samsvarende, sykliske, ugyldige og utilgjengelige DNS-saker. De originale kampene og resultatene forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet gir en foreslått bevismodell, ikke utførte skanninger eller verifisert verktøyadferd.