Et velrenommeret domæne eller en delt afsendelsestjeneste kan blive en del af en misbrugssti. Det nyttige spørgsmål er ikke, om infrastrukturen generelt er troværdig. Det er, om denne særlige meddelelse var autoriseret til at bruge den autentificerede identitet. Autentificering og virksomhedsgodkendelse besvarer forskellige spørgsmål.
Definer den myndighed, der skal genbruges
En kompromitteret postkasse kan sende gennem sin almindelige godkendte rute. En alt for bred netværksautorisation kan indrømme en utilsigtet kilde. En stafet kan underskrive en besked efter at have accepteret den under en utilstrækkelig specifik adgangsregel. Disse mekanismer har forskellige ejere og midler. Lad være med at kollapse dem i én uforklarlig påstand om omdømmekapring.
Den oprindelige BreakSPF-forskning undersøger eftergivende SPF konfigurationer og fælles infrastruktur. Dens trusselsmodel gør adgang til kildenetværk til en central betingelse. Det er en indsættelsesgrænse, ikke bevis på, at en angriber kan forfalske nogen DKIM signatur. BreakSPF-papir, afsnit III. Behandl papirets målinger som historisk forskning, ikke en nuværende opgørelse over sårbare tjenester.
Byg en præcis trusselsmodel
Skriv det beskyttede domæne, den godkendte identifikator, tilladte kildesæt, angriberkapacitet og modtagerbeslutning separat. I det afgrænsede scenarie her godkender brand.test 192.0.2.0/24 for SPF . Den godkendte ansøgning bruger 192.0.2.10 , mens en hypotetisk utilsigtet lejer kan stamme fra 192.0.2.99 . Begge adresser ligger i det offentliggjorte område. Hvorvidt en sådan lejeradgang eksisterer i en reel tjeneste, kræver særskilt bevis.
SPF kontrollerer kildegodkendelse for sin evaluerede identitet. Den identificerer ikke mennesket bag en delt IP. Hvis den forbigående SPF identitet også stemmer overens med forfatterdomænet, kan den sti opfyldes DMARC uden DKIM. RFC 7208 og RFC 9989. En vellykket evaluering kan derfor afsløre, at der blev givet for meget autoritet, snarere end at en modtager ignorerer beståelsesreglen.
Sammenlign tre skriftlige autorisationssager
Antag synlig fra alerts@brand.test , ikke-tom MAIL FRA bounce@brand.test , ingen DKIM signatur og en ellers kvalificeret DMARC evaluering. Sammenlign hypotetisk SPF optager v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Godkendt kilde 192.0.2.10 : inkluderet af begge netværkspræfikser; SPF består og tilpasser sig brand.test, så den illustrative meddelelse består DMARC i begge tilfælde.
- Utilsigtet kilde 192.0.2.99 : inkluderet af /24 men ikke /32; SPF passerer kun under den brede rekord. Uden DKIM signatur er det angivne DMARC resultat bestået under /24 og ikke under /32.
- Ekstern kilde 198.51.100.10 : inkluderet af hverken præfiks; -all udbytter SPF fejler i begge tilfælde. Uden DKIM signatur er det angivne DMARC resultat mislykket i begge.
Disse er skrevet præfiks-medlemskab og justering fradrag, ikke en kørende SPF parser, DNS observation eller reproduktion af BreakSPF. Kildekontrol forudsættes, ikke demonstreret. Ingen ekstern besked eller live-tjeneste blev testet. Papirets tværprotokolteknik ligger uden for dette undervisningseksempel.
En enkelt passerende justeret mekanisme kan opfylde en meddelelses DMARC pass-betingelse. Det gør ikke SPF-only-implementering tilstrækkelig: RFC9989 afsnit 7.4 kræver gyldig DKIM til domæneudgivelse p=reject, og afsnit 8 omhandler fuld deltagelse. Disse er separate implementeringsopgaver, ikke en ekstra per-meddelelse pass gate.
Fix den ansvarlige grænse
Før du indsnævrer en rigtig SPF record, skal du registrere alle legitime afsendere og følge udbyder-understøttet konfiguration. En dedikeret kilde er kun nyttig, hvis den faktisk er eksklusiv og vedligeholdt. Bekræft, at afsendertjenesten binder kunder til deres tilladte identiteter; verificere DKIM konfiguration og fjerne forældet autoritet gennem ændringskontrol.
Overvåg rutespecifikke fejl efter ændringen, bevar en genopretningsplan og dokumentér ukendte afsendere. Udskift ikke en bred post med en gættet IP-liste fra dette eksempel. Lektionen er at forene autorisation med faktisk tjenesteejerskab, ikke at kopiere demonstrations- DNS til produktion.