Mail Kuyruğu Birikti: Teşhis ve Çözüm

Bir sabah sunucuya bağlanıp mailq yazdığında ekranın binlerce satırla dolması, sistem yöneticiliğinin klasik kâbuslarından biridir. Mail kuyruğu birikti demek, aslında "posta akışının bir yerinde tıkanma var ve sunucu mesajları tutmaya devam ediyor" demektir. İyi haber şu: kuyruk tam olarak bunun için var. Mesajlar kaybolmadı, teslim edilemedikleri için bekliyorlar. Kötü haber ise kuyruk büyümeye devam ederse diskin dolacağı, sunucunun yeni posta kabul etmeyi bırakacağı ve en eski mesajların yaşam süresi dolduğunda kalıcı olarak bounce edeceğidir.

Bu yazıda kuyruğun neden şiştiğini adım adım teşhis edeceğiz. Önce kuyruğun yapısını ve komutlarını netleştireceğim, sonra en sık karşılaşılan altı sebebi tek tek ayıklayacağız: giden port engeli, DNS sorunu, greylisting, kara liste, disk/kaynak darlığı ve sızmış bir hesabın ürettiği spam. Her sebep için hem teşhis komutunu hem müdahaleyi vereceğim. Son bölümde de kuyruğu güvenle nasıl boşaltacağını ve hangi durumda mesaj silmenin veri kaybı anlamına geldiğini anlatacağım — çünkü panikle atılan postsuper -d ALL komutu, çözümden çok daha fazla zarar verebilir.

Kuyruk Nasıl Çalışır ve Hangi Bölümlerden Oluşur#

Postfix kuyruğu tek bir yığın değildir; birbirinden farklı davranan bölümlere ayrılır ve teşhis yaparken hangi bölümün şiştiğini bilmek, sebebi yarı yarıya daraltır. Dört ana bölüm vardır:

Pratikte %90 ihtimalle deferred bölümü şişmiştir. Bunun anlamı şudur: sunucu mesajı almaya çalıştı, karşı taraftan 4xx sınıfı bir geçici hata aldı ya da hiç bağlanamadı, ve mesajı artan aralıklarla yeniden denemek üzere sakladı. Postfix bu mesajları maximal_queue_lifetime süresi (varsayılan 5 gün) boyunca dener, sonra bounce eder.

İlk bakılacak komutlar şunlar:

# Kuyruğun özeti - kaç mesaj, ne kadar yer
postqueue -p | tail -n 1
# -- 48210 Kbytes in 3127 Requests.

# Bölüm bölüm sayım
find /var/spool/postfix/{incoming,active,deferred,hold} -type f 2>/dev/null \
  | awk -F/ '{print $5}' | sort | uniq -c

# Yaş ve alan adı dağılımı - teşhisin kalbi
qshape deferred | head -n 20

qshape deferred çıktısındaki T sütunu her alan adı için toplam mesaj sayısını, sağdaki sütunlar ise yaş dilimlerini gösterir. Tek bir alan adı listenin tepesindeyse sorun karşı taraftadır; onlarca farklı alan adı eşit dağılmışsa sorun senin sunucunda ya da ağındadır. Exim kullanıyorsan karşılıklar exim -bpc (sayı), exim -bp (liste) ve exim -bp | exiqsumm (alan adı özeti) komutlarıdır.

Sebep 1: Giden Bağlantı Engelli#

En sık karşılaşılan sebep budur ve teşhisi en kolayıdır. Loglarda Connection timed out ya da Network is unreachable satırları görüyorsan, sunucu karşı tarafa hiç ulaşamıyor demektir:

# Bağlantı hatalarını say
grep -c 'Connection timed out' /var/log/mail.log

# Tek bir mesajın son hata sebebini gör (queue ID ile)
postcat -q A1B2C3D4E5 | head -n 20

# Doğrudan test: dışarı 25 portu açık mı
nc -vz -w 8 gmail-smtp-in.l.google.com 25

Son komut cevapsız kalıyorsa giden 25 portun kapalıdır ve kuyruğun şişmesinin sebebi budur. Bu, yapılandırma değil ağ katmanı sorunudur; ayrıntılı teşhis ve çözüm yolları için SMTP 25 portu kapalı yazısına bak. Engel kalktıktan sonra kuyruğu elle tetiklemeyi unutma, yoksa mesajlar bir sonraki planlı denemeye kadar bekler.

Sebep 2: DNS Çözümlemesi Bozuk#

İkinci sık sebep, sunucunun alıcı alan adlarının MX kayıtlarını çözememesidir. Bu durumda loglarda Host or domain name not found ya da Name service error satırları görürsün. Sebep genellikle /etc/resolv.conf içindeki DNS sunucusunun ulaşılamaz olması ya da çıkış güvenlik duvarının 53 portunu kapatmasıdır.

