En mailserver kan sende en legitim besked med en tom SMTP omvendt sti, skrevet som MAIL FRA:<>. Meddelelser om leveringsstatus bruger en nul omvendt sti under RFC 5321 §4.5.5 for at undgå at skabe endeløse bounce loops. Tom omvendt sti betyder ikke, at der ikke er nogen SPF evaluering at overveje: RFC 7208 §2.4 definerer en MAIL FRA identitet ved hjælp af den lokale del postmester og den HELO domæne i dette tilfælde.
Administratorer, der kun tester almindelig brugermail, kan derfor gå glip af en separat godkendelsessti, der bruges af serveren selv.
Skelne HELO fra den synlige afsender
HELO eller EHLO introducerer SMTP klienten til den modtagende server. Dens domæne er adskilt fra meddelelsens synlige Fra overskrift og kan afvige fra et ikke-tomt MAIL FROM-domæne. En vært kan præsentere sig selv som relay.example.com mens du sender brugermail med en konvolutafsender kl example.com.
RFC 7208 §2.3 anbefaler at tjekke HELO separat og anbefaler at gøre det først, når begge identiteter er tjekket. De MAIL FRA regler afhænge af, om HELO tjekket blev udført og nåede frem til et endeligt politikresultat. Antag ikke, at hver modtager vil udsende to uafhængige SPF resultater for hver besked.
Til HELO kontrollen beskrevet i RFC'en skal den angivne værdi være et gyldigt multi-label domænenavn. En forkert udformet værdi eller adressebogstav kan ikke behandles, som om det var et almindeligt forespørgselsvenligt værtsnavn. Ret afsenderserverens konfiguration gennem dens understøttede kontroller i stedet for at opfinde DNS indgange for misdannede identiteter.
Udgiv for det værtsnavn, der faktisk bruges
Indfang en kontrolleret SMTP transaktion eller betroet modtagerlog for at etablere HELO værdien. Forespørg derefter SPF TXT på det nøjagtige værtsnavn. SPF -politikken kl example.com gælder ikke automatisk for relay.example.com.
For en server med stabile, eksplicit kontrollerede udgående adresser, kan en snæver politik beskrive disse adresser. For hostet afsendelsesinfrastruktur skal du følge udbyderens understøttede konfiguration og ejerskabsgrænser. Udgiv ikke en gættet post på et værtsnavn, du ikke kontrollerer, eller antag, at et værtsnavn En rekord er nødvendigvis SMTP udgående adresse.
Inkluder IPv6 i anmeldelsen. An MTA kan præsentere den samme HELO over forskellige adressefamilier, og en politik, der kun dækker dens IPv4 kilde, kan give forskellige resultater over IPv6 .
Udøv normal trafik og trafik med tomme kuverter separat
Illustrativ testplan, der kun bruger dokumentationsadresser:
- En server forbinder fra 192.0.2.10 og præsenterer sig selv som
relay.example.com. - Værtsnavnet offentliggøres
v=spf1 ip4:192.0.2.10 -all. - For en besked med
MAIL FRA:<>, SPF afledespostmaster@relay.example.comsom MAIL FRA identitet. Denne kilde er godkendt af værtsnavnepolitikken. - Gentag med en anden, uautoriseret test-IP. Med den samme værtsnavnepolitik mislykkes de umatchede kilden.
Disse er forventede evaluatorresultater, ikke resultater fra et live system. Brug kontrollerede, autoriserede modtagere til reelle notifikationstests. Fremkald ikke afvisninger mod vilkårlige eksterne adresser blot for at observere adfærd.
Registrer identiteten samt dommen
Bevar sessionens tilslutnings-IP, HELO værdi, omvendt sti og modtagergenereret resultat. Et generisk " SPF -pas" uden en identitet er utilstrækkeligt til fejlfinding. En vellykket almindelig brugermeddelelse beviser ikke, at null omvendt sti-mail udøvede det samme domæne.
Når en test mislykkes, skal du beslutte, om problemet er det annoncerede værtsnavn, DNS udgivelse, udgående beholdning eller en uventet rute. Ændring af medarbejderdomænets SPF politik vil ikke reparere en værtsnavnepolitik, der aldrig blev forespurgt.
Gør servergenereret mail til en del af ændringskontrollen
Tilføj notifikationstest til MTA-opgraderinger, relæmigreringer og IPv6 aktivering. Bevar den tidligere identitetskonfiguration og godkendte gendannelsessti. Luk kun ændringen, når almindelig post og de servergenererede flows, der er relevante for din organisation, er blevet vurderet. Dette forhindrer en sund bruger-mail-test i at skjule ødelagte driftsmeddelelser.
Brug beviserne til en beslutning
Hold almindelige MAIL FROM og null-path notifikationsrækker adskilt. For en nulsti og HELO = relay.example.com er den konstruerede afsender postmaster@relay.example.com ; test-IP'en skal evalueres i forhold til det pågældende domænes politik. Et almindeligt brugerbeskedpas for example.com fastslår ikke dette resultat. Brug autoriserede modtagere og kontrollerede meddelelser; ingen afvisningstest eller serverændring blev udført.