Bygg fra godkjente avsendere, ikke en gjettet leverandørliste
An SPF byggherren bør bevare organisasjonens eksplisitte beslutninger om hvilke systemer som kan bruke en bestemt SMTP identitet. En praktisk liste over populære leverandører kan ikke fastslå at disse tjenestene er autorisert for domenet, at deres anbefalte mekanisme er gjeldende eller at den resulterende posten passer oppslagsgrensene. Utdataene skal være et kommentert forslag knyttet til avsenderens eierskap, ikke en bred autorisasjon satt sammen fra merkevaregjenkjenning.
RFC 7208 definerer SPF -publisering og -evaluering. Denne artikkelen foreslår krav til en byggherre og dens vurderingsprosess. Den hevder ikke at EmailAuth tilbyr noen spesiell byggefunksjon, genererer en produksjonspost eller endrer DNS . Ingen leverandørkonto, privat legitimasjon eller brukerdomenepost ble inspisert. Original utgang og testbevis forblir åpne.
Inventar den faktiske SMTP identiteten og eieren
For hver arbeidsflyt registrerer du forretningsformål, godkjent tjenesteeier, sendetjeneste, relevant POST FRA eller HELO identitet og kilden til den foreslåtte autorisasjonen. SPF autentiserer ikke det synlige Fra-visningsnavnet direkte. En leverandør som brukes av ett team skal ikke automatisk legges til hver organisasjonsdomene. Den tiltenkte identiteten og tjenesteforholdet trenger eksplisitt bekreftelse fra ansvarlig eier.
RFC 9989 definerer justering forhold som SPF trenger å bidra til DMARC. En byggherre bør forklare at SPF autorisasjon og DMARC justering er relaterte, men separate beslutninger. Legge til en leverandør til en SPF rekord garanterer ikke at leverandøren bruker denne identiteten i faktisk post. Integrasjonseieren må oppgi gjeldende konfigurasjon og autorisert meldingsbevis når arbeidsflyten verifiseres.
Bruk gjeldende leverandørinstruksjoner uten å utvide omfanget
Det nøyaktige inkluderemålet eller adresseområdet skal komme fra gjeldende offisiell dokumentasjon eller autorisert konfigurasjon for den faktiske tjenesten. Ikke utlede det fra en annen kundes registrering, en gammel opplæring eller et lignende navngitt produkt. Registrer bevisdatoen og eieren som er ansvarlig for å spore leverandørendringer. Dette manuskriptet oppfinner ikke leverandøren inkluderer verdier fordi ingen spesifikk avsenderkonfigurasjon er godkjent for konstruksjon.
Direkte IP-mekanismer og delegerte avhengigheter har ulike vedlikeholdsforpliktelser. Statiske adresser kan unngå det samme oppslagstidsbudsjettet som DNS-spørringsfremkallende mekanismer, men kopiering av en leverandørs nåværende adresser til en rekord kan bli foreldet når leverandøren endrer infrastruktur. En byggherre bør ikke stille flate ut avhengigheter som en optimalisering uten en godkjent vedlikeholdsmodell. Ta vare på avveiningen og eierbeslutningen i merknaden.
Lag én sammenhengende SPF policy
RFC 7208 krever en enkelt SPF post for den evaluerte identiteten; publisering av flere SPF poster er ikke en gyldig måte å kombinere flere tjenester på. Den foreslåtte endringen bør derfor beskrive hvordan eksisterende autoriserte avsendere bevares i én sammenhengende policy. Den skal ikke bare instruere operatøren til å legge til en annen v=spf1 -post ved siden av en eksisterende. Ikke relatert TXT poster må ikke fjernes som en bivirkning.
RFC 1035 definerer TXT poststruktur. Flere tegnstrenger i én TXT post er forskjellig fra flere TXT poster, så byggerens skjerm og testarmaturer bør beholde den forskjellen. En editor kan formatere en lang verdi annerledes enn dens trådrepresentasjon. Den godkjente eksakte diff bør spesifisere det tiltenkte rekordsettet i stedet for å stole på et skjermbilde av et enkelt felt.
Forklar mekanismer, kvalifikatorer og modifikatorer
Hver generert term bør ha en eier og begrunnelse. Inkluder delegater en evaluering i henhold til standardens resultatkartlegging; omdirigering er en modifikator med forskjellig semantikk og ignoreres hvis noen all-mekanisme er til stede. En byggherre bør ikke bytte dem bare fordi begge refererer til et annet domene. Kvalifiserte påvirker resultatet knyttet til en samsvarsmekanisme og bør velges gjennom en eksplisitt policybeslutning.
Ikke antyd at å legge til alle gjør hver konfigurasjon trygg. Plasseringen og kvalifiseringen betyr noe, og en altfor bred autorisasjon kan bryte den tiltenkte grensen. Motsatt kan en restriktiv avslutning påvirke legitime avsendere som ble utelatt fra beholdningen. Byggherren bør vise uløste arbeidsflyter og kreve godkjenning før publisering i stedet for å velge en forretningsrisikoposisjon automatisk fra en mal.
Sjekk evalueringsgrensene uten å forvirre tellingen
RFC 7208 avsnitt 4.6.4 begrenser evaluerte DNS-spørring-forårsaker termer som include, a, mx, ptr, exists and redirect to ti. Dette er ikke en grense på ti synlige leverandørnavn eller ti råpakker. Nestede avhengigheter og den faktiske matchende banen har betydning. Byggherren bør gi en avhengighetsvurdering og identifisere hva den ikke har evaluert, i stedet for å bekrefte alle mulige innspill fra en grunn telling.
Standarden anbefaler også en void-lookup-grense på to med konfigurerbar oppførsel, og definerer ytterligere grenser for spesifikke mekanismer. En generators statiske utgang fastslår ikke hvordan alle mottakere vil evaluere hver bane under fremtidig DNS tilstand. Hold banetester atskilt fra formateringstester. En bygger kan forklare sannsynlige avhengigheter uten å hevde at en vellykket syntakssjekk beviser universell SPF suksess.
Et arbeidsark som bevarer eierskap
Lag et regneark med identitetsdomene, arbeidsflyt, bedriftseier, teknisk eier, godkjent avsenderbevis, foreslått begrep, begrunnelse og vedlikeholdsansvar. Legg til den eksisterende postreferansen, eksakt tiltenkt diff, uløste avsendere, oppslagsbanegjennomgang, verifiseringsplan og tilbakestillingskriterier. Utdataene skal forklare hvorfor hver autorisasjon eksisterer og hvem som kan godkjenne fjerning eller utvidelse.
Testsettet bør inneholde et positivt gyldig forslag, ugyldig syntaks, dupliserte SPF poster og tilfeller av ustøttede termer. Skille ukjente mekanismer fra ukjente modifikatorer fordi RFC 7208 behandler dem annerledes. Katalogteksten krever ikke-støttede tag-tilfeller; for SPF , kartlegg dette kravet eksplisitt til protokollens mekanisme og modifikasjonsordforråd i stedet for å finne opp en generisk tag-parser. Ingen slike tester ble utført for dette utkastet.
Fiktiv diagnose: en gammel leverandør forblir autorisert
En fiktiv organisasjon ber en byggherre legge til en ny posttjeneste. Den nåværende posten refererer også til en pensjonert leverandør, men ingen har dokumentert om en annen arbeidsflyt fortsatt bruker den avhengigheten. En forenklet byggherre slår sammen det nye begrepet og bevarer alt annet uten forklaring. Den foreslåtte eierskapsbevisste gjennomgangen markerer i stedet den gamle autorisasjonen som uløst og ber de ansvarlige virksomhetene og tekniske eierne om å fastslå statusen.
Teamet ville ikke slette den gamle termen bare for å redusere antallet, og heller ikke legge den nye leverandøren til urelaterte identiteter. Det vil forberede en nøyaktig godkjent endring etter å ha løst avhengighets- og planrepresentantverifiseringen. Dette er en fiktiv livssyklusøvelse, ikke en observert registrering, leverandørpensjonering eller fullført DNS endring. Det illustrerer hvorfor eierskap av avsendere er en del av platekonstruksjonen i stedet for administrativt papirarbeid etterpå.
Bekreft den tiltenkte arbeidsflyten før du erklærer fullføring
Etter en autorisert publisering vil driftsteamet beholde eksakte DNS observasjoner og representativt pålitelig mottatt meldingsbevis for hver relevant arbeidsflyt. Disse observasjonene må vise den faktiske identiteten og justeringen, ikke bare at den genererte strengen vises i et redigeringsprogram. En vellykket prøve forblir avgrenset til avsender, tid og mottaker; det fastslår ikke utfallet av alle fremtidige meldinger.
Katalogen krever en kommentert post og positive, ugyldige, dupliserte og ikke-støttede tag-testtilfeller. De originale gjenstandene forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet gir et foreslått regneark og fiktiv diagnose, ikke en generert produksjonspolicy, utført testpakke eller bekreftet EmailAuth -funksjonskrav.