Postfix Kuyruk Yönetimi: postqueue ve postsuper

Postfix kuyruk yönetimi, mail sunucusu işleten herkesin er geç öğrenmek zorunda kaldığı konudur. Bir sabah sunucuya bağlanırsınız ve kuyrukta on binlerce mektup bekliyordur; bunların bir kısmı meşru müşteri mektubu, bir kısmı ele geçirilmiş bir hesaptan çıkan spam, bir kısmı da alıcı sunucunun geçici olarak reddettiği normal trafiktir. Hepsini birden silmek en kolay yoldur ve genellikle en yanlış olanıdır.

Bu yazıda Postfix'in beş kuyruğunu, postqueue ile kuyruğu nasıl okuyacağınızı, postsuper ile mektupları nasıl yeniden kuyruklayıp seçerek sileceğinizi, tek bir mektubun içeriğine postcat ile nasıl bakacağınızı ve kuyruk şişmesinin tipik sebeplerini anlatacağım. Komutları körü körüne uygulamak yerine hangi durumda hangisinin doğru olduğunu ayırt edebilecek duruma gelmenizi hedefliyorum.

Postfix'in Kuyruk Yapısı#

Postfix tek bir kuyruk kullanmaz; mektuplar yaşam döngülerine göre farklı dizinlerde tutulur. Kök dizin genellikle /var/spool/postfix altındadır ve her kuyruk ayrı bir alt dizindir.

Günlük hayatta ilgilendiğiniz kuyruk neredeyse her zaman deferred olur. Bir mektup burada, alıcı sunucu 4xx cevabı verdiği için bekler. Postfix onu artan aralıklarla yeniden dener; bekleme süreleri minimal_backoff_time ve maximal_backoff_time ile, kuyrukta kalabileceği toplam süre ise maximal_queue_lifetime ile belirlenir. Varsayılan yaşam süresi genellikle beş gündür; sonunda teslim edilemezse mektup bounce olarak gönderene döner.

Bu değerleri görmek ve gerekirse değiştirmek için:

# Kuyruk davranışını belirleyen parametreleri göster
postconf maximal_queue_lifetime bounce_queue_lifetime \
         minimal_backoff_time maximal_backoff_time queue_run_delay

# Örnek: yaşam süresini 2 güne indir (uzun bekleyen mektupları erken bounce et)
sudo postconf -e 'maximal_queue_lifetime = 2d'
sudo postconf -e 'bounce_queue_lifetime = 2d'
sudo systemctl reload postfix

Geçici retlerin bir kısmı sizin sunucunuzla ilgili değil, karşı tarafın greylisting uygulamasıyla ilgilidir; bu tamamen normaldir ve mektup birkaç dakika sonra teslim edilir. Ayrımı greylisting ve mail gecikmesi yazısında ele aldım.

Kuyruğu Okumak: postqueue#

postqueue -p (eski adıyla mailq) kuyruktaki mektupları listeler. Çıktı her mektup için iki satır verir: kimlik, boyut, tarih, gönderen; altında da bekleme gerekçesi ve alıcılar.

postqueue -p

Tipik bir çıktı şöyle görünür:

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A19E4C2*     4821 Mon Aug 25 09:12:41  [email protected]
                                          [email protected]

7B1C44D0A9      3190 Mon Aug 25 08:44:03  [email protected]
   (host mx.ornek.com[203.0.113.9] said: 451 4.7.1 Try again later)
                                          [email protected]

-- 812 Kbytes in 214 Requests.

Kimliğin sonundaki * işareti mektubun active kuyrukta olduğunu, yani şu anda teslim edilmeye çalışıldığını gösterir. ! işareti ise hold kuyruğunda beklediğini belirtir. Parantez içindeki satır, karşı sunucunun son verdiği cevaptır ve teşhiste en değerli bilgidir.

Yüzlerce satırlık bir kuyrukta gözle inceleme yapmak anlamsızdır; özet çıkarın:

# Toplam mektup sayısı
postqueue -p | tail -1

