MTA-STS'i testing'den enforce'a: policy dosyası, DNS ve HTTPS sunumunu doğru kurmak
MTA-STS kurmak DNS'e bir TXT satırı atmak değildir; asıl risk enforce moduna erken geçip meşru postayı çöpe atmaktır. Policy dosyası, DNS kaydı ve HTTPS sunumunu doğru kurup TLSRPT verisiyle güvenle enforce'a geçmenin sahadan disiplinini anlatıyoruz.
EvilMail Team19 Temmuz 202611 dk okuma
Geçen ay bir müşteri denetim raporuyla geldi: "evilmail.pro'ya giden postalarımızın bir kısmı şifresiz teslim edilebiliyor." Haklıydı. STARTTLS fırsatçıdır (opportunistic); gönderen MTA, alıcının 250-STARTTLS yeteneğini görmezse sessizce düz metne düşer. Aradaki aktif bir saldırgan tam da bunu istismar eder: SMTP banner'ından STARTTLS satırını siler, bağlantı plaintext kurulur ve hiçbir taraf hata görmez. Buna STARTTLS stripping denir; fırsatçı TLS'in yapısal açığıdır.
MTA-STS (RFC 8461, 2018) bu downgrade'i kapatmak için var. Alan sahibi şunu ilan eder: "Bana posta gönderirken TLS zorunludur ve MX'lerimin sertifikası şu desenlere uymalı." Gönderen MTA bu politikayı bir kez çektikten sonra, düz metne düşürme girişimi teslimi durdurur. Ama iki keskin tuzak var: MTA-STS üç ayrı bileşenin (DNS TXT, HTTPS ile sunulan policy dosyası, MX–sertifika eşleşmesi) kusursuz hizalanmasını ister; ve enforce moduna kanıtsız geçerseniz meşru postayı reddedersiniz. Bu yazı üç bileşeni kurmayı, neden mode: testing ile başlanması gerektiğini ve enforce'a hangi veriyle geçileceğini anlatıyor.
MTA-STS aslında neyi çözüyor (ve neyi çözmüyor)
Mekanizma üç parçadan oluşur:
MTA-STS Kurulumu: Testing'den Enforce Moduna Güvenli Geçiş | evilmail.pro — EvilMail Blog
`_mta-sts` TXT kaydı: Bir sürüm etiketi ve bir policy id. Gönderen MTA önce buraya bakar; id değişmişse policy dosyasını yeniden çeker, değişmemişse önbelleğini kullanır.
HTTPS policy dosyası:https://mta-sts.<domain>/.well-known/mta-sts.txt adresinden, geçerli WebPKI sertifikasıyla sunulan sabit formatlı metin. Mod, izin verilen MX desenleri ve max_age burada tanımlanır.
MX eşleşmesi: Bağlantı kurulan MX'in gerçek sertifikasının, policy'deki mx: desenlerine ve WebPKI zincirine uyması.
Üçü hizalanmadan koruma çalışmaz. Ama daha kritik olan, MTA-STS'in neyi çözmediğidir:
Gönderen MTA desteklemiyorsa koruma yoktur. Birçok küçük posta sunucusu MTA-STS bilmez; onlar için bağlantı hâlâ fırsatçıdır. Bu "her şeyi çözen kalkan" değil, destekleyen gönderenler için bir sözleşmedir.
DNSSEC koruması sağlamaz._mta-sts TXT kaydının kendisi sahtelenebilir. Saldırgan TXT yanıtını düşürebilirse gönderen "policy yok" varsayar ve fail-open olur.
Teslim garantisi değil, downgrade korumasıdır. Amacı postayı ulaştırmak değil, ulaşırken şifreli kalmasını garantilemektir.
Bu yüzden MTA-STS ile DANE tamamlayıcıdır, rakip değil. DANE, DNSSEC + TLSA kayıtlarına dayanır ve WebPKI'ye hiç güvenmez; MTA-STS ise DNSSEC gerektirmez, WebPKI + HTTPS'e dayanır. İkisini aynı anda yayınlamak katmanlı savunmadır: DNSSEC'iniz varsa DANE, olmayan altyapılarda MTA-STS devreye girer.
DNS kaydı: `_mta-sts` TXT ve PolicyID mantığı
Somut kayıt şöyle görünür:
dns
_mta-sts.evilmail.pro. IN TXT "v=STSv1; id=20260704T090000"
_smtp._tls.evilmail.pro. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
id, policy dosyasının sürüm etiketidir; gönderen MTA bu değeri önbelleğe alır. Kural basit ama en çok yanılınan yer tam burası: policy dosyasını her değiştirdiğinizde `id`'yi de değiştirin. Tarih-zaman damgası (20260704T090000) yaygın bir konvansiyondur çünkü monotonik artar ve gözle okunur.
id'yi güncellemeden policy dosyasını değiştirirseniz ne olur? Gönderenler DNS'te aynı id'yi görür, "değişmemiş" der ve önbellekteki eski policy'yi max_age süresince kullanmaya devam eder. Yaptığınız değişiklik günlerce yayılmaz — üstelik hiçbir hata da almazsınız. Bu, MTA-STS'in en sinsi arıza modudur.
İkinci kayıt olan TLSRPT (RFC 8460), enforce'a geçmeden önce şart. rua adresine gönderenler her gün, kaç oturumun TLS ile başarılı/başarısız olduğunu bildiren JSON raporlar yollar. Bu raporlar olmadan testing modunda kör uçarsınız — policy'nizin gerçek trafiğe uyup uymadığını göremezsiniz.
Policy dosyası ve HTTPS sunumu — asıl tuzakların olduğu yer
Dosyanın adresi ve yolu sabittir, pazarlık yoktur: alt alan adı mutlakamta-sts, yol mutlaka.well-known/mta-sts.txt. testing ile başlayan içerik:
Ayrı bir A/AAAA kaydı:mta-sts.evilmail.pro kendi başına bir hosta çözülmeli. Kök domainle aynı sunucuya işaret edebilir ama alt alan adının kendisi gerçek olmalı.
Geçerli WebPKI sertifikası: Self-signed sertifika policy fetch'ini başarısız kılar. mta-sts.evilmail.pro için ayrı bir Let's Encrypt sertifikası alın; SNI ve zincir doğru kurulmalı.
`Content-Type: text/plain`: Sunucunuz bunu text/html verirse bazı istemciler policy'yi reddeder.
HTTP→HTTPS 301 yönlendirmesi OLMAMALI. İstemci policy'yi doğrudan HTTPS üzerinden ister; yönlendirme zinciri bazı gönderen implementasyonlarında policy'yi geçersiz kılar. Redirect yok, düz 200 dönün.
Sertifika fetch'i başarısız olursa istemci — enforce modunda bile — "policy yok" gibi davranır ve fail-open olur. Bu bilinçli bir tasarım: MTA-STS altyapınızın çökmesi postanızı tümden durdurmasın diye. Ama madalyonun öteki yüzü şu: sertifikanız sessizce süresi dolarsa korumanız da sessizce kapanır ve kimse fark etmez. Bu yüzden mta-sts sertifikasının yenilenmesini izlemeye bağlamak zorunludur.
`mode: testing` — neden buradan başlanır, ne zaman terk edilir
testing modunun tek işi şudur: MX eşleşmesi başarısız olsa bile posta yine teslim edilir, sadece TLSRPT'ye bir failure kaydı düşer. Yani üretimi hiç bozmadan, gerçek gönderen trafiğinin policy'nize uyup uymadığını ölçersiniz. Bu, MTA-STS'in dry-run modudur ve atlanmaması gereken bir güvenlik ağıdır.
testing'de yakaladığınız tipik hatalar:
`mx:` deseni sertifika CN/SAN'ı ile uyuşmuyor.mx: mail.evilmail.pro yazdınız ama MX'in sunduğu sertifikanın SAN'ında bu ad yok. Özellikle kiralık spam-filtre veya relay MX'lerinde host, bambaşka bir sağlayıcının sertifikasını sunar.
MX aslında farklı bir host. DNS'teki MX kaydı ile policy'deki desen ayrışır.
Wildcard kapsamı yetersiz.mx: *.evilmail.pro yalnızca tek seviye alt alanı kapsar; mail.eu.evilmail.pro eşleşmez.
TLSRPT raporlarını okumanın somut eşiği şudur: raporlardaki policies[].summary.total-failure-session-count değeri sıfıra inene ve orada kalana kadar bekleyin. Pratik kural: en az 7-14 gün boyunca, binlerce başarılı oturuma karşılık 0 policy-failure. Failure sayısı hâlâ hareketliyse enforce'a geçmek, o başarısız oturumlardaki gerçek postayı çöpe atmak demektir.
testing'den enforce'a güvenli geçiş
Geçişten önce şu ön koşulların hepsi doğru olmalı: tüm MX'lerin sertifikaları geçerli ve mx: desenleriyle eşleşiyor, policy fetch her ağdan 200 + text/plain dönüyor, TLSRPT en az bir haftadır temiz.
2.Policy dosyasındaki değişiklik yayında olduktan sonra DNS TXT'teki id'yi yeni damgayla güncelleyin.
Neden önce dosya, sonra TXT? Çünkü gönderen id değişimini görünce yeni dosyayı çeker. TXT'yi önce güncellerseniz, kısa bir pencere boyunca gönderenler yeni id'yi görüp hâlâ eski dosyayı çekebilir. Önce dosyayı hazır edin, sonra id ile "yeni sürüm var" sinyalini verin.
Rollback planı en baştan hazır olmalı: sorun çıkarsa policy'yi testing'e (veya none'a) çekin ve id'yi değiştirin. Ama şu gerçeği unutmayın — gönderenler policy'yi max_age kadar önbelleğe almıştır. enforce'ta max_age: 604800 verdiyseniz, bir gönderenin geri dönmesi bir haftaya kadar sürebilir. Bu yüzden max_age stratejisi iki fazlıdır: testing'de düşük tutun (86400 = 1 gün) ki hata düzeltmesi hızlı yayılsın; enforce'ta güvendikten sonra yükseltin (604800 veya daha uzun) ki koruma kalıcı olsun. Erken verilen uzun max_age, rollback'inizi felç eder.
Doğrulama ve sürekli izleme
Elle doğrulama komutları — her kurulum ve her id rotasyonundan sonra çalıştırın:
1.komuttaki SAN çıktısında mail.evilmail.pro (veya wildcard'ınızın kapsadığı ad) görünmüyorsa, policy'niz o MX için başarısız olur — testing'de bunu raporda, enforce'ta müşteri şikâyetinde görürsünüz.
Üçüncü parti doğrulayıcılar işi hızlandırır: Hardenize ve benzeri MTA-STS test araçları policy sözdizimini, sertifika zincirini ve redirect tuzağını sizin yerinize kontrol eder. Google Postmaster Tools ve Microsoft SNDS raporları da büyük gönderenlerin gözünden TLS başarısızlıklarını gösterir.
Sürekli izleme tek cümlede özetlenir: TLSRPT raporlarını bir mailbox'a toplayın ve haftalık policy-failure trendine bakın. evilmail.pro tarafında bu raporları ayrıştırıp total-failure-session-count'un haftalık grafiğini çıkarıyoruz; sıfır olması gereken bir çizginin yukarı kıpırdaması, ya bir MX sertifikasının süresinin dolduğunu ya da bir MX'in policy dışına çıktığını anında haber verir.
Enforce'a geçmeden önce operasyonel checklist
_mta-sts TXT kaydı yayında ve id güncel policy dosyasıyla eşleşiyor.
_smtp._tls TLSRPT kaydı yayında ve rua mailbox'ı raporları alıyor.
Rollback prosedürü yazılı: mode'u testing'e çek + id rotasyonu, max_age gecikmesi hesaba katılmış.
mta-sts sertifika yenilemesi ve id rotasyonu izlemeye/alarmlamaya bağlı.
id rotasyonu ve sertifika yenileme, MTA-STS'in iki sessiz kırılma noktasıdır — biri değişikliğinizi yaymaz, diğeri korumanızı sessizce kapatır. İkisini de izlemeye bağlamadan enforce'a geçmeyin.
