Exim Log Okuma: Teşhis ve Sorun Giderme

Mail sunucusu sorunlarıyla uğraşmak, özellikle müşteri “mailim gitmiyor” diye arıyorsa, oldukça stresli olabiliyor. Exim, cPanel/WHM tabanlı sunucularda ve birçok Linux dağıtımında varsayılan MTA olarak kullanıldığından, log dosyalarını okumayı öğrenmek bir sysadmin için vazgeçilmez bir beceri. Bu yazıda Exim loglarını nasıl okuyacağınızı, ne arayacağınızı ve karşılaştığınız sorunları nasıl çözeceğinizi adım adım ele alacağız.

Exim Log Dosyaları Nerede?

İlk adım, log dosyalarının nerede olduğunu bilmek. Sisteme ve kuruluma göre farklılık gösterebilir:

• /var/log/exim/mainlog: Ana işlem logu, en çok kullandığınız yer
• /var/log/exim/rejectlog: Reddedilen mesajlar
• /var/log/exim/paniclog: Kritik hatalar, Exim’in çöktüğü durumlar
• /var/log/exim4/mainlog: Debian/Ubuntu sistemlerde
• /var/log/exim_mainlog: cPanel sunucularda

cPanel sunucusundaysanız şunu çalıştırın:

ls -la /var/log/exim_mainlog*

Eğer log rotation aktifse eski loglar .1, .2 gibi uzantılarla veya gzip sıkıştırılmış halde bulunur. Sıkıştırılmış loglarda arama yapmak için zgrep kullanabilirsiniz.

Log Satırı Anatomisi

Bir Exim log satırını ilk gördüğünüzde karmaşık gelebilir. Ama aslında oldukça düzenli bir yapısı var. Şöyle bir satıra bakalım:

2024-01-15 09:23:41 1rJkXm-0003kl-Qp <= [email protected] H=mail.example.com [192.168.1.10] P=esmtps X=TLS1.3:ECDHE-RSA-AES256-GCM-SHA384:256 S=2847 id=<[email protected]> T="Test maili" for [email protected]

Bu satırı parçalara ayıralım:

• 2024-01-15 09:23:41: Zaman damgası
• 1rJkXm-0003kl-Qp: Mesaj ID’si, her işlemi takip etmek için bu ID’yi kullanırsınız
• <=: Mail teslim alındı (inbound)
• [email protected]: Gönderici
• H=mail.example.com: Bağlanan sunucunun hostname’i
• [192.168.1.10]: Bağlanan sunucunun IP adresi
• P=esmtps: Kullanılan protokol
• S=2847: Mesaj boyutu (byte)
• T=”Test maili”: Konu satırı

Temel operatörler şunlar:

• <=: Mail kabul edildi (alındı)
• =>: Mail başarıyla teslim edildi
• ->: Aynı mesajın ek bir kopyası teslim edildi
• : Kalıcı hata, mail teslim edilemedi
• ==: Geçici hata, mail kuyruğa alındı, tekrar denenecek

Mesaj ID ile Takip Etmek

Bir mailin hayatını takip etmenin en pratik yolu mesaj ID’sini kullanmak. Diyelim ki bir kullanıcı “falanca maili gönderdim ama gitmiyor” dedi. Önce o maili logda bulmanız lazım.

grep "1rJkXm-0003kl-Qp" /var/log/exim_mainlog

Bu komut o mesaja ait tüm satırları listeler. Mesajın alınmasından teslim edilmesine kadar tüm adımları görebilirsiniz. Eğer mesaj ID’sini bilmiyorsanız gönderici veya alıcı adresine göre arama yapabilirsiniz:

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

cPanel’de bunu kolaylaştıran bir araç var:

exigrep "[email protected]" /var/log/exim_mainlog

exigrep komutu, aradığınız ifadeyle ilgili tüm mesajları, o mesaja ait tüm log satırlarıyla birlikte getirir. Tek bir grep satırı yerine komple mesaj hikayesini görürsünüz. Bu çok işe yarıyor.

Gerçek Dünya Senaryosu 1: Mail Gitmiyor

Müşteri arıyor, “Sabahtan beri mail gönderemiyorum” diyor. Klasik senaryo. Önce son bir saatteki hataları görelim:

grep "$(date -d '1 hour ago' '+%Y-%m-%d %H')" /var/log/exim_mainlog | grep "**"

