MTA-STS antaa vastaanottavan toimialueen julkaista odotuksia todennettua TLS toimitusta varten. Se osoittaa SMTP yhteyden vastaanottavaan palveluun. Se ei todenna viestin kirjoittajan Lähettäjä-osoitetta tai salaa viestiä aina yhden henkilön laitteelta toiselle.
Toimiva käyttöönotto yhdistää kolme asiaa: toimialueen todelliset saapuvat MX reitit, HTTPS-käytännön ja DNS tietueen, joka ilmoittaa tämän käytännön. TLS -raportointi tarjoaa erillisen palautepolun.
Aseta todellinen vastaanottoraja
Viitteet: RFC 8461 §3.4, RFC 8461 §4.
Luettelo MX -isännät, jotka hyväksyvät postia verkkotunnukselle, mukaan lukien varmuuskopiointipalvelut ja ylävirran suojausyhdyskäytävä. Tarkista TLS ja varmenteen käyttäytyminen todellisella julkisen vastaanottajan rajalla, ei vain sisäisellä postilaatikkopalvelimella.
Tallenna kuka omistaa MX reitin, käytäntöjen isännöinnin, varmenteen uusimisen ja raportointikohteen. Isännöity postilaatikkopalvelu ei välttämättä isännöi asiakkaan MTA-STS käytäntöä tai käytä kaikkia sen edessä olevia yhdyskäytäviä.
Arvioi aliverkkotunnukset erikseen. MTA-STS ei käytä DMARC-tyylistä vanhempien käytäntöjen periytymistä. Vastaanottava aliverkkotunnus tarvitsee kyseiseen verkkotunnukseen sovellettavat määritykset.
Luo käytäntö todellisille isännille
Viitteet: RFC 8461 §3.2, RFC 8461 §3.3.
Käytä käytäntöä vastaanottavan verkkotunnuksen vaaditusta HTTPS-sijainnista. example.com , sijainti on https://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS-palvelu tarvitsee kelvollisen varmenteen käytäntöään varten.
Käytäntö tunnistaa sen version, tilan, sallitut MX mallit ja välimuistin enimmäiskeston. Aloita laajuuteen sopivalla testauksen käyttöönotolla ja tarkista tulokset ennen täytäntöönpanoa. Valitse havaintojakso todellisesta liikenteestä ja riippuvuuksista sen sijaan, että käsittelet otoksen kestoa yleisenä todisteena.
Kuvaava käytäntö kuvitteelliselle yhden MX-verkkotunnukselle on:
versio: STSv1-tila: testaus mx: mx1.example.net max_age: 86400Tässä esimerkissä oletetaan, että mx1.example.net on toimialueen todellinen vastaanottava isäntä ja sillä on asianmukainen SMTP TLS -tuki. Se ei ole valmis käytäntö toiselle palveluntarjoajalle. Yhdistä sallitut isännät tarkasti ja sisällytä kaikki lailliset vastaanottoreitit.
Julkaise löytö ja raportointi erikseen
Viitteet: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
Osoitteessa _mta-sts.example.com kuvaava TXT arvo on v=STSv1; id=2026110701. Tunniste on merkki politiikan muutoksesta. Julkaise ja vahvista käytäntö ennen kuin julkaiset sen uuden version DNS ssä.
TLS-RPT käyttää omaa tietuettaan osoitteessa _smtp._tls.example.com . Esimerkkipyyntö on v=TLSRPTv1; rua=mailto:tls-reports@example.com, olettaen, että osoite on olemassa ja sen keräyspolku toimii.
Älä oleta a DMARC rua-kohde vastaanottaa automaattisesti TLS raportit tai pelkkä MTA-STS -testaus luo toimivan raportointipyynnön. Tarkista jokainen tietue oikealla nimellä ja jokainen kohde omalla keräysprosessillaan.
Testaa käytössä oleva ketju
Viitteet: RFC 8461 §4, RFC 8461 §6.
Hae käytäntö ulkoisesti ja varmista, että vaadittu HTTPS-päätepiste palvelee tarkoitettua pelkkätekstitekstiä HTTP 200:n kanssa. Älä seuraa HTTP-uudelleenohjauksia: uudelleenohjaus ei ole kelvollinen käytäntöhaku RFC 8461 §3.3:n mukaisesti. Tarkista Discovery DNS ja vertaa kaikkia mainostettuja MX reittejä sallittuihin malleihin.
Testaa SMTP TLS ja varmenteen validointia jokaisella vastaanottavalla reitillä. Toimiva verkkosertifikaatti osoitteessa mta-sts.example.com ei vahvista, että MX palvelin esittää kelvollista SMTP varmennetta.
Tarkista saatavilla olevat TLS -raportit ja valvotut toimitukset. Lähetyspalvelut vaihtelevat osallistumisen suhteen, joten hiljaisuus ei takaa yleistä menestystä. Säilytä reportteri, intervalli ja vaikutuksen alainen MX jokaisen havainnon yhteydessä.
Synteettisessä tapauksessa käytäntö sallii vain pääyhdyskäytävän, kun taas DNS mainostaa myös vara- MX . Varmuuskopio hyväksyy postin tavallisissa testeissä, mutta epäonnistuu käytäntöjen yhteensovittamisessa. Korjaa käytäntö tai reitityssuunnitelma ennen täytäntöönpanoa; älä hylkää varmuuskopiota, koska sen päivittäinen määrä on pieni.
Suunnittele täytäntöönpano ja palautus välimuistien ympärille
Viitteet: RFC 8461 §5, RFC 8461 §8.3.
Pakota tila voi estää tukevia lähettäjiä toimittamasta yhteensopivan yhteyden kautta. Ei-tuevat lähettäjät eivät kuulu tämän varmuuden piiriin. Kirjaa ylös riippuvuus ja hyväksyttävä toimintavaste ennen tilan vaihtamista.
Lähettäjien välimuistit voivat säilyttää voimassa olevat aikaisemmat käytännöt niiden max_age. DNS etsinnän poistaminen tai HTTPS-päätepisteen poistaminen ei ole välitön globaali palautus. Peruuttamista varten julkaise kelvollinen tila: ei mitään käytäntöä, jonka käyttöikä on lyhyt, ja päivitä sitten hakutunnus. Pidä molemmat päätepisteet saatavilla, kunnes kaikki aikaisemmat käytännöt ovat vanhentuneet, mukaan lukien vanhemmat versiot, joiden käyttöikä on pidempi. Laske jokainen käyttöaika siitä, kun kyseinen versio viimeksi toimitettiin, ei vain seuraavasta muokkauksesta.
Yhdyskäytävän siirtoa varten tee käytännöstä yhteensopiva suunnitellun siirtymän kanssa, tarkista uusi reitti ja salli välimuistiversiot. Pidä käytännön päätepiste saatavilla, kun asiaankuuluvat lähettäjät voivat edelleen luottaa siihen.
Siirron tulisi liittyä MX kokoonpanoon, käytäntöhistoriaan, varmenteen omistajuuteen ja raporttien käsittelyyn. MTA-STS pysyy hyödyllisenä, kun nämä liikkuvat osat huolletaan yhdessä.