Byg ud fra godkendte afsendere, ikke en liste over gættede udbydere
An SPF builder bør bevare organisationens eksplicitte beslutninger om, hvilke systemer der må bruge en bestemt SMTP identitet. En praktisk liste over populære udbydere kan ikke fastslå, at disse tjenester er godkendt til domænet, at deres anbefalede mekanisme er aktuel, eller at den resulterende post passer til opslagsgrænserne. Outputtet skal være et kommenteret forslag, der er knyttet til afsenderens ejerskab, ikke en bred autorisation, der er samlet ud fra mærkegenkendelse.
RFC 7208 definerer SPF udgivelse og -evaluering. Denne artikel foreslår krav til en bygherre og dens gennemgangsproces. Det hævder ikke, at EmailAuth tilbyder nogen bestemt byggefunktion, genererer en produktionspost eller ændrer DNS . Ingen leverandørkonto, privat legitimationsoplysninger eller brugerdomæneregistrering blev inspiceret. Originalt output og testbeviser forbliver åbne.
Inventar den faktiske SMTP identitet og ejer
For hver arbejdsgang skal du registrere forretningsformål, godkendt tjenesteejer, afsendende tjeneste, relevant MAIL FRA eller HELO identitet og kilden til den foreslåede tilladelse. SPF godkender ikke direkte det synlige Fra-visningsnavn. En udbyder, der bruges af ét hold, bør ikke automatisk tilføjes til hver organisatorisk domæne. Den påtænkte identitet og serviceforhold kræver en eksplicit bekræftelse fra den ansvarlige ejer.
RFC 9989 definerer justering forhold, som SPF skal bidrage til DMARC. En bygherre bør forklare, at SPF godkendelse og DMARC tilpasning er relaterede, men separate beslutninger. Tilføjelse af en udbyder til en SPF rekord garanterer ikke, at udbyderen bruger denne identitet i faktisk post. Integrationsejeren skal levere den aktuelle konfiguration og autoriseret meddelelsesbevis ved verificering af arbejdsgangen.
Brug nuværende udbydervejledning uden at udvide omfanget
Det nøjagtige inkluderede mål eller adresseinterval bør komme fra den aktuelle officielle dokumentation eller autoriseret konfiguration for den faktiske tjeneste. Udled det ikke fra en anden kundes registrering, en gammel vejledning eller et lignende navngivet produkt. Registrer bevisdatoen og ejeren, der er ansvarlig for sporing af udbyderændringer. Dette manuskript opfinder ikke udbyderens værdier, fordi ingen specifik afsenderkonfiguration er blevet godkendt til konstruktion.
Direkte IP-mekanismer og delegerede afhængigheder har forskellige vedligeholdelsesforpligtelser. Statiske adresser kan undgå det samme søgetidsbudget som DNS-forespørgselsfremkaldende mekanismer, men kopiering af en udbyders aktuelle adresser til en rekord kan blive forældet, når udbyderen skifter infrastruktur. En bygherre bør ikke i det stille udjævne afhængigheder som en optimering uden en godkendt vedligeholdelsesmodel. Bevar afvejningen og ejerens beslutning i annotationen.
Lav én sammenhængende SPF politik
RFC 7208 kræver en enkelt SPF post for den evaluerede identitet; udgivelse af flere SPF poster er ikke en gyldig måde at kombinere flere tjenester på. Den foreslåede ændring bør derfor beskrive, hvordan eksisterende autoriserede afsendere bevares i én sammenhængende politik. Det bør ikke blot instruere operatøren om at tilføje en anden v=spf1 -post ved siden af en eksisterende. Ubeslægtet TXT registreringer må ikke fjernes som en bivirkning.
RFC 1035 definerer TXT poststruktur. Flere tegnstrenge inden for en TXT post adskiller sig fra flere TXT poster, så bygherrens skærm og testarmaturer bør bevare denne forskel. En editor kan formatere en lang værdi anderledes end dens trådrepræsentation. Den godkendte nøjagtige diff bør specificere det tilsigtede rekordsæt i stedet for at stole på et skærmbillede af et enkelt felt.
Forklar mekanismer, kvalificerende og modifikatorer
Hvert genereret udtryk bør have en ejer og begrundelse. Inkluder delegerede en evaluering i henhold til standardens resultatkortlægning; redirect er en modifikator med forskellig semantik og ignoreres, hvis der er nogen mekanisme til stede. En builder bør ikke udveksle dem, bare fordi begge refererer til et andet domæne. Kvalifikationer påvirker resultatet forbundet med en matchningsmekanisme og bør vælges gennem en eksplicit politisk beslutning.
Antyd ikke, at tilføjelse af alle gør enhver konfiguration sikker. Placeringen og kvalifikationen betyder noget, og en alt for bred autorisation kan overvinde den tilsigtede grænse. Omvendt kan en restriktiv slutning påvirke legitime afsendere, der blev udeladt fra beholdningen. Bygherren bør vise uløste arbejdsgange og kræve godkendelse før offentliggørelse i stedet for automatisk at vælge en forretningsrisiko fra en skabelon.
Tjek evalueringsgrænser uden at forvirre antallet
RFC 7208 afsnit 4.6.4 begrænser evaluerede DNS-forespørgselsforårsagende termer såsom include, a, mx, ptr, exists and redirect to ti. Dette er ikke en grænse på ti synlige udbydernavne eller ti råpakker. Indlejrede afhængigheder og den faktiske matchende sti har betydning. Bygherren bør give en afhængighedsgennemgang og identificere, hvad den ikke har evalueret, i stedet for at attestere alle mulige input fra en overfladisk optælling.
Standarden anbefaler også en void-lookup-grænse på to med konfigurerbar adfærd og definerer yderligere grænser for specifikke mekanismer. En generators statiske output fastslår ikke, hvordan alle modtagere vil evaluere hver sti under fremtidig DNS tilstand. Hold stitests adskilt fra formateringstests. En builder kan forklare sandsynlige afhængigheder uden at hævde, at et vellykket syntakstjek beviser universel SPF succes.
Et ejerskabsbevarende output-regneark
Opret et arbejdsark med identitetsdomæne, arbejdsgang, virksomhedsejer, teknisk ejer, godkendt afsenderbevis, foreslået term, begrundelse og vedligeholdelsesansvar. Tilføj den eksisterende postreference, nøjagtig tilsigtet diff, uafklarede afsendere, opslagsstigennemgang, verifikationsplan og rollback-kriterier. Outputtet skal forklare, hvorfor hver autorisation eksisterer, og hvem der kan godkende dens fjernelse eller udvidelse.
Testsættet skal indeholde et positivt gyldigt forslag, ugyldig syntaks, duplikerede SPF registreringer og sager med ikke-understøttede termer. Skeln ukendte mekanismer fra ukendte modifikatorer, fordi RFC 7208 behandler dem forskelligt. Katalogets ordlyd kræver ikke-understøttede tag-tilfælde; for SPF skal du kortlægge dette krav eksplicit til protokollens mekanisme og modifikatorordforråd i stedet for at opfinde en generisk tag-parser. Der blev ikke udført sådanne tests for dette udkast.
Fiktiv diagnose: En gammel leverandør forbliver autoriseret
En fiktiv organisation beder en bygmester om at tilføje en ny posttjeneste. Dens nuværende registrering refererer også til en pensioneret leverandør, men ingen har dokumenteret, om en anden arbejdsgang stadig bruger denne afhængighed. En forsimplet bygherre slår det nye udtryk sammen og bevarer alt andet uden forklaring. Den foreslåede ejerskabsbevidste gennemgang markerer i stedet den gamle autorisation uløst og beder de ansvarlige forretnings- og tekniske ejere om at bestemme dens status.
Teamet ville ikke slette det gamle udtryk blot for at reducere antallet, og heller ikke tilføje den nye leverandør til ikke-relaterede identiteter. Det ville forberede en nøjagtig godkendt ændring efter at have løst afhængigheds- og planrepræsentantverifikationen. Dette er en fiktiv livscyklusøvelse, ikke en observeret registrering, leverandørpensionering eller gennemført DNS ændring. Det illustrerer, hvorfor afsenderens ejerskab er en del af pladekonstruktionen frem for administrativt papirarbejde bagefter.
Bekræft den tilsigtede arbejdsgang, før du erklærer færdiggørelse
Efter en autoriseret offentliggørelse vil det operationelle team beholde nøjagtige DNS observationer og repræsentative pålidelige beviser for modtaget meddelelse for hver relevant arbejdsgang. Disse observationer skal vise den faktiske identitet og justering, ikke blot at den genererede streng vises i en editor. En vellykket prøve forbliver omfattet af sin afsender, tid og modtager; det fastslår ikke alle fremtidige budskabers udfald.
Kataloget kræver en kommenteret post og positive, ugyldige, duplikerede og ikke-understøttede tag-testsager. Disse originale artefakter forbliver åbne. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast leverer et foreslået arbejdsark og fiktiv diagnose, ikke en genereret produktionspolitik, udført testsuite eller verificeret EmailAuth -funktionspåstand.