MTA-STS ve TLS-RPT'yi önce test modunda yayınlayın

SPF, DKIM ve DMARC başkalarının adınızı taklit etmesini engeller (DMARC kaydınızı kontrol edebilirsiniz), ancak hiçbiri bir gönderen sunucunun size postayı düz metin olarak iletmesini önlemez. MTA-STS, posta sunucularınızın kimlik doğrulamalı TLS desteklediğini bildiren bir politika yayınlamanızı sağlar. TLS-RPT ise göndericiler bunu sağlayamadığında sizi bilgilendirir. İkisini de iki DNS kaydı ve tek bir metin dosyasıyla devreye alabilirsiniz, üstelik kademeli geçiş için tasarlanmış bir modla başlayabilirsiniz.

STARTTLS neyi açık bırakıyor

Sunucular arası posta şifrelemesi STARTTLS uzantısını kullanır ve bu şifreleme fırsatçıdır (opportunistic). RFC 8461 zayıf noktayı şöyle tarif eder: SMTP oturumundaki "250 STARTTLS" yanıtını silebilen ya da çözümlenen MX kaydının üzerine yazarak oturumu yönlendirebilen bir saldırgan, düşürme (downgrade) saldırısı yapabilir veya oturumu araya girerek dinleyebilir.

DANE, RFC 7672 içinde tanımlanan diğer çözümdür, ancak DNSSEC gerektirir. MTA-STS ise bunun yerine sertifika otoritelerine dayanır ve DNSSEC gerektirmez. Bunun bedeli RFC'nin kendi ifadesiyle "kötü niyetli düşürme saldırıları riskini göze almaktır". Zaten DANE kullanıyorsanız ikisi çakışmaz: MTA-STS uygulayan göndericiler, başarısız olan bir DANE doğrulamasını MTA-STS ile geçersiz kılmamalıdır.

NCSC'nin e-posta güvenliği rehberi, hizmetinizin TLS kullanarak e-posta gönderip alabilmesi gerektiğini ve Google G Suite ile Microsoft O365 gibi bulut sağlayıcılarındakiler dahil tüm alan adlarınızı korumanız gerektiğini belirtir.

Birinci adım: test modunda politika

MTA-STS iki parçadan oluşur. _mta-sts.example.com adresindeki bir TXT kaydı, bir politikanın var olduğunu ve sürümünü duyurur:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

id, en fazla 32 karakterlik harf ve rakamlardan oluşur ve politikanın bu sürümünü benzersiz biçimde tanımlamalıdır. Örtük bir sıralama yoktur, dolayısıyla zaman damgası kullanmak zorunluluk değil, bir alışkanlıktır. Tam olarak bir adet bu tür kayıt yayınlayın: göndericiler v=STSv1; ile başlamayan kayıtları yok sayar ve sonrasında kayıt sayısı bir değilse politikanız olmadığını varsayar.

Politikanın kendisi, alan adınızın önüne mta-sts eklenerek oluşturulan sabit bir adresten HTTPS üzerinden çekilir:

https://mta-sts.example.com/.well-known/mta-sts.txt

Göndericilere medya türünü kontrol etmeleri söylendiği için dosyayı text/plain olarak sunun. Dosya şöyle görünür:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Her mx: satırı ayrı bir girdidir; tam bir ana makine adı ya da *.example.net gibi bir joker karakterli sonek olabilir. Bir bulut sağlayıcısınınkiler dahil, canlı MX kayıtlarınızdaki her ana makineyi listeleyin.

Üç mod vardır: enforce, testing ve none. RFC, testing modunu politika hatalarını tespit etmek için yumuşak geçişlere (soft deployment) olanak tanıyan isteğe bağlı bir mod olarak tanımlar; bu yüzden buradan başlıyoruz.

max_age saniye cinsindendir, en fazla 31557600 olabilir ve 604800 (bir hafta) RFC'nin kendi örneğidir. RFC, üretim değerlerinin genellikle haftalar veya daha uzun aralıkta olmasını bekler. Önerim şu: test sırasında bir hafta veya daha kısa tutun ki düzeltilmiş bir politika göndericilere hızla ulaşsın, enforce kararlı çalıştıktan sonra artırın.

İkinci adım: TLS-RPT'yi açın

Tespit, ancak göndericiler gördüklerini size bildirirse işe yarar. _smtp._tls.example.com adresinde bir TXT kaydı yayınlarsınız:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

