STARTTLS mi Implicit SSL mi: Mail Şifreleme Modları

Bir mail hesabını istemciye eklerken karşınıza iki soru çıkar: hangi port ve hangi şifreleme yöntemi. Seçenekler genellikle "SSL/TLS", "STARTTLS" ve "Yok" olarak listelenir, portlar ise 25, 465, 587 arasında gidip gelir. Yanlış kombinasyon seçtiğinizde ya bağlantı hiç kurulmaz ya da — çok daha kötüsü — şifreniz ağda açıkta gider ve hiçbir hata mesajı almazsınız. STARTTLS mi implicit SSL mi sorusu bu yüzden bir tercih meselesinden çok bir güvenlik kararıdır.

Bu yazıda iki şifreleme modunun protokol düzeyinde ne kadar farklı çalıştığını, hangi portun hangi işi yaptığını, STARTTLS'in downgrade saldırısına neden açık olduğunu ve bunu MTA-STS ile nasıl kapatacağınızı anlatacağım. Ardından Postfix ve Dovecot üzerinde iki modu birlikte sunan doğru bir yapılandırma kuracağız ve istemci tarafındaki ayar tablosunu netleştireceğiz.

İki Şifreleme Modunun Temel Farkı#

Implicit TLS (eskiden SMTPS denirdi) en basit modeldir: TCP bağlantısı kurulur kurulmaz, tek bir SMTP komutu bile geçmeden TLS el sıkışması başlar. İstemci ile sunucu arasında hiçbir zaman şifresiz bir bayt dolaşmaz. HTTPS'in çalışma biçiminin aynısıdır — 443 portuna bağlanırsınız ve şifreleme peşinen vardır.

STARTTLS ise fırsatçı bir yaklaşımdır. Bağlantı şifresiz kurulur, istemci EHLO gönderir, sunucu desteklediği uzantıları listeler ve bu listede STARTTLS varsa istemci STARTTLS komutuyla oturumu şifrelemeye yükseltir. Yükseltme başarılı olursa istemci EHLO'yu bir kez daha gönderir ve bu noktadan sonra her şey şifrelidir. Yani şifreleme, protokolün içinden müzakere edilir.

Aradaki fark yalnızca teknik bir ayrıntı değil, bir güven modeli farkıdır. Implicit TLS'te "şifreleme olmazsa bağlanma" kuralı bağlantının ta kendisine gömülüdür. STARTTLS'te ise şifreleme, sunucunun cevabına bakıp karar verilen bir seçenektir — ve o cevap araya giren biri tarafından değiştirilebilir. İki modu yan yana koyalım:

Modern standart (RFC 8314), kullanıcı gönderimi ve posta kutusu erişimi için implicit TLS'i tercih etmeyi önerir. Yani yeni bir kurulum yapıyorsanız istemcileri 465, 993 ve 995 portlarına yönlendirmek daha sağlam bir varsayılandır.

Portlar: 25, 465, 587 ve Diğerleri#

Port kafa karışıklığının kaynağı, bu numaraların farklı zamanlarda farklı amaçlarla tahsis edilmiş olmasıdır. Bugün geçerli olan görev dağılımı şudur ve karıştırmamak önemlidir.

Port 25 sunucular arası teslimat içindir. Bir mail sunucusu başka bir mail sunucusuna mesaj teslim ederken bu portu kullanır ve burada kimlik doğrulaması yoktur — göndericinin sizde hesabı yoktur. Şifreleme burada fırsatçıdır: karşı taraf STARTTLS destekliyorsa kullanılır, desteklemiyorsa mesaj yine de teslim edilir. Kullanıcı istemcilerinin bu porta bağlanması gerekmez; birçok internet servis sağlayıcısı ve bulut sağlayıcısı 25'i abone bağlantılarında zaten kapatır.

Port 587 kullanıcı gönderimi (submission) içindir ve STARTTLS ile çalışır. Bağlantı şifresiz başlar, STARTTLS ile yükseltilir, kimlik doğrulaması ancak bundan sonra yapılır. Doğru yapılandırılmış bir sunucu, TLS kurulmadan AUTH uzantısını duyurmaz.

Port 465 implicit TLS ile kullanıcı gönderimi içindir. Bir dönem "kullanımdan kaldırıldı" diye anlatıldığı için hâlâ tereddütle karşılanır; oysa RFC 8314 ile resmen geri getirilmiş ve gönderim için önerilen yol haline gelmiştir. Bugün 465'ten kaçmak için teknik bir sebep yoktur.

IMAP ile POP3 arasında hangisini seçeceğinize karar vermediyseniz IMAP ve POP3 farkı yazısı bu tercihi netleştirir; port seçimi o kararın ardından gelir.

