Az MTA-STS és a TLS-RPT rövid magyarázata
Az MTA-STS és a TLS-RPT két olyan beállítás a domainhez, amelyek a beérkező levelek titkosításával kapcsolatosak. Ezekkel találkozhat olyan tesztekben, mint az internet.nl, vagy egy biztonsági vizsgálat jelentésében. Ebben a cikkben olvashat arról, mit csinálnak, hogyan néznek ki, és szükség van-e rájuk. Rövid válasz előre: a legtöbb ügyfélnek nincs rá szüksége.
Mit old meg?
Amikor egy levelezőszerver levelet kézbesít a címzett levelezőszerverének, a kapcsolatot titkosítják, ha lehetséges (STARTTLS). Ha ez nem sikerül, a levél általában egyszerűen titkosítatlanul megy tovább. A fogadó szerver tanúsítványát emellett gyakran nem ellenőrzik szigorúan. Aki útközben módosítani tudja a forgalmat, ezáltal kikapcsolhatja a titkosítást, vagy a levelet saját szerverére irányíthatja.
Az MTA-STS segítségével fogadóként tudathatja: a domainemre érkező leveleket mindig titkosítani kell, és csak ezekre a levelezőszerverekre, érvényes tanúsítvánnyal. Az MTA-STS-t támogató küldő ehhez tartja magát.
Az MTA-STS két összetevője
1. Egy TXT-rekord a _mta-sts néven, amely jelzi, hogy létezik szabályzat:
_mta-sts.jouwdomein.nl. TXT "v=STSv1; id=20261108T120000;"
Az id egy verziószám, amelyet Ön választ ki. Ha módosítja a szabályzatot, változtassa meg az id-t is, hogy a küldők lekérjék az új szabályzatot.
2. Egy szabályzatfájl pontosan ezen a címen, https-en keresztül, érvényes tanúsítvánnyal:
https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Sor | Jelentés |
|---|---|
mode: testing | A küldők a szokásos módon kézbesítenek, de a problémákat TLS-RPT-n keresztül jelzik. Ezzel kezdje. |
mode: enforce | A küldők csak titkosított kapcsolaton keresztül kézbesítenek, érvényes tanúsítvánnyal, az egyik megadott levelezőszerverhez. Ha ez nem sikerül, a levél a küldőnél a várakozási sorban marad. |
mode: none | Nincs (már) szabályzat. |
mx: | A levelezőszerver neve, pontosan úgy, ahogyan az MX-rekordban szerepel. Ha több MX-rekord van, minden nevet külön sorba kell helyezni. Egy WebOké csomag esetén ez általában a csomag szervernevéhez tartozik, ahogy a példában is látható; levelezőszerverünk tanúsítványa erre a névre szól. Ha az MX a saját domainnevére mutat, előfordulhat, hogy a tanúsítvány nem illik hozzá, ezért nem szabad az enforce módot használni. |
max_age: | Meddig jegyezheti meg a küldő a szabályzatot, másodpercben megadva. A 604800 egy hetet jelent. |
A küldő megjegyzi a szabályzatot. Emiatt az MTA-STS nem véd az első alkalommal, amikor egy küldő levelet küld Önnek, de azután igen.
TLS-RPT: jelentések a titkosításról
A TLS-RPT segítségével napi jelentést kérhet a küldőktől a sikertelen titkosításról, például lejárt tanúsítvány vagy a szabályzatban nem szereplő levelezőszerver-név miatt. Ez egyetlen TXT-rekord a _smtp._tls néven:
_smtp._tls.jouwdomein.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@jouwdomein.nl"
A jelentések technikai fájlok (JSON). A DMARC-jelentésekhez hasonlóan ehhez is használjon külön postafiókot. Lásd: Egy DMARC-jelentés olvasása.
A sorrend: először TLS-RPT, majd MTA-STS testing módban, néhány hétig jelentések olvasása, és csak ezután enforce.
MTA-STS vagy DANE?
A DANE ugyanazt teszi, más módon: a levelezőszerver tanúsítványának ujjlenyomata a DNS-ben található (egy TLSA-rekordban), DNSSEC-kel védve. A DANE az első kapcsolatot is védi, de csak akkor működik, ha a DNSSEC be van kapcsolva. Az MTA-STS-hez nincs szükség DNSSEC-re, viszont egy tanúsítvánnyal rendelkező weboldalra igen. A kettő egymás mellett is használható; a DANE-t támogató küldő ilyenkor a DANE-nek ad elsőbbséget.
Ha a levelezése a WebOkénál van, a DANE-t a Fiókomban kapcsolhatja be, ugyanott, ahol a DNSSEC-et. A WebOké ezután saját maga gondoskodik a TLSA-rekordokról. Olvassa el: DNSSEC és DANE és Internet.nl-ellenőrzőlista: 100%-ot elérni a weboldalával és e-mailjével.
Szükség van rá?
A legtöbb ügyfél esetében nincs. A nagy levelezőszerverek közötti levelezés manapság szinte mindig titkosított, és ha a WebOkénál szeretné extra módon védeni a leveleit, a DANE a legegyszerűbb lépés. Az MTA-STS elsősorban akkor hasznos, ha a szervezete előírja, vagy ha olyan címzetteket vár, akik MTA-STS-t használnak, de DANE-t nem. A saját kimenő levelezéséhez nem kell semmit beállítania: ezt a levelet küldő szerver határozza meg.
Önálló beállítás egy tárhelycsomagnál
A két TXT-rekordot a DirectAdmin DNS Kezelés menüpontjában, vagy a Fiókom DNS lapján állíthatja be. Lásd: DNS-rekordok kezelése a Fiókomban (példákkal CNAME, TXT és külső szolgáltatások esetére).
A szabályzatfájlnak az mta-sts aldomainen kell lennie. A csomagjában ezt az aldomaint az Aldomain Kezelés menüpontban hozhatja létre; a DirectAdmin ekkor automatikusan SSL-tanúsítványt igényel hozzá. Lásd: Aldomainek létrehozása és törlése és Tanúsítvány www, aldomainek és wildcard számára. Az aldomain mappájában hozzon létre egy .well-known mappát, benne az mta-sts.txt fájllal.
enforce módba. Ha egy levelezőszerver-név nem megfelelő, vagy a levelezőszerver tanúsítványa nem illik ahhoz a névhez, akkor az MTA-STS-t követő küldőktől nem érkezik be több levél. A szabályzatfájlnak emellett közvetlenül megnyithatónak kell lennie: a küldők nem követik a más címre mutató átirányítást. Kezdje testing móddal, olvassa el a TLS-RPT-jelentéseket, és kétség esetén vegye fel velünk a kapcsolatot.Háttér: RFC 8461 (MTA-STS) és RFC 8460 (TLS-RPT).