Postfix Log Analizi ile Mail Sunucu Hatalarını Tespit Etme

Bykomut

Mail sunucunuzu kurdunuz, her şey çalışıyor gibi görünüyor ama müşteriler maillerini alamıyor. Ya da gönderdiğiniz mailler spam’e düşüyor, bounce alıyorsunuz ama sebebini bilmiyorsunuz. İşte tam bu noktada Postfix logları hayat kurtarıcı olur. Yıllarca mail sunucusu yöneten biri olarak söyleyebilirim ki, Postfix log analizi öğrendiğinizde mail sorunlarının %90’ını kendi başınıza çözebilirsiniz.

Postfix Log Dosyaları Nerede ve Ne İçerir

Postfix, tüm işlemlerini sistem log’una yazar. Dağıtıma göre log dosyasının yeri değişir:

  • Debian/Ubuntu: /var/log/mail.log
  • RHEL/CentOS/Rocky Linux: /var/log/maillog
  • Systemd tabanlı sistemler: journalctl -u postfix

Log dosyasına her baktığınızda önce yapısını anlamanız gerekiyor. Bir Postfix log satırı şu formatta gelir:

Ayın Günü Saat Hostname ProcessName[PID]: queue_id: mesaj

Örnek bir satır:

Dec 15 09:23:14 mailserver postfix/smtp[12345]: A1B2C3D4E5F6: to=<[email protected]>, relay=mx1.hedef.com[192.168.1.1]:25, delay=2.5, delays=0.1/0.2/1.8/0.4, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as XYZ123)

Bu satırda şunları okuyoruz:

  • A1B2C3D4E5F6: Mail’in kuyruk ID’si, takip için kullanacağınız ana referans
  • to=: Alıcı adresi
  • relay=: Mailin iletildiği sunucu
  • delay=: Toplam gecikme süresi (saniye)
  • delays=: Gecikmenin nereden kaynaklandığı (sırasıyla: kuyruk öncesi, kuyrukta, bağlantı, transfer)
  • dsn=: Delivery Status Notification kodu, 2.x.x başarılı, 4.x.x geçici hata, 5.x.x kalıcı hata
  • status=: sent, bounced, deferred gibi durumlar

Temel Log Okuma Komutları

Logları ham haliyle okumak yerine filtreleyerek çalışmak çok daha verimli. İşte günlük kullandığım komutlar:

# Son 100 mail log satırını göster
tail -100 /var/log/mail.log

# Gerçek zamanlı log takibi
tail -f /var/log/mail.log

# Belirli bir mail adresine ait tüm log satırları
grep "[email protected]" /var/log/mail.log

# Bugünün hatalarını göster
grep "$(date '+%b %e')" /var/log/mail.log | grep -E "reject|error|warning|bounced"

# Belirli bir queue ID'yi takip et
grep "A1B2C3D4E5F6" /var/log/mail.log

Buradaki en önemli nokta queue ID takibi. Bir mail sorununu araştırırken ilk adımınız her zaman o mailin queue ID’sini bulmak olmalı. Queue ID’yi bulduktan sonra tüm süreci adım adım takip edebilirsiniz.

Gerçek Dünya Senaryosu 1: Mail Gönderilemiyor, “Connection Refused” Hatası

Sabah erkenden bir müşteri arıyor: “Dün akşamdan beri mail gönderemiyorum.” Log’a bakıyorsunuz:

grep "status=bounced|status=deferred" /var/log/mail.log | tail -50

Çıktıda şunu görüyorsunuz:

Dec 15 08:45:22 mailserver postfix/smtp[9876]: B2C3D4E5F601: to=<[email protected]>, relay=none, delay=0.5, delays=0.1/0.0/0.4/0.0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection refused)

dsn=4.4.1 geçici bir bağlantı hatası. Port 25 üzerinden dışarıya çıkamıyorsunuz. Bu genellikle şu sebeplerden kaynaklanır:

  • ISP port 25 engeli
  • Firewall kuralı
  • Sunucunun IP’sinin kara listeye alınması

Hızlıca kontrol edelim:

# Port 25 çıkışını test et
telnet gmail-smtp-in.l.google.com 25

# Alternatif olarak
nc -zv gmail-smtp-in.l.google.com 25

# Firewall kurallarını kontrol et
iptables -L OUTPUT -n | grep 25
# ya da
firewall-cmd --list-all