# MX çözümlemesi çalışıyor mu
dig +short MX gmail.com
# 5 gmail-smtp-in.l.google.com.

# Sunucunun kullandığı çözümleyicileri gör
cat /etc/resolv.conf
resolvectl status | grep -A2 'DNS Servers'

# DNS'e giden trafik açık mı
nc -vzu -w 5 1.1.1.1 53

dig cevap vermiyorsa sorun burada demektir. Geçici çözüm olarak /etc/resolv.conf içine güvenilir bir genel çözümleyici ekleyip Postfix'i yeniden yükleyebilirsin, ama kalıcı çözüm ağ yapılandırmanı düzeltmektir. Ayrıca Postfix chroot içinde çalışıyorsa çözümleyici dosyasının kopyasının da güncel olması gerekir; bunu postfix reload yerine systemctl restart postfix ile tazelemen gerekebilir.

Sebep 3: Greylisting ve Hız Sınırlaması#

Kuyruk şişmiş ama mesajlar yavaş yavaş çıkıyorsa ve loglarda 450 4.7.1 gibi geçici retler görüyorsan, karşı taraf ya greylisting uyguluyordur ya da sana hız sınırı koymuştur. Greylisting kasıtlı bir gecikmedir: karşı sunucu ilk denemeyi reddeder, aynı gönderici tekrar denerse kabul eder. Bu normaldir ve müdahale gerektirmez, ama kuyruk sayını geçici olarak yükseltir. Konunun ayrıntısı için greylisting ve mail gecikmesi yazısına bakabilirsin.

Hız sınırlaması ise farklı bir durumdur. Büyük sağlayıcılar aynı IP'den gelen bağlantı ve mesaj sayısını sınırlar; sınırı aşarsan 421 4.7.0 Try again later benzeri cevaplar alırsın. Bu durumda çözüm daha hızlı denemek değil, daha yavaş göndermektir:

# /etc/postfix/main.cf - alan adı başına eşzamanlılık ve hız
# Aynı hedefe aynı anda en fazla 2 bağlantı
smtp_destination_concurrency_limit = 2
# Bir teslimat turunda en fazla 10 alıcı
smtp_destination_rate_delay = 1s
# Yeniden deneme aralığını makul tut
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Belirli bir alan adına özel sınır koymak istersen transport_maps ile o alan adını ayrı bir teslimat kanalına yönlendirip master.cf içinde o kanala düşük eşzamanlılık verirsin. Bu, tek bir büyük müşteriye ya da sağlayıcıya yapılan yoğun gönderimlerde kuyruğun kilitlenmesini önler.

Sebep 4: Kara Liste ve İtibar Sorunu#

Loglarda 550 5.7.1 ile başlayan ve içinde bir kara liste adresi ya da "blocked" ifadesi geçen retler varsa, IP'n listeye düşmüştür. Bu durumda kuyruk hem şişer hem de mesajlar kalıcı ret aldığı için bounce etmeye başlar. Önce durumu doğrula:

# En sık dönen ret mesajlarını gör
grep 'status=bounced' /var/log/mail.log \
  | grep -oE 'said: [0-9]{3}[^)]*' | sort | uniq -c | sort -rn | head

# IP'yi kara listede sorgula (oktetleri ters çevir)
IP=185.12.34.56
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
host $REV.zen.spamhaus.org

Sorgu bir cevap dönüyorsa listedesin. Çözüm iki aşamalıdır ve sırası önemlidir: önce sebebi kapat, sonra çıkarma talebi aç. Sebebi kapatmadan çıkarma talebi açarsan birkaç saat içinde tekrar listelenirsin. En yaygın sebep, ele geçirilmiş bir posta hesabının sunucudan spam göndermesidir; bir sonraki bölümde bunu nasıl tespit edeceğini anlatıyorum.

Sebep 5: Sızmış Hesap ve Ani Spam Dalgası#

Kuyruk birkaç saat içinde binlerce mesajla dolduysa ve bu mesajların göndericisi kendi alan adındaki bir hesapsa, o hesabın parolası ele geçirilmiş olabilir. Teşhis, kuyruktaki mesajların göndericilerini saymakla başlar:

# Kuyrukta en çok mesajı olan göndericiler
postqueue -p | awk '/^[A-F0-9]/ {print $7}' | sort | uniq -c | sort -rn | head

# Hangi kimlikle gönderim yapılmış (SASL kullanıcısı)
grep 'sasl_username' /var/log/mail.log \
  | grep -oE 'sasl_username=[^ ]+' | sort | uniq -c | sort -rn | head

# Başarılı girişlerin geldiği IP'ler
grep 'sasl_method=' /var/log/mail.log \
  | grep -oE '\[[0-9.]+\]' | sort | uniq -c | sort -rn | head

Tek bir hesap listenin tepesindeyse ve bağlantılar tanımadığın ülkelerden geliyorsa müdahale sırası şudur:

1. Hesabın parolasını hemen değiştir ve tüm oturumları kapat.
2. O hesaba ait kuyruktaki mesajları beklemeye al: postsuper -h ile hold bölümüne taşı.
3. Beklemeye alınan mesajları inceleyip spam olduklarını doğrula, sonra sil.
4. Sunucuda giden hız sınırı ve kimlik doğrulama hatası limiti kur.
5. Kara listede isen çıkarma talebi aç.

İkinci adımı atlayıp doğrudan silmek risklidir: aynı anda gerçek kullanıcıların meşru postaları da kuyrukta olabilir. Parola değiştirme adımını nasıl yapacağını e-posta şifresi değiştirme yazısında bulabilirsin. Kalıcı önlem olarak güçlü parola politikası şarttır; rastgele parola üretmek için şifre üretici aracımızı kullanabilirsin.

Sebep 6: Disk, inode ve Kaynak Darlığı#

Bazen kuyruk şişmesinin sebebi teslimat değil, sunucunun mesajı işleyememesidir. Disk dolduğunda Postfix yeni mesajı kabul etmeyi bırakır ama kuyruktakiler de teslim edilemez; inode tükendiğinde ise disk boş görünürken hiçbir dosya oluşturulamaz.

# Disk ve inode doluluğu birlikte
df -h /var/spool
df -i /var/spool

