Exim Log Analizi ve Hata Ayıklama Rehberi

yazar

Mail sunucusu yönetiminde en can sıkıcı anlar, bir şeylerin sessiz sedasız bozulduğu ve kullanıcıların “mailim gitmiyor” diye geldiği o anlardır. Exim bu konuda oldukça detaylı loglar üretir, ama bu logları okumak başlı başına bir sanat. Bu yazıda Exim log yapısını, sık karşılaşılan hata senaryolarını ve bunları nasıl hızlıca çözeceğini ele alacağız.

Exim Log Dosyaları Nerede ve Ne İçeriyor?

Exim varsayılan kurulumda loglarını /var/log/exim4/ dizininde tutar (Debian/Ubuntu sistemlerde). CentOS/RHEL tabanlı sistemlerde ise /var/log/exim/ altında bulunur. cPanel/WHM kullananlar için yol /var/log/exim_mainlog şeklindedir.

Temel log dosyaları şunlardır:

  • mainlog: Tüm mail trafiğinin kayıt altına alındığı ana log dosyası
  • rejectlog: Reddedilen mesajların loglandığı dosya
  • paniclog: Kritik sistem hatalarının tutulduğu dosya, bu dosyada bir şey görüyorsanız acil müdahale gerekebilir
  • processlog: Exim process yönetimine dair bilgiler

Logların nerede tutulduğunu konfigürasyondan doğrulamak için:

exim -bP log_file_path
exim -bP log_selector

Exim Log Formatını Anlamak

Exim mainlog’unda her satır belirli bir formata sahip. Bunu anlamadan log analizi yapmak neredeyse imkansız.

Tipik bir log satırı şöyle görünür:

2024-01-15 09:23:41 1rJkXp-0003mK-4f <= [email protected] H=mail.example.com [192.168.1.10] P=esmtps X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 S=4521 id=<[email protected]> T="Test maili" for [email protected]

Bu satırı parçalayalım:

  • 2024-01-15 09:23:41: Zaman damgası
  • 1rJkXp-0003mK-4f: Exim mesaj ID’si (bu ID ile mesajı takip edebilirsiniz)
  • <=: Mail alındı (gelen mesaj)
  • [email protected]: Gönderen adresi
  • H=: Bağlanan host adı
  • P=esmtps: Kullanılan protokol
  • X=: TLS bilgisi
  • S=: Mesaj boyutu (byte)

Ok işaretlerinin anlamları kritik öneme sahip:

  • <=: Mesaj alındı (received)
  • =>: Mesaj teslim edildi (delivered)
  • ->: Ek teslim (aynı mesajın kopyaları)
  • : Mesaj teslim edilemedi (failed)
  • ==: Mesaj queue’da bekliyor (deferred)

Temel Log Analiz Komutları

Günlük işlerde en çok kullanacağınız komutlara bakalım.

Belirli bir mail adresine ait tüm log kayıtlarını bulmak:

grep "[email protected]" /var/log/exim4/mainlog | tail -50

Belirli bir mesaj ID’sini takip etmek (en değerli araç):

exim -Mvh 1rJkXp-0003mK-4f    # Header bilgisi
exim -Mvb 1rJkXp-0003mK-4f    # Mesaj gövdesi
exim -Mvc 1rJkXp-0003mK-4f    # Tüm mesaj içeriği

Son bir saatteki mail trafiğini özet görmek:

exigrep "$(date -d '1 hour ago' '+%Y-%m-%d %H')" /var/log/exim4/mainlog | grep "=>" | wc -l

Hata mesajlarını filtrelemek:

grep "**" /var/log/exim4/mainlog | tail -100
grep "rejected" /var/log/exim4/rejectlog | tail -50

Exigrep: Exim’in Kendi Log Analiz Aracı

exigrep aracı Exim ile birlikte gelir ve tek bir mesajla ilgili tüm log satırlarını bir arada gösterir. Bu araç olmadan log analizi çok daha zor olurdu.

# Belirli bir adres için tüm log akışını getir
exigrep "[email protected]" /var/log/exim4/mainlog

# Belirli bir IP'den gelen mailleri filtrele
exigrep "192.168.1.10" /var/log/exim4/mainlog

# Gziplenmiş eski logları da dahil et
exigrep "[email protected]" /var/log/exim4/mainlog /var/log/exim4/mainlog.1 /var/log/exim4/mainlog.2.gz

exigrep ile ilgili önemli bir nokta: bu araç mesaj ID bazlı çalışır. Yani bir mesajla ilgili herhangi bir satırda arama yaptığınızda, o mesajın tüm log satırlarını (alındı, queue’a alındı, teslim edildi veya hata verdi) tek seferde görürsünüz.

