MTA-STS ve TLS-RPT nasıl kurulur

MTA-STS'in çözdüğü sorun

Bir e-posta sunucusu diğerine teslimat yaparken, STARTTLS adlı bir komutla alıcı sunucunun şifrelemeyi destekleyip desteklemediğini sorar. Yanıt evetse bağlantı şifreli hale yükseltilir. Bu fırsatçı bir yöntemdir: STARTTLS teklifi yoksa gönderen sistem düz metin olarak teslim eder. Çoğu gönderen sistem de kendisine gösterilen sertifikanın doğru sunucuya ait olup olmadığını kontrol etmez.

Dolayısıyla iki sunucunun arasına yerleşmiş biri STARTTLS teklifini silebilir veya e-posta sunucusunun yerine kendi sertifikasıyla yanıt verip e-postayı okuyabilir ya da değiştirebilir. RFC 8461'de tanımlanan MTA-STS bu açığı kapatır. Alıcı domainin şunu söyleyen bir politika yayınlamasını sağlar: bu domaine gelen e-posta TLS üzerinden, adı belirtilen şu sunuculardan birine, o ad için geçerli bir sertifikayla teslim edilmelidir. MTA-STS destekleyen bir gönderen sistem, aksi durumda teslim etmeyi reddeder.

Bir politikanın iki parçası

MTA-STS, yalnızca DNS'in yeterli olmaması bakımından alışılmışın dışındadır. Politika, HTTPS üzerinden sunulan bir metin dosyasında durur. Bir DNS kaydı da dosyanın var olduğunu ve ne zaman değiştiğini bildirir. Bu tasarım bilinçli bir tercihtir: politikanın HTTPS üzerinden alınması, onun bir web sertifikasıyla doğrulanması demektir. Böylece mekanizma DNSSEC'e bağımlı olmaz.

Gönderen sistem önce domaininizin altındaki _mta-sts adında TXT kaydını sorgular. Kayıt bulursa, politika dosyasını domaininizin mta-sts ana makine adındaki sabit bir adresten alır ve önbelleğe kaydeder. Sonraki teslimatlarda yalnızca TXT kaydındaki id değerinin değişip değişmediğine bakar.

_mta-sts.example.com.  TXT  "v=STSv1; id=20261110120000"

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

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Politikanın her satırı ne anlama gelir

version satırı her zaman STSv1'dir. mode üç değerden biridir. testing modunda gönderen sistemler her zamanki gibi teslim eder ve rapor istediyseniz hataları bildirir. enforce modunda gönderen sistemler kontrollerden geçemeyen bir sunucuya teslimat yapmamalıdır. none modunda gönderen sistemlere domainin artık bir politikası olmadığı bildirilir. Bir politika bu yolla temiz biçimde geri çekilir.

Her mx satırı, domain için e-posta almasına izin verilen bir e-posta sunucusunu adlandırır. Bir satır joker (wildcard) etiketle başlayabilir. Bu durumda *.mail.example.com o konumdaki herhangi bir tek etiketle eşleşir. max_age satırı, gönderen sistemin politikayı önbellekte tutabileceği saniye sayısıdır ve yaklaşık bir yıla kadar çıkabilir. Güven kazanana kadar bir hafta makul bir değerdir. Daha uzun değerler daha fazla koruma sağlar, çünkü politika dosyasını engelleyen bir saldırgan önbellek süresi dolana kadar hiçbir şey kazanmaz.

Başlamadan önce

Politika e-posta sunucularınızı tanımlar, bu yüzden onların gerçek durumuna göre yazılmalıdır. Herhangi bir politikanın uygulanabilmesi için önce üç şeyin doğru olması gerekir.

