MTA-STS Nedir ve E-posta TLS Teslimatını Nasıl Korur?

Sesli Dinle — Makale

MTA-STS (SMTP MTA Strict Transport Security), alıcı alan adının posta sunucularına hangi adlarla ve hangi TLS koşullarıyla bağlanılacağını bildiren bir güvenlik mekanizmasıdır. E-postayı sunucular arasında taşıyan SMTP için kullanılır.

Posta aktarımı yapan MTA (Mail Transfer Agent) sistemleri, alıcı alan adının MX kayıtlarında belirtilen sunuculara bağlanır. MTA-STS, bu hedeflerin alan adının yayımladığı politikayla eşleşmesini ve TLS bağlantısının doğrulanmasını sağlar. Geçerli enforce politikası varken uyumlu gönderen, yalnız izin verilen MX sunucusuna, bağlantıyı şifreli hale getiren STARTTLS komutu üzerinden ve güvenilir sertifika doğrulamasıyla teslimat yapar.

SMTP aktarımında TLS çoğu zaman fırsatçı biçimde kullanılır. STARTTLS sunulmazsa veya bağlantı sırasında bu yetenek gizlenirse gönderen sunucu şifresiz teslimata dönebilir; MTA-STS, önceden alınmış geçerli bir enforce politikası üzerinden bu geri dönüşü sınırlar.

MTA-STS, e-posta içeriğini uçtan uca şifrelemez ve alıcı posta kutusundaki veriyi koruma yöntemi değildir. Gönderim yapan IP adresinin alan adı için yetkisini denetleyen SPF (Sender Policy Framework), iletiyi kriptografik imzayla doğrulayan DKIM (DomainKeys Identified Mail) ve bu sonuçları görünen From (Gönderen) alan adıyla ilişkilendiren DMARC (Domain-based Message Authentication, Reporting, and Conformance) gibi gönderen kimliği denetimlerinin yerine geçmez; yalnız sunucudan sunucuya SMTP teslimat yolundaki TLS ve hedef sunucu doğrulamasına odaklanır.

Politika iki parçadan oluşur: DNS üzerindeki _mta-sts TXT işaret kaydı ve şifreli web bağlantısı sağlayan HTTPS üzerinden sunulan politika dosyası. DNS kaydı politikanın varlığını ve sürüm kimliğini duyurur; politika dosyası ise izin verilen MX adlarını, çalışma modunu ve önbellek süresini tanımlar.

MTA-STS Politikasının Teslimata Etkisi

• Alıcı alan adı, kabul ettiği MX sunucu adlarını açıkça tanımlar.
• Gönderen sunucu, alıcı MX'in STARTTLS desteğini ve sertifikasını doğrular.
• enforce modunda doğrulamayı geçemeyen sunucuya teslimat yapılmaz.
• testing modu, zorunlu engelleme öncesinde yapılandırma hatalarının görülmesine yardımcı olur.
• Politika sürümü DNS'teki id değeriyle, içeriği ise HTTPS dosyasıyla yönetilir.

MTA-STS Nasıl Çalışır?

Gönderen MTA, alıcı alan adı için önbelleğinde geçerli bir politika varsa onu kullanır. Geçerli politika yoksa DNS işaret kaydını sorgular; geçerli kayıt bulduğunda veya kayıttaki id değerinin değiştiğini gördüğünde HTTPS politika dosyasını alır ve geçerlilik süresi boyunca önbelleğe kaydeder. E-posta tesliminde normal MX öncelik sırasını izlerken her adayın politika ve TLS koşullarına uyup uymadığını kontrol eder.

DNS İşaret Kaydı Politikayı Duyurur

Alan adının DNS bölgesinde _mta-sts alt alanında bir TXT kaydı yayımlanır. Örneğin example.com için kayıt adı _mta-sts.example.com olur. Kayıt v alanında STSv1 değerini, id alanında ise o politika sürümünü benzersiz biçimde tanımlayan kısa bir kimliği taşır. id değeri tarih olmak zorunda değildir; önemli olan politika değiştiğinde farklı bir değere dönüştürülmesidir.

