Postfix ile Greylisting Yapılandırması

Spam ile mücadele söz konusu olduğunda, pek çok sistem yöneticisi kara listeler, içerik filtreleme ve SPF/DKIM doğrulaması gibi yöntemlere başvurur. Ancak bu yöntemlerin yanında, kurulumu oldukça basit ama etkinliği şaşırtıcı derecede yüksek olan bir teknik daha var: Greylisting. Doğru yapılandırıldığında, sunucunuza gelen spam trafiğinin yüzde ellisini ile yüzde seksenini arasında bir kısmını hiçbir içerik analizi yapmadan engelleyebilirsiniz. Bu yazıda Postfix üzerinde greylisting’i adım adım nasıl kuracağınızı, ince ayarlarını nasıl yapacağınızı ve gerçek ortamlarda karşılaşılan sorunları nasıl aşacağınızı anlatacağım.

Greylisting Nedir ve Nasıl Çalışır?

Greylisting, basit ama zekice bir mantığa dayanır. Bir mail sunucusuna ilk kez bağlanan ve daha önce görülmemiş bir gönderici-alıcı-IP üçlüsü ile karşılaşıldığında, sunucu bu e-postayı hemen kabul etmek yerine geçici bir hata kodu döndürür. SMTP protokolünde bu, 451 veya 450 kodlu geçici ret mesajları anlamına gelir.

RFC standartlarına uyan meşru bir mail sunucusu, geçici bir hata aldığında belirli bir süre bekler ve mesajı yeniden göndermeyi dener. Spam botları ise genellikle bu standartlara uymaz; yüksek hacimli spam göndermek için tasarlandıklarından, geçici hata aldıklarında mesajı yeniden denemek yerine bir sonraki hedefe geçerler.

İşte bu fark, greylisting’in temel silahıdır. Sistem şu bilgileri bir veritabanında tutar:

• Gönderici IP adresi
• Gönderici e-posta adresi (MAIL FROM)
• Alıcı e-posta adresi (RCPT TO)

Bu üçlüye “triplet” denir. Bir triplet ilk kez görüldüğünde geçici ret yapılır ve belirli bir bekleme süresi (genellikle 5 dakika ile 30 dakika arası) başlatılır. Bu süre geçtikten sonra aynı triplet tekrar bağlantı kurarsa bu sefer mesaj kabul edilir ve triplet beyaz listeye alınır. Sonraki bağlantılarda artık doğrudan kabul gerçekleşir.

Postgrey: Postfix için Greylisting Daemon’u

Postfix’in kendisi doğrudan greylisting desteği sunmaz. Ancak Postfix’in policy service mekanizması sayesinde harici bir servis üzerinden greylisting kolayca uygulanabilir. Bu iş için en yaygın kullanılan araç Postgrey‘dir.

Postgrey, Perl ile yazılmış, Berkeley DB üzerinde triplet verilerini saklayan hafif bir daemon’dur. Postfix’in smtpd_recipient_restrictions direktifi üzerinden policy check olarak çalışır.

Kurulum

Debian/Ubuntu tabanlı sistemlerde:

apt update
apt install postgrey -y

RHEL/CentOS/AlmaLinux tabanlı sistemlerde (EPEL reposu gerekli):

dnf install epel-release -y
dnf install postgrey -y

Kurulum sonrası servisin durumunu kontrol edin:

systemctl status postgrey
systemctl enable postgrey
systemctl start postgrey

Varsayılan olarak Postgrey, 127.0.0.1:10023 adresinde TCP üzerinden dinler. Bunu doğrulamak için:

ss -tlnp | grep 10023

Çıktıda 127.0.0.1:10023 satırını görüyorsanız Postgrey başarıyla çalışıyor demektir.

Postgrey Yapılandırması

Debian/Ubuntu sistemlerde ana yapılandırma dosyası /etc/default/postgrey yolundadır:

nano /etc/default/postgrey

Dosyanın içeriği şu şekilde görünür:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=300 --max-age=35"

Buradaki parametreleri inceleyelim:

• –inet=127.0.0.1:10023: Postgrey’nin dinleyeceği IP ve port. Sadece yerel bağlantılar için 127.0.0.1 kullanmak güvenlik açısından doğrudur.
• –delay=300: Geçici ret sonrasında beklenmesi gereken süre (saniye cinsinden). 300 saniye yani 5 dakika genellikle yeterlidir.
• –max-age=35: Beyaz listede bir triplet kaç gün boyunca saklanacak. 35 gün sonra hiç mail gelmezse triplet silinir.
• –greylist-text: İstenirse özel bir ret mesajı tanımlanabilir.

