Greylisting Kaynaklı Mail Gecikme Sorunları ve Çözüm Yöntemleri

Bykomut

Mail sunucunuza gelen bir e-posta neden 15-20 dakika geç ulaşıyor? Müşteriler şikayet ediyor, patronunuz kafayı yiyor ve siz log dosyalarına bakıp “her şey normal görünüyor” diyorsunuz. İşte tam bu noktada greylisting devreye giriyor ve çoğu sysadmin’in gözden kaçırdığı klasik bir tuzağa düşüyorsunuz.

Greylisting, spam’e karşı oldukça etkili bir yöntem. Ama yanlış yapılandırıldığında meşru mailleri dakikalarca, hatta saatlerce geciktirebiliyor. Bu yazıda greylisting kaynaklı gecikmeleri nasıl tespit edeceğinizi, log dosyalarında nelere bakmanız gerektiğini ve sorunu nasıl çözeceğinizi adım adım anlatacağım.

Greylisting Nedir ve Neden Sorun Çıkarır?

Greylisting’in mantığı basit: Gelen bir bağlantıyı ilk seferinde reddedip “şu kadar sonra tekrar dene” diyorsunuz. Meşru mail sunucuları bu reddi görüp belirli bir süre sonra tekrar deneyecektir. Spam botları ise genellikle bu zahmete katlanmaz.

Üçlü anahtar kavramı burada kritik: gönderen IP, gönderen adres ve alıcı adres kombinasyonu. Bu üçlü ilk kez görüldüğünde sunucu geçici olarak reddeder. Kombinasyon daha önce görüldüyse ve bekleme süresi geçtiyse, mail kabul edilir.

Sorun şu: Bazı büyük mail altyapıları farklı IP’lerden retry yapıyor. Google, Microsoft, Amazon SES gibi servisler, ilk gönderimi yapan sunucuyla aynı IP’den retry yapmayabiliyor. Bu durumda greylisting sizi sürekli döngüye sokuyor.

Semptomlar ve İlk Teşhis

Greylisting kaynaklı gecikmeyi diğer sorunlardan ayırt etmek için şu belirtilere bakın:

  • Maillar hiç kaybolmuyor ama 15 dakika ile 2 saat arasında gecikiyor
  • Sorun belirli gönderenlerden gelen maillerde yoğunlaşıyor
  • Log’larda “450” veya “421” hata kodları görünüyor
  • Gönderen taraf “geçici red” mesajı aldıklarını söylüyor
  • Sabah ilk saatlerde gelen mailler daha geç ulaşıyor (düşük traffic dönemlerinde retry süreleri uzuyor)

İlk teşhis için mail log’larına bakalım. Postfix kullananlar için:

grep "450|421|greyli" /var/log/mail.log | tail -50

Eximde durum biraz farklı:

grep "temporarily rejected|greylist" /var/log/exim4/mainlog | tail -50

Tipik bir greylisting logu şöyle görünür:

tail -f /var/log/mail.log | grep -E "450|Greylisted|greylist"
# Çıktı örneği:
# Oct 15 09:23:11 mailsrv postfix/smtpd[12345]: NOQUEUE: reject: RCPT from 
# mail-yw1-f172.google.com[209.85.161.172]: 450 4.2.0 
# <[email protected]>: Recipient address rejected: Greylisted

Log Analizi: Nereden Bakmalısınız?

Postfix ile Greylisting Tespiti

Postfix genellikle Postgrey veya SQLgrey ile birlikte çalışır. Önce hangi greylisting yazılımının kullanıldığını tespit edin:

ps aux | grep -E "postgrey|sqlgrey|milter-greylist"

Postgrey kullanılıyorsa özel log’a bakın:

# Postgrey varsayılan log konumu
tail -100 /var/log/mail.log | grep postgrey

# Ya da journald kullanıyorsanız
journalctl -u postgrey -n 100 --no-pager

Belirli bir göndericinin greylisting durumunu kontrol etmek için:

grep "209.85.161.172" /var/log/mail.log | grep -E "greyli|passed|updated" | tail -20

Bu çıktıda şunları arayın:

  • greylisted: İlk kez görülen bağlantı, geçici olarak reddedildi
  • passed: Bekleme süresi doldu, mail kabul edildi
  • updated: Mevcut kayıt güncellendi

Gecikme Süresini Hesaplama

