MTA-STS lar et mottakende domene publisere forventninger til autentisert TLS levering. Den adresserer SMTP tilkoblingen til mottakstjenesten. Den autentiserer ikke meldingsforfatterens Fra-adresse eller krypterer meldingen hele veien fra en persons enhet til en annen.
En fungerende distribusjon kobler sammen tre ting: domenets faktiske innkommende MX ruter, HTTPS-policyen og DNS posten som signaliserer denne policyen. TLS -rapportering gir en egen tilbakemeldingsbane.
Etabler den reelle mottaksgrensen
Referanser: RFC 8461 §3.4, RFC 8461 §4.
List opp MX vertene som godtar e-post for domenet, inkludert sikkerhetskopieringstjenester og en oppstrøms sikkerhetsgateway. Bekreft TLS og sertifikatadferd på den faktiske offentlige mottaksgrensen, ikke bare på en intern postboksserver.
Registrer hvem som eier MX ruten, policy-hosting, sertifikatfornyelse og rapporteringsdestinasjon. En vertsbasert postbokstjeneste er ikke nødvendigvis vert for kundens MTA-STS policy eller opererer hver gateway foran den.
Vurder underdomener separat. MTA-STS bruker ikke DMARC-stil overordnet policy-arv. Et mottakende underdomene trenger konfigurasjonen som gjelder for det domenet.
Lag en policy for de faktiske vertene
Referanser: RFC 8461 §3.2, RFC 8461 §3.3.
Vis policyen fra den nødvendige HTTPS-plasseringen for mottakerdomenet. For example.com , plasseringen er https://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS-tjenesten trenger et gyldig sertifikat for policyvertsnavnet.
Retningslinjen identifiserer versjon, modus, tillatte MX mønstre og maksimal cache-levetid. Start med en testdistribusjon som passer for omfanget, og inspiser resultatene før håndhevelse. Velg observasjonsperioden fra den virkelige trafikken og avhengighetene i stedet for å behandle en prøvevarighet som et universelt bevis.
En illustrativ policy for et fiktivt enkelt-MX-domene er:
versjon: STSv1-modus: testing mx: mx1.example.net max_age: 86400Dette eksemplet forutsetter at mx1.example.net er domenets faktiske mottakervert og har passende SMTP TLS støtte. Det er ikke en ferdig politikk for en annen leverandør. Match tillatte verter nøyaktig og inkluderer alle legitime mottaksruter.
Publiser oppdagelse og rapportering separat
Referanser: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
På _mta-sts.example.com er en illustrativ TXT verdi v=STSv1; id=2026110701. Identifikatoren signaliserer en policyrevisjon. Publiser og bekreft retningslinjene før du annonserer den nye revisjonen i DNS .
TLS-RPT bruker sin egen post på _smtp._tls.example.com . En illustrativ forespørsel er v=TLSRPTv1; rua=mailto:tls-reports@example.com, forutsatt at adressen eksisterer og dens innsamlingsbane fungerer.
Ikke anta en DMARC rua destinasjon mottar automatisk TLS rapporter, eller at MTA-STS -testing alene oppretter en fungerende rapporteringsforespørsel. Bekreft hver post med riktig navn og hver destinasjon gjennom sin egen innsamlingsprosess.
Test den utplasserte kjeden
Referanser: RFC 8461 §4, RFC 8461 §6.
Hent policyen eksternt og bekreft at det nødvendige HTTPS-endepunktet betjener den tiltenkte tekstteksten med HTTP 200. Ikke følg HTTP-omdirigeringer: en omdirigering er ikke en gyldig policyhenting under RFC 8461 §3.3. Sjekk oppdagelses- DNS og sammenlign alle annonserte MX ruter med tillatte mønstre.
Test SMTP TLS og sertifikatvalidering ved hver mottakerrute. Et fungerende nettsertifikat på mta-sts.example.com fastslår ikke at MX serveren presenterer et gyldig SMTP sertifikat.
Se gjennom tilgjengelige TLS -rapporter og kontrollert leveringsbevis. Sending av tjenester varierer i deltakelse, så stillhet etablerer ikke universell suksess. Hold reporteren, intervallet og berørt MX ved hver observasjon.
I et syntetisk tilfelle tillater en policy bare hovedgatewayen mens DNS også annonserer en backup MX . Sikkerhetskopien godtar e-post i ordinære tester, men ikke samsvarer med policyen. Reparer policyen eller rutedesignet før håndhevelse; ikke avvis sikkerhetskopien fordi det daglige volumet er lite.
Planlegg håndheving og gjenoppretting rundt cacher
Referanser: RFC 8461 §5, RFC 8461 §8.3.
Håndhevingsmodus kan forhindre støttesendere i å levere gjennom en ikke-kompatibel tilkobling. Ikke-støttende avsendere er utenfor denne forsikringen. Registrer avhengighet og akseptabel operasjonell respons før du endrer modus.
Avsenderbuffere kan beholde gyldige tidligere retningslinjer for maks_alder. Å slette oppdagelses- DNS eller fjerne HTTPS-endepunktet er ikke en umiddelbar global tilbakeføring. For uttak, publiser en gyldig modus: ingen policy med kort levetid, og oppdater deretter oppdagelses-IDen. Hold begge endepunktene tilgjengelige til alle tidligere retningslinjer har utløpt, inkludert eldre revisjoner med lengre levetid. Tell hver levetid fra da revisjonen sist ble levert, ikke bare fra neste redigering.
For en gateway-migrering, gjør policyen kompatibel med den planlagte overgangen, verifiser den nye ruten og tillat bufrede versjoner. Hold policyendepunktet tilgjengelig mens relevante avsendere fortsatt kan stole på det.
Overleveringen skal være med i MX konfigurasjon, policyhistorikk, sertifikateierskap og rapporthåndtering. MTA-STS forblir nyttig når de bevegelige delene holdes sammen.