Mail Kuyruğu Doldu: Postfix ve Exim Kuyruk Temizleme Rehberi

Bykomut

Sabah 08:00’de gelen “mail sunucusu yanıt vermiyor” bildirimi, sysadmin’lerin en çok nefret ettiği uyarılardan biridir. Monitörünüzün başına geçiyorsunuz, logları açıyorsunuz ve görüyorsunuz: mail kuyruğu binlerce mesajla dolmuş, sunucu çökmüş gibi davranıyor. Bu yazıda hem Postfix hem de Exim için mail kuyruğu sorunlarını nasıl teşhis edip çözeceğinizi gerçek dünya senaryolarıyla anlatacağım.

Mail Kuyruğu Neden Dolar?

Önce durumu anlamak lazım. Mail kuyruğu bir anda dolmuyorlar, genellikle birkaç farklı senaryonun sonucu olarak bu noktaya gelinir.

En yaygın sebepler şunlardır:

  • Hedef mail sunucusunun geçici olarak erişilememesi (karşı taraf 421/450 hatası dönüyor)
  • DNS çözümleme sorunları nedeniyle mesajların teslim edilememesi
  • Spam botunun sunucunuzu ele geçirmesi ve yüzlerce/binlerce mesaj göndermesi
  • Yazılım hatasından kaynaklanan döngüsel mail gönderimi (mail loop)
  • Disk doluluk nedeniyle mesajların teslim edilememesi ama kuyruğa alınmaya devam etmesi
  • Greylisting uygulayan sunuculara gönderilen mesajların birikmesi

Hangisi olduğunu anlamadan rastgele komut çalıştırmak bazen durumu daha da kötüleştirir. O yüzden önce teşhis, sonra tedavi.

Postfix Kuyruk Yönetimi

Mevcut Durumu Görmek

Postfix’te ilk yapacağınız şey kuyruğu listelemek olmalı.

# Kuyruk özetini göster
mailq

# Daha detaylı çıktı için
postqueue -p

# Sadece mesaj sayısını öğren
postqueue -p | tail -1

postqueue -p çıktısı biraz karmaşık görünebilir. Her satırda mesaj ID’si, boyutu, tarihi, gönderen ve alıcı adresi görürsünüz. Parantez içindeki mesaj ise neden beklemede olduğunu açıklar. Örneğin (connect to mail.example.com[1.2.3.4]:25: Connection timed out) görüyorsanız sorun karşı taraftadır.

# Kuyrukta kaç mesaj var?
postqueue -p | grep "^[A-F0-9]" | wc -l

# Hangi alıcı domainlere mesaj var?
postqueue -p | grep "@" | awk '{print $1}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head -20

# Hangi göndericiden en çok mesaj geliyor?
postqueue -p | grep "^[A-F0-9]" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Bu komutlar size çok değerli bilgi verir. Mesela 5000 mesajın 4800’ü aynı göndericiden geliyorsa, büyük ihtimalle bir uygulama mail loopu veya spam sorunuyla karşı karşıyasınızdır.

Postfix Kuyruğunu Temizlemek

#### Belirli Mesajları Silmek

Eğer belirli bir alıcıya veya göndericiye ait mesajları silmek istiyorsanız, önce mesaj ID’lerini bulup sonra silmeniz gerekir.

# Belirli bir alıcıya giden tüm mesajları sil
postqueue -p | grep -B1 "[email protected]" | grep "^[A-F0-9]" | awk '{print $1}' | tr -d '*!' | while read id; do postsuper -d $id; done

# Belirli bir göndericiden gelen tüm mesajları sil
postqueue -p | awk 'BEGIN{id=""} /^[A-F0-9]/{id=$1} /[email protected]/{print id}' | tr -d '*!' | while read id; do postsuper -d $id; done

#### Tüm Kuyruğu Temizlemek

Bazen durum o kadar kötüdür ki tüm kuyruğu silmek en mantıklı çözümdür. Özellikle spam saldırısı sonrası bu tercih edilebilir.

# Tüm kuyruğu sil (dikkatli ol!)
postsuper -d ALL

# Sadece deferred (beklemedeki) mesajları sil
postsuper -d ALL deferred