Bir mailin ne kadar bekletildiğini anlamak için log üzerinde basit bir analiz yapabilirsiniz:

# Belirli bir gönderici için greylisted ve passed zamanlarını bul
grep "209.85.161.172" /var/log/mail.log | grep -E "greylisted|passed" | awk '{print $1, $2, $3, $NF}'

Ya da daha kapsamlı bir analiz için:

# Son 1 saatte greylisting nedeniyle geciken maillerin sayısı
awk '/greylisted/{count++} END{print "Greylisted count:", count}' /var/log/mail.log

# Hangi IP'lerden en çok greylisting yaşandığını bul
grep "greylisted" /var/log/mail.log | grep -oP 'd+.d+.d+.d+' | sort | uniq -c | sort -rn | head -20

Postgrey Yapılandırması ve Bekleme Sürelerini Ayarlama

Postgrey’in varsayılan bekleme süresi 300 saniye (5 dakika). Ama pratikte çoğu mail sunucusu 10-15 dakikada retry yaptığı için bu süre sorun çıkarmıyor. Asıl sorun delay süresinin çok uzun ayarlanması ya da whitelist’lerin güncellenmemiş olması.

Postgrey konfigürasyonunu kontrol edin:

cat /etc/default/postgrey
# Ya da
systemctl cat postgrey | grep -i delay

Tipik bir postgrey başlatma parametresi:

POSTGREY_OPTS="--inet=10023 --delay=300 --max-age=35 --retry-window=2"

Bu parametreleri açıklayalım:

  • –delay=300: İlk redden sonra kaç saniye bekleneceği (5 dakika)
  • –max-age=35: Veritabanındaki kayıtlar kaç gün sonra silinecek
  • –retry-window=2: Kaç günlük pencerede retry sayılacak
  • –greylist-action=DEFER_IF_PERMIT: Greylisting aksiyonu

Bekleme süresini düşürmek için:

# /etc/default/postgrey dosyasını düzenle
POSTGREY_OPTS="--inet=10023 --delay=60 --max-age=35"

# Servisi yeniden başlat
systemctl restart postgrey

Dikkat: Delay’i çok düşürürseniz greylisting’in spam filtreleme etkinliği azalır. 60-120 saniye makul bir denge noktasıdır.

Whitelist Yönetimi: Kalıcı Çözüm

Gecikme sorununu kökten çözmek için sık iletişim kurduğunuz gönderenleri whitelist’e eklemeniz gerekiyor. Postgrey için whitelist dosyaları genellikle şu konumlarda bulunur:

ls -la /etc/postgrey/
# whitelist_clients.local  - IP/hostname bazlı
# whitelist_recipients.local - alıcı bazlı

Whitelist’e eklemek için:

# /etc/postgrey/whitelist_clients.local dosyasını düzenle
echo "mail.partnerfirma.com" >> /etc/postgrey/whitelist_clients.local
echo "209.85.161.0/24" >> /etc/postgrey/whitelist_clients.local  # Google IP bloğu
echo "/.google.com$/" >> /etc/postgrey/whitelist_clients.local  # Regex ile

# Değişikliği uygula
systemctl reload postgrey

Büyük mail servislerini toplu whitelist’e almak için hazır listeleri kullanabilirsiniz:

# Postgrey'in kendi whitelist'ini güncelle
cd /tmp
wget https://postgrey.schweikert.ch/pub/postgrey_whitelist_clients
diff /etc/postgrey/whitelist_clients /tmp/postgrey_whitelist_clients
# Farkları inceleyip uygun bulduklarınızı ekleyin

Veritabanı Temizliği ve Yeniden Yapılanma

Postgrey BerkeleyDB kullanıyor ve zaman içinde bu veritabanı şişebiliyor. Şişmiş bir DB hem performans sorunlarına hem de beklenmedik gecikmelere yol açabiliyor:

# Postgrey DB boyutunu kontrol et
ls -lh /var/lib/postgrey/

# Servisi durdur ve DB'yi temizle
systemctl stop postgrey
cd /var/lib/postgrey/
db_dump greylist.db | head -20  # İçeriğe bak

# Eski kayıtları temizlemek için postgrey'i --max-age ile yeniden başlat
systemctl start postgrey

# Belirli bir IP'nin greylisting kaydını manuel sil (acil durumlarda)
postgreyreport --nosync 2>/dev/null | grep "209.85.161" | head -10