# Bekleme gerekçelerine göre dağılım — hangi sorun kaç mektubu tutuyor
postqueue -p | grep -E '^ *\(' | sed 's/^ *//' | cut -c1-70 \
  | sort | uniq -c | sort -rn | head

# Göndericiye göre dağılım — spam kaynağını bulmanın en hızlı yolu
postqueue -p | awk 'NF>3 && $1 ~ /^[0-9A-F]+\*?!?$/ {print $NF}' \
  | sort | uniq -c | sort -rn | head

Son komut, ele geçirilmiş bir hesabı saniyeler içinde ortaya çıkarır: tek bir gönderici adresi kuyruğun büyük bölümünü oluşturuyorsa o hesabın şifresi çalınmış demektir. Makine tarafından işlenebilir bir çıktı isterseniz JSON biçimi de vardır:

# JSON çıktı — script yazarken tercih edin
postqueue -j | head -1

Kuyruğu hemen taramaya zorlamak (yeniden deneme aralığını beklemeden) için:

# Tüm kuyruğu şimdi işle
postqueue -f

# Yalnızca belirli bir alan adına giden mektupları işle
postqueue -s ornek.com

postqueue -f her sorunun çözümü değildir: karşı taraf hâlâ hız sınırı uyguluyorsa tüm kuyruğu zorlamak durumu kötüleştirir ve mektuplar tekrar deferred olur.

Tek Bir Mektuba Bakmak: postcat#

Bir mektubun neden beklediğini anlamak için içeriğine bakmanız gerekebilir. postcat bunu yapar; kuyruk kimliğini verirsiniz, mektubun zarf bilgilerini ve içeriğini döker.

# Zarf + başlık + gövde
sudo postcat -q 7B1C44D0A9

# Yalnızca zarf ve başlıklar — genellikle yeterli
sudo postcat -qh 7B1C44D0A9

# Yalnızca gövde
sudo postcat -qb 7B1C44D0A9

Başlık çıktısında dikkat etmeniz gereken alanlar şunlardır: sender (zarf göndericisi), recipient (zarf alıcısı), Message-ID, Received zinciri ve varsa X- ile başlayan uygulama başlıkları. Zarftaki gönderici ile From: başlığındaki adres farklıysa bu normaldir — bounce yönetimi için kasıtlı yapılan bir ayrımdır ve gerekçesini bounce yönetimi: hard ve soft bounce farkı yazısında anlattım.

Spam şüphesi varsa Received zincirinin en alt satırına bakın: mektup gerçekten dışarıdan mı geldi, yoksa yerel bir PHP script'inden mi bırakıldı? İkinci durumda başlıklarda X-PHP-Originating-Script gibi bir alan görürsünüz ve bu, hangi dosyanın gönderim yaptığını doğrudan söyler.

postsuper ile Mektupları Yönetmek#

postsuper kuyruk üzerinde değişiklik yapan komuttur ve root yetkisi ister. Dört temel işlemi vardır:

Her komut ALL anahtar kelimesini de kabul eder ve bu, en tehlikeli kullanımdır:

# Kuyruktaki HER ŞEYİ yeniden kuyruklar (yeni yapılandırmayla dener)
sudo postsuper -r ALL

# Kuyruktaki HER ŞEYİ siler — geri dönüşü yoktur
sudo postsuper -d ALL

# Yalnızca deferred kuyruğunu siler
sudo postsuper -d ALL deferred

postsuper -d ALL komutunu yazmadan önce durup şunu sorun: bu kuyrukta müşterinin bekleyen faturası var mı? Silinen mektup kaybolur, gönderene bildirim bile gitmez. Doğru yaklaşım, önce seçmek sonra silmektir.

Seçerek silmenin standart yöntemi, kuyruk çıktısından hedef kimlikleri çıkarıp postsuper'a beslemektir:

# Belirli bir göndericiden çıkan tüm mektupları sil
postqueue -p | awk 'BEGIN{RS=""} /ele-gecirilen@firmaniz\.com/ {print $1}' \
  | tr -d '*!' | sudo postsuper -d -