postsuper -d ALL komutu çalıştırmadan önce bir kez daha düşünün. Meşru mesajlar da varsa onlar da gider. Eğer emin değilseniz önce belirli kategorileri temizleyin.

#### Kuyruğu Yeniden İşleme Zorlamak

Bazen mesajlar geçici bir hata nedeniyle beklemededir ve yeniden deneme zamanı gelmemiştir. Siz sunucuyu düzeltdiniz ama Postfix hala bekliyordur. Bu durumda kuyruğu manuel tetikleyebilirsiniz.

# Tüm kuyruğu hemen yeniden işlemeye zorla
postqueue -f

# Sadece belirli bir mesajı yeniden kuyruğa al
postsuper -r MESAJID

# Tüm deferred mesajları active kuyruğuna taşı
postsuper -r ALL deferred

Postfix Log Analizi

Kuyruğu temizlemek sorunun yüzeysel çözümüdür. Gerçek problemi bulmak için logları incelemeniz şart.

# Son 1 saatin mail loglarını izle
tail -f /var/log/mail.log

# Belirli bir mesaj ID'sinin izini sürmek
grep "MESAJID" /var/log/mail.log

# Bounce edilen mesajları listele
grep "status=bounced" /var/log/mail.log | tail -50

# Deferred olan mesajları ve sebeplerini gör
grep "status=deferred" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Gerçek dünya örneği: Bir müşteride kuyruğun dolmasının sebebini araştırırken şu log satırını bulduk:

postfix/smtp[12345]: connect to mx1.example.com[x.x.x.x]:25: Connection timed out

Binlerce mesaj aynı domaine gidiyordu ve o domain’in MX sunucusu yanıt vermiyordu. Çözüm: O domaine giden mesajları deferred kuyruğuna bırakıp diğer mesajların işlenmesine izin vermek. transport_maps ile o domain için farklı bir davranış tanımladık.

Postfix Kuyruk Limitlerini Ayarlamak

Kuyruğun gereğinden fazla büyümesini önlemek için main.cf dosyasında bazı parametreler tanımlayabilirsiniz.

# /etc/postfix/main.cf içine eklenecekler

# Maksimum mesaj boyutu (10MB)
message_size_limit = 10240000

# Kuyruktaki mesajın maksimum yaşam süresi (1 gün)
maximal_queue_lifetime = 1d

# Bounce mesajlarının maksimum yaşam süresi
bounce_queue_lifetime = 1d

# Eş zamanlı gönderim sayısını sınırla
default_process_limit = 100
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 1s

Bu ayarları yaptıktan sonra Postfix’i reload etmeyi unutmayın:

postfix reload
# veya
systemctl reload postfix

Exim Kuyruk Yönetimi

Exim, özellikle cPanel/WHM kullanan sunucularda çok yaygındır ve kendi kuyruk yönetim araçlarına sahiptir.

Mevcut Durumu Görmek

# Kuyruk özetini göster
exim -bp

# Sadece mesaj sayısını göster
exim -bpc

# Daha okunabilir format
exim -bp | exiqsumm

# Frozen (dondurulmuş) mesaj sayısı
exim -bp | grep frozen | wc -l

exim -bp çıktısında “frozen” kelimesini görüyorsanız bu mesajlar birden fazla kez denenmiş ve artık otomatik olarak yeniden denenmeyecek durumdadır. Bu mesajlar kuyruğu şişirmenin en yaygın sebebidir.

# Hangi alıcılara mesaj var?
exim -bp | awk '/^[0-9]/{print $4}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head -20

# Hangi göndericiden kaç mesaj var?
exim -bp | grep "<" | awk '{print $2}' | sort | uniq -c | sort -rn | head -20

# Belirli bir mesajın detaylarını gör
exim -Mvh MESAJID

Exim Kuyruğunu Temizlemek

#### Frozen Mesajları Silmek

Frozen mesajlar genellikle teslim edilemeyen ve artık denenmeyecek olan mesajlardır. Bunları silmek genellikle güvenlidir, özellikle spam kaynaklıysa.

# Tüm frozen mesajları sil
exiqgrep -z -i | xargs exim -Mrm

# Alternatif yöntem
exim -bp | grep frozen | awk '{print $3}' | xargs exim -Mrm

