MTA-STS lader et modtagende domæne offentliggøre forventninger til autentificeret TLS levering. Den adresserer SMTP forbindelsen til den modtagende tjeneste. Den godkender ikke meddelelsesforfatterens Fra-adresse eller krypterer meddelelsen hele vejen fra en persons enhed til en anden.
En fungerende implementering forbinder tre ting: domænets faktiske indgående MX ruter, HTTPS-politikken og DNS posten, der signalerer denne politik. TLS -rapportering leverer en separat feedback-sti.
Etabler den egentlige modtagegrænse
Referencer: RFC 8461 §3.4, RFC 8461 §4.
Angiv de MX værter, der accepterer e-mail for domænet, inklusive backuptjenester og en opstrøms sikkerhedsgateway. Bekræft TLS og certifikatadfærd på den faktiske offentlige modtagegrænse, ikke kun på en intern postkasseserver.
Registrer, hvem der ejer MX ruten, politikhosting, certifikatfornyelse og rapporteringsdestination. En hostet postkassetjeneste er ikke nødvendigvis vært for kundens MTA-STS -politik eller betjener alle gateways foran den.
Vurder underdomæner separat. MTA-STS bruger ikke DMARC-lignende forældrepolitik-arv. Et modtagende underdomæne skal have den konfiguration, der gælder for det pågældende domæne.
Byg en politik for de faktiske værter
Referencer: RFC 8461 §3.2, RFC 8461 §3.3.
Vis politikken fra den påkrævede HTTPS-placering for det modtagende domæne. For example.com , placeringen er https://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS-tjenesten har brug for et gyldigt certifikat for dens politikværtsnavn.
Politikken identificerer dens version, tilstand, tilladte MX mønstre og maksimal cachelevetid. Start med en testimplementering, der passer til omfanget, og inspicer resultaterne før håndhævelse. Vælg observationsperioden fra den reelle trafik og afhængigheder i stedet for at behandle en prøvevarighed som et universelt bevis.
En illustrativ politik for et fiktivt enkelt-MX-domæne er:
version: STSv1-tilstand: test mx: mx1.example.net max_age: 86400Dette eksempel antager, at mx1.example.net er domænets faktiske modtagende vært og har passende SMTP TLS understøttelse. Det er ikke en færdiglavet politik for en anden udbyder. Match tilladte værter præcist og medtag alle legitime modtageruter.
Udgiv opdagelse og rapportering separat
Referencer: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
På _mta-sts.example.com er en illustrativ TXT værdi v=STSv1; id=2026110701. Identifikationen signalerer en politikrevision. Udgiv og bekræft politikken, før du annoncerer dens nye revision i DNS .
TLS-RPT bruger sin egen post på _smtp._tls.example.com . En illustrativ anmodning er v=TLSRPTv1; rua=mailto:tls-reports@example.com, forudsat at adressen eksisterer, og dens indsamlingssti fungerer.
Antag ikke en DMARC rua destination modtager automatisk TLS rapporter, eller at MTA-STS -test alene skaber en fungerende rapporteringsanmodning. Bekræft hver post med det korrekte navn og hver destination gennem sin egen indsamlingsproces.
Test den installerede kæde
Referencer: RFC 8461 §4, RFC 8461 §6.
Hent politikken eksternt, og bekræft, at det påkrævede HTTPS-endepunkt tjener den tilsigtede almindelige teksttekst med HTTP 200. Følg ikke HTTP-omdirigeringer: en omdirigering er ikke en gyldig politikhentning i henhold til RFC 8461 §3.3. Tjek opdagelses DNS og sammenlign alle annoncerede MX ruter med tilladte mønstre.
Test SMTP TLS og certifikatvalidering ved hver modtagende rute. Et fungerende webcertifikat på mta-sts.example.com fastslår ikke, at MX serveren præsenterer et gyldigt SMTP certifikat.
Gennemgå tilgængelige TLS rapporter og kontrolleret leveringsbevis. Afsendelsestjenester er forskellige i deltagelse, så tavshed etablerer ikke universel succes. Hold reporteren, intervallet og berørt MX ved hver observation.
I et syntetisk tilfælde tillader en politik kun hovedgatewayen, mens DNS også annoncerer for en backup MX . Sikkerhedskopien accepterer e-mail i almindelige tests, men klarer ikke politikken. Reparer politikken eller routingdesignet før håndhævelse; afvis ikke sikkerhedskopien, fordi dens daglige volumen er lille.
Planlæg håndhævelse og gendannelse omkring caches
Referencer: RFC 8461 §5, RFC 8461 §8.3.
Håndhæv tilstand kan forhindre understøttende afsendere i at levere via en ikke-kompatibel forbindelse. Ikke-støttende afsendere er uden for denne sikkerhed. Registrer afhængigheden og acceptable operationelle reaktioner, før du skifter tilstand.
Afsendercaches kan beholde gyldige tidligere politikker for deres max_age. Sletning af opdagelses- DNS eller fjernelse af HTTPS-slutpunktet er ikke en øjeblikkelig global tilbagerulning. For tilbagetrækning skal du offentliggøre en gyldig tilstand: ingen politik med kort levetid, og derefter opdatere opdagelses-id'et. Hold begge endepunkter tilgængelige, indtil alle tidligere politikker er udløbet, inklusive ældre revisioner med længere levetid. Tæl hver levetid fra det tidspunkt, hvor revisionen sidst blev leveret, ikke kun fra den næste redigering.
For en gateway-migrering skal du gøre politikken kompatibel med den planlagte overgang, verificere den nye rute og tillade cachelagrede versioner. Hold politikslutpunktet tilgængeligt, mens relevante afsendere stadig kan stole på det.
Overdragelsen skal slutte sig til MX konfiguration, politikhistorik, certifikatejerskab og rapporthåndtering. MTA-STS forbliver nyttig, når disse bevægelige dele holdes sammen.