MTA-STS og TLS-RPT – trygg innføring og drift

MTA-STS lar et mottakerdomene publisere hvilke MX-verter som er gyldige, og at støttende avsendere skal bruke STARTTLS med et gyldig sertifikat. TLS-RPT gir aggregerte rapporter om vellykket og mislykket TLS-transport.

Dette er et tillegg til vanlig opportunistisk SMTP-TLS. Uten en autentisert transportpolicy kan en aktiv angriper forsøke å fjerne STARTTLS-tilbudet eller lede forbindelsen til feil server. En avsender som allerede har en gyldig MTA-STS-policy i cache kan avvise nedgraderingen og holde meldingen i kø i stedet for å levere usikkert.

MTA-STS er også en driftsrisiko hvis policyen er feil. I enforce kan et utelatt MX-navn, et utløpt sertifikat eller en utilgjengelig reserve-MX forsinke innkommende e-post fra avsendere som håndhever policyen. Innføring må derfor begynne med inventar, testmodus og rapportering.

Hva MTA-STS beskytter

MTA-STS gjelder server-til-server-levering til et domene. For navn@dittfirma.no er dittfirma.no normalt policydomenet. Domenet erklærer at gyldige MX-kandidater:

• matcher ett av mønstrene i policyfilen
• tilbyr STARTTLS
• presenterer et ikke-utløpt sertifikat fra en betrodd sertifikatutsteder
• har et sertifikatnavn som passer MX-verten

I enforce skal en avsender som støtter MTA-STS ikke levere til en MX som feiler disse kontrollene.

MTA-STS beskytter ikke:

• forbindelsen mellom telefonen og e-postleverandøren
• lagrede meldinger hos avsender eller mottaker
• meldingsinnholdet ende til ende
• mot phishing fra forvekslingsdomener
• mot en kompromittert ekte konto
• all e-post fra avsendere som ikke støtter standarden

Det erstatter heller ikke SPF, DKIM eller DMARC. De vurderer avsenderidentitet; MTA-STS vurderer transporten til mottakerens MX-system.

Fire deler må virke sammen

DNS-posten inneholder ikke hele MTA-STS-policyen. Den peker heller ikke til en valgfri URL. Standarden konstruerer HTTPS-adressen fra policydomenet og det faste mta-sts-navnet.

MTA-STS-indikatoren i DNS

For dittfirma.no kan indikatoren se slik ut:

_mta-sts.dittfirma.no TXT "v=STSv1; id=20260822a"

v=STSv1 velger versjonen. id er en kort identifikator for nøyaktig denne policyrevisjonen. Den trenger ikke være en dato, men en tidsbasert verdi er lett å drifte. Tillatte verdier er opptil 32 bokstaver og sifre.

Endre id hver gang innholdet i policyfilen endres. Avsendere kan sammenligne ID-en med den de har i cache og hente ny policy når den er forskjellig. En uendret ID kan gjøre at endringen ikke oppdages raskt.

Publiser ikke indikatoren før HTTPS-policyen er tilgjengelig og validert. En gyldig TXT-post med en policyfil som ikke kan hentes, skaper rapporterte feil og gjør utrullingen vanskeligere å forstå.

Policyfilen over HTTPS

Policyen må hentes fra nøyaktig:

https://mta-sts.dittfirma.no/.well-known/mta-sts.txt

HTTPS-verten trenger gyldig offentlig DNS, et gyldig sertifikat for mta-sts.dittfirma.no og stabil tilgjengelighet. Responsen bør ha medietype text/plain.

En policy i testmodus kan være:

version: STSv1
mode: testing
mx: mx1.mailleverandor.example
mx: mx2.mailleverandor.example
max_age: 604800

Eksempelnavnene skal erstattes med de faktiske MX-vertsnavnene leverandøren bruker. Hver MX-verdi står på sin egen linje.

Feltene i policyen

max_age kan være opptil 31 557 600 sekunder. En lang levetid styrker motstand mot at senere policyoppslag blokkeres, men gjør også feil og avvikling tregere å rulle tilbake. Velg levetid som del av endrings- og beredskapsplanen, ikke fra en generatorstandard dere ikke forstår.

Vær forsiktig med jokertegn

Et mønster som:

