"Mektup gitmiyor" şikâyeti geldiğinde bakılacak tek doğru yer mail loglarıdır. Panel ekranları, kampanya araçlarının istatistikleri ve kullanıcı beyanları hepsi ikinci eldir; log satırı ise sunucunun karşı tarafla yaptığı konuşmanın birebir kaydıdır. Mail loglarını okumayı öğrenmek, tahmin ederek zaman kaybetmek ile beş dakikada teşhis koymak arasındaki farktır.
Bu yazıda logların hangi dosyada tutulduğunu, bir Postfix log satırının alan alan neyi anlattığını, queue ID kullanarak tek bir mektubun tüm yaşam döngüsünü nasıl izleyeceğinizi, sık karşılaşılan hata kalıplarının ne anlama geldiğini ve günlük özet çıkarmak için kullanabileceğiniz pratik komutları anlatacağım. Örnekler Postfix üzerinden, ancak Dovecot ve Rspamd satırlarına da değineceğim çünkü teslimat sorunlarının bir kısmı orada başlar.
Loglar Nerede, Nasıl Okunur#
Dağıtıma göre yol değişir. Debian ve Ubuntu ailesinde geleneksel yol /var/log/mail.log, hataların ayrıca toplandığı yer /var/log/mail.err'dir. RHEL, Rocky ve AlmaLinux ailesinde ise dosya /var/log/maillog adını taşır. Modern sistemlerde rsyslog kaldırılmış olabilir; bu durumda loglar yalnızca systemd journal'ında bulunur.
| Sistem | Dosya | Journal alternatifi |
|---|---|---|
| Debian / Ubuntu | /var/log/mail.log | journalctl -u postfix |
| RHEL / Rocky / Alma | /var/log/maillog | journalctl -u postfix |
| Dovecot ayrı log | /var/log/dovecot.log | journalctl -u dovecot |
| Rspamd | /var/log/rspamd/rspamd.log | journalctl -u rspamd |
Dosya yoksa panik yapmadan journal'a bakın:
# Postfix'in tüm log satırları, canlı takip
sudo journalctl -u postfix -f
# Son bir saatin mail ile ilgili tüm satırları (syslog facility mail)
sudo journalctl --facility=mail --since "1 hour ago"
# Klasik dosya varsa canlı takip
sudo tail -f /var/log/mail.log
Uzun süreli analiz yapacaksanız log döndürmenin (logrotate) sizi kesmediğinden emin olun; /etc/logrotate.d/rsyslog dosyası genellikle mail loglarını haftalık döndürür ve dört hafta saklar. Bir sorunu geriye dönük araştırıyorsanız sıkıştırılmış eski dosyalara da bakın:
# Sıkıştırılmış eski loglarda da ara
sudo zgrep "[email protected]" /var/log/mail.log.*.gz
Bir Postfix Log Satırının Anatomisi#
Postfix her mektup için birden çok satır yazar ve bu satırları birbirine queue ID bağlar. Tipik bir başarılı teslim şu üç satırdan oluşur:
Aug 25 09:12:40 mail postfix/smtpd[2481]: connect from mail.ornek.com[203.0.113.9]
Aug 25 09:12:41 mail postfix/smtpd[2481]: 3F2A19E4C2: client=mail.ornek.com[203.0.113.9]
Aug 25 09:12:41 mail postfix/cleanup[2492]: 3F2A19E4C2: message-id=<[email protected]>
Aug 25 09:12:41 mail postfix/qmgr[1180]: 3F2A19E4C2: from=<[email protected]>, size=4821, nrcpt=1 (queue active)
Aug 25 09:12:42 mail postfix/smtp[2495]: 3F2A19E4C2: to=<[email protected]>, relay=mx.firmaniz.com[185.12.34.56]:25, delay=1.4, delays=0.3/0/0.6/0.5, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 8B4C21)
Aug 25 09:12:42 mail postfix/qmgr[1180]: 3F2A19E4C2: removed
Satırların ortak yapısı şudur: tarih, sunucu adı, postfix/<altsistem>[pid], queue ID ve ardından anahtar-değer çiftleri. Altsistem adı hangi bileşenin konuştuğunu söyler:
| Altsistem | Görevi |
|---|---|
smtpd | Dışarıdan gelen bağlantıları kabul eder |
smtp | Dışarıya bağlanıp teslim eder |
cleanup | Başlıkları düzenler, kuyruğa yazar |
qmgr | Kuyruk yöneticisi, teslim sırasını belirler |
local | Yerel kutuya teslim eder |
pickup | Yerel sendmail ile bırakılanları alır |
bounce | Geri dönüş bildirimi üretir |
En bilgi yoğun satır smtp altsisteminin yazdığı teslim satırıdır. Alanları tek tek okuyalım:
| Alan | Anlamı |
|---|---|
to= | Zarf alıcısı |
relay= | Bağlanılan sunucu, IP ve port |
delay= | Toplam süre (saniye) |
delays= | Dört parça: alım/kuyruk/bağlantı/teslim |
dsn= | Genişletilmiş durum kodu |
status= | sent, deferred, bounced, expired |
| Parantez içi | Karşı sunucunun birebir cevabı |
delays=0.3/0/0.6/0.5 biçimindeki dört sayı teşhiste çok işe yarar: ilki mektubun alınması, ikincisi kuyrukta bekleme, üçüncüsü karşı sunucuya bağlanma, dördüncüsü teslim süresidir. Üçüncü sayı büyükse sorun ağ ya da DNS tarafındadır; ikincisi büyükse kuyruk yoğunluğu vardır.
status= alanı dört değer alır ve her biri farklı bir eylem gerektirir: sent teslim edildi, deferred geçici hata (kuyrukta bekliyor), bounced kalıcı hata (gönderene döndü), expired kuyruk yaşam süresi doldu. deferred ve bounced ayrımının pratik karşılığını bounce yönetimi: hard ve soft bounce farkı yazısında ele aldım.
Queue ID ile Bir Mektubu Baştan Sona İzlemek#
Bir şikâyeti araştırırken izlenecek yol her zaman aynıdır: önce alıcı veya gönderici adresinden queue ID'yi bulun, sonra o ID ile tüm satırları toplayın.
# 1) Adresten queue ID bul
sudo grep "[email protected]" /var/log/mail.log | head
# 2) Bulduğun ID ile mektubun tüm yaşam döngüsünü çıkar
sudo grep "3F2A19E4C2" /var/log/mail.log
# 3) Message-ID biliniyorsa doğrudan ondan başla
sudo grep "[email protected]" /var/log/mail.log
Bir mektup relay edilerek ikinci bir kuyruk kimliği alabilir; örneğin içerik filtresinden geçen mektup yeni bir ID ile devam eder. Bu durumda ilk ID'nin satırlarında ikinci ID'yi görürsünüz ve zinciri oradan takip edersiniz.
Journal kullanıyorsanız aynı işi şöyle yaparsınız:
sudo journalctl -u postfix --since today | grep 3F2A19E4C2
Çok sayıda mektubu birlikte incelemek için pflogsumm aracı işinizi kolaylaştırır; Debian/Ubuntu'da postfix-pflogsumm, RHEL ailesinde postfix-pflogsumm paketiyle gelir:
# Günlük özet: teslim, red, bounce, en çok gönderen/alan adresler
sudo pflogsumm -d today /var/log/mail.log | head -40
Sık Karşılaşılan Log Kalıpları ve Anlamları#
Aşağıdaki kalıpları tanımak, teşhis süresini dakikalardan saniyelere indirir.
| Log içindeki metin | Anlamı | Yapılacak |
|---|---|---|
status=sent (250 ... Ok) | Teslim edildi | — |
status=deferred (... 451 4.7.1 ...) | Geçici ret, hız sınırı veya greylisting | Bekle, gerekirse hacmi kıs |
status=bounced (... 550 5.1.1 ...) | Alıcı yok, kalıcı | Adresi listeden çıkar |
status=bounced (... 550 5.7.1 ...) | Politika reddi | Kimlik doğrulama ve itibarı denetle |
Host or domain name not found | Alıcı MX çözümlenmiyor | DNS ve MX kaydını kontrol et |
Connection timed out | Karşı sunucuya ulaşılamıyor | Ağ, güvenlik duvarı, port 25 çıkışı |
Connection refused | Port kapalı ya da servis yok | Hedef sunucu durumu |
SASL LOGIN authentication failed | Yanlış kimlik bilgisi | Şifre veya kaba kuvvet saldırısı |
Relay access denied | Yetkisiz relay denemesi | Normal, dışarıdan spam denemesi |
warning: hostname ... does not resolve | rDNS tutarsız | PTR kaydını düzelt |
lost connection after ... from unknown | Bağlantı yarıda kesildi | Genellikle tarayıcı botları |
SASL LOGIN authentication failed satırlarının sayısı ansızın artmışsa kaba kuvvet saldırısı altındasınız demektir. Kaynak IP'leri hızlıca çıkarın:
# Başarısız kimlik doğrulama denemelerinin kaynak IP dağılımı
sudo grep "SASL LOGIN authentication failed" /var/log/mail.log \
| grep -oE 'unknown\[[0-9.]+\]' | grep -oE '[0-9.]+' \
| sort | uniq -c | sort -rn | head
Aynı IP'den yüzlerce deneme görüyorsanız Fail2ban kuralınızın çalışıp çalışmadığını kontrol edin. Buna karşılık, bir kullanıcı adının başarılı olduğu ve ardından kuyruğun şiştiği durum çok daha kötüdür: hesap ele geçirilmiştir. Kuyruk tarafındaki müdahaleyi Postfix kuyruk yönetimi yazısında anlattım.
Kendi gönderdiğiniz mektuplarda 4.7.1 kodlarının artması genellikle itibar uyarısıdır ve loglar bunu erken gösterir; sinyali okumayı gönderici itibarı nedir yazısında ele aldım.
Günlük Analiz Komutları#
Aşağıdaki komut seti, sabahları beş dakikada sunucunun mail sağlığını gözden geçirmenizi sağlar. Bunları bir script'e koyup cron ile günlük özet olarak kendinize gönderebilirsiniz.
LOG=/var/log/mail.log
# 1) Durum dağılımı
for s in sent deferred bounced expired; do
printf "%-9s %s\n" "$s" "$(grep -c "status=$s" "$LOG")"
done
# 2) En çok gönderen yerel adresler — anormallik burada görünür
grep -oE 'from=<[^>]+>' "$LOG" | sed 's/from=<//; s/>//' \
| grep -v '^$' | sort | uniq -c | sort -rn | head
# 3) Reddedilme gerekçelerinin dağılımı
grep -E "status=(bounced|deferred)" "$LOG" \
| sed 's/.*said: //; s/.*(\(.*\))$/\1/' | cut -c1-70 \
| sort | uniq -c | sort -rn | head
# 4) Hedef alan adına göre teslim başarısı
grep "status=sent" "$LOG" | grep -oE 'to=<[^>]+>' \
| sed 's/.*@//; s/>//' | sort | uniq -c | sort -rn | head
# 5) Ortalama teslim süresi (delay alanı)
grep "status=sent" "$LOG" | grep -oE 'delay=[0-9.]+' | cut -d= -f2 \
| awk '{t+=$1; n++} END {if(n) printf "ortalama %.2f sn (%d mektup)\n", t/n, n}'
İkinci komut özellikle değerlidir: yerel gönderici dağılımında hiç tanımadığınız bir adres ya da beklenmedik biçimde baskın bir hesap görüyorsanız, sorunu daha kimse şikâyet etmeden yakalamış olursunuz.
Dovecot tarafında ise kullanıcıların posta kutusuna erişimini izlersiniz. IMAP ve POP3 oturumları ayrı satırlar üretir ve hangi protokolün kullanıldığını doğrudan gösterir:
# Başarılı IMAP girişleri ve kaynak IP'ler
sudo grep "imap-login: Login" /var/log/dovecot.log | tail
# Başarısız girişler
sudo grep "auth failed" /var/log/dovecot.log | tail
Protokoller arasındaki farkın kullanıcı davranışına etkisini IMAP ve POP3 farkı yazısında karşılaştırdım.
Loglardan Teşhis Koyarken Yapılan Hatalar#
Yalnızca hata satırına bakmak. Bir status=bounced satırı size sonucu söyler ama sebebi genellikle önceki satırlardadır: smtpd bağlantı satırı, cleanup başlık satırı, varsa içerik filtresi satırı. Her zaman queue ID ile tüm zinciri çıkarın.
Zarf adresini From: başlığı sanmak. Logdaki from= alanı zarf göndericisidir ve kullanıcının gördüğü From: başlığından farklı olabilir. Kullanıcı "ben bu adresten göndermedim" derken haklı olabilir; loga bakıp doğru alanı ayırt etmek gerekir.
Saat dilimini gözden kaçırmak. Sunucu UTC, kullanıcı yerel saat kullanıyorsa satırları yanlış aralıkta ararsınız. timedatectl ile sunucu saatini doğrulayın ve aramalarınızı ona göre yapın.
Logrotate'i unutmak. "Dün akşamki mektubu bulamıyorum" şikâyetinin yarısı, logun döndürülmüş olmasıdır. zgrep ile sıkıştırılmış dosyalarda da arayın.
Teslim edildi satırını gelen kutusuna düştü sanmak. status=sent yalnızca karşı sunucunun mektubu kabul ettiğini söyler; mektubun spam klasörüne mi gelen kutusuna mı düştüğünü log bilmez. Yerleşim sorunlarında log size "kabul edildi" der ve teşhis başka yerde aranmalıdır.
Rspamd puanını atlamak. Kendi sunucunuz mektubu reddettiyse sebep genellikle içerik filtresidir; Rspamd loglarındaki action ve score alanları hangi kuralın tetiklendiğini gösterir.
Sıkça Sorulan Sorular#
Mail logları hangi dosyada tutulur#
Debian ve Ubuntu'da /var/log/mail.log, RHEL, Rocky ve AlmaLinux ailesinde /var/log/maillog dosyasıdır. Rsyslog kurulu değilse dosya hiç oluşmaz ve loglar yalnızca systemd journal'ında bulunur; bu durumda journalctl -u postfix ya da journalctl --facility=mail komutunu kullanın. Dovecot ve Rspamd genellikle kendi ayrı dosyalarına yazar.
Bir mektubun neden gitmediğini loglardan nasıl bulurum#
Önce alıcı ya da gönderici adresiyle grep yapıp queue ID'yi bulun, sonra o ID ile tüm satırları çıkarın. Teslim satırındaki status= alanı sonucu, parantez içindeki metin ise karşı sunucunun birebir cevabını verir. deferred ise mektup hâlâ kuyruktadır ve tekrar denenecektir; bounced ise kalıcı olarak reddedilmiştir ve gerekçe parantez içinde yazar.
status=sent görünüyor ama mektup gelen kutusunda yok#
status=sent, karşı sunucunun mektubu kabul ettiği anlamına gelir; nereye koyduğunu söylemez. Mektup büyük olasılıkla spam klasörüne düşmüştür ya da alıcı tarafta bir kural onu başka bir klasöre taşımıştır. Bu bir log sorunu değil, teslimat yerleşimi sorunudur; SPF, DKIM, DMARC uyumunu ve gönderici itibarınızı gözden geçirmeniz gerekir.
Logları ne kadar süre saklamalıyım#
Pratik bir alt sınır olarak en az 30 gün önerilir; teslimat şikâyetleri genellikle olaydan günler sonra gelir ve daha kısa saklama süresinde geriye dönük inceleme imkânsız hale gelir. Yasal veya sözleşmesel yükümlülükleriniz varsa süre daha uzun olabilir. logrotate yapılandırmasında saklama sayısını artırırken disk kullanımını da izleyin.
journalctl ile mail loglarını nasıl filtrelerim#
journalctl -u postfix yalnızca Postfix birimini gösterir; tüm mail trafiği için journalctl --facility=mail daha kapsamlıdır. Zaman aralığı için --since "2 hours ago" ya da --since today kullanın, canlı takip için -f ekleyin. Belirli bir queue ID'yi aramak isterseniz çıktıyı grep ile süzmeniz yeterlidir.
Log dosyası çok büyüdü, ne yapmalıyım#
Önce dosyayı elle silmeyin; çalışan servis dosya tanıtıcısını açık tutar ve disk alanı geri gelmez. logrotate yapılandırmasını gözden geçirip döndürme sıklığını artırın ve sıkıştırmayı etkinleştirin. Ani büyüme genellikle bir sorunun belirtisidir: kaba kuvvet saldırısı, ele geçirilmiş bir hesap ya da döngüye girmiş bir uygulama. Boyutu düşürmeden önce sebebi bulun.
Kapanış#
Mail logları, e-posta altyapısında tahmini bilgiye dönüştüren tek kaynaktır. Aklınızda dört alışkanlık kalsın: her incelemeye queue ID ile tüm zinciri çıkararak başlayın, status= ve parantez içindeki karşı sunucu cevabını birlikte okuyun, günlük özet komutlarını bir script'e koyup düzenli bakın ve status=sent satırının "gelen kutusuna düştü" anlamına gelmediğini asla unutmayın. Loglara bakma alışkanlığı, sorunları müşteri fark etmeden yakalamanın en ucuz yoludur.
Kendi mail sunucunuzu kurup logları uçtan uca kontrol etmek isterseniz tam root erişimli VDS paketlerimize, hazır yapılandırılmış bir posta yığınıyla başlamak isterseniz SMTP sunucu paketlerimize göz atabilirsiniz. Log izleme, uyarı kurma ve olay müdahalesini bizim üstlenmemizi isterseniz sunucu yönetimi hizmetimiz bunları kapsar; kurumsal posta kutuları için e-posta çözümlerimize bakabilirsiniz.