Postfix ile Dovecot Entegrasyon Sorunlarını Giderme

Bykomut

Mail sunucusu kurmak bir şeydir, onu çalışır halde tutmak bambaşka bir hikayedir. Postfix ve Dovecot ikisi birlikte kullanıldığında son derece güçlü bir mail altyapısı oluşturur, ancak bu iki servis arasındaki iletişim koptuğunda sorunları tespit etmek gerçekten sinir bozucu olabilir. Bu yazıda gerçek dünyada karşılaşılan entegrasyon sorunlarını, nasıl teşhis edileceğini ve nasıl çözüleceğini adım adım ele alacağız.

Temel Mimariyi Anlamak

Sorun gidermeden önce bu iki servisin nasıl haberleştiğini netleştirmek gerekiyor. Postfix gelen ve giden mailleri yönetir, Dovecot ise IMAP/POP3 servisi sağlar ve aynı zamanda SASL authentication için Postfix’e yardım eder. Bu iki servis arasında iki temel iletişim noktası vardır:

  • SASL Authentication: Postfix, kullanıcıların kimlik doğrulamasını Dovecot’a devreder
  • LMTP/Mailbox Delivery: Postfix, gelen mailleri Dovecot üzerinden kullanıcı mailbox’larına teslim eder

Bu iki noktadan birinde sorun yaşandığında semptomlar birbirinden çok farklı görünebilir. “Authentication failed” hatası ile “User unknown” hatası aynı kök nedenden kaynaklanıyor olabilir.

Log Dosyalarını Doğru Okumak

Sorun gidermenin ilk adımı her zaman log okumaktır. Çoğu sysadmin /var/log/mail.log veya /var/log/maillog dosyasını açar ve rastgele bir şeylere bakar. Oysa doğru yaklaşım daha sistematik olmalıdır.

# Gerçek zamanlı log takibi
tail -f /var/log/mail.log | grep -E "(warning|error|fatal|panic)"

# Son 100 satırda authentication hatalarını bul
grep -i "sasl|auth|login" /var/log/mail.log | tail -100

# Belirli bir IP'den gelen bağlantıları takip et
grep "192.168.1.100" /var/log/mail.log | tail -50

# Dovecot loglarını ayrı takip et
journalctl -u dovecot -f --since "10 minutes ago"

Dikkat etmeniz gereken log satırı kalıpları şunlardır. warning: SASL authentication failure görüyorsanız Dovecot-Postfix SASL entegrasyonunda sorun var demektir. noqueue: reject ile başlayan satırlar ise Postfix’in mail kabul etmediğini gösterir. dovecot: auth: Fatal ise Dovecot’un authentication servisinin tamamen çöktüğüne işaret eder.

Servis Durumu Kontrolü

İlk yapmanız gereken her iki servisin de ayakta olduğunu doğrulamaktır. Bu bariz görünse de üretim ortamında sık sık atlanan bir adımdır.

# Servis durumlarını kontrol et
systemctl status postfix
systemctl status dovecot

# Hangi portları dinlediklerini doğrula
ss -tlnp | grep -E "(25|143|587|993|995|110)"

# Postfix process listesi
postfix status

# Dovecot process ve worker listesi
doveadm who

Özellikle doveadm who komutu aktif bağlantıları gösterir. Eğer bu komut hata veriyorsa Dovecot’un authentication servisi ile ilgili ciddi bir sorun var demektir.

SASL Authentication Sorunları

Bu kategori en sık karşılaşılan sorunların başında gelir. Kullanıcılar mail istemcisinden bağlanmaya çalışırken “Authentication failed” hatası alır.

Postfix Tarafında SASL Yapılandırması

# Mevcut SASL yapılandırmasını kontrol et
postconf -n | grep -E "sasl|auth"

# Beklenen çıktı şuna benzer olmalı:
# smtpd_sasl_auth_enable = yes
# smtpd_sasl_path = private/auth
# smtpd_sasl_type = dovecot

Eğer smtpd_sasl_path değeri yanlışsa Postfix, Dovecot’un socket’ını bulamaz. /etc/postfix/main.cf dosyasında şu satırların olması gerekir:

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

Dovecot Tarafında Auth Socket

Dovecot’un Postfix için auth socket oluşturması gerekir. /etc/dovecot/conf.d/10-master.conf dosyasında şu blok bulunmalıdır:

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

Socket dosyasının gerçekten var olup olmadığını kontrol edin:

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

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

