[ Regionale krav ]

Mål MTA-STS -vedtagelse og tilgængelighed af værtspolitikker

Mål MTA-STS opdagelse, politikvaliditet og HTTPS-tilgængelighed separat med et reproducerbart datasæt og fejlregnskab.

Af EmailAuth -forskningsteamet · 8 min læst

[Nøglepunkter]

  • Definer adoptionskategorier, før du tæller domæner.
  • Bevar DNS opdagelse, HTTPS-hentning og MX kompatibilitet som separate beviser.
  • En sondeafbrydelse etablerer ikke alle afsenderes cachelagrede politikadfærd.
På denne side

Definer adoption og tilgængelighed som separate foranstaltninger

MTA-STS adoption kan referere til DNS opdagelse, hentning af en syntaktisk gyldig politik, offentliggørelse af en håndhævelsestilstand eller observeret kompatibilitet med domænets modtagende MX rute. Policy-host-tilgængelighed er en anden egenskab: det drejer sig om, hvorvidt HTTPS-slutpunktet var tilgængeligt og gyldigt på observationstidspunktet. En undersøgelse bør definere disse foranstaltninger separat i stedet for at behandle en vellykket hentning som fuldstændig transportsikkerhedsvedtagelse.

RFC 8461 definerer MTA-STS opdagelse, policy-hentning, validering og caching. Det understøtter et reproducerbart måledesign, ikke en påstand om, at der eksisterer et datasæt. Denne artikel indeholder ingen domænescanninger, tilgængelighedsprocenter, forbindelsestests eller longitudinelle fund. Alle eksempler er eksplicit hypotetiske.

Etabler populationen af ​​det modtagende domæne

MTA-STS vedrører det modtagende domænes mailrute. En liste over websteder, udgående afsendermærker eller kundeorganisationer er ikke automatisk en passende liste over modtagende domæner. Definer enhed, udvælgelsesmetode og udelukkelser før indsamling. Registrer, om prøven indeholder domæner uden en brugbar mailrute, og hvordan disse sager påvirker hver metrik i stedet for at slette dem uden at være.

Frys inputlisten og bevar dens kilde, dato, normaliseringsregler og hash. Hvis listen ændres mellem kørsler, skal du bevare medlemshistorikken. Et domæne, der går ind i eller forlader prøven, kan ændre tilsyneladende adoption uden nogen ændring af dets politik. Kald ikke en bekvemmelighedsprøve for et globalt estimat, medmindre prøveudtagningsdesignet understøtter denne slutning. Dette manuskript giver ikke et sådant skøn.

Adskil DNS opdagelse fra HTTPS-hentning

RFC 8461 definerer opdagelsesposten hos _mta-sts ejeren og policy-hentningsplaceringen under mta-sts-værten på den velkendte sti. Opdagelses-id'et signalerer politikændringer; det er ikke et certifikatfingeraftryk eller bevis for, at endepunktet fungerer i øjeblikket. Registrer DNS svar, ejer, resolver og tid uafhængigt af den efterfølgende HTTPS-observation.

Standarden kræver HTTP 200 OK til hentning af politikker og siger, at afsendere ikke må følge HTTP-omdirigeringer i denne genfindingsprocedure. Det siger også, at afsendere ikke må bruge HTTP-cache til hentning af politikker, til forskel fra MTA-STS -politikcache. Metoden bør bevare svarstatus og omdirigeringsadfærd i stedet for at acceptere enhver browserdestination, der ser vellykket ud. Intet endepunkt blev hentet eller omdirigeret fulgt under dette arbejde.

Valider politikken og forbindelsen i henhold til de angivne regler

Politikken indeholder version, tilstand, MX mønstre og maksimal alder under RFC 8461 's syntaks. Behold de faktiske bytes og parserversionen. En politik, der bruger testtilstand, er ikke den samme målte kategori som håndhævelsestilstand. En ingen-politik er en anden stat, der bør navngives i stedet for at kollapse i en generisk adoptionstælling. Rapportér indholdstypehåndtering med standardens kravstyrke: afsendere bør validere tekst/almindelig i stedet for at opfinde et universelt stærkere krav.

HTTPS-certifikatvalidering er en separat observation. Registrer det anmodede værtsnavn, slutpunkt, tidspunkt og faktiske valideringsresultat. En netværksfejl, certifikatfejl, uventet status og forkert udformet politik har forskellige betydninger og bør forblive adskilt i fejlloggen. Udled ikke, at en politik er fraværende, blot fordi én observationsplacering ikke kunne nå den, og ignorer ikke forbindelsesfejl for at producere en større adoptionstæller.

Sammenlign politikmønstre med den tilsigtede MX rute

