MTA-STS låter en mottagande domän publicera förväntningar på autentiserad TLS leverans. Den adresserar SMTP anslutningen till den mottagande tjänsten. Det autentiserar inte meddelandeförfattarens Från-adress eller krypterar meddelandet hela vägen från en persons enhet till en annan.
En fungerande distribution kopplar samman tre saker: domänens faktiska inkommande MX rutter, HTTPS-policyn och DNS posten som signalerar den policyn. TLS -rapportering tillhandahåller en separat återkopplingsväg.
Fastställ den verkliga mottagningsgränsen
Referenser: RFC 8461 §3.4, RFC 8461 §4.
Lista de MX värdar som accepterar e-post för domänen, inklusive säkerhetskopieringstjänster och en uppströms säkerhetsgateway. Verifiera TLS och certifikatbeteende på den faktiska offentliga mottagningsgränsen, inte bara på en intern postlådeserver.
Registrera vem som äger MX rutten, policyvärd, certifikatförnyelse och rapporteringsdestination. En värdbaserad postlådetjänst är inte nödvändigtvis värd för kundens MTA-STS policy eller driver varje gateway framför den.
Bedöm underdomäner separat. MTA-STS använder inte DMARC-liknande föräldrapolicyarv. En mottagande underdomän behöver den konfiguration som gäller för den domänen.
Bygg en policy för de faktiska värdarna
Referenser: RFC 8461 §3.2, RFC 8461 §3.3.
Servera policyn från den nödvändiga HTTPS-platsen för den mottagande domänen. Till example.com är platsen https://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS-tjänsten behöver ett giltigt certifikat för dess policyvärdnamn.
Policyn identifierar dess version, läge, tillåtna MX mönster och maximal cachelivslängd. Börja med en testimplementering som är lämplig för omfattningen och inspektera resultaten innan verkställighet. Välj observationsperioden från den verkliga trafiken och beroenden istället för att behandla en provlängd som ett universellt bevis.
En illustrativ policy för en fiktiv enkel-MX-domän är:
version: STSv1-läge: testning mx: mx1.example.net max_age: 86400Det här exemplet förutsätter att mx1.example.net är domänens faktiska mottagande värd och har lämpligt SMTP TLS stöd. Det är inte en färdig policy för en annan leverantör. Matcha tillåtna värdar exakt och inkludera alla legitima mottagningsvägar.
Publicera upptäckt och rapportering separat
Referenser: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
På _mta-sts.example.com är ett illustrativt TXT värde v=STSv1; id=2026110701. Identifieraren signalerar en policyrevision. Publicera och verifiera policyn innan du annonserar den nya versionen i DNS .
TLS-RPT använder sin egen post på _smtp._tls.example.com . En illustrativ begäran är v=TLSRPTv1; rua=mailto:tls-reports@example.com, förutsatt att adressen finns och dess insamlingsväg fungerar.
Anta inte a DMARC rua destination tar automatiskt emot TLS rapporter, eller att MTA-STS -testning ensam skapar en fungerande rapportbegäran. Verifiera varje post med rätt namn och varje destination genom sin egen insamlingsprocess.
Testa den utplacerade kedjan
Referenser: RFC 8461 §4, RFC 8461 §6.
Hämta policyn externt och bekräfta att den nödvändiga HTTPS-ändpunkten betjänar den avsedda texten i klartext med HTTP 200. Följ inte HTTP-omdirigeringar: en omdirigering är inte en giltig policyhämtning enligt RFC 8461 §3.3. Kontrollera upptäckts- DNS och jämför alla annonserade MX rutter med tillåtna mönster.
Testa SMTP TLS och certifikatvalidering vid varje mottagande rutt. Ett fungerande webbcertifikat på mta-sts.example.com fastställer inte att MX servern presenterar ett giltigt SMTP certifikat.
Granska tillgängliga TLS rapporter och kontrollerade leveransbevis. Att skicka tjänster skiljer sig åt i deltagande, så tystnad skapar inte universell framgång. Behåll reportern, intervallet och berörda MX vid varje observation.
I ett syntetiskt fall tillåter en policy endast huvudgatewayen medan DNS även annonserar en backup MX . Säkerhetskopieringen accepterar post i vanliga tester men klarar inte policymatchningen. Reparera policyn eller routingdesignen innan verkställighet; avvisa inte säkerhetskopian eftersom dess dagliga volym är liten.
Planera verkställighet och återhämtning runt cacher
Referenser: RFC 8461 §5, RFC 8461 §8.3.
Tillämpningsläge kan förhindra att stödjande avsändare levererar via en icke-kompatibel anslutning. Icke-stödjande avsändare är utanför denna garanti. Registrera beroendet och acceptabelt driftsvar innan du byter läge.
Avsändarcachar kan behålla giltiga tidigare policyer för sin max_age. Att ta bort upptäckts- DNS eller ta bort HTTPS-slutpunkten är inte en omedelbar global återställning. För uttag, publicera ett giltigt läge: ingen policy med kort livslängd, uppdatera sedan upptäckts-id:t. Håll båda slutpunkterna tillgängliga tills alla tidigare policyer har löpt ut, inklusive äldre versioner med längre livslängd. Räkna varje livstid från när den versionen senast visades, inte bara från nästa redigering.
För en gatewaymigrering, gör policyn kompatibel med den planerade övergången, verifiera den nya rutten och tillåt cachade versioner. Håll policyslutpunkten tillgänglig medan relevanta avsändare fortfarande kan lita på den.
Överlämningen bör ansluta sig till MX -konfiguration, policyhistorik, certifikatägande och rapporthantering. MTA-STS förblir användbar när de rörliga delarna hålls ihop.