# Dovecot auth servisini test et
doveadm auth test [email protected] testpassword

doveadm auth test komutu çok değerlidir. Bu komut başarılı çıktı verdiği halde Postfix üzerinden authentication çalışmıyorsa sorun socket izinlerindedir.

Sık Karşılaşılan Senaryo: Chroot Sorunu

Postfix bazı dağıtımlarda chroot içinde çalışır. Bu durumda socket yolu farklı değerlendirilir. Debian/Ubuntu’da Postfix chroot’u /var/spool/postfix altındadır.

# Postfix chroot durumunu kontrol et
grep "^smtpb|^smtpdb" /etc/postfix/master.cf | head -5

# n (no chroot) veya y (yes chroot) kolonuna bak
# Örnek çıktı:
# smtp      inet  n       -       y       -       -       smtpd

Eğer Postfix chroot içindeyse (y değeri), socket yolu /var/spool/postfix/private/auth olarak kalmalı ve Dovecot da bu yola yazmalıdır. Chroot yoksa (n değeri) tam yol belirtmeniz gerekebilir.

LMTP ile Mail Teslim Sorunları

Mail kimlik doğrulamasından geçiyor ama kullanıcının mailbox’ına ulaşmıyorsa sorun LMTP konfigürasyonundadır.

# Postfix virtual_transport ayarını kontrol et
postconf -n | grep -E "virtual|transport|lmtp"

# Mail kuyruğunu kontrol et
mailq

# Kuyrukta bekleyen mailleri detaylı incele
postcat -q QUEUE_ID

/etc/postfix/main.cf içinde LMTP için şu yapılandırma olmalıdır:

virtual_transport = lmtp:unix:private/dovecot-lmtp
# veya TCP üzerinden
virtual_transport = lmtp:inet:localhost:24

Dovecot tarafında LMTP servisinin aktif olması gerekir. /etc/dovecot/conf.d/10-master.conf içinde:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
  # veya TCP için
  inet_listener lmtp {
    address = 127.0.0.1
    port = 24
  }
}

LMTP Bağlantısını Manuel Test Etme

# LMTP servisini doğrudan test et (TCP kullanıyorsanız)
telnet 127.0.0.1 24

# Unix socket test (socat gerekli)
socat - UNIX-CONNECT:/var/spool/postfix/private/dovecot-lmtp

Bu komuttan sonra 220 hostname Dovecot LMTP ready gibi bir yanıt almanız gerekir. Yanıt gelmiyorsa servis dinlemiyordur.

Mailbox İzin Sorunları

Gerçek dünyada sıkça yaşanan ve çözümü genellikle göz ardı edilen bir sorun türüdür. Mail teslim edilmeye çalışılır ancak “Permission denied” veya “Maildir: mkdir failed” hatası alınır.

# Mevcut mail dizin yapısını kontrol et
ls -la /var/mail/vhosts/domain.com/

# Dovecot'un hangi kullanıcı olarak çalıştığını öğren
ps aux | grep dovecot

# Dovecot mail kullanıcı ayarlarını kontrol et
doveadm config -n | grep -E "mail_uid|mail_gid|first_valid_uid"

Mail dizinlerinin sahipliği ve izinleri kritiktir:

# Virtual mailbox dizini için tipik düzeltme
chown -R vmail:vmail /var/mail/vhosts/
chmod -R 700 /var/mail/vhosts/

# Sadece belirli bir kullanıcının dizinini düzelt
chown -R vmail:vmail /var/mail/vhosts/domain.com/username/

/etc/dovecot/conf.d/10-mail.conf dosyasında mail_uid ve mail_gid değerleri ile gerçek sistem kullanıcısı eşleşmelidir:

mail_uid = vmail
mail_gid = vmail
first_valid_uid = 150
last_valid_uid = 150

TLS/SSL Sertifika Sorunları

Modern mail sunucularında TLS neredeyse zorunludur. Sertifika sorunları hem SMTP hem IMAP bağlantılarını etkileyebilir.

# Postfix TLS konfigürasyonunu kontrol et
postconf -n | grep -E "tls|ssl|cert|key"

# Sertifika dosyalarının varlığını doğrula
ls -la /etc/ssl/certs/mail.crt
ls -la /etc/ssl/private/mail.key

# Sertifika geçerlilik süresini kontrol et
openssl x509 -in /etc/ssl/certs/mail.crt -noout -dates