1. Domainin MX kayıtlarını listeleyin. mx satırlarına bu adlar yazılır.
2. Her MX sunucusunun TLS 1.2 veya üzeri ile STARTTLS desteklediğini doğrulayın.
3. Her MX sunucusunun geçerli, süresi dolmamış, genel olarak güvenilen bir otorite tarafından verilmiş ve MX ana makine adının kendisini kapsayan bir sertifika sunduğunu doğrulayın.
4. Politika dosyasının nerede barındırılacağına karar verin. Statik barındırma hizmeti dahil, herhangi bir HTTPS sunucusu olur.

dig example.com MX +short
openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate -ext subjectAltName

Barındırılan bir e-posta sağlayıcısı kullanıyorsanız

Barındırılan bir sağlayıcıda e-posta sunucularını siz yönetmezsiniz, buna gerek de yoktur. Sağlayıcının MX sunucuları zaten geçerli sertifikalarla TLS destekler. Size düşen, onları doğru adlandıran bir politika yayınlamaktır. Yani mx satırları, sağlayıcının kullanmanızı söylediği MX kayıtlarıyla eşleşmelidir. Bu genellikle sağlayıcının domaini için bir joker ifadeyle yapılır. Tam kalıbı sağlayıcının belgelerinde bulursunuz.

Politika dosyasını yine de kendiniz, kendi domaininizin mta-sts adında barındırmanız gerekir. Sağlayıcı bunu bir özellik olarak sunmuyorsa, sağlayıcının e-posta sunucuları dosyayı sizin yerinize sunmaz.

Doğru sırayla yayınlama

Sıra önemlidir, çünkü eksik veya erişilemeyen bir dosyayı gösteren TXT kaydı, gönderen sistemlerin politikayı yok saymasına yol açar. Tekrarlanan alma hataları da önbelleklerinde eskimiş bir politikanın kalmasına neden olabilir.

1. mta-sts ana makine adı için, dosyanın sunulacağı yeri gösteren DNS kaydını oluşturun.
2. Politika dosyasını /.well-known/mta-sts.txt yolunda, HTTPS üzerinden, mta-sts ana makine adı için geçerli bir sertifikayla ve text/plain içerik türüyle sunun. Dosya bir yönlendirme üzerinden değil, doğrudan sunulmalıdır.
3. Dosyayı kendiniz çekin ve içeriği doğrulayın.
4. TLS-RPT kaydını yayınlayın. Böylece raporlar politika görülür görülmez gelmeye başlar.
5. _mta-sts TXT kaydını bir id ile yayınlayın.
6. Dosyayı bir gönderen sistemin yaptığı gibi çeken bir denetleyiciyle her şeyi geri okuyun.

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

TLS-RPT: neyin başarısız olduğunu nasıl öğrenirsiniz

RFC 8460'ta tanımlanan TLS-RPT, raporlar için bir adres veren tek bir TXT kaydıdır. Bunu destekleyen gönderen kuruluşlar, domaininize yaptıkları teslimatları özetleyen günde bir rapor gönderir: kaç oturumun TLS'i başarıyla kurduğu ve kaçının başarısız olduğu, hata türüne ve ilgili e-posta sunucusuna göre gruplanmış olarak.

Bu kaydı MTA-STS'ten önce veya onunla birlikte yayınlayın. testing modunda, bir politikanın e-postayı engelleyecek olduğunu öğrenmenin tek yolu budur. Raporlar JSON biçimindedir, genellikle sıkıştırılmıştır ve bir posta kutusuna ya da bir HTTPS uç noktasına gönderilebilir.

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Bir TLS raporunu okuma

Her rapor, gönderen sistemin uyguladığı politikayı adlandırır ve başarılı ile başarısız oturumların sayısını verir. Hatalar bir sonuç türüyle etiketlenir. En sık görülenler certificate-expired, certificate-host-mismatch, certificate-not-trusted, starttls-not-supported ve validation-failure türleridir. MTA-STS'e özgü olarak, sts-policy-fetch-error gönderen sistemin dosyanızı alamadığı, sts-policy-invalid dosyanın ayrıştırılamadığı, sts-webpki-invalid ise mta-sts sunucusundaki sertifikanın kabul edilebilir olmadığı anlamına gelir.

