E-posta aktarım protokolü SMTP, STARTTLS komutuyla mevcut bağlantıyı şifreleyen TLS korumasına geçebilir. Sunucular arası SMTP aktarımında bu koruma, zorunlu tutulmadığında fırsatçı biçimde uygulanır. TLS görüşmesi başarısız olduğunda veya karşı sunucu STARTTLS sunmadığında başka bir politika buna engel olmuyorsa ileti şifrelenmeden aktarılabilir.

SMTP REQUIRETLS, gönderenin belirli bir ileti için şifresiz aktarıma dönüşü kabul etmediğini bildirir. SMTP’ye ek yetenekler kazandıran ESMTP yapısındaki bir uzantıdır. İleti yalnız doğrulanmış TLS bağlantıları üzerinden ve REQUIRETLS desteği bulunan SMTP sunucuları aracılığıyla aktarılabilir; bu şartlar karşılanmazsa teslimat durur.

REQUIRETLS alan adı genelinde uygulanan bir teslimat politikası değildir ve uçtan uca içerik şifrelemesi sağlamaz. İletinin ilerleyebilmesi için onu yeniden aktaran her uyumlu SMTP sunucusunun REQUIRETLS gereksinimini kaydetmesi ve sonraki aktarımda yeniden uygulaması gerekir.

REQUIRETLS SMTP Oturumunda Nasıl İletilir?

SMTP istemcisi önce RFC 5321'e göre hedef SMTP sunucusunu belirler. Genellikle, alan adlarına ilişkin kayıtları sunan DNS sisteminden alıcı alan adının posta sunucularını gösteren MX kayıtlarını sorgular. REQUIRETLS bu hedef seçiminin yerine geçmez. MX kayıtları kullanılmışsa bunların DNSSEC ile dijital imza doğrulamasından geçmesi veya hedef adının alıcı alan adının MTA-STS politikasındaki izin verilen posta sunucusu adlarıyla eşleşmesi gerekir. MTA-STS, alıcı alan adının TLS kullanımı ve kabul edilen sunucu adları için yayımladığı politikadır.

  1. İstemci, MX kaydıyla seçilen hedef adını DNSSEC veya MTA-STS ile doğrular.
  2. SMTP bağlantısında EHLO komutuyla kendini tanıtır ve sunucunun bildirdiği yetenekler arasında STARTTLS desteğini arar.
  3. STARTTLS ile TLS korumalı oturum kurulur ve sunucu kimliği doğrulanır. Bunun için güvenilen bir kök sertifikaya uzanan zincir ve hedef adı denetlenir veya DNSSEC korumalı TLSA kayıtlarıyla kimlik doğrulayan DANE yöntemi uygulanır.
  4. TLS kurulduktan sonra istemci yeniden EHLO gönderir ve yanıtta REQUIRETLS yeteneğinin ilan edildiğini doğrular.
  5. Gönderen ve alıcı teslimat adreslerini taşıyan SMTP zarfı, MAIL FROM komutuna zarf gönderen adresi ve REQUIRETLS parametresi eklenerek başlatılır; alıcılar sonraki RCPT TO komutlarıyla bildirilir.

Karşı sunucu iletiyi kabul ettiğinde REQUIRETLS gereksinimini kendi kuyruğunda veya aktarım bilgisinde korur. İletiyi yeniden gönderirken aynı denetimleri uygular ve MAIL FROM komutunda REQUIRETLS parametresini sonraki sunucuya iletir.

REQUIRETLS Kontrolleri Her Aktarım Noktasında Tekrarlanır

İletiyi yeniden gönderen posta aktarım yazılımı MTA, hedefi belirler ve güvenlik denetimlerini kendi bağlantısı için tekrarlar. Hedef MX kaydıyla bulunmuşsa DNSSEC veya MTA-STS kontrolü yapılır; TLS oturumu, sunucu kimliği ve TLS sonrasındaki EHLO yanıtında REQUIRETLS desteği doğrulanır. Böylece gereksinim yalnız ilk bağlantıda kalmaz.

Bu adımlardan biri başarısız olursa gönderen MTA diğer MX hedeflerini dener. Koşulları karşılayan hedef kalmazsa iletiyi TLS olmadan göndermek yerine teslim edilememe bildirimi oluşturur. RFC 8689, REQUIRETLS desteği bulunmadığında 5.7.30, TLS korumalı oturum kurulamadığında ise 5.7.10 geliştirilmiş durum kodlarını önerir.

Uyumlu her aktarım noktası, iletiyi sonraki SMTP sunucusuna verirken aynı gereksinimi uygular. Zincirdeki bir sunucunun yalnız STARTTLS sunması yeterli değildir; TLS bağlantısının kurulması ve sunucu kimliğinin doğrulanması, ardından REQUIRETLS desteğinin ilan edilmesi gerekir.

REQUIRETLS, STARTTLS, MTA-STS ve DANE Arasındaki Farklar

STARTTLS, iki SMTP sunucusunun mevcut bağlantıyı TLS ile korumaya geçmesini sağlayan görüşme mekanizmasıdır. REQUIRETLS ise belirli bir iletinin TLS olmadan gönderilmemesini ve bu gereksinimin sonraki aktarımlarda korunmasını ister. STARTTLS desteğinin bulunması tek başına REQUIRETLS koşullarını karşılamaz.

MTA-STS, alıcı alan adı için TLS politikasının ve geçerli MX sunucu adlarının yayımlanmasını sağlar. DANE ise DNSSEC ile korunan TLSA kayıtlarını kullanarak TLS sunucusunun kimliğini doğrulayabilir. REQUIRETLS bu mekanizmaların yerine geçmez. Alıcı alan adının yayımladığı politika bütün bir alan adına yönelikken REQUIRETLS isteği tek bir iletiye aittir ve sonraki SMTP aktarımlarına taşınır.

TLS-Required Başlığı REQUIRETLS Talebi Değildir

RFC 8689, TLS-Required: No ileti başlığını da tanımlar. Bu başlık TLS'yi zorunlu kılmaz; gönderenin belirli bir ileti için MTA-STS ve DANE gibi alıcı tarafı politikaları yüzünden teslimatın durmamasını istediğini belirtir. Bu başlığı destekleyen SMTP istemcisi STARTTLS varsa yine kullanmayı dener, ancak alıcı alan adının bu politikaları uygulanamadığı için teslimatı başarısız saymaz. Başlık sunucunun kendisini şifresiz ileti kabul etmeye zorlayamaz; sunucu TLS olmadan aktarımı reddederse teslimat yine başarısız olabilir. REQUIRETLS desteği olmayan aracı sunucular da başlığı dikkate almayabilir.

MAIL FROM komutunda REQUIRETLS parametresi varsa TLS-Required başlığı aktarım kararı için göz ardı edilir. Bu nedenle REQUIRETLS kullanımını yalnız ileti başlıklarında aramak yeterli değildir; SMTP oturumundaki MAIL FROM parametresi ve sunucunun iç aktarım kaydı da incelenmelidir.

Teslim Edilememe Bildirimlerinde REQUIRETLS Koruması

REQUIRETLS ile gönderilen bir iletiden doğan teslim edilememe bildirimi asıl iletinin başlıklarını taşıyabileceği için aynı korumayı kullanmalıdır. Teslimat hatası REQUIRETLS dışındaki bir nedenden kaynaklansa bile bildirim REQUIRETLS parametresiyle gönderilir. Asıl iletiden geri döndürülen bölüm yalnız başlıklardan oluşur; tamamını geri istemek için RET=FULL belirtilmiş olsa bile gövde ve ekler bildirime konmaz.

Geri dönüş yolu ileri aktarım zinciriyle aynı REQUIRETLS desteğine sahip olmayabilir. Bu durumda hata bildirimi göndericiye ulaşmayabilir. Boş MAIL FROM dönüş yoluna sahip bu bildirim, sonraki sunucu REQUIRETLS ilan etmese bile sırf bu nedenle atılmamalıdır. Bu istisna hata bildiriminin geri dönmesini kolaylaştırır, ancak bildirim REQUIRETLS koşulları sağlanmadan aktarılırsa başlıklardaki bazı bilgiler açığa çıkabilir. REQUIRETLS isteyen gönderenin hata bildirimlerini de bu koşullarla alabilmesi önemlidir.

REQUIRETLS Uçtan Uca Şifreleme Sağlamaz

REQUIRETLS, SMTP sunucuları arasındaki taşıma bağlantılarını korur. Ayrıca uçtan uca şifrelenmemiş bir iletinin içeriğini, TLS bağlantısını sonlandıran MTA okuyabilir. TLS korumasının kaldırılması, ayrı bir uçtan uca şifrelemenin de çözüldüğü anlamına gelmez. Uzantı, iletinin posta kutusunda veya depolama sisteminde nasıl saklandığını belirlemez.

Aradaki posta sunucularının da içeriği okuyamaması gerekiyorsa S/MIME veya OpenPGP ile içerik ayrıca şifrelenir ve şifreyi açan anahtarlar aracı sunuculara verilmez. Bu yöntemlerle yalnız dijital imza eklemek içeriği gizlemez. REQUIRETLS bu yöntemlerle birlikte çalışabilir, ancak onların sağladığı içerik gizliliğinin yerini tutmaz.

Yönlendirme ve Yeniden Oluşturma REQUIRETLS'i Nasıl Etkiler?

E-posta yönlendirme hizmetleri, posta listeleri ve otomatik yanıt sistemleri bazen gelen iletiyi aktarmak yerine yeni bir ileti oluşturur. Bu durumda gelen SMTP oturumundaki REQUIRETLS parametresi yeni iletiye otomatik olarak aktarılmaz; aracı sistem gereksinimi ancak tanıyıp yeni iletide yeniden uygularsa koruyabilir.

RFC 8689, yeni ileti oluşturan aracıların REQUIRETLS gereksinimini mümkün olduğu ölçüde korumasını önerir. Kullanıcı tarafındaki yönlendirme kuralları SMTP oturum bilgisini görmeyebileceği için bu korumayı taşıyamayabilir. Hassas iletileri yönlendiriyorsanız aracı sistemin REQUIRETLS gereksinimini koruduğunu ayrıca doğrulayın.