Gönderenler, önbellekteki politika ile DNS'teki id değerini karşılaştırarak güncelleme olup olmadığını anlayabilir. Birden fazla geçerli STSv1 TXT kaydı yayımlamak veya kaydı sözdizimi açısından hatalı oluşturmak, politikanın keşfedilememesine yol açabilir.

HTTPS Dosyası Teslimat Koşullarını Tanımlar

Asıl politika, mta-sts alt alanında sabit /.well-known/mta-sts.txt yolundan HTTPS ile sunulur. Örneğin example.com için tam adres https://mta-sts.example.com/.well-known/mta-sts.txt olur. Politika sunucusunun sertifikası mta-sts ana bilgisayar adı için geçerli, süresi dolmamış ve gönderenin güvendiği bir sertifika otoritesine bağlı olmalıdır. Başarılı yanıtın HTTP 200 durum koduyla doğrudan verilmesi gerekir; 3xx yönlendirmeleri politika alımında izlenmez. Dosyanın düz metin olarak sunulması ve Content-Type başlığının text/plain medya türünü bildirmesi önerilir. Gönderen MTA, web sunucusunun HTTP önbellek başlıklarını politika süresi olarak kullanmaz; önbellek süresini politika içindeki max_age değeri belirler.

Dosyada version, mode ve max_age alanlarının bulunması zorunludur; none modu dışında en az bir mx değeri de gerekir. Her izin verilen MX adı ayrı bir mx satırıyla tanımlanır. max_age, gönderenin politikayı kaç saniye önbellekte tutabileceğini belirtir ve en fazla 31.557.600 saniye olabilir.

Gönderen Sunucu MX ve Sertifika Doğrulaması Yapar

Gönderen MTA, DNS'ten elde ettiği aday MX adını politikadaki mx kalıplarıyla karşılaştırır. Eşleşen sunucuya bağlandığında STARTTLS sunulmasını, TLS görüşmesinin tamamlanmasını ve sunulan sertifikanın bağlanılan MX ana bilgisayar adıyla eşleşmesini bekler.

MX sunucusu, süresi dolmamış ve güvenilen bir kök sertifikaya uzanan doğrulanabilir bir sertifika zinciri sunmalıdır. Bu denetim yalnız bağlantının şifrelenip şifrelenmediğini değil, gönderenin gerçekten politikada izin verilen posta sunucusuyla konuşup konuşmadığını da sınar.

enforce Modunda Başarısız Teslimatın Yeniden Denenmesi

Geçerli enforce politikası varken aday MX, STARTTLS veya sertifika doğrulamasını geçemezse uyumlu gönderen o sunucuya teslimat yapmaz. Diğer MX adayları normal öncelik sırasıyla denenebilir; hiçbir aday uygun değilse hata çoğu durumda geçici teslimat hatası olarak ele alınır ve ileti daha sonra yeniden denenir. İleti kalıcı olarak başarısız sayılmadan önce gönderen, DNS TXT kaydındaki id değerini yeniden kontrol etmeli ve yeni bir politika sürümü varsa onu almalıdır.

Bu davranış, yanlış yapılandırılmış bir politikada e-postaların gecikmesine neden olabilir. Bu nedenle politika zorunlu hale getirilmeden önce birincil ve yedek MX sunucularının tamamı doğrulanmalıdır.

MTA-STS Politika Modları Ne Anlama Gelir?

mode alanı, politika doğrulaması başarısız olduğunda gönderenin nasıl davranacağını belirler. testing modundan enforce moduna geçiş yalnız bir metin değişikliği değildir; alıcı altyapısının bütün MX yollarında TLS ve sertifika koşullarını karşılaması gerekir.

testing modu kendi başına teslimatı engellemez. Hataların rapor olarak görülebilmesi için gönderenin TLS-RPT'yi desteklemesi ve alıcı alan adının ilgili raporlama yapılandırmasına sahip olması gerekir; rapor kaydı ve rapor içeriği ayrı bir konudur.