Gerçek Dünya Senaryosu 1: “Mailim Gitmiyor”

Kullanıcı gönderdiği mailin gitmediğinden şikayet ediyor. İlk yapılacak şey mailin Exim’e ulaşıp ulaşmadığını kontrol etmek.

# Son 200 satırda kullanıcının adresini ara
grep "[email protected]" /var/log/exim4/mainlog | tail -200

# Queue'daki bekleyen mailleri listele
exim -bp | grep "[email protected]"

# Queue'daki tüm maillerin sayısını gör
exim -bpc

Diyelim ki mail queue’da takılmış. Mesaj ID’sini alıp detay inceleyelim:

# Queue'daki mesajın neden beklendiğini gör
exim -Mvl 1rJkXp-0003mK-4f

# Mesajı hemen göndermayı dene
exim -M 1rJkXp-0003mK-4f

# Tüm queue'yu göndermeye zorla
exim -qf

Queue’daki mesajın log çıktısı şöyle görünebilir:

2024-01-15 09:45:12 1rJkXp-0003mK-4f == [email protected] R=dnslookup T=remote_smtp defer (110): Connection timed out

Bu defer hatası genellikle DNS sorunu ya da karşı tarafın 25. portunu kapalı tutmasından kaynaklanır. Hızlı kontrol:

# Hedef domain'in MX kayıtlarını kontrol et
host -t MX hedeffirma.com
dig MX hedeffirma.com

# Hedef mail sunucusuna bağlantı testi
telnet mail.hedeffirma.com 25

Queue Yönetimi ve Sıkışmış Mesajlarla Başa Çıkma

Queue analizi için kullanışlı komutlar:

# Queue'daki mesajları yaşa göre sırala
exim -bp | exiqsumm

# Belirli bir alıcıya ait queue mesajlarını sil
exiqgrep -r "[email protected]" | xargs exim -Mrm

# Tüm queue'yu temizle (dikkatli kullanın!)
exim -bp | awk '/^ *[0-9]+[mhd]/{print $3}' | xargs exim -Mrm

# Queue'daki mesajları alıcı domain'e göre grupla
exim -bp | grep -oP "[w.-]+@[w.-]+" | sort | uniq -c | sort -rn | head -20

Spam nedeniyle queue şişmişse ve sistemi temizlemeniz gerekiyorsa:

# Belirli bir gönderenden gelen tüm mesajları queue'dan sil
exiqgrep -s "spam@kötüdomain.com" | xargs exim -Mrm

# Queue boyutunu izle
watch -n 5 'exim -bpc'

Gerçek Dünya Senaryosu 2: Spam Nedeniyle Kara Listeye Girmek

Sunucunuzun IP’si kara listeye girmiş ve gönderdiğiniz mailler reddediliyor. Log’da şöyle bir hata görürsünüz:

2024-01-15 10:15:33 1rJlAb-0004nL-2g ** [email protected] R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<[email protected]>: 550-5.7.1 [203.0.113.42] The IP you're using to send mail is not authorized

Bu durumda yapılacaklar:

# Son 24 saatte kim ne kadar mail göndermiş
grep "<=" /var/log/exim4/mainlog | grep "$(date '+%Y-%m-%d')" | 
  grep -oP "[w.+-]+@[w.-]+" | sort | uniq -c | sort -rn | head -20

# Outbound bağlantı sayısını kontrol et (anormal artış var mı)
grep "=>" /var/log/exim4/mainlog | grep "$(date '+%Y-%m-%d')" | wc -l

# Authentication olmadan gönderim yapan hesapları bul
grep "<=" /var/log/exim4/mainlog | grep -v "A=" | grep "$(date '+%Y-%m-%d')" | 
  grep -oP "[w.+-]+@[w.-]+" | sort | uniq -c | sort -rn

Kara liste kontrolü için:

# MXToolbox benzeri servisler için otomatik kontrol scripti
#!/bin/bash
SERVER_IP="203.0.113.42"
BLACKLISTS="zen.spamhaus.org bl.spamcop.net b.barracudacentral.org"

for BL in $BLACKLISTS; do
    RESULT=$(dig +short ${SERVER_IP}.${BL} 2>/dev/null)
    if [ -n "$RESULT" ]; then
        echo "KARA LİSTEDE: $BL - $RESULT"
    else
        echo "Temiz: $BL"
    fi
done

Exim ile TLS/SSL Sorunlarını Ayıklamak

