Deneyiminizi geliştirmek için çerezler kullanıyoruz. Bu siteyi ziyaret etmeye devam ederek çerez kullanımımızı kabul etmiş olursunuz.Gizlilik Politikası
Yanlış Pozitif Üretmeden Greylisting: rspamd greylist Modülünü Doğru Ayarlamak
Greylisting'in kötü şöhreti kavramın kendisinden değil, yanlış konumlandırılmış eşiklerden geliyor. rspamd'nin gövde-hash tabanlı greylist modülünü, OTP ve şifre-sıfırlama postalarını hiç geciktirmeden yalnızca şüpheli trafiği bekletecek şekilde nasıl kurgulayacağınızı adım adım anlatıyoruz.
EvilMail Team22 Temmuz 202610 dk okuma
"OTP kodu 6 dakika sonra geldi, o zamana kadar oturum zaman aşımına uğramıştı." Bu tek cümle, bir greylisting kurulumunun yanlış yapıldığının en net kanıtıdır. Ve neredeyse her seferinde suçlanan yanlış taraftır: greylisting.
Klasik yanlış pozitiflerin gerçek kaynağı eski Postgrey mantığıdır. Postgrey gelen her postayı (IP, envelope-from, envelope-to) üçlüsüyle hafızada tutar; ilk denemede 451 döner, gönderici RFC'ye uygun şekilde tekrar dener ve geçer. Sorun şurada: Google, Microsoft 365 ve Amazon SES gibi büyük sağlayıcılar retry'ı farklı bir IP adresinden yapar. Üçlünün IP bileşeni değişir, eşleşme tutmaz, posta yeniden bekletilir — ve bazı durumlarda saatlerce bu döngüde salınır. Gerçek yanlış pozitif tam olarak budur.
rspamd bu problemi tasarımdan çözer. Tezimiz de net: greylisting yanlış pozitif üretmez; kötü ayarlanmış eşikler ve eksik beyaz listeler üretir. Aşağıda modülü bir "aç/kapat" anahtarı gibi değil, skor tabanlı bir filtre gibi kurarak bunu göstereceğiz.
rspamd greylist modülü IP saklamaz. Redis'te tuttuğu anahtar üç parçadan oluşur: key_prefix (varsayılan rg
rspamd Greylisting: Yanlış Pozitif Üretmeden Kurulum (2026) — EvilMail Blog
) + mesaj gövdesinin hash'i (
body_digest
) + alıcı. Yani bir postayı benzersiz kılan şey, onu gönderen sunucunun adresi değil, taşıdığı içeriktir.
Bu tercih Postgrey'in en büyük derdini doğrudan ortadan kaldırır: retry farklı bir IP'den gelse bile gövde aynı olduğu için hash eşleşir ve posta geçer. Google'ın onlarca çıkış sunucusundan hangisi retry yaparsa yapsın rspamd için hiçbir fark yoktur.
Modül iki aşamada çalışır. Prefilter aşamasında rspamd "bu gövde-hash + alıcı daha önce görüldü mü?" kontrolünü yapar. Postfilter aşamasında ise nihai eylem kararını verir; yani greylist kararı, gövde ilk okunduğunda değil, skorlama tamamlandıktan sonra alınır. Bu ayrım kritik, çünkü greylisting'i skora bağlamamızı mümkün kılan şey tam olarak budur.
Bir ayrıntı: max_data_len = 10k. rspamd gövdenin tamamını değil, ilk 10 KB'ını hash'ler. Bu bilinçli bir tercihtir. Büyük ekli postalarda MTA'lar retry sırasında kodlamayı ya da satır sonlarını hafifçe değiştirebilir; tüm gövdeyi hash'leseydiniz aynı posta "farklı" görünür ve sonsuza dek bekletilirdi. İlk 10 KB, tutarlılık ile ayırt edicilik arasındaki pratik dengedir.
Sadece şüpheli postayı geciktir: greylist eylem eşiği
Asıl kaldıraç burada. rspamd'de greylist, add_header, reject gibi eylemler metric skoruna bağlı aksiyonlardır. Bir postanın skoru greylist eşiğinin altındaysa o posta hiçbir zaman geciktirilmez, doğrudan kabul edilir. Yalnızca skoru "şüpheli bölge"ye düşen posta bekletilir.
SPF geçen, DKIM imzalı, kimlik doğrulamalı, temiz reputasyonlu bir OTP postasının skoru zaten çok düşüktür. Bu posta greylist eşiğinin çok altında kalır ve saniyeler içinde teslim edilir. Botnet'ten gelen, SPF'i sallantılı, imzasız, karanlık IP'li posta ise şüpheli bölgeye düşer ve 451 yer.
Eşikleri /etc/rspamd/local.d/actions.conf ile kademelendirin:
Çoğu kurulumun hatası, greylist eşiğinin gereğinden agresif bırakılmasıdır. Pratikte greylist değerini reject'ten belirgin biçimde düşük, ama add_header'a yakın tutun. 4-6 bandı çoğu üretim sunucusu için isabetli bir başlangıçtır: gerçekten şüpheli postayı yakalar, sınırdaki meşru postayı boğmaz.
Ana yapılandırma: greylist.conf
Modülün kalbi /etc/rspamd/local.d/greylist.conf. Tam bir üretim bloğu:
hcl
# /etc/rspamd/local.d/greylist.conf
servers = "127.0.0.1:6379";
expire = 1d;
timeout = 5min;
key_prefix = "rg";
max_data_len = 10k;
message = "Greylisted, please try again later";
symbol = "GREYLIST";
# Retry davranışı düzensiz ESP'ler için resmi map
whitelist_domains_url = [
"https://maps.rspamd.com/rspamd/greylist_whitelist_domains.inc.zst"
];
Alanların anlamı şu: timeout, ilk denemeden sonra postanın bekletileceği süredir. Varsayılan 5min'dir; işlemsel SLA'nız sıkıysa 3min'e çekebilirsiniz — çoğu meşru MTA ilk retry'ı 1-5 dakika içinde yapar. expire, greylist kaydının Redis'te ne kadar yaşayacağıdır; 1d, aynı gönderici 24 saat içinde bir kez daha yazışırsa hiç bekletilmez demektir.
Altını çizerek bir uyarı: Redis erişilemezse greylist modülü hiçbir postayı greylist'leyemez. Bağlantı hatası rspamd loguna düşer, ama posta akışı durmadığı için bu sorun kolayca gözden kaçar. Kurulumdan sonra Redis'in ayakta olduğunu ve kayıtların gerçekten yazıldığını doğrulayın:
bash
redis-cli -n 0 --scan --pattern "rg*"
# örnek çıktı:
# rgh...9f2a <- gövde-hash kaydı
# rgm...bd10 <- meta kaydı
Bu komut boş dönüyorsa iki ihtimal var: ya trafik borderline bölgeye hiç düşmüyordur (iyi haber) ya da modül devrede değildir (kötü haber). Ayrımı rspamadm configdump greylist ile netleştirirsiniz.
Yanlış pozitifi sıfıra indiren beyaz listeler
Skor tabanlı yaklaşım işin yarısı. Diğer yarısı, belirli trafiği greylist mantığının tamamen dışında tutmaktır. Üç katman:
1. Kimlik doğrulamalı kullanıcılar. Kendi kullanıcılarınız SMTP AUTH ile gönderim yapıyorsa onları greylist'lemek anlamsızdır — zaten güvendiğiniz taraf. /etc/rspamd/local.d/settings.conf:
greylist = null, bu profil için greylist eylemini tamamen kaldırır.
2. SPF + DKIM + DMARC geçen postalar. Bunları doğrudan muaf tutmak yerine whitelist modülüyle skorlarını düşürün. Skoru düşen posta zaten greylist eşiğinin (4) altında kalır ve dolaylı olarak, geciktirilmeden geçer. Bu, sert bir bypass'tan daha güvenlidir: kimlik doğrulama gerçekten geçtiği sürece çalışır, sahtecilik durumunda skor tekrar yükselir ve muafiyet kendiliğinden kalkar.
3. IP/domain map. Bazı büyük gönderici platformları — Amazon SES, Mailchimp, PayPal — RFC 5321'e rağmen düzgün retry yapmaz ya da retry aralıkları saatleri bulur. Bunları beklemeye almak doğrudan yanlış pozitif demektir. Yukarıdaki whitelist_domains_url satırı rspamd'nin resmi greylist_whitelist_domains listesini yükler; bu liste tam da bu "retry davranışı düzensiz" göndericileri kapsar. Kendi güvendiğiniz IP'leri de ekleyin:
hcl
# greylist.conf içinde, whitelisted_ip haritası
whitelisted_ip = "/etc/rspamd/local.d/greylist_ip.map";
Bu map olmadan bir kampanya sağlayıcısının transactional postası günde bir-iki kez takılır ve teşhisi en zor şikayeti üretir: "ara sıra gelmiyor."
İşlemsel postayı koru: OTP/reset istisnaları
2026 gerçeği şu: greylisting'in tek anlamlı yanlış pozitif riski gecikmeye duyarlı postalardır. OTP, şifre sıfırlama, 2FA doğrulama, "giriş yapıldı" bildirimleri — bunlar 30 saniye içinde ulaşmazsa iş akışı kırılır.
İki yönü ayrı ele alın. Giden tarafta kendi transactional postalarınız SMTP AUTH ile çıktığı için yukarıdaki authenticated istisnası onları zaten korur. Gelen tarafta ise — örneğin geçici e-posta kutularına düşen OTP'ler — greylist eşiğini bu trafik profiline göre kalibre etmeniz gerekir. Bu postalar genelde büyük, iyi reputasyonlu ESP'lerden gelir; whitelist domain map'i ve düşük skorları sayesinde eşiğin altında kalır.
Yine de canlıda bir hafta boyunca greylist'lenen alıcıların örneklemini inceleyin: aralarında bir bankanın veya bir 2FA sağlayıcısının domain'i varsa onu doğrudan map'e ekleyin. Eşiği kör bir şekilde yükseltmek yerine cerrahi istisna koymak, spam korumasını feda etmeden sorunu çözer.
Doğrulama ve izleme
Kurdunuz; şimdi hem çalıştığını hem de fazla agresif olmadığını kanıtlayın.
Aktif yapılandırmayı görün:
bash
rspamadm configdump greylist
Loglarda GREYLIST sembolünü ve soft reject sayımını izleyin:
En önemli metrik geciktirme oranıdır: gelen postanın yüzde kaçı greylist'e takılıyor? Sağlıklı bir sunucuda bu oran yaklaşık %5-15 bandındadır. Çok üstündeyseniz eşiğiniz fazla agresiftir, meşru postayı boğuyorsunuzdur; greylist değerini yukarı çekin veya whitelist katmanlarını genişletin. Neredeyse %0 ise ya trafiğiniz zaten temizdir ya da modül devrede değildir — ikincisini configdump ile eleyin.
Pratik kontrol listesi
Redis ayakta ve redis-cli --scan --pattern "rg*" gerçek kayıt döndürüyor mu?