mx: *.mailleverandor.example

matcher én venstre etikett, som mx1.mailleverandor.example, men ikke selve mailleverandor.example eller a.b.mailleverandor.example.

Bruk den smaleste policyen leverandøren dokumenterer. Et bredt mønster under et domene der mange aktører kan opprette vertsnavn og sertifikater, kan godkjenne flere servere enn ønsket.

testing, enforce og none

testing betyr ikke at policyfilen kan være tilfeldig. Den skal beskrive det planlagte sluttbildet slik at rapportene viser reelle avvik før håndheving.

enforce betyr normalt midlertidig leveringsfeil og nye forsøk når ingen gyldig MX kan brukes. Det er bedre enn å levere til en mulig angriper, men en varig feilkonfigurasjon kan til slutt føre til retur når avsenders køperiode utløper.

TLS-RPT-posten

RFC 8460 definerer rapporteringen. DNS-posten for dittfirma.no ligger på:

_smtp._tls.dittfirma.no TXT "v=TLSRPTv1; rua=mailto:tlsrpt@dittfirma.no"

rua kan være en mailto:-adresse eller en HTTPS-adresse som rapportmottakeren støtter. Flere mål kan angis, men rapportøren kan velge å levere til ett støttet mål.

Rapportene er aggregerte JSON-data. De kan inneholde:

• avsenderorganisasjon og rapportperiode
• hvilken policy som ble brukt
• MX-vert og mottaksserver
• antall vellykkede økter
• feiltype og antall feilede økter
• sendende MTA-IP og tilleggskontekst

TLS-RPT endrer ikke leveringsbeslutningen. Det er rapportering, ikke håndheving. Rapporter kan likevel være falske eller skadelige som all annen innkommende data. Behandle komprimering, JSON, lenker og vedlegg i et isolert, begrenset system.

En vanlig innboks er sjelden nok. Det bør finnes parser, tilgangsstyring, varselterskel, eier og lagringstid.

Forbered alle MX-verter

Hent den aktive MX-listen:

dig dittfirma.no MX +short

For hver MX-kandidat må dere bekrefte:

• at vertsnavnet er forventet og tilhører aktiv leverandør
• at A- og/eller AAAA-oppslag virker
• at port 25 svarer fra relevante nettverk
• at serveren annonserer STARTTLS
• at TLS-håndtrykket lykkes
• at sertifikatkjeden er gyldig og ikke utløpt
• at sertifikatets SAN passer MX-navnet
• at navnet er dekket av én mx:-linje i policyen

Test også lavere prioriterte MX-er. En reserve kan se ubrukt ut fordi primærserveren alltid svarer, men blir kritisk under en hendelse. MTA-STS-feil på reserveveien oppdages noen ganger først når primæren er nede.

En tekniker kan inspisere STARTTLS uten å sende legitimasjon:

openssl s_client -starttls smtp -connect mx1.mailleverandor.example:25 -servername mx1.mailleverandor.example

Kommandoen tester én forbindelse fra ett sted. Den erstatter ikke leverandørens overvåking eller rapportdata fra mange avsendere.

En kontrollert innføringsplan

Fase 0: avklar ansvar og støtte

MTA-STS-policyen beskriver e-postleverandørens innkommende infrastruktur. Be leverandøren bekrefte:

• eksakte MX-mønstre som skal brukes
• at alle kandidater har stabil STARTTLS og riktige sertifikater
• hvordan MX- og sertifikatendringer varsles
• om leverandøren tilbyr eller forvalter MTA-STS
• hvem som håndterer en leveringshendelse

Ikke bygg policyen ved å gjette mønstre fra dagens DNS alene dersom leverandøren kan endre vertsnavn.

Fase 1: publiser TLS-RPT

Start rapportmottaket og bekreft at parser, eierskap og varsler fungerer. TLS-RPT kan gi transportdata også når MTA-STS-policyen ikke er i enforce.

Fase 2: publiser testing-policy

1. Gjør HTTPS-verten og policyfilen tilgjengelig.
2. Kontroller innhold, medietype og sertifikat eksternt.
3. Publiser _mta-sts-indikatoren med en unik ID.
4. Bekreft DNS hos alle autoritative navnetjenere.
5. Følg TLS-RPT og leverandørlogger.