Biraz daha sıkı bir yapılandırma istiyorsanız delay değerini artırabilirsiniz, ancak 300 saniyenin üstüne çıkmak meşru posta sunucularında da gecikmeye yol açabileceğinden dikkatli olun:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=300 --max-age=35 --greylist-text=Gecici red: Lutfen birkas dakika sonra tekrar deneyin"

RHEL tabanlı sistemlerde yapılandırma /etc/sysconfig/postgrey dosyasında bulunur:

POSTGREY_OPTS="--inet=127.0.0.1:10023"
POSTGREY_DELAY=300

Değişikliklerden sonra servisi yeniden başlatın:

systemctl restart postgrey

Postfix ile Entegrasyon

Asıl iş burada başlıyor. Postfix’in Postgrey’yi policy servisi olarak kullanması için main.cf dosyasını düzenlememiz gerekiyor.

nano /etc/postfix/main.cf

smtpd_recipient_restrictions direktifini bulun. Eğer yoksa oluşturun. Greylisting kontrolünü permit_sasl_authenticated ve reject_unauth_destination gibi kritik direktiflerin ardına, ancak sona ekleyin:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10023

Buradaki sıra çok önemlidir. permit_mynetworks ve permit_sasl_authenticated direktifleri en başta yer almalıdır; aksi takdirde kendi ağınızdan veya kimliği doğrulanmış kullanıcılardan gelen mailler de greylisting’e takılabilir. reject_unauth_destination ise relay saldırılarını engeller. Greylisting kontrolü en sona gelmelidir çünkü diğer tüm kontrollerden geçen ancak henüz tanınmayan göndericilere uygulanacaktır.

Postfix yapılandırmasını test edin:

postfix check

Hata yoksa Postfix’i yeniden yükleyin:

postfix reload

Beyaz Liste Yönetimi

Greylisting’in en can sıkıcı yanı, bazı meşru servislerin yeniden deneme mekanizması olmayan ya da çok kısa deneme süresi olan posta sunucularını kullanmasıdır. Örneğin bazı e-ticaret platformları, ticket sistemleri veya büyük kurumsal mail sunucuları bu kategoriye girebilir. Bunun için Postgrey’nin beyaz liste mekanizmasını kullanmanız gerekir.

Postgrey iki tür beyaz liste dosyası destekler:

• /etc/postgrey/whitelist_clients: Gönderici IP veya hostname bazlı beyaz liste
• /etc/postgrey/whitelist_recipients: Alıcı adresi bazlı beyaz liste

Beyaz liste dosyasını düzenleyelim:

nano /etc/postgrey/whitelist_clients

Örnek beyaz liste girişleri:

# Gmail sunucuları (büyük havuzları nedeniyle aynı IP'den retry gelmeyebilir)
gmail.com
googlemail.com

# Microsoft/Outlook sunucuları
outlook.com
hotmail.com
microsoft.com

# Belirli bir IP adresi
203.0.113.50

# Belirli bir IP aralığı (CIDR)
198.51.100.0/24

# Regex ile hostname eşleşmesi
/^mail[0-9]+.ornek.com$/

Özellikle Gmail dikkat gerektiren bir durumdur. Google, büyük bir sunucu havuzu kullandığından ilk deneme ile yeniden deneme aynı IP’den gelmeyebilir. Bu nedenle Gmail’i beyaz listeye almak genellikle iyi bir uygulamadır.

Beyaz liste dosyasını güncellediğinizde Postgrey’yi yeniden başlatmanız gerekmez; Postgrey bu dosyaları periyodik olarak yeniden okur. Ancak emin olmak için:

systemctl reload postgrey
# veya
kill -HUP $(cat /var/run/postgrey/postgrey.pid)

Postgrey Veritabanının Yönetimi

Postgrey, triplet verilerini bir Berkeley DB veritabanında saklar. Bu veritabanı zamanla büyüyebilir. Varsayılan veritabanı konumu genellikle /var/lib/postgrey/ dizinindedir.

Veritabanı boyutunu kontrol etmek için:

du -sh /var/lib/postgrey/
ls -lh /var/lib/postgrey/

Postgrey, --max-age parametresine göre eski kayıtları otomatik olarak temizler. Ancak manuel temizlik yapmak isterseniz:

systemctl stop postgrey
rm -f /var/lib/postgrey/postgrey.db
systemctl start postgrey

Dikkat edin: Veritabanını silerseniz tüm beyaz liste bilgileri de silinir. Bir sonraki birkaç saat içinde onaylı gönderenler için de geçici gecikmeler yaşanacaktır.

Mevcut beyaz liste kayıtlarını görüntülemek için postgreyreport aracını kullanabilirsiniz:

# Debian/Ubuntu
apt install postgrey
# postgreyreport genellikle postgrey paketiyle birlikte gelir

postgreyreport --show_tries --nosingle_line < /var/log/mail.log

Log İzleme ve Sorun Giderme

Greylisting’in çalışıp çalışmadığını doğrulamak için mail log dosyasını izleyin:

tail -f /var/log/mail.log | grep -i postgrey

Başarılı bir greylisting işlemi şöyle görünür:

postfix/smtpd[12345]: NOQUEUE: reject: RCPT from unknown[198.51.100.100]: 
450 4.2.0 <[email protected]>: Recipient address rejected: Greylisted, 
see http://postgrey.schweikert.ch/help/domain.com.html; 
from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.disdomain.com>

Bir sonraki denemede beyaz listeye alındığında:

postgrey[9876]: action=greylist, reason=new, client_name=mail.disdomain.com, 
client_address=198.51.100.100, [email protected], 
[email protected]

Ve onaylandıktan sonra:

postgrey[9876]: action=pass, reason=triplet found, 
client_name=mail.disdomain.com, client_address=198.51.100.100

Eğer bağlantı sorunları yaşıyorsanız Postgrey’nin gerçekten çalışıp çalışmadığını elle test edebilirsiniz:

# Postfix policy protokolünü manuel test etmek için
echo -e "request=smtpd_access_policynprotocol_state=RCPTnprotocol_name=ESMTPnclient_address=198.51.100.100nclient_name=test.example.comnsender=test@[email protected]" | nc 127.0.0.1 10023

Bu komut action=greylist veya action=pass gibi bir çıktı üretmelidir.

Gerçek Dünya Senaryoları ve İnce Ayarlar

Senaryo 1: E-ticaret Bildirimleri Gecikmesi

Bir müşteri sitenize üye oldu ve aktivasyon maili gelmiyor diye şikayet ediyor. Bu durum genellikle bazı e-ticaret platformlarının tek kullanımlık sunucular veya IP adresleri kullanmasından kaynaklanır. Bu IP’ler beyaz listede değilse 5 dakikalık gecikme yaşanabilir.

Çözüm olarak, bu tür transaksiyonel mail servisleri için gönderici domain veya IP’yi beyaz listeye ekleyebilirsiniz:

echo "sendgrid.net" >> /etc/postgrey/whitelist_clients
echo "mailgun.org" >> /etc/postgrey/whitelist_clients
echo "amazonses.com" >> /etc/postgrey/whitelist_clients

Senaryo 2: Delay Değerinin Optimizasyonu

5 dakikalık gecikme çoğu ortam için makul olmakla birlikte, kullanıcıların şifremi unuttum maillerinde bile gecikme şikayeti alıyorsanız delay değerini 60 saniyeye düşürebilirsiniz. Spam botlarının çoğu 60 saniye bekleyip tekrar denemeyeceğinden spam engelleme oranınız yine de yüksek kalır:

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60 --max-age=35"

Senaryo 3: Yüksek Hacimli Ortamlarda Performans

Eğer sunucunuz günde yüz binlerce mail alıyorsa Postgrey veritabanı performans sorunu yaratabilir. Bu durumda Unix socket kullanmak TCP’ye göre biraz daha hızlıdır:

POSTGREY_OPTS="--unix=/var/spool/postfix/postgrey/postgrey.sock --delay=300 --max-age=35"

Postfix’te de buna uygun güncelleme yapın:

check_policy_service unix:postgrey/postgrey.sock

Unix socket kullanırken socket dosyasının Postfix chroot ortamında erişilebilir olması gerektiğini unutmayın. Socket’i /var/spool/postfix/postgrey/ altına koymanız bu sorunu çözer.

Senaryo 4: SPF Kaydı Olmayan Gönderenler