#### Belirli Kriterlere Göre Silmek

# Belirli bir göndericiden gelen tüm mesajları sil
exiqgrep -f "[email protected]" -i | xargs exim -Mrm

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

# 24 saatten eski tüm mesajları sil
exiqgrep -o 86400 -i | xargs exim -Mrm

# Belirli bir subject içeren mesajları bul ve sil
exiqgrep -s "Cheap Viagra" -i | xargs exim -Mrm

#### Tüm Kuyruğu Temizlemek

# Tüm mesajları sil (çok dikkatli ol!)
exim -bp | awk '/^[0-9]/{print $3}' | xargs exim -Mrm

# Daha güvenli alternatif
exiqgrep -i | xargs exim -Mrm

Exim Log Analizi

# Ana log dosyası
tail -f /var/log/exim_mainlog

# cPanel sunucularında
tail -f /var/log/exim_mainlog | grep -E "rejected|frozen|failed"

# Bounce olan mesajları görüntüle
grep "== .* R=.* T=" /var/log/exim_mainlog | tail -50

# En çok mail gönderen IP'leri bul
grep "SMTP connection" /var/log/exim_mainlog | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Exim’de bir mesajın tam yaşam döngüsünü takip etmek için mesaj ID’sini kullanabilirsiniz:

# Mesajın tüm log kayıtlarını göster
grep "MESAJID" /var/log/exim_mainlog

# Mesajın header bilgilerini göster
exim -Mvh MESAJID

# Mesajın body içeriğini göster (dikkatli ol, büyük olabilir)
exim -Mvb MESAJID

Exim’de Kuyruğu Yeniden İşlemek

# Tüm kuyruğu hemen işlemeye zorla
exim -qf

# Frozen mesajları da dahil ederek işlemeye zorla
exim -qff

# Sadece belirli bir mesajı yeniden dene
exim -M MESAJID

# Kuyruğu arka planda işle
exim -q &

Spam Saldırısı Senaryosu: Gerçek Bir Vaka

Geçen yıl bir e-ticaret müşterisinde şu durumla karşılaştık: Gece yarısı sunucunun mail kuyruğuna 15.000’den fazla mesaj dolmuştu. Sunucu kendi IP’sinden spam gönderiyordu ve karşı sunucular mesajları reddediyordu.

Adım adım nasıl çözdük:

1. Önce boyutu anladık:

postqueue -p | tail -1
# Çıktı: -- 15847 Kbytes in 15234 Requests.

2. Hangi hesaptan geldiğini bulduk:

postqueue -p | grep "@" | grep -v "^(" | awk '{print $NF}' | sort | uniq -c | sort -rn | head -5

Çıktıda bir WordPress sitesinin “contact@” adresi öne çıkıyordu.

3. WordPress’in mail gönderme işlevini geçici olarak kapattık:

İlgili sitenin wp-config.php dosyasına define('DISABLE_WP_CRON', true); ekledik ve şüpheli eklentiyi devre dışı bıraktık.

4. Spam mesajları sildik ama meşru mesajları korumak istedik:

# Sadece o adresten gelen mesajları sil
postqueue -p | awk 'BEGIN{id=""} /^[A-F0-9]/{id=$1} /[email protected]/{print id}' | tr -d '*!' | while read id; do postsuper -d $id; done

5. IP’nin kara listeye girip girmediğini kontrol ettik:

# MXToolbox veya manuel DNS sorgusu
dig +short 4.3.2.1.zen.spamhaus.org

# Kendi IP'niz için (ters çevrilmiş formatta)
dig +short [reversed_ip].bl.spamhaus.org

6. Rate limiting ekledik:

# /etc/postfix/main.cf
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
anvil_rate_time_unit = 60s

Otomatik Kuyruk Temizleme Scripti

Hem Postfix hem de Exim için kullanabileceğiniz basit bir monitoring scripti:

#!/bin/bash
# /usr/local/bin/mail-queue-check.sh

THRESHOLD=1000
POSTFIX_LOG="/var/log/mail.log"
EMAIL_ALERT="[email protected]"

# Postfix mi Exim mi kontrol et
if command -v postfix &> /dev/null; then
    QUEUE_COUNT=$(postqueue -p | tail -1 | awk '{print $1}' | tr -d '--')
    MTA="Postfix"
elif command -v exim &> /dev/null; then
    QUEUE_COUNT=$(exim -bpc)
    MTA="Exim"
else
    echo "MTA bulunamadi"
    exit 1
fi

# Sayı boş veya sayısal değilse 0 yap
if ! [[ "$QUEUE_COUNT" =~ ^[0-9]+$ ]]; then
    QUEUE_COUNT=0
fi

echo "$(date): $MTA kuyrugunda $QUEUE_COUNT mesaj var"

if [ "$QUEUE_COUNT" -gt "$THRESHOLD" ]; then
    echo "$MTA kuyruğu kritik seviyede: $QUEUE_COUNT mesaj" | 
    mail -s "UYARI: Mail Kuyrugu Dolu - $MTA" $EMAIL_ALERT
fi

Bu scripti cron’a ekleyerek her 15 dakikada bir çalıştırabilirsiniz:

# crontab -e
*/15 * * * * /usr/local/bin/mail-queue-check.sh >> /var/log/mail-queue-check.log 2>&1

Yaygın Hata Mesajları ve Çözümleri

“Too many connections” hatası:

Genellikle karşı sunucunun bağlantı sınırı aşılmış demektir. Postfix’te çözüm:

# /etc/postfix/main.cf
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 2s
smtp_extra_recipient_limit = 10

“Relay access denied” hatası:

Sunucunuz açık relay olarak kötüye kullanılıyordur. Postfix’te open relay kontrolü:

# Test et
telnet localhost 25
EHLO test
MAIL FROM: [email protected]
RCPT TO: target@başka-domain.com

# /etc/postfix/main.cf kontrolü
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
# Sadece localhost olmalı, geniş ağ aralıkları olmamalı

“Disk quota exceeded” hatası:

# Disk durumunu kontrol et
df -h /var/spool/postfix
df -h /var/spool/exim

# En büyük mesajları bul ve sil
find /var/spool/postfix -name "*.db" -size +10M

Önleyici Tedbirler

Kuyruğun dolmasını önlemek için almanız gereken birkaç temel önlem:

  • SPF, DKIM ve DMARC kaydlarınızı DNS’e ekleyin. Bu hem spam gönderimi önler hem de mesajlarınızın karşı tarafa ulaşma oranını artırır.
  • Rate limiting mutlaka konfigüre edin. Hem gelen hem giden mesajlar için sınır koyun.
  • Postfix veya Exim log izlemesini Grafana/Prometheus veya basit script ile yapın. 500’ü aşınca alarm gelsin.
  • Bounce mesajlarını inceleyin düzenli olarak. Sürekli bounce alan adresler listenizden çıkarın.
  • ClamAV veya SpamAssassin entegrasyonu yapın. Kötü niyetli mesajları kuyruktan önce filtreleyin.
  • Kuyruktaki mesajların maksimum yaşını makul tutun. 5 gün boyunca teslim edilemeyen mesaj teslim edilmeyecektir büyük ihtimalle.

Sonuç

Mail kuyruğu sorunları stresli ama aslında çözümü çok zor değil durumlar. Önemli olan önce teşhis, sonra müdahale prensibini uygulamak. Tüm kuyruğu silmek bazen cazip gelir ama meşru mesajları kaybetme riskini de beraberinde getirir.

Postfix için postqueue -p ve postsuper, Exim için exim -bp ve exiqgrep araçları günlük hayatınızın parçası olmalı. Bu komutları ezberlemenize gerek yok ama nerede bulacağınızı ve ne sorduğunuzda neye bakacağınızı bilmeniz yeterli.

Son olarak şunu söyleyeyim: Mail sunucusu sorunları genellikle başka bir şeyin belirtisidir. Kuyruk doluysa “neden doldu” sorusunu sormadan sadece temizlemek, hastalığın belirtisini tedavi etmek gibidir. Log analizi yapın, kök sebebi bulun ve kalıcı çözümü uygulayın. Yoksa aynı sabahı birkaç kez daha yaşarsınız.

Benzer Konular

Bir yanıt yazın

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