SQLgrey kullanıyorsanız durum biraz farklı. MySQL/PostgreSQL tabanlı olduğu için sorgulama daha kolay:

# SQLgrey MySQL veritabanına bağlan
mysql -u sqlgrey -p sqlgrey

# Belirli bir göndericinin kaydını sorgula
SELECT * FROM greylist WHERE sender_domain = 'google.com' LIMIT 10;

# El ile whitelist'e ekle
INSERT INTO sender_domain_whitelist (sender, create_time) VALUES ('google.com', UNIX_TIMESTAMP());

# Eski greylisting kayıtlarını temizle (30 günden eski)
DELETE FROM greylist WHERE record_expires < UNIX_TIMESTAMP() - 2592000;

Gerçek Dünya Senaryosu: Microsoft 365 Kaynaklı Gecikmeler

En sık karşılaşılan senaryo Microsoft 365 gönderimlerindeki gecikmeler. Microsoft farklı IP bloklarından retry yapıyor ve bu durum greylisting ile klasik bir çatışmaya yol açıyor.

Önce Microsoft’un kullandığı IP bloklarını tespit edin:

# Log'larda Microsoft IP'lerini bul
grep "outlook.com|hotmail.com|microsoft.com" /var/log/mail.log | grep "greylisted" | grep -oP 'd+.d+.d+.d+' | sort -u

Microsoft’un tüm mail IP bloklarını SPF kaydından çekebilirsiniz:

# Microsoft SPF lookup
dig TXT spf.protection.outlook.com +short
nslookup -type=TXT spf.protection.outlook.com 8.8.8.8

# include referanslarını takip et
dig TXT _spf-a.microsoft.com +short
dig TXT _spf-b.microsoft.com +short
dig TXT _spf-c.microsoft.com +short

Bu IP bloklarını whitelist_clients.local dosyasına ekleyin:

# Microsoft 365 IP bloklarını whitelist'e ekle
cat >> /etc/postgrey/whitelist_clients.local << 'EOF'
# Microsoft 365 / Exchange Online
/.outlook.com$/
/.hotmail.com$/
/.microsoft.com$/
40.92.0.0/15
40.107.0.0/16
52.100.0.0/14
104.47.0.0/17
EOF

systemctl reload postgrey

SPF ve DKIM ile Greylisting Bypass

Modern greylisting implementasyonları SPF ve DKIM doğrulamasını geçen mailleri otomatik olarak bypass edebiliyor. Bu özelliği aktif etmek hem güvenliği korur hem de gecikmeleri azaltır.

Postfix + Postgrey + SPF kombinasyonu için:

# /etc/postfix/main.cf içinde policy servislerinin sıralamasını kontrol et
cat /etc/postfix/main.cf | grep "smtpd_recipient_restrictions"

# SPF check BAŞARILI ise greylisting'i atla
# Bu yapılandırma check_policy_service'dan ÖNCE SPF kontrolü yapıyor
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_client_access hash:/etc/postfix/spf_bypass,
    check_policy_service inet:127.0.0.1:10023

Milter-greylist kullanıyorsanız DKIM bypass çok daha kolay:

# /etc/milter-greylist/greylist.conf
racl whitelist dkim on
racl whitelist spf pass

Monitoring: Greylisting Metriklerini Takip Etme

Sorunun tekrarlamasını önlemek için düzenli izleme şart. Basit bir monitoring scripti yazalım:

#!/bin/bash
# /usr/local/bin/check_greylisting.sh

LOG_FILE="/var/log/mail.log"
THRESHOLD=50  # Saatte bu kadardan fazla greylisting uyarı ver
MAIL_TO="[email protected]"

# Son 1 saatteki greylisting sayısını hesapla
CURRENT_HOUR=$(date "+%b %e %H")
GREYLIST_COUNT=$(grep "$CURRENT_HOUR" "$LOG_FILE" | grep -c "greylisted")

echo "Greylisting count (last hour): $GREYLIST_COUNT"

if [ "$GREYLIST_COUNT" -gt "$THRESHOLD" ]; then
    echo "UYARI: Son 1 saatte $GREYLIST_COUNT greylisting tespit edildi!" | 
    mail -s "Greylisting Uyarisi - $(hostname)" "$MAIL_TO"
    
    # En çok greylisting yaşanan IP'leri logla
    grep "$CURRENT_HOUR" "$LOG_FILE" | grep "greylisted" | 
    grep -oP 'd+.d+.d+.d+' | sort | uniq -c | sort -rn | head -10 >> 
    /var/log/greylisting_report.log
fi

Bu scripti cron’a ekleyin:

chmod +x /usr/local/bin/check_greylisting.sh
echo "0 * * * * root /usr/local/bin/check_greylisting.sh" >> /etc/cron.d/greylisting-check

Greylisting’i Tamamen Devre Dışı Bırakmak Ne Zaman Mantıklı?

Bazı durumlarda greylisting’i tamamen kapatmak doğru karar olabilir:

  • Transactional mail altyapısı işletiyorsanız (kargo bildirimleri, banka otpları vs.)
  • Müşterilerinizin büyük çoğunluğu Microsoft 365 veya Google Workspace kullanıyorsa
  • Başka spam filtreleme mekanizmalarınız yeterliyse (SpamAssassin, Rspamd, harici filtre)
  • SLA gereksinimleriniz var ve mail gecikmeleri kabul edilemiyorsa

Postgrey’i devre dışı bırakmak için:

# Postfix main.cf'den policy servisini kaldır
# check_policy_service inet:127.0.0.1:10023 satırını comment'la

postconf smtpd_recipient_restrictions
# Mevcut konfigürasyonu gör, sonra düzenle
vi /etc/postfix/main.cf

# Postgrey servisini durdur ve disable et
systemctl stop postgrey
systemctl disable postgrey

# Postfix'i yeniden yükle
postfix reload

Rspamd ile Modern Yaklaşım

Eğer Rspamd kullanıyorsanız, onun dahili greylisting modülü çok daha akıllı çalışıyor. SPF, DKIM, reputasyon ve puan bazlı greylisting yapabiliyor:

# Rspamd greylisting konfigürasyonu
cat /etc/rspamd/local.d/greylisting.conf

# Tipik yapılandırma örneği
cat > /etc/rspamd/local.d/greylisting.conf << 'EOF'
enabled = true;
expire = 86400;  # 24 saat
timeout = 300;   # 5 dakika bekleme
greylist_min_score = 5.0;  # Sadece şüpheli mailleri greylist'e al
whitelist_domains_url = "https://maps.rspamd.com/rspamd/whitelist.inc.zst";
EOF

systemctl reload rspamd

Rspamd’da greylisting istatistiklerini görmek için:

rspamc stat | grep -i grey
rspamadm control stat | grep greylist

Sorun Giderme Kontrol Listesi

Greylisting sorunuyla karşılaştığınızda şu adımları takip edin:

  • Adım 1: Log’larda 450/421 hata kodlarını ve “greylisted” ifadesini arayın
  • Adım 2: Hanyin IP’lerin en çok greylisting yaşadığını tespit edin
  • Adım 3: Bu IP’lerin meşru mail servislere ait olup olmadığını doğrulayın (rDNS, SPF)
  • Adım 4: Meşru servisler için whitelist’e ekleyin
  • Adım 5: Delay süresini gözden geçirin, gerekirse düşürün
  • Adım 6: Postgrey/SQLgrey veritabanının sağlıklı olduğunu kontrol edin
  • Adım 7: Monitoring ekleyin ve düzenli rapor alın

Sonuç

Greylisting hala spam’e karşı etkili bir silah, ama modern mail altyapılarının dağıtık yapısı bu mekanizmayı zaman zaman sorunlu hale getiriyor. Microsoft 365, Google Workspace gibi büyük servisler farklı IP’lerden retry yaparken sizi sürekli döngüye sokabilir.

Çözüm, greylisting’i körü körüne kapatmak değil, akıllıca yapılandırmak. Whitelist’lerinizi güncel tutun, delay sürelerini makul seviyelere çekin, SPF/DKIM bypass özelliklerini aktif edin ve düzenli monitoring yapın. Rspamd gibi modern alternatifler, puan bazlı greylisting ile çok daha seçici davranmanıza olanak tanıyor.

Mail gecikme şikayetleri sysadmin hayatının kaçınılmaz bir parçası. Ama bu yazıdaki araçlar ve yöntemlerle en azından greylisting kaynaklı sorunları hızla tespit edip çözebileceksiniz. Log’larınız temiz, maillerin yolculuğu hızlı olsun.

Benzer Konular

Bir yanıt yazın

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