MX Adı ve Sertifika Eşleşmesi Nasıl Planlanır?

Politikadaki mx alanları, gerçek DNS MX kayıtlarının öncelik değerlerini değil, kabul edilen ana bilgisayar adlarını tanımlar. Tam ad kullanılabileceği gibi yalnız en soldaki etiketi kapsayan yıldızlı bir kalıp da kullanılabilir. Örneğin yıldızlı bir alt alan kalıbı tek seviyedeki ana bilgisayarları eşleştirir; kök alan adını veya daha derin alt alanları otomatik olarak kapsamaz.

Gereğinden geniş bir yıldızlı kalıp, aynı alan altında geçerli sertifika alabilen fakat e-posta kabul etmemesi gereken sunucuları da politika kapsamında izinli sayabilir. Mümkün olduğunda gerçek MX adlarını açıkça listelemek ve e-posta hizmeti sağlayıcısı değişikliklerini kontrollü yönetmek, yetkisiz bir sunucunun politikayla eşleşme riskini azaltır.

Politikaya eklenen her MX için SMTP hizmetinin STARTTLS sunduğu ve sertifikanın bağlanılan MX adıyla eşleştiği doğrulanmalıdır. Sertifikanın yalnız alıcı e-posta alan adını kapsaması yeterli olmayabilir; gönderen, bağlantı kurduğu MX ana bilgisayar adını doğrular.

MTA-STS Kurulumu Nasıl Planlanır?

E-posta hizmeti sağlayıcısına veya barındırma modeline göre DNS ve web sunucusu adımları değişebilir. Önce testing modunda bütün MX yollarını denetlemek, ardından enforce politikasını yayımlamak teslimat gecikmesi riskini azaltır.

1. Tüm MX sunucularını envantere alın. Birincil, yedek ve yalnız arıza sırasında kullanılan MX adlarını; bunların STARTTLS davranışını ve sertifikalarını denetleyin.
2. Politika ana bilgisayarını hazırlayın. mta-sts alt alanını HTTPS hizmetine yönlendirin ve bu ad için geçerli bir web sertifikası kurun.
3. Politika dosyasını testing modunda yayımlayın. İzin verilen MX adlarını ayrı ayrı yazın ve ilk aşamada yönetilebilir bir max_age belirleyin.
4. _mta-sts TXT kaydını ekleyin. STSv1 sürümünü ve benzersiz id değerini yayımlayarak gönderenlerin politikayı keşfetmesini sağlayın.
5. Hataları düzeltin. Politika dosyasına erişim, web sertifikası, MX listesi, SMTP STARTTLS ve SMTP sertifika eşleşmesini birlikte kontrol edin.
6. enforce moduna kontrollü geçin. Tüm teslimat yolları doğrulandıktan sonra politika dosyasını güncelleyin, ardından TXT kaydındaki id değerini değiştirin.

Politika güncellenirken önce HTTPS dosyasının yeni içeriği yayımlanmalı, sonra DNS'teki id değiştirilmelidir. Böylece yeni id değerini gören gönderenin eski dosyayı yeniden önbelleğe alma ihtimali azaltılır. Eski MX yolları, DNS kayıtlarının TTL’si ve daha önce dağıtılmış max_age süreleri dolana kadar çalışır durumda tutulmalıdır.

Yaygın MTA-STS Yapılandırma Hataları

• _mta-sts TXT kaydı bulunmasına rağmen HTTPS politika adresinin erişilememesi.
• Politika ana bilgisayarının yanlış sertifika sunması, süresi dolmuş zincir kullanması veya yönlendirme döndürmesi.
• Birincil MX'in listelenip yedek MX'lerin politika dışında bırakılması.
• SMTP sunucusunun STARTTLS sunmasına rağmen sertifikanın gerçek MX adıyla eşleşmemesi.
• Politika dosyası değiştirildiği halde TXT kaydındaki id değerinin değiştirilmemesi.
• Test süreci tamamlanmadan enforce moduna ve uzun max_age değerine geçilmesi.
• E-posta hizmeti sağlayıcısı değişiminde eski ve yeni MX kümelerinin önbellek süreleri boyunca birlikte desteklenmemesi.