TLS sorunları özellikle son yıllarda çok daha sık karşımıza çıkıyor. Log’da şöyle görünür:

2024-01-15 11:20:45 TLS error on connection from mail.example.com [192.168.1.5] (SSL_accept): error:1408F10B:SSL routines:ssl3_get_record:wrong version number

TLS bağlantılarını debug modda test etmek:

# Exim'in TLS yapılandırmasını kontrol et
exim -bP tls_certificate
exim -bP tls_privatekey
exim -bP tls_verify_certificates

# OpenSSL ile manuel TLS bağlantı testi
openssl s_client -starttls smtp -connect mail.sunucu.com:25 -servername mail.sunucu.com

# Sertifika geçerlilik kontrolü
openssl x509 -in /etc/exim4/exim.crt -text -noout | grep -A2 "Validity"

TLS ile ilgili detaylı log almak için /etc/exim4/exim4.conf.template dosyasında:

# exim4.conf içinde log_selector ayarı
log_selector = +tls_cipher +tls_certificate_verified +smtp_connection +smtp_incomplete_transaction

Bu ayarı yaptıktan sonra loglar çok daha detaylı hale gelir.

Gerçek Dünya Senaryosu 3: DKIM ve SPF Hataları

Mail teslim oranınız düşmüş, bazı mailler spam klasörüne düşüyor. Bu genellikle DKIM veya SPF sorunlarından kaynaklanır.

# DKIM imzalama sorunlarını bul
grep -i "dkim" /var/log/exim4/mainlog | grep -i "error|fail" | tail -50

# Gelen maillerin SPF kontrollerini gör
grep "spf" /var/log/exim4/mainlog | tail -50

DKIM durumunu test etmek için Exim’i test modunda çalıştırın:

# Test maili gönder ve tüm süreci izle
exim -v -f [email protected] [email protected] <<EOF
Subject: DKIM Test

Test mesaji
EOF

# DKIM anahtarının doğru yüklenip yüklenmediğini kontrol et
exim -bP dkim_domain
exim -bP dkim_selector
exim -bP dkim_private_key

DNS’te DKIM kaydını doğrula:

dig TXT selector._domainkey.domain.com +short

Exim’i Debug Modunda Çalıştırmak

Karmaşık durumlarda Exim’i debug modunda çalıştırmak altın değerinde bilgi sağlar:

# Tek bir mail için debug modu
exim -d -v -f [email protected] [email protected] < /dev/null

# Belirli bir debug kategorisi ile çalıştır
exim -d+all -v [email protected] < /tmp/test_mail.txt

# Routing kararını debug et (mail nereye gidecek?)
exim -bt [email protected]

# Exim ACL (Access Control List) testleri
exim -bh 192.168.1.100   # Belirli IP'den SMTP simülasyonu

exim -bt çıktısı şöyle görünür:

[email protected]
  router = localuser, transport = local_delivery
  /home/alici/Maildir

Bu çıktı mailin nereye teslim edileceğini açıkça gösterir.

Performans Analizi ve Darboğaz Tespiti

Mail sunucusunun yavaş çalıştığını düşünüyorsanız:

# Saatlik mail istatistikleri (gmail exim log analyzer scripti)
grep "=>" /var/log/exim4/mainlog | awk '{print $1" "$2}' | 
  cut -d: -f1 | sort | uniq -c

# Ortalama teslim süresini hesapla (alındı ile teslim arası fark)
# Bu karmaşık bir hesap, eximstats aracını kullan
eximstats /var/log/exim4/mainlog

# Exim process durumunu gör
exiwhat

# Eşzamanlı bağlantı sayısını izle
watch -n 2 'exiwhat | wc -l'

eximstats varsa çok güzel özetler üretir:

# Son bir günün istatistiklerini çıkar
eximstats -h1 /var/log/exim4/mainlog

# Sadece hata istatistiklerini göster
eximstats -nr /var/log/exim4/mainlog | head -50

Paniclog: Acil Durumların İzlenmesi

/var/log/exim4/paniclog dosyası boş olmalıdır. İçinde bir şey varsa mutlaka incelenmelidir.

# Paniclog'u kontrol et
cat /var/log/exim4/paniclog

# Cron ile düzenli paniclog kontrolü
# /etc/cron.d/exim-paniclog dosyası
*/5 * * * * root [ -s /var/log/exim4/paniclog ] && mail -s "EXIM PANIC: $(hostname)" [email protected] < /var/log/exim4/paniclog

