Når to SPF brikker viser forskellige opslagstal, vælg ikke det mere betryggende tal. Bestem, hvad hvert værktøj målte. En kan vise DNS-afhængige termer på en evalueret sti, en anden kan udvide en politikgraf, og en tredje kan vise netværksforespørgsler. Disse output kan besvare forskellige spørgsmål, selv når de inspicerer det samme domæne.
Spørg hvad tælleren betyder
RFC 7208 afsnit 4.6.4 begrænser evaluerede DNS-afhængige termer på tværs af rekursion. Det er ikke blot antallet af alle TXT strenge, hver DNS pakke eller antallet af inkluderer synligt skrevet på øverste niveau. Cachede svar giver ikke et større logisk terminsbudget.
Adskil andre begrænsninger også. Specifikationen adresser ugyldige opslag og mekanismespecifikke grænser ud over det primære evaluerede periodeloft. Et værktøj kan præsentere én kombineret advarsel, mens et andet afslører hver kategori. Gem den nøjagtige advarselstekst og dokumentation i stedet for at antage, at hver rød etiket betyder det samme.
Giv begge værktøjer det samme armatur
Registrer det evaluerede domæne, forbindelses-IP, afsenderidentitet, HELO hvor det er relevant, resolvervisning og forespørgselstid. Hvis værktøjet kun accepterer et domæne, skal du finde ud af, om dets antal er et statisk estimat, en worst-case-analyse eller en bestemt syntetisk sti. En domænescanning svarer ikke automatisk til at evaluere en rigtig forbindelse.
For politikker, der bruger makroer, kan de manglende identitetsinputs have direkte betydning. Sammenlign IPv4 og IPv6 tilfælde separat, når begge opstår. Bevar DNS svarene eller en reproducerbar kontrolleret armatur, så et senere udbyderskifte ikke gør en formodet værktøjssammenligning til en sammenligning af forskellige politikker.
Gå et lille illustrativt eksempel
Overvej en syntetisk politik:
v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all
Under RFC 7208 §4.6.2 og RFC 7208 §5.6, for 192.0.2.10 kan den eksplicitte adresse matche, før inkluderingen evalueres. For en anden adresse kan evaluering nå inkluderet og dets indlejrede afhængigheder. Et grafudvidelsesværktøj kan vise den gren, selv når den første meddelelses sti aldrig når den. De forskellige tal skal forklares, ikke en automatisk dom om, at begge værktøjer er defekte.
Gør inkludere-målet eksplicit for at sammenligne numeriske tællinger. I dette syntetiske armatur, _spf.vendor.example har præcis én SPF TXT post, v=spf1 ip4:192.0.2.20 -all. Antag vellykket DNS hentning, gyldig syntaks, ingen yderligere afhængigheder og alm MAIL FRA evaluering for det overordnede domæne.
- Input 192.0.2.10 : forældrenes første ip4-mekanisme matcher. Den faktiske sti evaluerer 0 DNS-afhængige termer og besøger aldrig include.
- Input 192.0.2.20 : forældrenes ip4 stemmer ikke overens. Inkluderingen evalueres, dens mål-ip4 matcher, og forælderen returnerer bestået. Den faktiske sti evaluerer 1 DNS-afhængig term, inklusive.
- Input 192.0.2.30 : Inkluderingsmålet når -all og returnerer mislykkes, så inkluderingen stemmer ikke overens. Forælderen når sit eget -all og returnerer fejler. Den faktiske sti evaluerer stadig 1 DNS-afhængig term, i overensstemmelse med RFC 7208 §5.2.
Et statisk grafantal af DNS-afhængige termer er 1 for hele denne opstilling, uanset hvilken forbindelse der er valgt. Den første TXT hentning af den overordnede politik er påkrævet, men er ikke i sig selv en af de evaluerede vilkår, der tælles med i denne grænse. Således kan en visning på 0 for det første input og 1 for den udvidede graf begge forklares. Disse er analytiske forventede resultater, ikke udførte målinger eller netværkspakketællinger.
Forestil dig nu, at den inkluderede politik ændres mellem de to scanninger. En ny scanning kunne legitimt afsløre et andet afhængighedstræ. Gem tidsstempler og faktiske svar, før du eskalerer uenigheden. Et skærmbillede uden input er et svagt bevis.
Sammenlign spor ved den første divergens
Opbyg en side om side liste over de evaluerede termer. Find det første sted, hvor værktøjerne er uenige: registreringsvalg, et tidligt match, rekursion, en DNS fejl, en makroudvidelse eller en tællekonvention. Kontroller, om den ene stopper ved en fejl, mens den anden fortsætter til diagnostiske formål. En diagnostisk udvidelse kan være nyttig uden at repræsentere en gyldig gennemført evaluering.
Hvis et værktøj ser ud til at modsige standarden, skal du fremstille en minimal syntetisk armatur og den forventede adfærd med en sektionsreference. Send det til værktøjsvedligeholderen gennem din normale supportproces, og undgå fortrolige produktionsdata, hvor en armatur gør det. Ændre ikke produktionen bare for at få inkonsekvente dashboards til at stemme overens.
Træf en beslutning ud fra de opgjorte beviser
En gyldig kort vej for én afsender etablerer ikke helbred for hver afsender. Test repræsentative legitime input og et ikke-matchende input, og inspicér de afhængigheder, der kan ændre sig senere. Omvendt er en stor statisk graf ikke i sig selv et bevis på, at hver meddelelse overskrider den evaluerede tidsgrænse.
Registrer, hvilken måling der understøtter din beslutning, enhver uløst værktøjsbegrænsning og den forventede effekt af en foreslået ændring. Bruge mekanisme bestilling først efter at have forstået disse veje. Hvis du ikke kan afstemme en følgelig uoverensstemmelse, skal du beholde den aktuelle dokumentation og søge en implementeringsspecifik gennemgang i stedet for at præsentere en uforklarlig opgørelse som sikkerhed.
Skriv beslutningen på skrift
For den givne to-record-opstilling skal du beholde den overordnede og underordnede tekst, indtastningsadresse, tælledefinition og forventet bestået/ikke bestået. 0/1/1-værdierne er analytiske evaluerede terminstællinger, ikke målte DNS pakker eller uafhængig værktøjsudførelse. Hvis et værktøj rapporterer en anden mængde, skal du mærke det før sammenligning. En uoverensstemmelse i en fejlhåndteringssti har brug for sin egen fixtur frem for ekstrapolering fra disse vellykkede opslag.