Et enkelt HTTP-kontrollpunkt er:

curl -i https://mta-sts.dittfirma.no/.well-known/mta-sts.txt

Kontroller status, sertifikat, Content-Type og at responskroppen er nøyaktig policyteksten.

Fase 3: rett alle avvik

Vanlige TLS-RPT-feil gjelder:

• manglende STARTTLS
• sertifikat som er utløpt
• sertifikatnavn som ikke matcher MX-verten
• ukjent sertifikatutsteder eller brutt kjede
• MX-navn som ikke er dekket av policyen
• policyfil som ikke kan hentes eller parses
• DNS- eller tilkoblingsfeil

Skill enkelthendelser fra systematiske feil. En vedvarende feil på én reserve-MX må rettes selv om nesten all trafikk lykkes på primærserveren.

Fase 4: gå til enforce med tilbakeføring klar

Gå først til enforce når:

• alle aktive MX-kandidater er dekket og validert
• rapportperioden inkluderer normale og sjeldne driftsmønstre
• sertifikatfornyelse er overvåket
• DNS-, web- og e-postansvarlige er navngitt
• tilbakeføring og eskalering er dokumentert

Oppdater policyfilen til mode: enforce før dere publiserer en ny ID i TXT-posten. Det reduserer risikoen for at en avsender ser ny ID og henter gammel fil.

Endre MX uten å bryte cachede policyer

Avsendere kan bruke en tidligere policy helt til dens max_age utløper. Ved leverandør- eller MX-bytte må gammel og ny verden overlappe:

1. Legg nye MX-mønstre i policyfilen mens gamle fortsatt finnes.
2. Publiser ny policy-ID.
3. Vent til oppdateringen er hentet bredt og cachevinduet er forstått.
4. Endre MX etter migreringsplanen.
5. Hold gamle, policygyldige mottaksveier operative lenge nok.
6. Fjern gamle mønstre først når både DNS- og policycacher er ute av risikovinduet.

En rask MX-endring etterfulgt av umiddelbar sletting av gammel infrastruktur kan gjøre at avsendere med cachet policy ikke finner en gyldig leveringsvei.

Tilbakeføring er ikke øyeblikkelig

En feil enforce-policy kan ligge i avsenders cache. Å slette TXT-posten gir ikke nødvendigvis umiddelbar effekt. Kontrollert avvikling etter RFC 8461 er:

1. Publiser en ny policy med mode: none og kort max_age, for eksempel én dag.
2. Publiser en ny TXT-ID som utløser henting.
3. Behold policyverten tilgjengelig.
4. Vent til alle tidligere policyer kan forventes utløpt.
5. Fjern deretter DNS-indikator og HTTPS-endepunkt dersom ordningen skal avvikles helt.

Ved en akutt feil bør selve mottaksinfrastrukturen og policyfilen først bringes tilbake til en kombinasjon som de cachede policyene aksepterer. Derfor skal den forrige policyen, sertifikatstatusen og gamle MX-veier være dokumentert før endring.

MTA-STS mot DANE

DANE for SMTP bruker DNSSEC og TLSA-poster til å autentisere SMTP-tjenesten. MTA-STS bruker DNS for oppdagelse, HTTPS for policy og den offentlige sertifikatinfrastrukturen for identitet.

De er ikke identiske erstatninger:

Når de overlapper, skal en MTA-STS-validering ikke overstyre en feilende DANE-validering. Valget avhenger av e-postleverandør, DNSSEC-drift og hvilke avsendere som støtter mekanismene.

Produktgrensen hos Vymo

Vymos publiserte e-postpakker oppgir postkasse, webmail, klienttilgang samt spam- og virusfilter. De lover ikke kundestyrt MTA-STS, TLS-RPT, DANE eller håndhevet partner-TLS som standardfunksjon.

Før dere publiserer policy for en Vymo-konto, send MX-listen og det konkrete transportkravet til kundeservice . Vi må bekrefte vertsnavn, sertifikatansvar, støtte og endringsrutine. Del aldri passord eller private nøkler.

For konteksten rundt transport og innhold, les e-postkryptering og valg av sikker kanal . Trenger dere vanlige postkasser på eget domene, finner dere Vymos e-postpakker og priser .