Sık görülen paniclog hataları:

  • failed to expand: Konfigürasyon dosyasında değişken genişletme hatası
  • socket bind() failed: Port çakışması, başka bir process 25. portu kullanıyor
  • retry time not reached: Queue yönetim sorunu

Log Rotasyonu ve Uzun Vadeli Analiz

Loglar zamanla büyür ve yönetilemez hale gelir. Doğru log rotasyonu şart:

# /etc/logrotate.d/exim4 içeriğini kontrol et
cat /etc/logrotate.d/exim4

# Manuel log rotasyonu test et
logrotate -d /etc/logrotate.d/exim4

# Eski logları sıkıştır ve arşivle
find /var/log/exim4/ -name "*.log.*" -mtime +30 -exec gzip {} ;

Çoklu log dosyalarında arama yapmak için:

# Tüm sıkıştırılmış logları dahil ederek ara
zgrep "[email protected]" /var/log/exim4/mainlog* 2>/dev/null

# Belirli tarih aralığında arama
awk '/2024-01-10/,/2024-01-15/' /var/log/exim4/mainlog | grep "[email protected]"

Exim Rate Limiting ve Brute Force Tespiti

Sistemde anormal SMTP trafiği ve olası brute force saldırıları:

# En çok bağlantı yapan IP'leri bul
grep "SMTP connection" /var/log/exim4/mainlog | 
  grep -oP 'd+.d+.d+.d+' | sort | uniq -c | sort -rn | head -20

# Başarısız authentication denemelerini bul
grep "authenticator failed" /var/log/exim4/mainlog | 
  grep -oP 'd+.d+.d+.d+' | sort | uniq -c | sort -rn | head -20

# Bu IP'leri fail2ban ile otomatik engelle
# /etc/fail2ban/jail.local
[exim-esmtp]
enabled = true
filter = exim
logpath = /var/log/exim4/mainlog
maxretry = 5
bantime = 3600

Şüpheli IP’leri anında engelleme:

# IP adresini geçici olarak engelle
iptables -I INPUT -s 192.168.1.100 -p tcp --dport 25 -j DROP

# Exim konfigürasyonunda IP engelleme (kalıcı çözüm)
# acl_check_connect içine ekle:
# deny hosts = /etc/exim4/blocked_hosts
echo "192.168.1.100" >> /etc/exim4/blocked_hosts
exim -bhc 192.168.1.100   # Ayarı test et

Faydalı Tek Satırlık Komutlar

Günlük hayatta sık kullandığım pratik komutlar:

# Bugün kaç mail gönderildi
grep "$(date '+%Y-%m-%d')" /var/log/exim4/mainlog | grep "=>" | wc -l

# En çok mail gönderen 10 adres
grep "<=" /var/log/exim4/mainlog | grep "$(date '+%Y-%m-%d')" | 
  grep -oP "[w.+-]+@[w.-]+" | sort | uniq -c | sort -rn | head -10

# Teslim edilemeyen maillerin gönderenlerini listele
grep "**" /var/log/exim4/mainlog | grep "$(date '+%Y-%m-%d')" | 
  grep -oP "[w.+-]+@[w.-]+" | sort | uniq -c | sort -rn

# Exim servis durumu ve istatistik
exim -bP | head -20
systemctl status exim4

# Son hatayı bul ve mesaj ID'sini çıkar
grep "**" /var/log/exim4/mainlog | tail -1 | grep -oP '[a-zA-Z0-9]+-[a-zA-Z0-9]+-[a-zA-Z0-9]+'

Sonuç

Exim log analizi ilk bakışta karmaşık görünse de birkaç temel konsepti kavradıktan sonra oldukça sistematik bir hal alıyor. Mesaj ID’si üzerinden takip, exigrep kullanımı ve ok işaretlerinin anlamları bu konseptlerin başında geliyor.

Günlük operasyonlarda en değerli alışkanlık, paniclog’u düzenli kontrol etmek ve queue boyutunu izlemektir. Beklenmedik queue artışları genellikle bir sorunun habercisidir ve erken müdahale çok büyük baş ağrılarını önler.

Kara listeye girme, TLS sorunları ve DKIM hataları gibi durumlar artık çok daha sık karşılaştığımız sorunlar. Bu nedenle eximstats ile günlük özet rapor almayı ve kritik hataları mail ile bildiren basit bir monitoring scripti kurmayı şiddetle öneririm. Exim’in kendi araçlarını (exim -bt, exim -bh, exim -d) kullanmayı öğrenmek ise herhangi bir üçüncü parti aracın sağlayabileceğinin çok ötesinde debugging imkanı sunar.

Yorum yapın