An SPF include for en delt e-mail-tjeneste kan godkende infrastruktur, der bruges af mange kunder. Det er ofte sådan, tjenesten er designet, men tilladelsen fortjener en klar forklaring. SPF kontrollerer en forbindende vært i forhold til en domænepolitik; et bredt positivt match er ikke en lejerspecifik kryptografisk legitimation.
Det praktiske spørgsmål er, om din udbyder forhindrer en anden kunde i at sende med din SMTP identitet, og om politikken kun giver de infrastrukturtilladelser, din brug faktisk har brug for.
Kortlæg tillidsforholdet
For hvert inkluderet eller delt IP-område skal du registrere tjenesten, virksomhedsejeren, det understøttede konvolutdomæne og den dokumenterede udbyderopsætning. Bestem, om din mail bruger et udbyderejet kuvertdomæne eller et brugerdefineret domæne, du kontrollerer. Hvis udbyderen ejer det faktisk evaluerede domæne, vil tilføjelse af en inkludering til dit roddomæne muligvis slet ikke påvirke meddelelsens SPF resultat.
Læs udbyderens aktuelle dokumentation for domænebekræftelse og afsenderkontroller. Hvis dokumentationen er uklar, skal du identificere spørgsmålet til tjenesteejeren eller udbyderens support. Påstå ikke, at alle lejere er isoleret, blot fordi en test fra din egen konto består.
Forstå grænsen for en IP-baseret beslutning
RFC 7208 §11.4 beskriver forfalskningsrisici på tværs af brugere, hvor et delt system tillader brugere at gøre krav på andre brugeres identiteter. Et SPF pas kan fastslå, at den tilsluttende vært er autoriseret til det evaluerede domæne uden at bevise, hvilken kundekonto der startede meddelelsen. Håndhævelse på udbydersiden er derfor en del af sikkerhedsgrænsen.
Dette betyder ikke, at alle delte tjenester er usikre. Det betyder, at autorisationsmodellen har to lag: DNS giver tilladelse til infrastruktur, og tjenesten skal begrænse, hvordan kunder bruger identiteter på den infrastruktur. Beviser for det ene lag bør ikke fremlægges som bevis for det andet.
Vælg den smalleste understøttede konfiguration
Foretrækker den nøjagtige inkludering eller domænekonfiguration, som udbyderen understøtter for dit afsendende produkt og område, hvor sådanne forskelle er dokumenteret. Undgå at tilføje en leverandørs hele netværkstildeling, når en snævrere vedligeholdt politik er tilgængelig. Opfind ikke snævrere inkluderer eller udskift leverandørstyret politik med et øjebliksbillede af IP'er, medmindre du kan vedligeholde dette design sikkert.
En dedikeret retur-sti underdomæne kan adskille en tjenestes SPF politik fra anden post. Det forbedrer ejerskab og livscyklusstyring, men det beviser ikke i sig selv isolation blandt kunder, der deler udbyderen. Gennemgå andre godkendelses- og kontokontroller som separate dele af designet.
Sammenlign to konfigurationer omhyggeligt
Illustrerende eksempel: v=spf1 ip4:192.0.2.0/24 -all autoriserer hver IPv4 adresse i det dokumentationsnetværk til den evaluerede identitet. Kun en politiknavngivning ip4:192.0.2.10 tillader én adresse. Den snævrere politik reducerer kildesættet, men det er kun nyttigt, hvis udbyderen faktisk garanterer denne adresse for din tjeneste. En ikke-understøttet begrænsning kan bryde legitim levering under failover.
Under RFC 7208 §5.2, en include evaluerer en refereret politik; dens nuværende udvidelse er en observation, ikke en permanent kontrakt. Det kan ændre sig, når udbyderen ændrer sin politik. Indfang afhængigheden og ejerskabet i stedet for at behandle dagens afklarede adresser som den endelige sandhed.
Gennemgå uden at teste andre lejere
Brug dine egne autoriserede konti og kontrollerede modtagere til validering. Bekræft dine forventede identiteter og noter, hvilken infrastruktur der producerer pass. Vurder lejerbegrænsninger gennem dokumentation, godkendt konfigurationsbevis eller en eksplicit autoriseret sikkerhedstest. Forsøg ikke at efterligne en anden kundes domæne for at demonstrere en teoretisk bekymring.
Overvåg for nye inkluderer, usædvanligt brede netværksområder og tjenester uden ejer. En politikgennemgang bør også kontrollere rekursive evalueringsgrænser, fordi flere delte udbydere kan skabe et ressourceproblem, selv når hver inkludering er individuelt legitim.
Gør acceptbeslutningen eksplicit
Hold en kort fortegnelse over den tildelte infrastrukturtilladelse, identitetskontrol på udbydersiden, kendte bevishuller og den ansvarlige ejer. Planlæg gennemgang, når udbyderen eller tjenestekonfigurationen ændres. Det kan være rimeligt at acceptere delt infrastruktur, men beslutningen bør hvile på den komplette tillidsmodel frem for et grønt SPF mærke alene.
Optag den næste beslutning
Brug to bevisrækker: infrastrukturtilladelse (faktisk politik, kuvertdomæne og observeret kilde) og lejerkontrol (dokumenteret verifikation/håndhævelse, konfigurationsbevis og uløste huller). Dit eget succesfulde SPF resultat fylder kun den første række. Hvis en smallere adresse ikke er garanteret af udbyderen, skal du ikke behandle en ikke-understøttet begrænsning som en bekræftet sikkerhedsforbedring. Der blev ikke udført en test på tværs af lejer eller udbyderskift.