# Sertifika ve anahtar uyumunu kontrol et
openssl x509 -in /etc/ssl/certs/mail.crt -noout -modulus | md5sum
openssl rsa -in /etc/ssl/private/mail.key -noout -modulus | md5sum

Bu iki md5sum çıktısı aynı olmalıdır. Farklıysa sertifika ve anahtar dosyaları birbirine uymuyor demektir, bu durumda Postfix başlatılırken hata verir.

Dovecot için SSL konfigürasyonu /etc/dovecot/conf.d/10-ssl.conf dosyasındadır:

ssl = required
ssl_cert = </etc/ssl/certs/mail.crt
ssl_key = </etc/ssl/private/mail.key
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

< işaretinin dosya yolunun önünde olması Dovecot’a özgü bir sözdizimidir, unutmayın.

Veritabanı Tabanlı Kullanıcı Yönetiminde Sorunlar

Büyük ölçekli ortamlarda kullanıcılar genellikle MySQL veya PostgreSQL veritabanında tutulur. Bu durumda ek sorun noktaları ortaya çıkar.

# Dovecot'un veritabanı bağlantısını test et
doveadm auth lookup [email protected]

# Postfix virtual user tablosunu kontrol et
postmap -q [email protected] mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

# MySQL bağlantısını manuel test et
mysql -u mailuser -p maildb -e "SELECT username FROM virtual_users WHERE username='[email protected]';"

Eğer postmap -q komutu sonuç döndürmüyorsa Postfix MySQL konfigürasyon dosyasında sorun var demektir. /etc/postfix/mysql-virtual-mailbox-maps.cf içeriği şöyle olmalıdır:

user = mailuser
password = gizlisifre
hosts = 127.0.0.1
dbname = maildb
query = SELECT 1 FROM virtual_users WHERE username='%s' AND active=1

Önemli not: query satırındaki %s Postfix için doğru placeholder’dır. Bazı konfigürasyon örneklerinde yanlış placeholder kullanıldığını görüyorum, bu çok yaygın bir hata kaynağıdır.

Debug Modunu Etkinleştirme

Standart log çıktısı yetmediğinde her iki servisi de debug modunda çalıştırabilirsiniz.

# Postfix debug modu - belirli bir IP için
postconf -e "debug_peer_list = 192.168.1.100"
postconf -e "debug_peer_level = 3"
systemctl reload postfix

# İşlem bittikten sonra debug'ı kapat
postconf -e "debug_peer_list ="
postconf -e "debug_peer_level = 2"

# Dovecot auth debug
# /etc/dovecot/conf.d/10-logging.conf dosyasına ekle:
# auth_verbose = yes
# auth_debug = yes
# auth_debug_passwords = yes
systemctl reload dovecot

auth_debug_passwords = yes ayarını sadece sorun giderme sırasında açın ve işiniz bittikten hemen sonra kapatın. Bu ayar açıkken şifreler log dosyasına düz metin olarak yazılır.

Sık Karşılaşılan Hata Mesajları ve Çözümleri

“SASL LOGIN authentication failed: UGFzc3dvcmQ6”

Bu Base64 encoded bir metin olup “Password:” anlamına gelir. Genellikle Postfix’in Dovecot’un SASL cevabını anlayamadığı durumlarda görülür.

Çözüm olarak broken_sasl_auth_clients = yes satırının main.cf içinde olduğundan emin olun ve Postfix’i yeniden başlatın.

“Temporary lookup failure”

# DNS çözümleme sorunlarını kontrol et
dig +short MX domain.com
host -t MX domain.com

# Postfix DNS ayarları
postconf -n | grep "resolve|dns|lookup"

Bu hata genellikle virtual_mailbox_maps veya virtual_alias_maps için yapılan veritabanı sorgusunun geçici olarak başarısız olduğunu gösterir.

“maildir: error: chdir”

# Kullanıcı home dizininin varlığını kontrol et
doveadm user [email protected]

# Dizini oluştur ve izinleri düzelt
maildirmake.dovecot /var/mail/vhosts/domain.com/testuser
chown -R vmail:vmail /var/mail/vhosts/domain.com/testuser

“Connection refused” Hatası

Hem Postfix hem de Dovecot ayakta olduğu halde bu hata geliyorsa firewall veya SELinux/AppArmor kaynaklı olabilir:

# Firewall kontrolü
iptables -L -n | grep -E "(25|143|587|993)"
ufw status verbose

# SELinux durumu
getenforce
# SELinux aktifse mail için izinleri kontrol et
sealert -a /var/log/audit/audit.log | grep dovecot