STARTTLS'in Zayıf Noktası: Downgrade Saldırısı#

STARTTLS'in mimari zaafı şudur: şifrelemenin devreye girip girmeyeceği, şifrelenmemiş bir kanalda müzakere edilir. Araya giren bir saldırgan, sunucunun EHLO cevabındaki 250-STARTTLS satırını silerse istemci sunucunun TLS desteklemediğini sanır. Fırsatçı davranan bir istemci de "madem desteklemiyor, şifresiz devam edeyim" der ve kimlik bilgilerini düz metin gönderir. Buna STARTTLS stripping denir ve kullanıcı hiçbir uyarı görmez.

Bu saldırıya karşı üç katmanlı savunma vardır ve üçünü birden uygulamak gerekir:

1. İstemci tarafında zorunlu kılın. İstemcinin şifreleme ayarı "varsa kullan" değil "gerekli" olmalıdır. Çoğu istemcide bu, "STARTTLS (gerekli)" veya "SSL/TLS" seçenekleridir; "Yok" ve "otomatik algıla" seçeneklerinden uzak durun.
2. Sunucuda TLS'siz kimlik doğrulamayı reddedin. Şifresiz oturumda AUTH duyurulmazsa ve kabul edilmezse, saldırgan STARTTLS'i silse bile şifre asla gönderilmez — istemci hata alır ve kullanıcı durumu fark eder. Bu ayarın Postfix ve Dovecot karşılıklarını SMTP kimlik doğrulama yöntemleri yazısında ayrıntılı anlattım.
3. Sunucular arası trafik için MTA-STS yayınlayın. Bu, alan adınıza mail gönderen diğer sunuculara "bana yalnızca doğrulanmış TLS ile teslimat yap" demenin standart yoludur.

En temiz çözüm ise istemcileri doğrudan implicit TLS portlarına (465/993/995) yönlendirmektir: müzakere edilecek bir şey olmadığı için silinecek bir satır da yoktur.

Sunucular Arası Teslimatta MTA-STS ve DANE#

Port 25 üzerindeki teslimatta STARTTLS'i zorunlu kılamazsınız — zorunlu kılarsanız TLS desteklemeyen sunuculardan hiç mail alamazsınız. Çözüm, politikayı DNS ve HTTPS üzerinden yayınlamaktır. MTA-STS (RFC 8461) tam olarak bunu yapar: bir DNS TXT kaydı politikanın varlığını duyurur, politika dosyası ise HTTPS üzerinden sabit bir adresten sunulur.

; Politikanın varlığını ve sürümünü duyuran TXT kaydı
_mta-sts.firmaniz.com.   3600  IN  TXT  "v=STSv1; id=20260825000000"

; Politika dosyasını sunacak alt alan adı
mta-sts.firmaniz.com.    3600  IN  A    185.12.34.56

; TLS raporlarının nereye gönderileceği (isteğe bağlı ama çok faydalı)
_smtp._tls.firmaniz.com. 3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Politika dosyası https://mta-sts.firmaniz.com/.well-known/mta-sts.txt adresinden, geçerli bir sertifikayla sunulmalıdır:

version: STSv1
mode: enforce
mx: mail.firmaniz.com
max_age: 604800

mode değeri üç olabilir: testing (uygulama yok, yalnızca raporla), enforce (TLS doğrulanamazsa teslimatı reddet) ve none (politikayı geri çek). Yeni kurulumda mutlaka testing ile başlayın, gelen TLS raporlarında hata görmediğinizden emin olduktan sonra enforce'a geçin. Doğrudan enforce ile başlamak, bir sertifika sorunu olduğunda size gelen mailin tamamen kesilmesi demektir.

DANE (RFC 7672) aynı işi DNSSEC üzerine kurulu TLSA kayıtlarıyla yapar. Daha güçlüdür çünkü sertifikayı doğrudan DNS'e bağlar, ancak alan adınızda DNSSEC'in çalışıyor olmasını şart koşar. İkisi birbirini dışlamaz; DNSSEC'iniz varsa ikisini birden yayınlamak en sağlam kurulumdur.

Yayınladıktan sonra doğrulayın:

# TXT kaydı yayında mı
dig +short _mta-sts.firmaniz.com TXT

# Politika dosyası doğru içerik tipiyle ve geçerli sertifikayla sunuluyor mu
curl -sI https://mta-sts.firmaniz.com/.well-known/mta-sts.txt | head -5
curl -s  https://mta-sts.firmaniz.com/.well-known/mta-sts.txt

# Sunucunuzun MX'i gerçekten STARTTLS duyuruyor mu
openssl s_client -connect mail.firmaniz.com:25 -starttls smtp -brief 2>&1 | head -8

Postfix ve Dovecot'ta İki Modu Birlikte Sunmak#

Doğru kurulum, üç portu birden açık tutup her birine kendi kuralını vermektir: 25 fırsatçı ve kimlik doğrulamasız, 587 STARTTLS zorunlu ve kimlik doğrulamalı, 465 implicit TLS ve kimlik doğrulamalı. Postfix'te bu ayrım master.cf içinde yapılır:

# /etc/postfix/master.cf

# 587 - submission, STARTTLS zorunlu
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

# 465 - submissions, implicit TLS (wrappermode)
smtps     inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Buradaki iki anahtar ayar şudur: smtpd_tls_security_level=encrypt STARTTLS'i zorunlu kılar (fırsatçı olan may değil), smtpd_tls_wrappermode=yes ise 465 portunda TLS'in bağlantı başında kurulmasını sağlar. main.cf tarafında ise 25 portunun davranışı ve giden teslimat politikası tanımlanır:

# /etc/postfix/main.cf

# Gelen teslimat (25): fırsatçı - TLS varsa kullan, yoksa mesajı yine al
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.firmaniz.com/privkey.pem

# Eski ve zayıf protokolleri kapat
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols  = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Giden teslimat: fırsatçı TLS, DNSSEC varsa dane tercih edin
smtp_tls_security_level = may
smtp_tls_loglevel = 1

Dovecot tarafında IMAP ve POP3 için hem implicit hem STARTTLS portları açık kalır ama şifresiz oturum reddedilir:

# /etc/dovecot/conf.d/10-ssl.conf
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
ssl_key  = </etc/letsencrypt/live/mail.firmaniz.com/privkey.pem
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes

Değişikliklerin ardından servisleri yeniden yükleyip her portu ayrı ayrı test edin:

postfix reload && systemctl reload dovecot

# 465 - implicit TLS: STARTTLS parametresi YOK
openssl s_client -connect mail.firmaniz.com:465 -brief

# 587 - STARTTLS: parametre gerekli
openssl s_client -connect mail.firmaniz.com:587 -starttls smtp -brief

# 993 - IMAP implicit TLS
openssl s_client -connect mail.firmaniz.com:993 -brief

Bu testleri elle yazmak yerine port, TLS modu ve HELO/PTR uyumunu tek ekranda görmek isterseniz SMTP test aracı gerekli komutları sizin için üretir.

Sık Yapılan Hatalar#

En yaygın hata, portu doğru seçip şifreleme modunu yanlış eşleştirmektir. 465 portuna STARTTLS ile bağlanmaya çalışan bir istemci hiçbir zaman bağlanamaz, çünkü sunucu daha ilk baytta TLS bekler ve gelen düz metin EHLO'yu anlamaz. Tersi de geçerlidir: 587'ye implicit TLS ile bağlanmaya çalışmak da başarısız olur. Bağlantı hiç kurulmuyorsa ilk bakacağınız yer bu eşleşmedir.

İkinci klasik hata, istemcide şifrelemeyi "otomatik" veya "varsa kullan" modunda bırakmaktır. Bu ayar downgrade saldırısına kapıyı açık tutar ve kullanıcıya hiçbir uyarı vermez. Her zaman açıkça "SSL/TLS" ya da "STARTTLS (gerekli)" seçin.

Üçüncü tuzak sertifika ile sunucu adının uyuşmamasıdır. İstemci mail.firmaniz.com adına bağlanıyorsa sertifika bu adı içermelidir; sertifikada yalnızca firmaniz.com varsa istemci uyarı verir ve kullanıcı "her seferinde güvenlik uyarısı çıkıyor" der. Sertifikanın kapsadığı adları openssl s_client çıktısındaki subject ve subjectAltName alanlarından teyit edin.

Dördüncüsü, MTA-STS politikasını doğrudan enforce ile yayınlamaktır. Politika dosyasındaki mx satırı gerçek MX kayıtlarınızla birebir uyuşmuyorsa veya sertifikanız süresi geçmişse, gelen mailiniz tamamen durur. Önce testing modunda birkaç hafta rapor toplayın. Bu tür kesintilerde ilk teşhis adımı MX kayıtlarını doğrulamaktır; maillerim gelmiyor MX sorunu yazısı bu kontrolü adım adım anlatıyor.

Sıkça Sorulan Sorular#

465 portu kullanımdan kaldırıldı mı#

Hayır, bu yaygın bir yanlış bilgidir. 465 bir dönem tahsisi geri alınmış bir porttu ve o dönemden kalan tavsiyeler hâlâ dolaşıyor. RFC 8314 ile port resmen "submissions" olarak yeniden tanımlandı ve kullanıcı gönderimi için önerilen yol haline geldi. Bugün 465 kullanmak modern ve doğru bir tercihtir; hatta yeni kurulumlarda 587'ye göre daha sağlam bir varsayılandır.

587 mi 465 mi kullanmalıyım#

İkisi de doğru çalışır, ancak yeni bir kurulumda 465 (implicit TLS) daha güvenli bir varsayılandır çünkü şifreleme müzakere edilmez, peşinen vardır ve downgrade riski taşımaz. 587'yi açık tutmanın sebebi uyumluluktur: bazı eski istemciler ve uygulama kütüphaneleri yalnızca STARTTLS ile çalışır. En iyi yaklaşım ikisini birden açık tutup kullanıcıları 465'e yönlendirmektir.

STARTTLS güvenli değil mi#

STARTTLS'in kendisi, kurulduktan sonra implicit TLS kadar güvenlidir; aynı TLS protokolü çalışır. Zayıflık şifrelemenin kurulup kurulmayacağının şifresiz kanalda kararlaştırılmasındadır. İstemcide TLS'i zorunlu kıldığınızda ve sunucuda şifresiz kimlik doğrulamayı reddettiğinizde bu zayıflık pratikte kapanır. Yani sorun protokolde değil, "varsa kullan" şeklindeki gevşek yapılandırmadadır.

Sunucumun hangi şifreleme modunu desteklediğini nasıl kontrol ederim#

openssl s_client en pratik araçtır. Implicit TLS portu için openssl s_client -connect sunucu:465 -brief, STARTTLS portu için openssl s_client -connect sunucu:587 -starttls smtp -brief komutunu çalıştırın. Bağlantı kurulup sertifika bilgisi geliyorsa o mod destekleniyor demektir. Ayrıca STARTTLS portunda EHLO cevabında 250-STARTTLS satırını görmeniz gerekir.

Port 25 kapalıysa mail gönderebilir miyim#

Kullanıcı olarak evet: istemcinizden gönderim 587 veya 465 üzerinden yapılır, 25'e ihtiyacınız yoktur. Ancak kendi mail sunucunuzu işletiyorsanız 25 hem gelen teslimat hem de diğer sunuculara giden teslimat için gereklidir. Birçok bulut sağlayıcısı yeni sunucularda giden 25 portunu varsayılan olarak kapatır; kendi MTA'nızı kuracaksanız bu portun açık olduğunu önceden teyit edin.

MTA-STS kurmak zorunda mıyım#

Zorunlu değil ama güçlü tavsiye edilir, özellikle kurumsal yazışma yapan alan adları için. MTA-STS olmadan size mail gönderen sunucular downgrade saldırısına açık kalır ve bunu fark etmezsiniz. Kurulumu bir DNS TXT kaydı ile HTTPS üzerinden sunulan küçük bir metin dosyasından ibarettir. Yalnızca testing modunda başlayıp TLS raporlarını inceledikten sonra enforce'a geçmeyi unutmayın.

Sertifika uyarısı alıyorum, ne yapmalıyım#

Önce istemcide yazan sunucu adının sertifikadaki adlarla eşleştiğini kontrol edin; en sık sebep budur. openssl s_client çıktısındaki subject ve subjectAltName alanlarına bakın. İkinci sebep sertifikanın süresinin dolmasıdır — Let's Encrypt kullanıyorsanız yenileme kancasının servisleri gerçekten yeniden yüklediğinden emin olun; yenilenen sertifika, servis yeniden yüklenmediği sürece bellekte eskisiyle sunulmaya devam eder.

Kapanış#

Şifreleme modu seçimi, aslında "şifrelemeyi müzakere mi ettireceğim yoksa peşinen mi dayatacağım" sorusudur. Aklınızda kalması gereken dört şey: implicit TLS (465/993/995) müzakere gerektirmediği için daha sağlam bir varsayılandır; STARTTLS güvenlidir ama yalnızca zorunlu kılındığında; şifresiz oturumda kimlik doğrulamayı asla kabul etmeyin; ve sunucular arası trafiği korumak için MTA-STS'i önce testing modunda yayınlayın.

Kendi mail sunucunuzu kurup bu portları ve sertifikaları yönetmek isterseniz Postfix, Dovecot, TLS sertifikası ve DKIM'i hazır yapılandırılmış gelen SMTP sunucu paketleri iyi bir başlangıç noktasıdır; daha genel bir altyapı için VDS sunucularına bakabilirsiniz. Sertifika tarafını ayrıca yönetmek isterseniz SSL sertifikası sayfamıza, posta kutularını hazır yapılandırmayla almak isterseniz e-posta paketlerimize göz atın.