Eğer port 25 engelliyse ve VPS kullanıyorsanız, büyük ihtimalle hosting sağlayıcınız port 25’i kapatmıştır. Bu durumda SMTP relay (SendGrid, AWS SES, Mailgun) kullanmanız gerekir.

Gerçek Dünya Senaryosu 2: Bounce Alan Mailler ve 5xx Hataları

Bir diğer yaygın senaryo: Gönderdiğiniz mailler anında bounce olarak geri geliyor. Log analizi:

# Son 24 saatteki bounce'ları listele
grep "status=bounced" /var/log/mail.log | grep "$(date '+%b %e')" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Tipik bir 5xx hatası şöyle görünür:

Dec 15 10:12:33 mailserver postfix/smtp[11234]: C3D4E5F60712: to=<[email protected]>, relay=mail.firma.com[10.0.0.1]:25, delay=1.2, delays=0.1/0.1/0.9/0.1, dsn=5.1.1, status=bounced (host mail.firma.com[10.0.0.1] said: 550 5.1.1 The email account that you tried to reach does not exist (in reply to RCPT TO command))

dsn=5.1.1 kullanıcı bulunamadı demek. Bu durumda yapılacak şey basit: alıcı adresini doğrulamak. Ama bazen daha karmaşık durumlarla karşılaşırsınız:

dsn=5.7.1: Mesaj reddedildi, spam politikası
dsn=5.7.26: DMARC politikası ihlali
dsn=5.7.0: Relay erişimi reddedildi

5.7.26 görürseniz DMARC sorununuz var demektir. Hemen DNS kayıtlarınızı kontrol edin:

# DMARC kaydını kontrol et
dig TXT _dmarc.sirketiniz.com

# SPF kaydını kontrol et
dig TXT sirketiniz.com | grep spf

# DKIM kontrolü için postfix ayarları
postconf | grep dkim

Kuyruk Yönetimi ve Takışmış Mailler

Bazen mailler kuyrukta takılır ve sürekli “deferred” durumunda kalır. Kuyruğu görüntülemek için:

# Kuyruktaki mail sayısını göster
mailq | tail -1

# Detaylı kuyruk listesi
mailq

# Postqueue ile kuyruk durumu
postqueue -p

# Takılmış mailleri say
postqueue -p | grep "^[A-Z0-9]" | wc -l

Kuyruktaki belirli bir maili incelemek için:

# Queue ID ile mail içeriğini görüntüle (header dahil)
postcat -q A1B2C3D4E5F6

# Sadece envelope bilgisi
postcat -qe A1B2C3D4E5F6

Kuyruğu yönetmek gerektiğinde:

# Tüm deferred mailleri tekrar göndermeyi dene
postqueue -f

# Kuyruktaki tüm mailleri sil (dikkatli kullanın!)
postsuper -d ALL

# Sadece deferred mailleri sil
postsuper -d ALL deferred

# Belirli bir queue ID'yi sil
postsuper -d A1B2C3D4E5F6

# Belirli bir adrese giden mailleri kuyruktan sil
postqueue -p | grep "[email protected]" | awk '{print $1}' | postsuper -d -

Log Analizi ile Spam ve Kara Liste Kontrolü

Sunucunuzun IP’si kara listeye alındığında mailler sürekli reddedilir. Logda şunu görürsünüz:

Dec 15 11:30:45 mailserver postfix/smtp[13456]: D4E5F6071823: to=<[email protected]>, relay=mx.hedef.com[203.0.113.1]:25, delay=3.1, delays=0.2/0.1/2.5/0.3, dsn=5.7.1, status=bounced (host mx.hedef.com[203.0.113.1] said: 550 5.7.1 Service unavailable; Client host [123.45.67.89] blocked using Spamhaus. To request removal from this list see https://www.spamhaus.org/query/ip/123.45.67.89)

Bu tür hataları toplu tespit etmek için:

# Kara liste red mesajlarını bul
grep "blocked|blacklist|blacklisted|RBL|DNSBL|Spamhaus|Barracuda" /var/log/mail.log | tail -30

# Hangi IP'ler tarafından kaç kez reddedildik
grep "status=bounced" /var/log/mail.log | grep -oP "relay=S+" | sort | uniq -c | sort -rn | head -10

# Son 1 saat içinde kaç mail reddedildi
grep "$(date '+%b %e %H')" /var/log/mail.log | grep -c "status=bounced"

Kara liste durumunu doğrudan kontrol etmek için:

# mxtoolbox ile kontrol (curl gerekli)
curl -s "https://api.mxtoolbox.com/api/v1/Lookup/blacklist/?argument=SUNUCU_IP_ADRESI" | python3 -m json.tool

# dig ile manuel Spamhaus kontrolü
dig +short 89.67.45.123.zen.spamhaus.org
# Eğer cevap gelirse IP kara listede demektir
# 127.0.0.2 = SBL, 127.0.0.4 = XBL, 127.0.0.10/11 = PBL

Gelen Mail Sorunları: Reject Analizi

Sadece giden mailleri değil, gelen mail redlerini de analiz etmeniz gerekebilir. Özellikle önemli bir mailin neden gelm ediğini araştırırken:

# Gelen bağlantılarda yaşanan redleri göster
grep "reject:" /var/log/mail.log | tail -50

# Hangi IP'lerden en çok red aldık
grep "reject:" /var/log/mail.log | grep -oP "from=[K[^]]+" | sort | uniq -c | sort -rn | head -20

# HELO/EHLO hatalarını listele
grep "reject: RCPT|reject: HELO|reject: EHLO" /var/log/mail.log | tail -30

Tipik bir gelen mail red satırı:

Dec 15 12:45:10 mailserver postfix/smtpd[15678]: NOQUEUE: reject: RCPT from unknown[185.220.101.1]: 550 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<spammer.xyz>

Bu tamamen normal bir durum, açık relay denemesi veya spam girişimi. Ama eğer meşru bir sunucudan red geliyorsa sorun yaşarsınız.

Pflogsumm ile Otomatik Log Özeti

Her gün logları manuel incelemek yerine pflogsumm aracını kullanabilirsiniz. Bu araç Postfix loglarından güzel bir özet çıkarır:

# Debian/Ubuntu kurulum
apt-get install pflogsumm

# RHEL/CentOS kurulum
yum install postfix-perl-scripts

# Bugünün özeti
pflogsumm /var/log/mail.log

# Dünün log dosyasını analiz et
pflogsumm /var/log/mail.log.1

# Sadece hataları ve uyarıları göster
pflogsumm -e /var/log/mail.log

# Özeti mail olarak gönder (cronjob için ideal)
pflogsumm /var/log/mail.log | mail -s "Günlük Mail Raporu" [email protected]

Bunun için şu cronjob’ı ekleyebilirsiniz:

# crontab -e ile ekleyin
0 7 * * * /usr/sbin/pflogsumm /var/log/mail.log | mail -s "Mail Sunucu Raporu - $(date '+%d.%m.%Y')" [email protected]

İleri Seviye: Log Parsing Scripti

Kendi yazdığım ve günlük kullandığım basit bir log analiz scripti:

#!/bin/bash
# postfix_analiz.sh - Postfix Log Analiz Scripti

LOG="/var/log/mail.log"
TARIH=$(date '+%b %e')

echo "===== POSTFIX LOG ANALİZİ - $(date '+%d.%m.%Y %H:%M') ====="
echo ""

echo "### GENEL İSTATİSTİKLER ###"
echo -n "Başarıyla gönderilen: "
grep "$TARIH" $LOG | grep -c "status=sent"

echo -n "Ertelenen (deferred): "
grep "$TARIH" $LOG | grep -c "status=deferred"

echo -n "Geri dönen (bounced): "
grep "$TARIH" $LOG | grep -c "status=bounced"

echo -n "Reddedilen (rejected): "
grep "$TARIH" $LOG | grep -c "reject:"

echo ""
echo "### EN ÇOK HATA VEREN HEDEF DOMAINLER ###"
grep "$TARIH" $LOG | grep "status=deferred|status=bounced" | 
  grep -oP "to=<[^>]+>" | grep -oP "@K[^>]+" | 
  sort | uniq -c | sort -rn | head -10

echo ""
echo "### SON 10 BOUNCE HATASI ###"
grep "$TARIH" $LOG | grep "status=bounced" | tail -10 | 
  awk '{for(i=1;i<=NF;i++) if($i ~ /dsn=|status=/) printf $i" "; print ""}'

echo ""
echo "### KUYRUK DURUMU ###"
mailq | tail -3

Bu scripti çalıştırmak için:

chmod +x postfix_analiz.sh
./postfix_analiz.sh

Logwatch Entegrasyonu

Eğer sisteminizde Logwatch kullanıyorsanız, Postfix raporlarını otomatik alabilirsiniz:

# Logwatch kurulumu
apt-get install logwatch  # Debian/Ubuntu
yum install logwatch      # RHEL/CentOS

# Sadece postfix raporunu göster
logwatch --service postfix --detail high --range today

# Dünün raporunu al
logwatch --service postfix --detail med --range yesterday --output mail --mailto [email protected]

Yaygın Hata Kodları Referansı

Log okurken sürekli karşılaşacağınız DSN kodları:

  • 2.0.0: Başarılı teslimat
  • 4.1.1: Geçici olarak bilinmeyen alıcı
  • 4.2.2: Posta kutusu dolu (geçici)
  • 4.4.1: Bağlantı kurulamadı (geçici)
  • 4.4.2: Bağlantı zaman aşımı
  • 4.7.0: Geçici güvenlik hatası
  • 5.1.1: Kullanıcı bulunamadı (kalıcı)
  • 5.1.2: Geçersiz domain
  • 5.2.2: Posta kutusu dolu (kalıcı)
  • 5.3.4: Mesaj boyutu aşıldı
  • 5.7.1: Mesaj reddedildi, yetki yok
  • 5.7.26: DMARC politikası ihlali

Postfix process isimleri de önemli, her biri farklı bir işlevi temsil eder:

  • postfix/smtpd: Gelen SMTP bağlantıları
  • postfix/smtp: Giden SMTP bağlantıları
  • postfix/qmgr: Kuyruk yönetimi
  • postfix/local: Yerel teslimat
  • postfix/bounce: Bounce işlemleri
  • postfix/cleanup: Mail temizleme ve header işleme

Performans Sorunlarını Log ile Tespit Etme

Bazen mail sunucusu yavaşlar ama neden olduğunu anlayamazsınız. Log’daki delay değerlerine bakmanız gerekir:

# En yavaş gönderilen mailleri bul (10 saniyeden uzun)
grep "status=sent" /var/log/mail.log | awk -F'delay=' '{print $2}' | awk '{print $1}' | 
  awk -F',' '$1 > 10' | sort -rn | head -20

# Ortalama gönderim süresini hesapla
grep "status=sent" /var/log/mail.log | grep "$(date '+%b %e')" | 
  grep -oP "delay=K[0-9.]+" | awk '{ sum += $1; count++ } END { print "Ortalama delay:", sum/count, "saniye" }'

# Hangi hedef sunucularda en çok gecikme var
grep "status=sent" /var/log/mail.log | grep "$(date '+%b %e')" | 
  grep -oP "relay=K[^,]+" | sort | uniq -c | sort -rn | head -10

delays= alanındaki dört değer sırasıyla şu gecikmeleri gösterir:

  • İlk değer: Kuyruk öncesi işlem süresi
  • İkinci değer: Kuyrukta bekleme süresi (bu yüksekse sunucu meşgul)
  • Üçüncü değer: Bağlantı kurma süresi (bu yüksekse network sorunu)
  • Dördüncü değer: Mesaj transfer süresi (bu yüksekse büyük mail veya yavaş hedef)

Sonuç

Postfix log analizi başta karmaşık gelebilir ama birkaç temel komutu öğrendikten sonra mail sorunlarını dakikalar içinde tespit edebilirsiniz. Özetlemek gerekirse pratik yaklaşımım şu şekilde:

Bir sorun geldiğinde önce tail -f /var/log/mail.log ile canlı izleme yapın. Sonra sorunlu mailin queue ID’sini bulup grep ile tüm sürecini takip edin. DSN koduna bakarak sorunun kalıcı mı (5xx) yoksa geçici mi (4xx) olduğunu anlayın. Geçici sorunlarda postqueue -f ile kuyruğu tekrar deneyebilirsiniz.

Günlük rutin için pflogsumm ile sabah raporunu otomasyona alın, kara liste kontrolünü haftalık yapın ve kuyruk boyutunu izleyin. Kuyrukta anormal bir büyüme varsa mutlaka araştırın, bu genellikle spam gönderimi veya ulaşılamayan bir relay sunucu anlamına gelir.

Mail sunucusu yönetimi öğrenme gerektiren bir alan ama doğru araçları ve komutları bildiğinizde log dosyaları size her şeyi anlatır. Logları düzenli okuma alışkanlığı edinin, sorun çıkmadan önce küçük uyarı işaretlerini yakalamayı öğrenirsiniz.

Benzer Konular

Bir yanıt yazın

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