Authentication Hatası: SASL ve SMTP Auth Sorunlarını Çözme

Bykomut

Mail sunucunuzda kullanıcılar “Authentication failed” hatası alıyor, e-postalar gitmiyor ve telefon çalmaya başlıyor. Bu senaryoyu yaşadıysanız, SASL ve SMTP auth sorunlarının ne kadar sinir bozucu olabileceğini biliyorsunuzdur. Bu yazıda bu hataların kökünü nasıl bulacağınızı ve düzelteceğinizi adım adım anlatacağım.

SASL Nedir ve Neden Önemlidir?

SASL (Simple Authentication and Security Layer), mail sunucularının kullanıcı kimlik doğrulamasını gerçekleştirdiği çerçeve protokoldür. Postfix gibi bir MTA (Mail Transfer Agent) kendi başına kullanıcı adı/şifre doğrulaması yapmaz. Bu işi Dovecot veya Cyrus SASL gibi bir servise devreder. Yani aradaki bu köprü koptuğunda, tüm auth mekanizması çöker.

Tipik bir mail sunucusunda zincir şu şekilde işler:

  • Mail istemcisi SMTP sunucusuna bağlanır
  • Sunucu AUTH komutunu desteklediğini bildirir
  • İstemci kullanıcı adı ve şifreyi gönderir
  • Postfix bu bilgiyi SASL mekanizmasına (genellikle Dovecot) iletir
  • Dovecot doğrulamayı yapar ve sonucu Postfix’e bildirir
  • Postfix izin verir ya da reddeder

Bu zincirin herhangi bir halkası koptuğunda “535 5.7.8 Authentication credentials invalid” veya “454 4.7.0 Temporary authentication failure” gibi hatalar görürsünüz.

Hata Mesajlarını Okumak

İlk yapmanız gereken şey log dosyalarına bakmaktır. Sorunun nerede olduğunu anlamak için doğru log satırını bulmak kritik öneme sahiptir.

# Postfix loglarını gerçek zamanlı izle
tail -f /var/log/mail.log | grep -E "sasl|auth|warning|error"

# Son 100 satırı filtrele
grep -i "authentication" /var/log/mail.log | tail -100

# Belirli bir kullanıcı için hataları bul
grep "[email protected]" /var/log/mail.log | grep -i "fail|error|reject"

Karşılaştığınız hata mesajları size çok şey söyler:

  • 535 Authentication credentials invalid: Kullanıcı adı veya şifre yanlış, ya da auth mekanizması çalışmıyor
  • 454 Temporary authentication failure: SASL servisi geçici olarak çalışmıyor, socket bağlantısı yok
  • 503 5.5.1 Error: send HELO/EHLO first: İstemci auth öncesi EHLO göndermedi
  • 538 5.7.11 Encryption required: TLS olmadan auth denemesi
  • 334: Sunucu auth için kullanıcı adı bekliyor (bu normal bir adım)

Postfix SASL Konfigürasyonunu Kontrol Etmek

main.cf Ayarları

Postfix’in SASL için doğru yapılandırıldığından emin olun:

# Mevcut SASL ayarlarını görüntüle
postconf | grep -i sasl

# Kritik parametreleri tek tek kontrol et
postconf smtpd_sasl_auth_enable
postconf smtpd_sasl_type
postconf smtpd_sasl_path
postconf smtpd_sasl_security_options

/etc/postfix/main.cf dosyasında şu satırların olması gerekir:

# SASL Authentication
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes

# TLS ile birlikte auth zorunlu kılmak için
smtpd_tls_auth_only = yes

smtpd_sasl_path = private/auth satırı önemlidir. Bu, Postfix’in Dovecot SASL socket’ını nerede arayacağını belirtir. Bu yol /var/spool/postfix/private/auth olarak genişler.

Socket Dosyasını Kontrol Etmek

En yaygın sorunlardan biri socket dosyasının olmaması veya izin sorunlarıdır:

# Socket dosyasının varlığını kontrol et
ls -la /var/spool/postfix/private/auth

# Eğer yoksa Dovecot'u yeniden başlat
systemctl restart dovecot

# Socket'ın dinlediğini doğrula
ss -xlp | grep auth

Eğer socket dosyası yoksa Dovecot düzgün çalışmıyor demektir. Bu durumda Dovecot loglarına bakmalısınız.

Dovecot SASL Konfigürasyonu

10-master.conf Ayarları

Dovecot’un SASL socket’ını Postfix için açması gerekir. /etc/dovecot/conf.d/10-master.conf dosyasını kontrol edin:

# Dovecot konfigürasyonundaki auth-userdb bloğunu bul
grep -A 20 "service auth " /etc/dovecot/conf.d/10-master.conf

Doğru konfigürasyon şu şekilde olmalıdır:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }

  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }
}

Bu bloğu değiştirdikten sonra Dovecot’u yeniden başlatın:

systemctl restart dovecot
systemctl status dovecot

# Dovecot loglarını kontrol et
journalctl -u dovecot -n 50 --no-pager