# Belirli bir alıcı alan adına giden mektupları beklemeye al
postqueue -p | awk 'BEGIN{RS=""} /@ornek\.com/ {print $1}' \
  | tr -d '*!' | sudo postsuper -h -

# Belirli bir hata mesajıyla bekleyenleri yeniden dene
postqueue -p | awk 'BEGIN{RS=""} /Connection timed out/ {print $1}' \
  | tr -d '*!' | sudo postsuper -r -

Buradaki BEGIN{RS=""} ayarı, awk'ın kayıtları boş satırla ayırmasını sağlar; böylece her mektubun tüm satırları (kimlik, gerekçe, alıcılar) tek bir kayıt olarak değerlendirilir ve desen bunların herhangi birinde eşleşebilir. tr -d '*!' ise kimliğin sonundaki durum işaretlerini temizler — bu adımı atlarsanız postsuper kimliği tanımaz.

Silmeden önce mutlaka sayıyı görün:

# Önce kaç mektup etkilenecek, onu öğrenin
postqueue -p | awk 'BEGIN{RS=""} /ele-gecirilen@firmaniz\.com/ {print $1}' | wc -l

Kuyruk dosyaları arasında tutarsızlık şüphesi varsa (Postfix çakılmışsa, disk dolmuşsa) yapı kontrolü de yapabilirsiniz:

# Kuyruk dosyalarının bütünlüğünü kontrol et ve bozukları corrupt/'a taşı
sudo postsuper -s

Kuyruk Neden Şişer: Tipik Senaryolar#

Ele geçirilmiş hesap. Kuyrukta binlerce mektup, hepsi tek bir gönderici adresinden ve alıcılar tanımadığınız alan adlarından. Yapılacak sıra: hesabın şifresini değiştirin, postsuper -h ile o göndericinin mektuplarını beklemeye alın, örnekleri postcat ile inceleyip kaynağı doğrulayın, sonra silin. Silmeden önce beklemeye almak, yanlış hesabı seçtiğinizi fark ettiğinizde geri dönebilmenizi sağlar.

Web uygulamasından çıkan döngü. Bir PHP formu ya da eklenti hatalı biçimde tekrar tekrar mektup üretir. postcat -qh çıktısındaki X-PHP-Originating-Script başlığı hangi dosyanın sorumlu olduğunu söyler.

Tek bir alıcı sunucunun erişilemez olması. Kuyruğun tamamı aynı hedef alan adına gidiyor ve gerekçe Connection timed out. Bu durumda yapılacak şey beklemektir; karşı taraf döndüğünde postqueue -s ornek.com ile o alan adını hemen deneyebilirsiniz.

İtibar kaynaklı hız sınırı. Gerekçelerde 4.7.x kodları ve "rate limited" benzeri metinler görüyorsanız sorun kuyrukta değil, gönderim davranışınızdadır. Kuyruğu zorlamak yerine hacmi kısmak gerekir; bunun planını mail IP ısıtma (warm-up) planı yazısında ele aldım.

Yanlış DNS ya da MX. Gerekçe Host or domain name not found ise alıcı alan adının MX kaydı çözümlenmiyordur. Kendi alan adınız için bu hatayı görüyorsanız kaydınızda sorun var demektir; teşhis için e-postalarım gelmiyor: MX sorunu yazısına bakın.

Kuyruğu düzenli izlemek için basit bir eşik uyarısı kurmak iyi bir alışkanlıktır:

# Kuyruk 500'ü aşarsa uyarı üret (cron ile 15 dakikada bir çalıştırın)
SAYI=$(postqueue -p | awk '/^-- /{print $5}')
[ "${SAYI:-0}" -gt 500 ] && echo "Postfix kuyrugu: $SAYI mektup" \
  | mail -s "Kuyruk uyarisi" [email protected]

Sıkça Sorulan Sorular#

Postfix kuyruğunda kaç mektup olduğunu nasıl görürüm#

