SMTP Kimlik Doğrulama Yöntemleri: PLAIN, LOGIN, CRAM-MD5

Mail istemcisi kurulumu yaparken karşınıza çıkan "kimlik doğrulama yöntemi" listesi genellikle en az anlaşılan alandır: Normal Şifre, Şifrelenmiş Şifre, CRAM-MD5, NTLM... Çoğu kişi bir tanesini seçer, çalışmazsa diğerini dener ve tutan neyse onu bırakır. Oysa SMTP kimlik doğrulama yöntemleri arasındaki fark, mail sunucunuzun güvenlik duruşunu doğrudan belirler ve yanlış seçim ya bağlantıyı hiç kurdurmaz ya da şifrenizi ağda açıkta bırakır.

Bu yazıda SMTP AUTH'un nasıl çalıştığını, PLAIN ile LOGIN arasındaki gerçek farkı (ipucu: sandığınız kadar büyük değil), CRAM-MD5'in neden "daha güvenli" görünüp aslında ciddi bir dezavantaj taşıdığını, SCRAM ve OAuth tabanlı modern alternatifleri ve bunları Postfix + Dovecot üzerinde nasıl doğru yapılandıracağınızı anlatacağım. Ayrıca bir SMTP oturumunu elle açıp mekanizmaları kendi gözünüzle göreceksiniz.

SMTP AUTH Neden Var ve Ne Zaman Devreye Girer#

SMTP protokolü tasarlandığında kimlik doğrulama diye bir kavram yoktu; sunucular birbirine mesaj teslim ederdi ve kimse "sen kimsin" diye sormazdı. Spam sorunu büyüyünce herkese açık relay'ler kapatıldı ve gönderim yetkisini kanıtlamak için SMTP AUTH uzantısı (RFC 4954) eklendi. Bugün kimlik doğrulamanın devreye girdiği tek senaryo, bir kullanıcının kendi sunucusu üzerinden dışarıya mail göndermesidir.

Buradaki ayrımı net tutmak önemli: sunucular arası teslimat (port 25) kimlik doğrulaması kullanmaz, çünkü size mail gönderen yabancı bir sunucunun sizde hesabı yoktur; orada kimlik doğrulama işini SPF, DKIM ve DMARC yapar. Kullanıcı gönderimi (submission, port 587 veya 465) ise her zaman kimlik doğrulaması ister. Bu iki yolun karışması, sunucuyu açık relay haline getiren klasik yapılandırma hatasıdır.

Bir SMTP oturumunda sunucunun hangi mekanizmaları desteklediğini EHLO cevabında görürsünüz:

# Submission portuna bağlan ve STARTTLS ile şifreli oturum aç
openssl s_client -connect mail.firmaniz.com:587 -starttls smtp -crlf

# Bağlantı kurulduktan sonra elle:
EHLO test.firmaniz.com
# Sunucunun cevabında şuna benzer bir satır görürsünüz:
# 250-AUTH PLAIN LOGIN
# 250-STARTTLS
# 250 8BITMIME

250-AUTH satırındaki liste, o sunucunun kabul ettiği mekanizmalardır. Dikkat edin: birçok sunucu bu listeyi yalnızca TLS kurulduktan sonra yayınlar. Şifresiz bağlanıp AUTH satırını göremiyorsanız bu bir arıza değil, doğru yapılandırılmış bir sunucunun beklenen davranışıdır.

AUTH PLAIN: En Yaygın ve En Basit Mekanizma#

PLAIN mekanizması (RFC 4616) adını hak eder: kullanıcı adı ve şifre, aralarına null bayt konularak birleştirilir, base64 ile kodlanır ve tek satırda gönderilir. Kodlama şu biçimdedir: \0kullanıcı\0şifre. Kendiniz üretebilirsiniz:

# AUTH PLAIN için gönderilecek dizeyi üret
printf '\[email protected]\0Sifre123' | base64
# Çıktı:
# AGt1bGxhbmljaUBmaXJtYW5pei5jb20AU2lmcmUxMjM=

Oturum içinde kullanımı tek satırdır:

AUTH PLAIN AGt1bGxhbmljaUBmaXJtYW5pei5jb20AU2lmcmUxMjM=
# Başarılı: 235 2.7.0 Authentication successful
# Başarısız: 535 5.7.8 Error: authentication failed

Burada anlaşılması gereken en kritik nokta şudur: base64 şifreleme değildir, kodlamadır. Yukarıdaki dizeyi base64 -d ile geri çevirebilirsiniz ve şifre karşınıza çıkar. Yani PLAIN mekanizması, TLS olmadan kullanıldığında şifreyi ağda düz metin göndermekle eşdeğerdir. Ancak TLS ile birlikte kullanıldığında tamamen güvenlidir, çünkü tüm oturum zaten şifrelenmiştir.

PLAIN'in bir başka avantajı, sunucunun kullanıcı şifresini karma (hash) olarak saklayabilmesidir. Sunucu gelen düz şifreyi alır, kendi karma fonksiyonundan geçirir ve veritabanındaki karma ile karşılaştırır. Bu, birazdan göreceğimiz CRAM-MD5 ile arasındaki en önemli mimari farktır.

AUTH LOGIN: Aynı Şey, Farklı Ambalaj#

LOGIN mekanizması hiçbir zaman resmi bir RFC ile standartlaşmadı ama Microsoft istemcilerinin yaygınlığı sayesinde neredeyse her yerde destekleniyor. Güvenlik açısından PLAIN ile tamamen aynı seviyededir: kullanıcı adı ve şifre yine base64 ile kodlanır, yine şifrelenmez. Tek fark, tek satır yerine iki adımda, sunucunun sorusuna cevap vererek gönderilmesidir.

AUTH LOGIN
# Sunucu: 334 VXNlcm5hbWU6      ("Username:" kelimesinin base64 hali)
# Siz: kullanıcı adının base64'ü
a3VsbGFuaWNpQGZpcm1hbml6LmNvbQ==
# Sunucu: 334 UGFzc3dvcmQ6      ("Password:" kelimesinin base64 hali)
# Siz: şifrenin base64'ü
U2lmcmUxMjM=
# Sunucu: 235 2.7.0 Authentication successful

334 kodları sunucunun "devam et, sıradaki parçayı gönder" demesidir. Gördüğünüz VXNlcm5hbWU6 ve UGFzc3dvcmQ6 dizeleri sabittir ve sırasıyla Username: ile Password: kelimelerinin base64 karşılığıdır — bu iki değeri log'larda gördüğünüzde bir LOGIN oturumuna baktığınızı anlarsınız.

Pratik sonuç şu: PLAIN ile LOGIN arasında güvenlik açısından seçim yapmanız gereken bir durum yoktur. İkisini de açık tutmak, hangi istemcinin bağlanacağını bilmediğiniz bir ortamda uyumluluğu artırır. Asıl belirleyici karar, bu mekanizmaların TLS olmadan kullanılmasına izin verip vermediğinizdir.

CRAM-MD5 ve Meydan Okuma Tabanlı Mekanizmalar#

CRAM-MD5 (RFC 2195), şifreyi hiç göndermeden kimlik kanıtlamak üzere tasarlandı. Akış şöyle işler: sunucu rastgele bir meydan okuma (challenge) üretip base64 kodlu olarak gönderir; istemci bu meydan okumayı şifresini anahtar olarak kullanarak HMAC-MD5 ile işler ve sonucu kullanıcı adıyla birlikte geri yollar. Ağı dinleyen biri şifreyi göremez, sadece o oturuma özel bir imzayı görür.

AUTH CRAM-MD5
# Sunucu rastgele bir meydan okuma yollar (base64):
# 334 PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZmlybWFuaXouY29tPg==
# İstemci "kullanici HMAC-MD5-onaltilik" dizesini base64 kodlayıp gönderir

Kulağa PLAIN'den daha güvenli geliyor ve TLS olmayan bir dünyada gerçekten öyleydi. Ancak günümüzde CRAM-MD5'i tavsiye etmememin iki sağlam sebebi var. Birincisi sunucunun şifreyi geri döndürülebilir biçimde saklamak zorunda olmasıdır: HMAC hesabı için sunucunun ham şifreye erişmesi gerekir, dolayısıyla şifreler bcrypt gibi tek yönlü bir karma ile saklanamaz. Veritabanı sızarsa tüm şifreler açığa çıkar. İkincisi MD5'in çok eskimiş olması ve mekanizmanın sunucu kimliğini doğrulamamasıdır — yani sahte bir sunucu sizden geçerli bir cevap toplayabilir.

Modern alternatif SCRAM ailesidir (RFC 5802 ve RFC 7677'deki SCRAM-SHA-256). SCRAM da meydan okuma tabanlıdır, ancak şifreyi tuzlanmış ve yinelemeli olarak saklamaya izin verir, karşılıklı doğrulama yapar ve modern bir karma fonksiyonu kullanır. Kurumsal ortamlarda ise XOAUTH2 / OAUTHBEARER giderek standart hale geliyor: burada istemci şifre yerine kısa ömürlü bir erişim jetonu sunar, böylece uygulama şifreleri hiç dolaşıma girmez.

Hangi Mekanizmayı Ne Zaman Seçmelisiniz#

Kararın özeti tek cümlede toplanır: TLS'i zorunlu kılın, PLAIN ve LOGIN'i açık bırakın, gerisini dert etmeyin. TLS zaten tüm oturumu şifreliyorsa mekanizmanın şifreyi nasıl taşıdığı ikinci derecede bir mesele haline gelir ve siz de şifreleri düzgün karma ile saklama özgürlüğünü korursunuz.

Bu kararı uygularken izlenecek sıra şudur:

1. Sunucuda smtpd_tls_auth_only benzeri bir ayarla, kimlik doğrulamayı yalnızca TLS kurulmuş oturumlarda kabul edin.
2. Desteklenen mekanizma listesini plain login ile sınırlayın; uyumluluk için ikisi birlikte durmalı.
3. Anonim ve boş kullanıcılı mekanizmaları kapatın (noanonymous).
4. Sunucunuz SCRAM destekliyor ve istemcileriniz de destekliyorsa listeye ekleyin, ama PLAIN'i kaldırmayın — eski bir istemci bağlanamaz hale gelir.
5. CRAM-MD5'i yalnızca eskiden kalma bir zorunluluk varsa açık tutun; açtığınız anda şifre saklama politikanız da geriye gider.

Port ve TLS modu seçimi bu kararın ayrılmaz parçasıdır; 587 ile 465 arasındaki farkı ve hangisinin ne zaman doğru olduğunu STARTTLS mi implicit SSL mi yazısında ayrıntısıyla anlattım. İstemci tarafındaki ayarları kurarken Outlook e-posta istemci kurulumu yazısındaki alan eşleşmeleri işinizi kolaylaştırır.

Postfix ve Dovecot Tarafında Yapılandırma#

Postfix kimlik doğrulamayı kendisi yapmaz; SASL katmanını bir sağlayıcıya devreder. Linux dünyasında en yaygın kurulum, Dovecot'un SASL sunucusu olarak kullanılmasıdır — böylece IMAP ve SMTP aynı kullanıcı veritabanını paylaşır. Postfix tarafında yapılandırma şöyledir:

# /etc/postfix/main.cf
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

# Kimlik doğrulamayı YALNIZCA TLS oturumunda kabul et - en kritik satır
smtpd_tls_auth_only = yes

# Relay yetkisi: sadece kimliği doğrulanmış kullanıcılar ve kendi ağımız
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

Dovecot tarafında hem mekanizma listesini hem de Postfix'in bağlanacağı soketi tanımlarsınız:

# /etc/dovecot/conf.d/10-auth.conf
disable_plaintext_auth = yes
auth_mechanisms = plain login

# /etc/dovecot/conf.d/10-master.conf
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

disable_plaintext_auth = yes ile smtpd_tls_auth_only = yes birbirini tamamlar: ilki Dovecot'un, ikincisi Postfix'in şifresiz oturumda kimlik doğrulamayı reddetmesini sağlar. İkisini birlikte açın; yalnızca birini açmak katmanlardan birinde açık kapı bırakır.

Değişikliklerden sonra doğrulayın:

# Servisleri yeniden yükle
postfix reload && systemctl reload dovecot

# Postfix'in gördüğü ayarı teyit et
postconf smtpd_tls_auth_only smtpd_sasl_auth_enable smtpd_sasl_path

# Şifresiz bağlantıda AUTH duyurulmadığını doğrula (AUTH satırı GÖRÜNMEMELİ)
printf 'EHLO test\r\nQUIT\r\n' | nc mail.firmaniz.com 587 | grep -i auth

# TLS'li bağlantıda AUTH duyurulduğunu doğrula (AUTH satırı GÖRÜNMELİ)
openssl s_client -connect mail.firmaniz.com:587 -starttls smtp -crlf 2>/dev/null <<< $'EHLO test\r\nQUIT\r' | grep -i auth

Sunucunuzun kimlik doğrulama, port ve TLS uyumunu tek seferde kontrol etmek için SMTP test aracı size gerekli openssl ve swaks komutlarını hazır üretir.

Sık Yapılan Hatalar ve Kimlik Doğrulama Hataları#

En sık karşılaşılan hata, permit_sasl_authenticated'ı reject_unauth_destination'dan sonra yazmayı unutmak ya da kısıtlama listesini hiç tanımlamamaktır. Postfix bu listeyi yukarıdan aşağı işler ve ilk eşleşen kural kazanır; sıra bozulursa ya kimliği doğrulanmış kullanıcılarınız gönderemez ya da sunucunuz açık relay olur. İkinci sık hata, smtpd_tls_auth_only ayarını atlamaktır: bu durumda istemciler şifresiz bağlanıp şifrelerini düz gönderebilir ve siz bunu asla fark etmezsiniz.

Üçüncü tuzak, Dovecot soket izinlerini yanlış vermektir. /var/spool/postfix/private/auth soketine Postfix erişemezse her giriş denemesi 535 ile reddedilir ve log'da SASL bağlantı hatası görürsünüz. Dördüncüsü, istemcide "Şifrelenmiş Şifre" (CRAM-MD5) seçili kalmasıdır: sunucu bu mekanizmayı duyurmuyorsa istemci hiç denemeden hata verir ve kullanıcı şifresinin yanlış olduğunu sanır.

Karşılaşacağınız cevap kodlarının anlamı şöyledir:

Son olarak, kimlik doğrulama sorunlarını teşhis ederken sunucu log'u tek gerçek kaynaktır. Bir kullanıcı "şifrem doğru ama giremiyorum" dediğinde /var/log/mail.log içinde o oturumu bulup hangi mekanizmanın denendiğini ve neden reddedildiğini görün; mail başlıklarından sorun izlemeyi öğrenmek için mail başlıklarını okuma ve analiz etme yazısına bakabilirsiniz.

Sıkça Sorulan Sorular#

AUTH PLAIN güvenli mi#

TLS ile birlikte kullanıldığında evet, tamamen güvenlidir. PLAIN mekanizması şifreyi base64 ile kodlar ama şifrelemez; şifrelemeyi sağlayan katman TLS'tir. Dolayısıyla soru "PLAIN güvenli mi" değil, "TLS zorunlu mu" olmalıdır. Sunucunuzda kimlik doğrulamayı yalnızca TLS kurulmuş oturumlarda kabul edecek şekilde ayarladıysanız PLAIN kullanmakta hiçbir sakınca yoktur.

PLAIN ile LOGIN arasında ne fark var#

Güvenlik açısından hiçbir fark yoktur; ikisi de kimlik bilgilerini base64 ile kodlayıp gönderir. Tek fark aktarım biçimidir: PLAIN her şeyi tek satırda yollar, LOGIN ise sunucunun iki ayrı sorusuna cevap vererek iki adımda ilerler. LOGIN standartlaşmamış bir mekanizmadır ama Microsoft istemcilerinin yaygınlığı sayesinde her yerde desteklenir. İkisini birlikte açık tutmak en pratik yaklaşımdır.

CRAM-MD5 kullanmalı mıyım#

Genel öneri hayır. Şifreyi ağda göstermemesi cazip görünse de sunucunun şifreleri geri döndürülebilir biçimde saklamasını zorunlu kılar, yani veritabanı sızarsa tüm şifreler açığa çıkar. MD5 ayrıca modern standartların gerisinde kalmıştır. TLS zaten oturumu şifrelediği için CRAM-MD5'in sunduğu ek koruma pratikte anlamsızdır; TLS + PLAIN kombinasyonu hem daha güvenli hem daha basittir.

535 authentication failed hatasını nasıl çözerim#

Önce kullanıcı adının tam e-posta adresi olarak mı yoksa yalnızca kullanıcı adı olarak mı bekleniyor olduğunu kontrol edin; bu en sık sebeptir. Ardından sunucu log'una bakıp SASL katmanının hata verip vermediğini görün. Postfix + Dovecot kurulumunda /var/spool/postfix/private/auth soketinin izinleri yanlışsa her deneme bu kodla reddedilir. Son olarak istemcideki kimlik doğrulama yönteminin sunucunun duyurduğu listede olduğundan emin olun.

Sunucumun hangi kimlik doğrulama yöntemlerini desteklediğini nasıl görürüm#

Sunucuya bağlanıp EHLO komutu verdiğinizde dönen cevapta 250-AUTH ile başlayan satır desteklenen mekanizmaları listeler. Çoğu düzgün yapılandırılmış sunucu bu satırı yalnızca TLS kurulduktan sonra yayınlar, bu yüzden testi openssl s_client -connect sunucu:587 -starttls smtp ile yapın. Şifresiz bağlantıda AUTH satırının görünmemesi doğru davranıştır, arıza değil.

587 ve 465 portlarında kimlik doğrulama farklı mı çalışır#

Mekanizmalar aynıdır; fark, TLS'in ne zaman kurulduğudur. 465 portunda bağlantı daha kurulur kurulmaz şifrelenir, dolayısıyla AUTH duyurusu ilk EHLO cevabında görünür. 587 portunda ise önce şifresiz bağlanılır, STARTTLS komutuyla şifreleme başlatılır ve AUTH duyurusu ancak ikinci EHLO'da ortaya çıkar. Her iki durumda da kimlik doğrulaması TLS içinde gerçekleşmelidir.

OAuth ile SMTP kimlik doğrulaması yapabilir miyim#

Evet, bunun için XOAUTH2 veya OAUTHBEARER mekanizmaları kullanılır ve büyük kurumsal sağlayıcılar bu yönde ilerliyor. Bu modelde istemci şifre yerine kısa ömürlü bir erişim jetonu sunar, böylece uygulama şifresi hiç dolaşmaz ve jeton iptal edilebilir. Kendi Postfix + Dovecot kurulumunuzda bunu devreye almak ek bir kimlik sağlayıcı ve jeton doğrulama katmanı gerektirir, yani küçük kurulumlar için ciddi bir ek yüktür.

Kapanış#

SMTP kimlik doğrulaması karmaşık görünen ama kararı aslında sade olan bir konu. Aklınızda kalması gereken dört şey: base64 şifreleme değildir, güvenliği sağlayan TLS'tir; PLAIN ile LOGIN arasında güvenlik farkı yoktur, ikisini de açık tutun; CRAM-MD5 şifreleri geri döndürülebilir saklamaya zorladığı için bugün bir gerileme sayılır; ve smtpd_tls_auth_only ile disable_plaintext_auth ayarlarını birlikte açmadan kurulumu bitmiş saymayın.

Kendi mail sunucunuzu kurup bu ayarları yönetmek isterseniz Postfix, Dovecot, Rspamd ve DKIM'i yapılandırılmış olarak gelen SMTP sunucu paketleri size kurulum aşamasını atlatır; daha genel bir altyapı için tam root erişimli VDS sunucularına bakabilirsiniz. Posta kutularını kendiniz işletmek istemiyorsanız e-posta paketlerimiz hazır yapılandırmayla gelir, sunucu tarafını tamamen devretmek isterseniz sunucu yönetimi hizmetimiz devreye girer.