En syntaktisk gyldig politik kan stadig beskrive de forkerte modtagende værter. RFC 8461 definerer matchning af nøjagtige MX værtsnavne og jokertegnmønstre. Et jokertegn er ikke en ubegrænset glob nogen steder i et navn; metoden skal implementere standardens definerede syntaks og matchning. Gem MX observationerne og den matchende beslutning for hver vært inden for det målte omfang.

En HTTPS-hentning alene fastslår ikke, at hvert MX slutpunkt tilbyder en gyldig TLS tjeneste, der matcher politikken. Hvis undersøgelsen ikke udfører autoriserede SMTP observationer, skal du angive, at rutekompatibiliteten er umålt. Hvis senere test godkendes, skal du holde dens forbindelsesbevis og population adskilt fra tilgængeligheden af ​​politikværten. Krav ikke ende-til-ende håndhævelse fra DNS og HTTP alene.

Redegør for cachelagret politikadfærd

Afsendere kan beholde en MTA-STS -politik for dens maksimale alder i henhold til protokollen. Et midlertidigt policy-host-udfald kan derfor påvirke en afsender med en brugbar cache-politik anderledes end en afsender, der opdager domænet for første gang. En ekstern målesonde kender generelt ikke hver afsenderes cachetilstand. Undersøgelsen må ikke oversætte nedetid for slutpunkter direkte til en universel periode med ubeskyttet post.

På samme måde har opdagelses-id'et og den observerede politikversion brug for en tidsmæssig registrering. Hvis en politik ændres under indsamlingen, skal du bevare sekvensen i stedet for at slutte den gamle DNS observation til et nyt organ uden forklaring. Gentagne målinger bør registrere probetilstand og enhver tilsigtet cachebehandling. Metoden skal skelne dens måleadfærd fra en fuld afsendelse MTA implementering.

Design tilgængelighedsplanen før afhentning

Definer sondeplaceringer, kadence, timeout, genforsøgspolitik og klassifikationsregler på forhånd. Et slutpunkt, der mislykkes én gang og lykkes ved genforsøg, bør ikke forsvinde fra fejlregistreringen. Rapportér forsøgte observationer, vellykkede observationer og fejlkategorier ved hjælp af en klar nævner. Hvis vedligeholdelsesvinduer eller uopnåelige udsigtspunkter er udelukket, behold årsagerne og vis, hvordan udelukkelser ændrer resultatet.

Ingen kadence eller mål på serviceniveau pålægges universelt af denne artikel. Vælg en tidsplan, der passer til forskningsspørgsmålet og godkendelsen, og undgå overdreven belastning. Dokumenter værktøjsversionen og afhængighederne, så en anden analytiker kan gengive metoden. Faktiske tilgængelighedskonklusioner kræver indsamlede data; en foreslået tidsplan er ikke et bevis på, at en tjeneste nåede eller missede noget mål.

Et versioneret datasæt arbejdsark

Opret felter til eksempelversion, modtagende domæne, observationstid, DNS opdagelsesresultat, politik-id, HTTPS-slutpunkt, status, certifikatresultat, indholdstype, kropshash, parseret tilstand, MX mønstre og maksimal alder. Tilføj MX observationsreferencer, matchende resultater, fejlkategori, genforsøgshistorik og ekskluderingsårsag. Bevar råbevis adskilt fra normaliserede klassifikationer.

RFC 8460 definerer SMTP TLS rapportering, som kan give et andet perspektiv, når det er lovligt tilgængeligt. Sådanne rapporter svarer ikke til en ekstern tilgængelighedssonde og dækker ikke automatisk hver afsender. Hvis inkluderet, dokumenter deres kilde og omfang separat. Dette udkast indsamlede hverken sonder eller rapporter og indebærer ikke en nøjagtig sammenhæng mellem dem.

Fiktiv diagnose: slutpunktsudfald bliver et håndhævelseskrav

En fiktiv undersøgelse observerer en mislykket HTTPS-hentning og mærker det modtagende domæne som ingen MTA-STS -beskyttelse hele dagen. Den foreslåede gennemgang identificerer manglende beviser: observationen dækkede én gang og udsigtspunkt, og afsendere kan have cachelagrede politikker. Den korrekte konklusion er snævrere og beskriver den mislykkede hentning og dens fejlkategori inden for den målte tidsplan.

Holdet ville beholde efterfølgende observationer og rapportere nævneren i stedet for at slette fejlen eller ekstrapolere den til universel postadfærd. Dette er et fiktivt metodologisk eksempel, ikke en observeret fejl eller en påstand om et navngivet domæne. Ingen netværksprobe eller e-mailleveringstest blev udført.

Frigiv kun reproducerbare fund

Kataloget kræver et versioneret datasæt, forespørgselsmetode og fejl-/udelukkelseslog, som en anden analytiker kan gengive. Disse originale artefakter forbliver åbne. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast leverer et undersøgelsesdesign og fiktiv diagnose, ikke adoptionstællinger, tilgængelighedsresultater eller en end-to-end transportsikkerhedsvurdering.