rua bir https URI'si de olabilir; bu durumda göndericiler raporu bu adrese POST eder. Virgülle ayrılmış bir liste de kullanılabilir. MTA-STS kaydında olduğu gibi, tam olarak bir TXT kaydı v=TLSRPTv1; ile başlamalıdır, aksi halde göndericiler bunu uygulamadığınızı varsayar.

mailto seçerseniz ayrı bir posta kutusu kullanın. Göndericiler bu raporları TLS başarısız olduğunda bile iletir, dolayısıyla bir rapor şifrelenmemiş olarak gelebilir. E-postayla gönderilen raporlar, raporlayan alan adından geçerli bir DKIM imzası taşımalıdır ve RFC, alıcıların imzasız olanları yok saymasını şart koşar. İmzasız raporlara göre aksiyon almayın, onları atın.

Göndericilerin gördüğünü kontrol edin

Her iki kaydı sorgulayın ve politika dosyasını ağınızın dışından çekin:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

dig çıktısı her biri için tek bir kayıt göstermeli ve v= öneki başta olmalıdır. curl çıktısı 200, Content-Type: text/plain ve politika gövdesini göstermelidir; mode ve her mx: satırının istediğiniz gibi olduğunu kontrol edin. TXT kaydını yayınlamadan önce curl'ün bildirdiği tüm sertifika hatalarını düzeltin.

Raporları okumak

Raporlar, belirli bir zaman aralığını kapsayan JSON dosyalarıdır ve başarı ile başarısızlık sayılarını içeren bir teslimat özeti barındırır. RFC, hataları müzakere (negotiation), politika, genel ve geçici hatalar olarak gruplar. Raporlar sıkıştırılmış gelebilir (RFC application/tlsrpt+gzip türünü tanımlar), bu yüzden önce açın:

gzip -dc report.json.gz | jq .

Alan adları RFC 8460'ın 4.4 bölümünde tanımlanmıştır. Önce özet sayılarını, ardından hata girdilerini okuyun.

Başarı oranı yüksek ve hatasız bir rapor görmek istediğiniz durumdur. RFC, bir raporun TLS'in beklendiği gibi müzakere edildiğini gösteren bir kalp atışı (heartbeat) işlevi görebileceğini belirtir; art arda gelen temiz raporlar bir sonraki adıma geçmek için kanıtınızdır. Kendi MX ana makinelerinizden birini işaret eden hatalar, düzeltmeniz gereken bir sertifikaya ya da mx desenine işaret eder. Yığını bozuk tek bir gönderici ise o göndericinin sorunudur.

Bir değişikliğe bağlayamadığınız STARTTLS hatası artışını olay yönetiminden sorumlu kişiye iletin; böyle biri yoksa olay müdahale ekibimize iletin.

Enforce moduna geçiş

Raporlar, aylık fatura sistemleri gibi nadir gönderenler dahil normal posta trafiğinizin tamamında temiz olana kadar bekleyin. Ardından mode: testing değerini mode: enforce olarak değiştirin ve TXT kaydındaki id değerini de değiştirin; çünkü göndericiler bir şeyin değiştiğini öğrenmek için bunu önbelleklerindeki kopyayla karşılaştırır.

Göndericiler bir politikayı son çekmeden itibaren max_age süresi boyunca önbellekte tutabilir, dolayısıyla bir hata uzun süre kalabilir. RFC'nin de belirttiği gibi, TXT kaydını silmek önbellekteki politikayı kaldırmaz. Kaldırma işlemi RFC 8461'in 8.3 bölümünde ele alınır; ihtiyaç duymadan önce okumanızı öneririm.

Nereden başlamalı

1. Bir bulut sağlayıcısınınkiler dahil canlı MX ana makinelerinizi listeleyin ve her birinin adıyla eşleşen geçerli bir sertifika sunduğunu doğrulayın.
2. mta-sts ana makinesini HTTPS üzerinden kurun ve politika dosyasını mode: testing ile text/plain olarak sunun.
3. Tek bir _mta-sts TXT kaydını yeni bir id ile yayınlayın, ardından yukarıdaki dig ve curl kontrollerini çalıştırın.
4. _smtp._tls TXT kaydını ayrı bir posta kutusuna ya da HTTPS uç noktasına yönlendirerek yayınlayın ve genel kurulumunuzu e-posta güvenliği denetleyicimizle kontrol edin.
5. Raporları en az bir tam iş döngüsü boyunca, ay sonu çalışmaları dahil inceleyin (çoğu kurum için bu bir aydır). Sahibi olduğunuz her hatayı düzeltin, ardından enforce moduna geçin ve id değerini değiştirin.