# AppArmor durumu (Ubuntu/Debian)
aa-status | grep -E "dovecot|postfix"

Yapılandırma Tutarlılığını Doğrulama

Her iki servisi de yeniden başlatmadan önce konfigürasyon sözdizimini kontrol etmek kritik bir alışkanlıktır:

# Postfix konfigürasyonunu kontrol et
postfix check
postconf -n

# Dovecot konfigürasyonunu kontrol et
dovecot -n
doveconf -n

# Tüm Dovecot ayarlarını göster (varsayılanlar dahil)
doveconf -a | grep -A2 "service auth"

# Postfix master.cf syntax kontrolü
postfix check 2>&1 | grep -i error

dovecot -n komutu syntax hatası varsa açıkça belirtir ve hangi satırda olduğunu gösterir. Bu komutu her büyük değişiklikten önce çalıştırın.

Monitoring ve Proaktif Sorun Tespiti

Sorunları reaktif olarak çözmek yerine proaktif izleme kurabilirsiniz:

# Mail kuyruğu boyutunu periyodik kontrol et
watch -n 30 "mailq | tail -1"

# Authentication başarısızlıklarını say
grep "$(date '+%b %e')" /var/log/mail.log | grep -c "authentication failed"

# Dovecot istatistikleri
doveadm stats dump

# Son 1 saatte gelen mail sayısı
grep "$(date '+%b %e %H')" /var/log/mail.log | grep "status=sent" | wc -l

Basit bir cron job ile mail kuyruğu şiştiğinde uyarı alabilirsiniz:

# /etc/cron.d/mail-queue-check dosyası oluştur
*/15 * * * * root QUEUE=$(mailq | grep -c "^[0-9A-F]"); [ $QUEUE -gt 100 ] && echo "Mail kuyruğu $QUEUE mesaj içeriyor" | mail -s "UYARI: Mail Kuyruğu" [email protected]

Gerçek Dünya Senaryosu: Güncelleme Sonrası Kopan Entegrasyon

Bir müşterinin Ubuntu sunucusunda apt upgrade sonrasında Dovecot güncellendi ve socket yolu değişti. Postfix eski socket yolunu aradığı için tüm authentication çalışmaz hale geldi. Bu tip sorunları hızlıca teşhis etmek için şu kontrol akışını öneririm:

  • Önce her iki servisin de ayakta olduğunu doğrulayın
  • doveadm auth test ile Dovecot’un kendi içinde çalıştığını teyit edin
  • Socket dosyasının var olduğunu ve doğru izinlere sahip olduğunu kontrol edin
  • postconf smtpd_sasl_path ile Postfix’in hangi socket yoluna baktığını görün
  • İki değer uyuşmuyorsa main.cf dosyasını güncelleyip Postfix’i reload edin
# Hızlı teşhis scripti
echo "=== Postfix SASL Path ===" 
postconf smtpd_sasl_path
echo "=== Dovecot Socket ===" 
ls -la /var/spool/postfix/private/auth 2>/dev/null || echo "Socket YOK!"
echo "=== Dovecot Auth Test ===" 
doveadm auth test [email protected] testpass123 2>&1 | head -3
echo "=== Mail Queue ===" 
mailq | tail -1

Bu scripti bir alias olarak .bashrc dosyasına eklemek mail sorunlarında ilk başvuru noktanız olabilir.

Sonuç

Postfix ve Dovecot entegrasyon sorunlarının büyük çoğunluğu üç ana kategoride toplanır: socket iletişim sorunları, izin hataları ve konfigürasyon uyuşmazlıkları. Bu üç kategoriye odaklanarak ve yukarıdaki sistematik teşhis yaklaşımını izleyerek sorunların yüzde seksenini çok hızlı çözebilirsiniz.

Önemli olan nokta şudur: değişiklik yapmadan önce postfix check ve dovecot -n komutlarını çalıştırın, log dosyalarını düzenli takip edin ve authentication debug’ı açtıysanız kapatmayı unutmayın. Mail sunucusu yönetimi sabır isteyen bir iştir, ancak log okuma alışkanlığı edindikten sonra sorunlar düşündüğünüzden çok daha çabuk çözülür. Son olarak yaptığınız her değişikliği belgelendirin, çünkü iki ay sonra aynı sorunu yaşadığınızda kendi notlarınız en değerli kaynağınız olacaktır.

Benzer Konular

Bir yanıt yazın

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