# Kuyruk dizininin boyutu
du -sh /var/spool/postfix/*

# Süreç limitlerine takılıyor musun
grep -c 'resource temporarily unavailable' /var/log/mail.log

Disk %100'e yaklaşmışsa önce yer aç: eski logları temizle, hold bölümündeki gereksiz mesajları sil, gerekirse kuyruğu geçici olarak daha büyük bir bölüme taşı. Yeterli kaynak planlaması için mail sunucusu kaynak gereksinimleri yazısındaki tablolar iyi bir referans verir.

Kuyruğu Güvenle Boşaltmak#

Sebebi bulup düzelttikten sonra kuyruğun kendiliğinden erimesini beklemek zorunda değilsin. Postfix'in kuyruk yönetim komutları şunlardır ve her birinin ne yaptığını bilerek kullanmak önemlidir:

Doğru sıra şudur: önce sebebi düzelt, sonra postqueue -f ile hepsini tetikle, birkaç dakika bekleyip kuyruğun erimeye başladığını gör. Erimiyorsa sebep hâlâ ayakta demektir; silmek yerine tekrar teşhise dön.

Yalnızca belirli mesajları silmen gerekiyorsa hedefli sil. Örneğin sızmış hesabın gönderdiklerini temizlemek için:

# Önce say ve gözünle doğrula (silmeden!)
postqueue -p | grep -c '[email protected]'

# Sadece o göndericinin mesajlarını beklemeye al
postqueue -p | awk -v RS='' '/sizmis@firmaniz\.com/ {print $1}' \
  | tr -d '*!' | postsuper -h -

# İnceleyip emin olduktan SONRA sil
postqueue -p | awk -v RS='' '/sizmis@firmaniz\.com/ {print $1}' \
  | tr -d '*!' | postsuper -d -

postsuper -d ALL komutunu yalnızca kuyruktakilerin tamamının çöp olduğundan eminsen kullan. Kuyrukta gerçek müşteri postaları varsa bu komut onları geri dönülemez biçimde yok eder ve gönderen taraf hiçbir bounce bile almaz — mesaj sessizce kaybolur.

Sık Yapılan Hatalar#

En pahalı hata, teşhis yapmadan postsuper -d ALL çalıştırmaktır. Kuyruk şişmesi neredeyse her zaman düzeltilebilir bir sebepten kaynaklanır ve mesajların büyük bölümü meşrudur. İkinci hata, Postfix'i yeniden başlatmanın kuyruğu çözeceğini sanmaktır; yeniden başlatma teslimat sorununu düzeltmez, sadece süreçleri tazeler.

Üçüncü hata, postqueue -f komutunu bir çözüm sanıp sebep düzeltilmeden defalarca çalıştırmaktır. Bu, aynı anda yüzlerce bağlantının karşı sunuculara gitmesine ve hız sınırına takılıp durumun daha da kötüleşmesine yol açar. Dördüncü hata, deferred kuyruğun büyümesini otomatik olarak "arıza" saymaktır: greylisting yüzünden geçici bir yükselme normaldir, önemli olan sayının azalarak seyretmesidir. Beşinci hata, kuyruk sorununu çözdükten sonra izleme kurmamaktır; aynı sorun bir sonraki sefer de sessizce büyür. İzleme kurulumu için mail sunucusu izleme yazısındaki eşikleri doğrudan kullanabilirsin.

Sıkça Sorulan Sorular#

Kuyruktaki mesajlar ne kadar süre bekler#

Postfix varsayılan olarak bir mesajı maximal_queue_lifetime süresi boyunca, yani genellikle 5 gün, yeniden dener. Bu sürede teslim edilemezse gönderene kalıcı bir bounce mesajı gönderilir ve kuyruktan düşer. Bounce mesajlarının kendisi için ayrı ve daha kısa bir süre tanımlıdır. Bu süreleri main.cf içinden değiştirebilirsin ama çok kısaltmak, geçici sağlayıcı arızalarında postaların gereksiz yere kaybolmasına yol açar.

Mail kuyruğunu nasıl temizlerim#

Önce sebebi bul ve düzelt, sonra postqueue -f ile kuyruğu yeniden dene. Mesajların gerçekten silinmesi gerekiyorsa hedefli silme yap: ilgili mesajları önce postsuper -h ile beklemeye al, içeriklerini postcat ile doğrula, ardından postsuper -d ile sil. postsuper -d ALL komutu tüm kuyruğu geri dönüşsüz siler ve gönderen taraf bounce bile almaz, o yüzden yalnızca son çare olarak kullan.

Kuyruk neden sürekli aynı mesajları deniyor#

Çünkü karşı taraftan geçici hata (4xx) alıyor. Postfix bu mesajları artan aralıklarla, yaşam süresi dolana kadar dener. Aynı mesajın tekrar tekrar denenmesi normaldir; anormal olan, hiçbirinin ilerlememesidir. postcat -q QUEUEID komutuyla o mesajın son aldığı hata metnini okuyup sebebi doğrudan görebilirsin.

Kuyruk şiştiğinde disk dolarsa ne olur#

Postfix yeni posta kabul etmeyi bırakır ve gelen bağlantılara geçici hata döner; bu, gönderen tarafın daha sonra tekrar denemesi anlamına gelir, yani mesajlar hemen kaybolmaz. Ancak kuyruktakiler de teslim edilemez ve durum kötüleşir. Disk doluluğunu ve inode kullanımını birlikte izlemen, bu senaryoyu önlemenin en kolay yoludur.

Exim kullanıyorum, komutlar aynı mı#

Mantık aynı, komutlar farklı. Kuyruk sayısı için exim -bpc, kuyruk listesi için exim -bp, alan adı özeti için exim -bp | exiqsumm kullanılır. Kuyruğu tetiklemek exim -qff, tek bir mesajı silmek ise exim -Mrm QUEUEID komutudur. Teşhis yaklaşımı, sebep sınıflandırması ve müdahale sırası bu yazıdakiyle birebir aynıdır.

Kuyruk kaç mesaja kadar normaldir#

Bu tamamen trafiğine bağlıdır; mutlak bir sayı yok. Doğru yaklaşım, normal günlerde kuyruk sayını bir hafta ölçüp kendi temel çizgini çıkarmaktır. Genel bir başlangıç eşiği olarak aktif kuyrukta 100, deferred kuyrukta 500 mesaj makuldür. Sayıdan daha güvenilir bir gösterge ise en eski mesajın yaşıdır: dört saati aşan bir mesaj varsa, kuyruk küçük olsa bile bir şey takılmış demektir.

Kapanış#

Şişmiş bir kuyruk panik sebebi değil, teşhis daveti. Aklında kalması gereken dört alışkanlık: qshape deferred çıktısına bakıp sorunun tek bir alan adında mı yoksa her yerde mi olduğunu ilk adımda ayır; log satırındaki gerçek hata metnini oku, tahmin etme; sebebi düzeltmeden kuyruğu tetikleme ya da silme; ve hedefli silmeyi her zaman toplu silmeye tercih et. Sorun çözüldükten sonra da kuyruk büyüklüğü ve en eski mesaj yaşı için bir uyarı kurmayı ihmal etme.

Bu tür arızalarla uğraşmak istemiyor, posta altyapının bakımını devretmek istiyorsan Clou.TR tarafında birkaç seçenek var. Sunucu yönetimi hizmetimiz izleme ve müdahaleyi birlikte üstlenir; kendi kurulumunu yönetmek isteyenler için VDS paketlerimiz tam root erişimi sunar. Yoğun gönderim yapıyorsan trafiği ayırmak için SMTP sunucu çözümümüze, hazır kurumsal posta kutuları içinse e-posta paketlerimize göz atabilirsin.