Greylisting’i SPF doğrulamasıyla birleştirip SPF kaydı olmayan ama geçerli görünen gönderenler için greylisting uygulamak, SPF kaydı olan ve DKIM imzalı meşru gönderenler içinse daha hızlı kabul sağlamak isteyebilirsiniz. Bu tür gelişmiş konfigürasyon için Postfix’in postscreen modülü ile birlikte çalışmak daha uygun olabilir, ancak temel greylisting için Postgrey yeterlidir.

Milter Tabanlı Alternatif: rspamd ile Greylisting

Postgrey yerine rspamd kullanıyorsanız (ki modern bir mail ortamı için şiddetle tavsiye edilir), greylisting rspamd içinde doğrudan desteklenir. Postfix ile rspamd entegrasyonu milter protokolü üzerinden gerçekleşir.

rspamd greylisting modülünü etkinleştirmek için:

nano /etc/rspamd/local.d/greylisting.conf

enabled = true;
expire = 1d;
timeout = 5min;
whitelist_domains_url = [
  "$LOCAL_CONFDIR/local.d/maps.d/whitelist_greylist.map"
];

rspamd tabanlı greylisting, Postgrey’ye kıyasla daha fazla özellik sunar: içerik skorlamasına göre dinamik greylisting, DKIM imzalı mailleri greylisting’den muaf tutma gibi gelişmiş kurallar tanımlanabilir. Ancak rspamd kurulumu ayrı bir yazının konusu.

Greylisting’in Sınırları ve Dikkat Edilmesi Gerekenler

Greylisting her derde deva değildir. Bazı önemli sınırları ve dikkat noktaları var:

• Büyük botnet’ler: Milyonlarca IP’ye sahip büyük botnet operatörleri, greylisting delay süresi geçtikten sonra farklı bir IP’den tekrar deneyebilir. Bu durumda greylisting etkisizdir.
• Meşru posta gecikmesi: İlk kez bir adresten mail alan kullanıcılar en az 5 dakika (veya belirlediğiniz delay süresi kadar) beklemek zorunda kalır.
• Retry mekanizması olmayan sistemler: Bazı kötü yazılmış mail sistemleri geçici hata alınca kalıcı ret olarak yorumlar ve yeniden denemez. Bu nadir ama gerçek bir sorundur.
• SPF ile çakışma sorunu: Bazı gönderenler SPF include zinciri aracılığıyla farklı IP’lerden gönderim yapabilir. İlk deneme ile retry farklı IP üzerinden gelirse triplet eşleşmez ve mail sürekli reddedilebilir.

Bu sınırları göz önünde bulundurarak greylisting’i katmanlı bir güvenlik stratejisinin parçası olarak konumlandırın; tek başına yeterli bir çözüm olarak değil.

Greylisting Etkinliğini Ölçmek

Bir hafta sonra greylisting’in ne kadar etkili olduğunu ölçmek için log analizi yapın:

grep "action=greylist" /var/log/mail.log | wc -l
grep "action=pass" /var/log/mail.log | wc -l
grep "action=whitelist" /var/log/mail.log | wc -l

Daha detaylı analiz için:

grep "postgrey" /var/log/mail.log | awk '{print $6}' | sort | uniq -c | sort -rn | head -20

Tipik bir ortamda greylisting’e takılan maillerin yüzde otuzundan fazlasının ikinci deneme yapmadığını göreceksiniz. Bu, hiçbir içerik analizi yapmadan engellenen spam demektir.

Sonuç

Postfix üzerinde Postgrey ile greylisting yapılandırmak, sistem kaynaklarına etkisi minimal olan, bakımı kolay ve son derece etkili bir spam önleme katmanıdır. Kurulum süreci basit olsa da asıl değeri beyaz liste yönetimi ve log izleme süreçlerinde gösteriyor kendini. Gmail, Microsoft gibi büyük sağlayıcıları baştan beyaz listeye almak, yüzde doksan oranında meşru mail gecikmesi şikayetini önler. Delay değerini 60-300 saniye arasında tutmak ise spam engelleme etkinliğini yüksek tutarken kullanıcı deneyimini de makul bir seviyede korur.

Greylisting’i SPF/DKIM doğrulaması, SpamAssassin veya rspamd gibi içerik filtreleriyle birlikte kullandığınızda, sunucunuza ulaşan spam miktarını ciddi ölçüde azaltabilirsiniz. Tek başına mucizevi bir çözüm beklemeyin, ama katmanlı savunma stratejinizin olmazsa olmaz bir parçası olarak mutlaka dahil edin.