[ Takeaway ]

Rapportér politik-værts observationer inden for deres tidsplan og omfang uden at konvertere dem til universelle transportbeskyttelseskrav.

[Efter rolle]

Hvad betyder det for dig

Vælg din rolle for praktiske næste trin.

Måleingeniør

Implementer den definerede hentning

Browsersucces kan skjule omdirigeringer eller cache-forskelle.

Næste trin

  1. Kræv det dokumenterede HTTP-resultat.
  2. Behold fejl og krops-hash.

Mail sikkerhedsanalytiker

Separat ruteberedskab

Politiksyntaks beviser ikke, at alle MX slutpunkter fungerer.

Næste trin

  1. Bevar MX matchingsomfang.
  2. Skelne eksterne prober fra afsendercaches.

Forskningsanmelder

Revider nævneren

Ekskluderinger og genforsøg kan ændre det tilsyneladende tilgængelighedsresultat.

Næste trin

  1. Version populationen og metoden.
  2. Gem fejl- og ekskluderingslogfiler.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Hvad tæller som MTA-STS -adoption?

Undersøgelsen skal definere, om det betyder opdagelse, gyldig politik, håndhævelsestilstand eller rutekompatibilitet; disse er distinkte egenskaber.

RFC 8461 : SMTP MTA Strict Transport Security

Er enhver HTTP-successtatus tilstrækkelig?

Nej. RFC 8461 kræver HTTP 200 OK til hentning af politik.

RFC 8461 : SMTP MTA Strict Transport Security

Må den definerede hentning følge omdirigeringer?

Nej. Standarden siger, at afsendere ikke må følge HTTP-omdirigeringer for at hente politik.

RFC 8461 : SMTP MTA Strict Transport Security

Er HTTP caching det samme som MTA-STS politik caching?

Nej. Standarden forbyder HTTP-cache til hentning, mens den definerer bevaret politikadfærd separat.

RFC 8461 : SMTP MTA Strict Transport Security

Har tekst/plain universel MUST-valideringsstyrke?

RFC siger, at afsendere SKAL validere medietypen. Bevar denne kravstyrke i metoden.

RFC 8461 : SMTP MTA Strict Transport Security

Beviser en mislykket hentning, at al post er ubeskyttet?

Nej. Observationen er omfangsrig, og afsendere kan have cachelagrede politikker med deres egen stat.

RFC 8461 : SMTP MTA Strict Transport Security

Erstatter TLS -rapporter eksterne sonder?

Nr. RFC 8460 -rapportering er en anden observationskilde med sin egen dækning og semantik.

RFC 8460 : SMTP TLS -rapportering

Blev resultaterne af adoption eller tilgængelighed målt?

Nej. Det versionerede datasæt, forespørgselsmetode og fejl-/udelukkelseslog forbliver åbne.

[ Kilder ]

Kilder

  1. RFC 8461 : SMTP MTA Strict Transport Security

    Afsnit §3.1 MTA-STS TXT poster · §3.2 MTA-STS politikker · §3.3 HTTPS-politikhentning · §4.1 MX værtsvalidering · §5 Politikapplikation · §8.1 Politikopdateringer

  2. RFC 8460 : SMTP TLS -rapportering

    Afsnit §3 Indberetningspolitik · §4 Indberetningsskema · §5 Indberetningslevering

[ Ordliste ]

Ordliste

Politik-vært tilgængelighed
Den observerede tilgængelighed og gyldighed af HTTPS-politikkens slutpunkt under en erklæret tidsplan.
Discovery identifier
MTA-STS DNS id'et, der bruges til at signalere politikændringer, ikke et certifikatfingeraftryk.

RFC 8461 : SMTP MTA Strict Transport Security

Politik cache
Afsenderens bevarede MTA-STS -politiktilstand styret af protokollen.

RFC 8461 : SMTP MTA Strict Transport Security

Fejl/udelukkelseslog
Den bibeholdte bogføring af fejlslagne observationer og udeladte sager med begrundelse.

Virksomhedens herkomst

Hvorfor top finansielle institutioner og regeringer pensionerede deres e-mailsikkerhedsdashboards.

Traditionelle e-mail-godkendelsesplatforme sælger dig et dashboard og beder dine ingeniører om at gøre arbejdet. I miljøer med høj indsats betyder manuel overvågning forsinket håndhævelse, konfigurationsdrift og uovervågede skyggedomæner.

EmailAuth er den agentiske e-mail-herkomstplatform. Vores agenter håndhæver p=reject, hold tredjepartsafsendere på linje og flyt dine domæner til fuld RFC 9989 compliance, den nye DMARC standard, med menneskelig auditabilitet.

regeringer Store virksomheder Tier-1 finansielle institutioner

SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering

Vidensbase