Bu komut son bir saatteki kalıcı hataları filtreler. Eğer çok fazla sonuç geliyorsa belirli bir domain’e odaklanabilirsiniz:

grep "[email protected]" /var/log/exim_mainlog | grep -E "(**|==)"

Şöyle bir satır görürseniz:

2024-01-15 10:45:22 1rJkXm-0003kl-Qp ** [email protected] R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<[email protected]>: 550 5.1.1 The email account that you tried to reach does not exist

Burada ** kalıcı hata ve hata mesajı “email hesabı mevcut değil” diyor. Yani sorun karşı tarafta, mail adresi yanlış veya silinmiş. Bu durumda yapabileceğiniz bir şey yok, kullanıcıya doğru adresi kontrol etmesini söylersiniz.

Gerçek Dünya Senaryosu 2: Kuyruk Birikmiyor mu?

Bazen mailler gitmez ama hata da vermez, kuyruğa takılır. Kuyruk durumunu görmek için:

exim -bp

Bu komut mevcut mail kuyruğunu listeler. Eğer kuyruğa takılmış yüzlerce mail görüyorsanız bir sorun var demektir. Takılmış bir mesajın neden kuyruğa girdiğini anlamak için:

exim -Mvl MESAJ_ID

Daha ayrıntılı log için:

exim -Mvc MESAJ_ID

Bu komut mesajın içeriğini, başlıklarını ve neden beklemede olduğunu gösterir. Genellikle geçici DNS hatası, karşı sunucunun geçici olarak erişilememesi veya greylisting nedeniyle beklemede olduğunu görürsünüz. == operatörünü içeren satirlar şunu söyler: “Şimdi göndermedim, tekrar deneyeceğim.”

Kimlik Doğrulama Hatalarını Bulmak

Spam göndericiler veya yanlış yapılandırılmış mail istemcileri authentication hatası üretir. Bu hataları bulmak için:

grep "authenticator" /var/log/exim_mainlog | grep -i "fail|reject|denied" | tail -20

Şöyle bir çıktı görürsünüz:

2024-01-15 11:02:33 1rJm2k-0007ab-Lx authenticator failed for ([192.168.1.55] helo=Windows-PC): 535 Incorrect authentication data ([email protected])

Bu, [email protected] için yanlış şifre girildiğini gösterir. Eğer aynı IP’den çok fazla böyle hata görüyorsanız brute-force saldırısı olabilir. IP’ye göre gruplamak için:

grep "authenticator failed" /var/log/exim_mainlog | grep -oP '[([0-9]{1,3}.){3}[0-9]{1,3}]' | sort | uniq -c | sort -rn | head -20

Bu komut authentication hatalarını IP adresine göre gruplar ve en çok hata yapan IP’leri sıralar. 50’den fazla deneme yapan bir IP varsa o IP’yi firewall’da bloklayın.

Spam ve Relay Sorunları

“Sunucunuz spam gönderiyor” şikayeti her sysadmin’in korkulu rüyasıdır. Bunu tespit etmek için önce hangi hesaptan gönderim yapıldığını bulmanız lazım:

grep "<=" /var/log/exim_mainlog | grep -v "localhost|127.0.0.1" | awk '{print $6}' | sort | uniq -c | sort -rn | head -20

Bu komut son maillerin gönderenlerini listeler ve en çok gönderen adresleri sıralar. Normal bir durumda belirli bir adresin yüzlerce mail göndermesi şüphelidir.

Belirli bir IP’den gelen tüm gönderileri görmek için:

grep "H=.*[192.168.1.100]" /var/log/exim_mainlog | grep "<=" | wc -l

Eğer bir IP’den kısa sürede binlerce mail geldiyse o IP compromised olmuş olabilir. Hemen bloklayın ve ilgili hesabın şifresini değiştirin.

Open relay kontrolü yapmak için dışarıdan test edebilirsiniz ama önce log’da şüpheli relay girişimlerini arayın:

grep "relay not permitted|Relay not permitted" /var/log/exim_mainlog | tail -30

Eğer bu hataları görüyorsanız sisteminiz relay denemelerini engelliyor demektir, iyi. Ama bu hataları hiç görmüyorsanız ve dışarıdan relay testi yapıyorsanız dikkatli olun.

Bounce ve NDR Analizi

Geri dönen mailler (bounce), posta yönetiminin önemli bir parçası. Bounce mesajları genellikle /var/mail/ altında veya özel bir bounce adreste toplanır. Log’da bounce durumlarını görmek için:

grep "bounce" /var/log/exim_mainlog | tail -30

Kalıcı bounce (hard bounce) ile geçici bounce (soft bounce) arasındaki farkı anlamak önemli:

# Hard bounce - 5xx kodları
grep "**" /var/log/exim_mainlog | grep "5[0-9][0-9]" | tail -20

# Soft bounce - 4xx kodları  
grep "==" /var/log/exim_mainlog | grep "4[0-9][0-9]" | tail -20

5xx hataları kalıcı, 4xx hatalar geçici. 422, 450, 452 gibi kodlar geçici sorunlara işaret eder ve Exim bunları otomatik olarak tekrar deneyecektir. 550, 551, 553 ise kalıcı hatalardır.

TLS ve Güvenlik Sorunları

Günümüzde TLS olmadan mail göndermek neredeyse imkansız hale geldi. TLS el sıkışma hatalarını bulmak için:

grep -i "TLS error|SSL error|certificate|handshake" /var/log/exim_mainlog | tail -30

Şöyle bir hata görürseniz:

2024-01-15 14:22:11 TLS error on connection from mail.suspect.com [203.0.113.45] (SSL_accept): error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown

Bu, karşı tarafın sertifikanızı tanımadığı anlamına gelir. Sertifikanızın güncel olup olmadığını kontrol edin:

openssl s_client -connect localhost:465 -quiet 2>&1 | head -20

Sertifika süresi dolmuşsa hemen yenilemeniz gerekiyor. Let’s Encrypt kullanıyorsanız:

certbot renew --dry-run

DKIM, SPF ve DMARC Logları

Mail deliverability sorunlarının büyük kısmı DKIM/SPF/DMARC kaynaklıdır. Exim bu konuda log tutabilir ama yapılandırma gerekebilir. Mevcut durumu görmek için:

grep -i "dkim|spf|dmarc" /var/log/exim_mainlog | tail -30

DKIM imza hatalarını görmek için:

grep -i "dkim.*fail|dkim.*invalid|dkim.*error" /var/log/exim_mainlog

Eğer DKIM ile ilgili hiç log göremiyorsanız, Exim’in DKIM logging’i aktif olmayabilir. cPanel sistemlerinde DKIM durumunu kontrol etmek için:

exim -bV 2>&1 | grep -i dkim

Gerçek Dünya Senaryosu 3: Belirli Bir Domain’e Mail Gitmiyor

Kullanıcı “gmail’e mail gönderiyorum ama gitmiyor” diyor. Bu çok yaygın bir şikayet. Gmail, Yahoo gibi büyük providerlar çok katı filtrelere sahip.

grep "gmail.com" /var/log/exim_mainlog | grep -E "(**|==)" | tail -20

Şöyle bir hata görürsünüz muhtemelen:

2024-01-15 15:30:45 1rJpQr-0002mn-Xv ** [email protected] R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<[email protected]> SIZE=1234: 550-5.7.26 This mail is unauthenticated, which poses a

Bu durumda SPF, DKIM veya DMARC ayarlarınız eksik ya da yanlış demektir. DNS kayıtlarınızı kontrol edin:

dig TXT yourdomain.com | grep -i "v=spf"
dig TXT _dmarc.yourdomain.com
dig TXT default._domainkey.yourdomain.com

Üç kayıt da düzgün görünüyorsa Google Postmaster Tools’a bakın, IP reputasyonunuz düşmüş olabilir.

Log’dan İstatistik Çıkarmak

Günlük/saatlik mail trafiğini görmek, anomali tespiti açısından önemli. Saate göre mail sayısını görmek için:

grep "<=" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | awk '{print $2}' | cut -d: -f1 | sort | uniq -c

Bu komut bugünkü günlüğü saate göre gruplar ve her saatte kaç mail alındığını gösterir. Eğer gece 3’te anormal bir spike görüyorsanız araştırmanız gerekiyor.

Gün içindeki hata oranını görmek için:

echo "Toplam mail:"; grep "<=" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | wc -l
echo "Kalici hatalar:"; grep "**" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | wc -l
echo "Gecici hatalar:"; grep "==" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | wc -l

Paniclog’u Asla Atlamayın

paniclog dosyası genellikle görmezden gelinir ama aslında kritik bilgiler içerir. Exim bir şeyleri çok yanlış bulduğunda buraya yazar:

cat /var/log/exim/paniclog
# veya cPanel için
cat /var/log/exim_paniclog

Eğer bu dosya boş değilse ciddi bir sorun var demektir. Tipik paniclog girişleri şunlardır:

• Veritabanı bağlantı hataları
• Konfigürasyon dosyasındaki sözdizimi hataları
• Disk alanı dolması
• Process başlatma hataları

Exim konfigürasyonunu test etmek için:

exim -bV
exim -C /etc/exim.conf -bV

Rejectlog Analizi

rejectlog dosyası, Exim’in reddettiği bağlantıları kaydeder. Spam girişimlerini, geçersiz domain bağlantılarını ve politika ihlallerini burada görebilirsiniz:

tail -100 /var/log/exim/rejectlog

Kara listeye (blacklist/RBL) alınmış IP’lerden gelen bağlantıları görmek için:

grep -i "rbl|blacklist|dnsbl|spamhaus|barracuda" /var/log/exim/rejectlog | tail -20

Eğer kendi sunucu IP’niz blacklist’e alınmışsa, önce spam kaynağını temizleyin, sonra ilgili blacklist sağlayıcısından delisting isteyin.

Pratik Araçlar ve Kısayollar

Günlük kullanım için işinize yarayacak bazı komutlar:

# Son 100 maili izle (canlı)
tail -f /var/log/exim_mainlog

# Sadece hataları canlı izle
tail -f /var/log/exim_mainlog | grep -E "(**|panic|error)"

# Bugünkü teslim başarı oranı
SUCCESS=$(grep "=>" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | wc -l)
FAIL=$(grep "**" /var/log/exim_mainlog | grep "$(date '+%Y-%m-%d')" | wc -l)
echo "Basarili: $SUCCESS, Basarisiz: $FAIL"

# Kuyrukta bekleyen mail sayisi
exim -bpc

# Tum kuyrugu temizle (dikkatli kullanin!)
# exim -bp | awk '/^ *[0-9]+[mhd]/{print "exim -Mrm " $3}' | bash

Bu son komutu çalıştırmadan önce defalarca düşünün. Tüm kuyruğu silmek geri alınamaz.

Log Rotasyonu ve Arşivleme

Uzun süreli sorun takibi için eski loglara da bakmanız gerekebilir. Log rotation genellikle daily ayarlıdır ve eski loglar sıkıştırılır:

# Sıkıştırılmış logda arama
zgrep "[email protected]" /var/log/exim_mainlog.1.gz

# Tum log dosyalarinda arama (hem aktif hem arsiv)
for f in /var/log/exim_mainlog*; do
    echo "--- $f ---"
    if [[ $f == *.gz ]]; then
        zgrep "aradiginiz_ifade" $f
    else
        grep "aradiginiz_ifade" $f
    fi
done

Sonuç

Exim loglarını okumak başta zor görünse de biraz pratikle çok hızlı hale geliyor. En önemli nokta, mesaj ID’si ile takip etmeyi alışkanlık haline getirmek. Bir sorun geldiğinde önce ilgili mesaj ID’sini bulun, sonra o ID ile tüm log’u tarayın. Böylece mailin tam olarak nerede takıldığını görebilirsiniz.

Özetleyecek olursak dikkat etmeniz gereken başlıca noktalar şunlar:

• işareti**: Kalıcı hata, o mail asla gitmeyecek, kullanıcıyı bilgilendirin
• == işareti: Geçici hata, Exim tekrar deneyecek, birkaç saat bekleyin
• paniclog: Boş olmalı, doluysa acil müdahale gerekli
• Authentication hataları: Brute-force veya yanlış ayarlanmış istemci
• TLS hataları: Sertifika sorunu olabilir, kontrol edin
• Kuyruğun birikmesi: DNS sorunu, karşı sunucu kapalı veya blacklist’e alınmış olabilirsiniz

Mail sunucusu yönetimi hiçbir zaman tamamen sorunsuz olmaz. Ama logları düzgün okuyabilirseniz sorunları çok daha hızlı çözersiniz ve “neden gitmiyor” sorusuna somut bir cevap verebilirsiniz. Bu da hem sizin hem de kullanıcının hayatını kolaylaştırır.