Özellikle yedek MX hataları normal trafikte görünmeyebilir; birincil sunucuya başarıyla teslimat yapan gönderenlerin yedek adayı denemesi gerekmez. Arıza anında ortaya çıkan uyumsuzluk, MTA-STS nedeniyle teslimatın ertelenmesine neden olabilir.

MTA-STS STARTTLS Düşürme Saldırısını Her Durumda Önler mi?

Fırsatçı SMTP TLS kullanımında aktif bir saldırgan STARTTLS ilanını bağlantıdan çıkararak tarafları şifresiz aktarım yapmaya yöneltebilir. Gönderen daha önce geçerli bir enforce politikası alıp önbelleğe kaydetmişse, TLS sunulmayan bağlantıyı kabul etmek yerine teslimatı erteler. Bu, şifresiz geri dönüşü ve politikaya uymayan MX'e teslimatı zorlaştırır.

MTA-STS mutlak koruma sağlamaz. İlk politika keşfi, DNS yanıtlarının kaynağını doğrulamaya yardımcı olan DNSSEC’i zorunlu kılmayan bir TXT sorgusuna dayandığı için daha önce politika almamış bir gönderende saldırgan keşfi engelleyebilir. Önbelleğe alınmış politika bu pencereyi daraltır; mekanizma ayrıca genel sertifika otoritesi sisteminin güvenilirliğine ve gönderen sunucunun MTA-STS desteğine bağlıdır.

MTA-STS Kaydı, Politika Dosyası ve MX Sunucularını Doğrulama

DNS kaydını ve politika dosyasını denetlemek, gerçek teslimat yollarının tümünün sorunsuz olduğunu tek başına kanıtlamaz. Aşağıdaki kontrolleri birincil ve yedek MX sunucularının tamamına uygulayın.

• _mta-sts altında yalnız bir geçerli STSv1 TXT kaydı bulunduğunu ve dosya her değiştiğinde id değerinin de güncellendiğini doğrulayın.
• Politika adresinin yönlendirme yapmadan HTTP 200 yanıtı verdiğini, dosyanın düz metin olduğunu ve Content-Type değerinin önerilen text/plain türünü bildirdiğini kontrol edin.
• Web sertifikasının politika ana bilgisayarıyla eşleştiğini, süresinin dolmadığını ve zincirinin güvenilir olduğunu doğrulayın.
• Tüm MX adlarının politikayla eşleştiğini, SMTP sunucularının STARTTLS sunduğunu ve sertifikalarının ilgili MX adlarını kapsadığını denetleyin.
• testing modundan enforce moduna geçmeden önce yedek MX sunucularını ve e-posta hizmeti sağlayıcısına özgü yönlendirmeleri gerçek posta akışıyla sınayın.

MTA-STS Politikası Nasıl Güncellenir veya Kaldırılır?

MTA-STS politikası yalnız kaydın yayımlanmasıyla tamamlanmaz; gerçek e-posta altyapısıyla sürekli uyumlu kalmalıdır. MX değişikliği, sertifika yenilemesi, e-posta hizmeti sağlayıcısı geçişi veya yedek sunucu eklenmesi sırasında politika da aynı değişiklik planının parçası olmalıdır.

Politika kaldırılacaksa TXT kaydını ve HTTPS dosyasını aniden silmek yerine önce none modunda, max_age değeri kısa olan yeni bir politika yayımlamak gerekir. Yeni id ile bu politika duyurulduktan ve eski önbellekler sona erdikten sonra uç noktalar kaldırılabilir; aksi halde bazı gönderenler önceki enforce politikasını uygulamaya devam edebilir.