En hızlı yol postqueue -p | tail -1 komutudur; çıktının son satırı toplam mektup sayısını ve kapladıkları alanı verir. Yalnızca sayıyı almak isterseniz postqueue -p | awk '/^-- /{print $5}' kullanabilirsiniz. Kuyruk boşsa çıktı "Mail queue is empty" olur ve bu satır görünmez, script yazarken bu durumu da ele alın.

postsuper -d ALL komutu güvenli mi#

Hayır, geri dönüşü yoktur ve gönderene hiçbir bildirim gitmez. Kuyrukta yalnızca spam olduğundan kesin olarak emin değilseniz kullanmayın. Doğru yöntem, silmek istediğiniz mektupları göndericiye, alıcıya ya da hata mesajına göre süzüp yalnızca o kimlikleri postsuper -d - ile beslemek; öncesinde de wc -l ile kaç mektubun etkileneceğini görmektir.

Kuyrukta bekleyen mektupları nasıl hemen gönderirim#

postqueue -f tüm kuyruğu hemen işlemeye zorlar, postqueue -s ornek.com ise yalnızca o alan adına giden mektupları dener. Ancak mektuplar geçici bir hata yüzünden bekliyorsa ve o hata sürüyorsa zorlamak işe yaramaz; hatta karşı taraf hız sınırı uyguluyorsa durumu kötüleştirir. Önce bekleme gerekçesini okuyun.

Bir mektup kuyrukta ne kadar kalır#

Varsayılan olarak maximal_queue_lifetime süresi kadar, ki bu genellikle beş gündür. Bu sürenin sonunda teslim edilemeyen mektup bounce olarak gönderene döner. postconf maximal_queue_lifetime ile mevcut değeri görebilir, postconf -e ile değiştirebilirsiniz. Süreyi kısaltmak, göndericilerin sorunu daha erken öğrenmesini sağlar.

Kuyruktaki bir mektubun içeriğini nasıl okurum#

postcat -q <kuyruk-kimliği> komutu mektubun zarf bilgilerini, başlıklarını ve gövdesini gösterir. Genellikle postcat -qh ile yalnızca başlıklara bakmak yeterlidir; Received zinciri ve X- başlıkları mektubun kaynağını ortaya çıkarır. Komut root yetkisi ister çünkü kuyruk dosyaları kısıtlı izinlerle saklanır.

Kuyruğu temizledim ama tekrar doluyor, ne yapmalıyım#

Kaynağı kapatmadan kuyruğu temizlemek geçici bir rahatlama sağlar. Önce göndericiye göre dağılıma bakın; tek bir hesap baskınsa şifresini değiştirip oturumları sonlandırın. Kaynak bir web uygulamasıysa postcat -qh çıktısındaki originating script başlığı dosyayı gösterir. Yerel gönderimi kısıtlamak ve kimlik doğrulamalı gönderime zorlamak da kalıcı çözümün parçasıdır.

Kapanış#

Postfix kuyruğu, sunucunuzun o anki sağlık durumunun en dürüst göstergesidir. Aklınızda dört alışkanlık kalsın: müdahale etmeden önce postqueue -p çıktısını gerekçe ve gönderici bazında özetleyin, silmeden önce postsuper -h ile beklemeye alıp postcat ile örnek inceleyin, ALL anahtar kelimesini yalnızca ne yaptığınızdan emin olduğunuzda kullanın ve kuyruk büyüklüğü için basit bir eşik uyarısı kurun. Kuyruk şişmesi çoğu zaman bir sonuçtur; asıl iş sebebi bulup kapatmaktır.

Kendi mail sunucunuzu tam root erişimiyle işletmek isterseniz VDS ve sanal sunucu paketlerimiz uygun bir zemin sunar; Postfix, Dovecot ve Rspamd yığını hazır kurulu gelen SMTP sunucu paketlerimizle kuruluma zaman harcamadan başlayabilirsiniz. Kuyruk izleme, log takibi ve güvenlik güncellemelerini bizim üstlenmemizi isterseniz sunucu yönetimi hizmetimiz bu işleri kapsar.