Tek bir gönderen sistemden gelen az sayıda ve istikrarlı hata, çoğu zaman o gönderen sistemin sorunudur. Birkaç gönderen sistemden gelen ve MX sunucularınızdan birini adlandıran hataları ise sizin düzeltmeniz gerekir.

testing modundan enforce moduna geçiş

En az iki hafta testing modunda kalın. Bu süre, büyük e-posta sağlayıcılarından rapor almak ve yedek MX gibi yalnızca ara sıra kullanılan e-posta sunucularını görmek için yeterlidir. Raporlar kendi sunucularınıza atfedilebilecek hiçbir hata göstermediğinde enforce moduna geçin.

1. Politika dosyasını düzenleyin: mode değerini testing'den enforce'a değiştirin.
2. TXT kaydındaki id değerini değiştirin. Yeni bir id olmazsa gönderen sistemler, önbellekteki testing politikasını süresi dolana kadar kullanmaya devam eder.
3. Sonraki hafta boyunca TLS raporlarını yakından izleyin.
4. Durum istikrara kavuşunca max_age değerini bir aya veya daha fazlasına çıkarın.

Daha sonra e-posta sağlayıcısı değiştirme

En yaygın MTA-STS kesintisi kurulumdan aylar sonra, domainin MX kayıtları değiştirilip politika unutulduğunda yaşanır. Önbelleğinde politikayı tutan gönderen sistemler, listede olmayan yeni MX sunucularını görür ve enforce modunda teslim etmeyi reddeder. E-posta kuyrukta bekler ve sonunda geri döner.

MX kayıtlarını değiştirmeden önce yeni sunucuları politika dosyasına eskilerin yanına ekleyin ve id değerini değiştirin. Her gönderen sistemin yeni listeyi alması için en az önceki politikanın max_age süresi kadar bekleyin. Sonra MX kayıtlarını değiştirin ve ardından eski sunucuları politikadan çıkarın. Zamanlama yönetilemiyorsa önce politikayı testing moduna alın.

Kaçınılması gereken hatalar

Başarısız kurulumların çoğu kısa bir hata listesinden kaynaklanır.

1. id değerini değiştirmeden politika dosyasını düzenlemek.
2. mx satırlarına MX ana makine adları yerine domain adını yazmak.
3. Dosyayı süresi dolmuş veya mta-sts adını kapsamayan bir sertifikayla sunmak.
4. Dosyayı bir yönlendirmenin arkasında sunmak. Gönderen sistemler yönlendirmeyi izlememelidir.
5. TLS-RPT ile bir testing dönemi geçirmeden doğrudan enforce moduna geçmek.
6. Seyrek kullanılan bir yedek MX sunucusunu unutmak.
7. MTA-STS'i kapatmak için önce mode none yayınlamak yerine TXT kaydını silmek. Gönderen sistemler, max_age süresi bitene kadar önbellekteki politikayı uygulamaya devam eder.

MTA-STS ne yapmaz

MTA-STS, onu destekleyen gönderen sistemlerden domaininize aktarım halindeki e-postayı korur. Depolanan e-postayı şifrelemez, kendi politikalarını yayınlamadıkları sürece başkalarına gönderdiğiniz e-postayı korumaz ve onu uygulamayan gönderen sistemler üzerinde hiçbir etkisi yoktur. Bir iletiyi kimin gönderdiğini doğrulamaz. Bu SPF, DKIM ve DMARC'ın işidir. DANE, DNSSEC'e dayanan benzer bir koruma sunar ve MTA-STS ile birlikte kullanılabilir. CloudSpex MTA-STS Denetleyici TXT kaydını okur, politika dosyasını alır ve domainin MX kayıtlarıyla karşılaştırır. Bir hatanın yeri bulunabilsin diye her adımı ayrı ayrı raporlar.