10-auth.conf Kontrolleri

# Auth mekanizmalarını kontrol et
grep -v "^#|^$" /etc/dovecot/conf.d/10-auth.conf

# Hangi mekanizmalar aktif?
dovecot -a 2>&1 | grep "auth_mechanisms"

auth_mechanisms = plain login satırı olması gerekir. Sadece CRAM-MD5 gibi challengeresponse mekanizmaları varsa bazı istemcilerle sorun yaşayabilirsiniz.

Gerçek Dünya Senaryosu: “535 Authentication Failed” Sorunu

Bir müşterinin mail sunucusunda tüm kullanıcılar sabah 8’den itibaren mail gönderemiyor diye çağrı aldım. Log dosyasına baktığımda şunu gördüm:

grep "535" /var/log/mail.log | head -20
# Çıktı:
# postfix/smtpd[12345]: warning: SASL authentication failure: no secret in database
# postfix/smtpd[12345]: warning: hostname.example.com[192.168.1.100]: SASL PLAIN authentication failed: authentication failure

“no secret in database” mesajı Cyrus SASL kullandıklarına işaret ediyordu ve sasldb dosyası bozulmuştu. Çözüm:

# Cyrus SASL kullanılıyorsa sasldb'yi kontrol et
ls -la /etc/sasldb2
sasldblistusers2

# Bozuksa rebuild et
# Önce kullanıcıları yedekle, sonra yeniden ekle
echo "password" | saslpasswd2 -c -u example.com username

# Postfix'in sasldb'yi okuyabilmesi için izinleri ayarla
chown postfix:postfix /etc/sasldb2
chmod 640 /etc/sasldb2

Asıl sorun şuydu: Gece yarısı çalışan bir yedekleme scripti sasldb2 dosyasının sahipliğini değiştirmişti ve Postfix dosyayı okuyamaz hale gelmişti.

Manuel SMTP Auth Testi

Sorunun nedenini bulmak için SMTP auth’u manuel olarak test etmek çok işe yarar. Bunun için önce base64 encoded kullanıcı adı ve şifre hazırlamanız gerekir:

# Kullanıcı adı ve şifreyi base64'e çevir
echo -ne "[email protected]" | base64
# Çıktı: AHVzZXJuYW1lQGV4YW1wbGUuY29tAHBhc3N3b3Jk

# Telnet ile manuel test (plain text, sadece test için)
telnet mail.example.com 25
# Bağlandıktan sonra:
EHLO testclient.example.com
AUTH PLAIN AHVzZXJuYW1lQGV4YW1wbGUuY29tAHBhc3N3b3Jk

TLS gerektiren sunucularda openssl kullanın:

# OpenSSL ile TLS üzerinden test
openssl s_client -starttls smtp -connect mail.example.com:587 -quiet

# Bağlandıktan sonra aynı EHLO ve AUTH komutlarını kullanın
EHLO testclient
AUTH PLAIN AHVzZXJuYW1lQGV4YW1wbGUuY29tAHBhc3N3b3Jk

235 2.7.0 Authentication successful görürseniz auth çalışıyor demektir. Sorun muhtemelen istemci tarafındadır.

İzin Sorunları ve SELinux/AppArmor

Bu konuyu atlayan sysadminlerin çoğu saatlerce boşa uğraşır. Özellikle CentOS/RHEL sistemlerde SELinux, Postfix ve Dovecot arasındaki socket iletişimini engelleyebilir.

# SELinux audit loglarını kontrol et
ausearch -m avc -ts recent | grep postfix
ausearch -m avc -ts recent | grep dovecot

# SELinux'un mail ile ilgili boolean'larını kontrol et
getsebool -a | grep mail
getsebool -a | grep postfix

# Gerekli boolean'ları aktif et
setsebool -P allow_postfix_local_write_mail_spool 1

Ubuntu/Debian sistemlerde AppArmor benzer sorunlara yol açabilir:

# AppArmor durumunu kontrol et
aa-status | grep -E "postfix|dovecot"

# Logları kontrol et
grep -i "apparmor" /var/log/syslog | grep -E "postfix|dovecot" | tail -20

Gerçek Dünya Senaryosu: Port 587 vs 465

Bir diğer yaygın senaryo: Kullanıcıların bir kısmı mail gönderirken sorun yaşıyor, bir kısmı yaşamıyor. Log incelendiğinde port 587 üzerinden bağlananların sorun yaşadığı görülüyor.

# master.cf'deki submission port ayarlarını kontrol et
grep -A 15 "^submission" /etc/postfix/master.cf

Sorun genellikle master.cf‘de submission servisinin eksik SASL ayarları içermesidir:

# /etc/postfix/master.cf - submission servisi
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Değişiklik sonrası Postfix’i reload edin:

postfix check && systemctl reload postfix

Dovecot Auth Debug Modu

Dovecot’un debug modunu açmak, sorunun tam olarak nerede olduğunu anlamak için altın değerindedir:

# /etc/dovecot/conf.d/10-logging.conf dosyasını düzenle
# auth_verbose = yes
# auth_debug = yes
# auth_debug_passwords = yes  # DİKKAT: Şifreleri loglar, sadece test için!

# Değişikliği uygula
systemctl reload dovecot

# Gerçek zamanlı dovecot loglarını izle
journalctl -u dovecot -f

# Test sonrası debug'u kapat!

Bu loglar size “user not found”, “password mismatch”, “user disabled” gibi çok spesifik mesajlar verir.

Yaygın Hataların Hızlı Çözüm Rehberi

“454 Temporary authentication failure”

Bu hata genellikle Dovecot çalışmıyor ya da socket mevcut değil demektir:

# Dovecot durumu
systemctl status dovecot

# Socket var mı?
ls -la /var/spool/postfix/private/auth

# Dovecot'u yeniden başlat
systemctl restart dovecot

# 5 saniye bekle, socket oluştu mu kontrol et
sleep 5 && ls -la /var/spool/postfix/private/auth

“535 5.7.8 Error: authentication failed”

Bu hata yanlış kimlik bilgileri veya mekanizma uyumsuzluğu demektir:

# Kullanıcının Dovecot'ta var olup olmadığını test et
doveadm auth test [email protected] password

# Kullanıcı bilgilerini görüntüle
doveadm user [email protected]

# Şifreyi sıfırla (virtual kullanıcılar için)
doveadm pw -s SHA512-CRYPT
# Üretilen hash'i passwdfile veya database'e yaz

“Broken pipe” veya “Connection reset” Hataları

# TLS sertifikalarını kontrol et
openssl x509 -in /etc/postfix/ssl/cert.pem -text -noout | grep -E "Not Before|Not After|Subject"

# Sertifika süresi dolmuş mu?
openssl x509 -in /etc/postfix/ssl/cert.pem -checkend 86400

# Postfix TLS ayarlarını doğrula
postconf | grep tls

Postfix SASL Debug Etkinleştirme

Postfix tarafında da debug seviyesini artırabilirsiniz:

# main.cf'e debug ekle (geçici olarak)
# /etc/postfix/main.cf
# debug_peer_list = 192.168.1.100  # Test istemcisinin IP'si
# debug_peer_level = 3

# Reload
postfix reload

# Log izle
tail -f /var/log/mail.log | grep "debug|sasl|auth"

# Test bitti mi? Debug'u kaldır
# main.cf'den satırları sil, reload yap

Atak Senaryosu: Brute Force ve Auth Lockout

Bazen sorun teknik değil, güvenlik önlemlerinden kaynaklanır. Bir kullanıcı sürekli yanlış şifre girince IP’si veya hesabı kilitlenebilir:

# Fail2ban durumunu kontrol et
fail2ban-client status postfix-sasl

# Belirli bir IP'nin engellenip engellenmediğine bak
fail2ban-client status postfix-sasl | grep "192.168.1.100"

# IP'yi unban et
fail2ban-client set postfix-sasl unbanip 192.168.1.100

# Son 1 saatte kaç auth failure var?
grep "authentication failed" /var/log/mail.log | 
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Eğer bir IP’den çok sayıda başarısız deneme geliyorsa ve meşru kullanıcılar etkileniyorsa, Fail2ban’ın bantime ve maxretry değerlerini gözden geçirin.

Konfigürasyon Değişikliği Sonrası Doğrulama

Her değişiklik sonrası şu doğrulama rutinini uygulayın:

# Postfix konfigürasyonunu doğrula
postfix check
echo $?  # 0 ise hata yok

# Dovecot konfigürasyonunu doğrula
dovecot -n 2>&1 | grep -i "error|warning"

# Servisleri yeniden başlat
systemctl restart dovecot
systemctl restart postfix

# Her iki servis de ayakta mı?
systemctl is-active dovecot postfix

# Socket oluştu mu?
ls -la /var/spool/postfix/private/auth

# Hızlı auth testi
echo "Test e-postası" | mail -s "SASL Test" [email protected] 2>&1

Sonuç

SASL ve SMTP auth sorunları genellikle şu beş kategoriden birinde gizlidir: socket/izin sorunları, yanlış konfigürasyon, servis çökmesi, sertifika problemleri ve brute force koruması. Sistematik yaklaşırsanız, yani önce log, sonra socket, sonra konfigürasyon, sonra test sırasıyla giderseniz, bu sorunların büyük çoğunluğunu 15-20 dakikada çözebilirsiniz.

doveadm auth test komutu her sysadmin’in silahşörünün baş tabancası olmalıdır. Auth zincirini en kısa yoldan test etmenizi sağlar ve “sorun Postfix’te mi, Dovecot’ta mı, istemcide mi?” sorusunu hemen yanıtlar.

Bir de şunu söyleyeyim: Production ortamında auth debug ve özellikle auth_debug_passwords = yes ayarını açık bırakmayın. Test bitince kapatın. Log dosyalarında kullanıcı şifrelerini düz metin olarak görmek hiç iyi bir his değildir.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir