Postfix'te Gönderim Hız Limiti Ayarlama

Bir posta hesabının şifresi ele geçirildiğinde ilk fark ettiğiniz şey genellikle kuyrukta biriken on binlerce mesaj olur — ve o noktaya geldiğinizde IP itibarınız çoktan yanmıştır. Postfix'te gönderim hız limiti, tam olarak bu birkaç saatlik pencereyi kapatmak için vardır: hesap ele geçirilse bile saldırgan dakikada beş mesaj gönderebiliyorsa, siz sorunu fark edene kadar zarar sınırlı kalır. Aynı mekanizma, büyük sağlayıcılara çok hızlı gönderim yaptığınızda yediğiniz geçici ret ("421 4.7.0 Try again later") duvarını aşmak için de kullanılır.

Bu yazıda Postfix'te hız kontrolünün üç ayrı katmanda çalıştığını göstereceğim: bağlantı kuran istemciyi sınırlayan anvil sayaçları, kullanıcı başına kota koyan harici politika servisleri, ve alıcı sunucuya göre teslimatı yavaşlatan hedef bazlı ayarlar. Her katmanın hangi soruna çare olduğunu, hangisinin sizin sorununuza çare olmadığını, gerçek yapılandırma satırlarını ve sınıra takılan mesajlara ne olduğunu ayrıntısıyla anlatacağım.

Hız Sınırı Hangi Sorunu Çözer#

Aynı isimle anılan ama tamamen farklı üç ihtiyaç var; hangisini çözmek istediğinizi baştan netleştirmezseniz yanlış parametreyi ayarlayıp sonuç alamazsınız.

Bu ayrımın en kritik sonucu şudur: anvil sayaçları IP adresi başına çalışır, SASL kullanıcı adı başına değil. Yani ele geçirilmiş bir hesabı farklı IP'lerden kullanan bir saldırgan, anvil limitlerinin altından rahatça geçer. Bu yüzden hesap bazlı koruma isteyen herkesin harici bir politika servisine ihtiyacı vardır. Bu ayrımı bilmemek, "limit koydum ama yine spam çıktı" şikâyetinin bir numaralı sebebidir.

İkinci önemli nokta, hız sınırının bir güvenlik önlemi değil bir zarar sınırlama aracı olmasıdır. Sınır, şifresi çalınmış hesabı geri getirmez ve saldırganı sunucudan atmaz; yalnızca birim zamanda çıkabilecek mesaj sayısını düşürerek size fark etme süresi kazandırır. Bu yüzden hız limitini her zaman bir uyarı mekanizmasıyla birlikte kurun: tavan dolduğunda üretilen 450 yanıtları loglara düşer ve bunları izlemiyorsanız korumanın yarısını kullanmıyorsunuz demektir.

Üçüncüsü, sınırların gönderim yönüne göre değiştiğidir. Dışarıdan gelen postayı sınırlamak (gelen kutunuzu bot yükünden korumak) ile kendi kullanıcılarınızın dışarı gönderimini sınırlamak farklı parametrelerle yapılır ve karıştırıldığında sonuç ters olur: gelen tarafa koyduğunuz sıkı bir tavan meşru gönderenleri geciktirirken, giden tarafta hiç tavan olmadığı için asıl korkulan senaryo hâlâ açıktadır. Aşağıdaki katmanları okurken her parametrenin hangi yönü etkilediğine dikkat edin.

Anvil: İstemci Bazlı Sınırlar#

Postfix'in anvil bileşeni, bağlantı kuran her istemci IP'si için sayaç tutar ve belirlediğiniz tavanı aşanı geçici olarak reddeder. Mevcut değerleri görmek için önce varsayılanlara bakın:

# Varsayilan degerleri gor
postconf -d | grep -E 'smtpd_client_(connection|message|recipient|new_tls)'
postconf -d anvil_rate_time_unit

# Sizin sunucunuzda etkin olan degerler
postconf -n | grep -E 'smtpd_client_|anvil'

Postfix varsayılanında bu sayaçların çoğu 0, yani sınırsızdır; bağlantı sayısı dışında hiçbir tavan yoktur. Makul bir başlangıç seti şöyle:

# /etc/postfix/main.cf

# Sayac penceresi (varsayilan 60 saniye)
anvil_rate_time_unit = 60s

# Ayni IP'den es zamanli acik baglanti sayisi
smtpd_client_connection_count_limit = 20

# Ayni IP'den dakikada acilabilecek yeni baglanti sayisi
smtpd_client_connection_rate_limit = 30

# Ayni IP'den dakikada gonderilebilecek MESAJ sayisi
smtpd_client_message_rate_limit = 30

# Ayni IP'den dakikada adreslenebilecek ALICI sayisi
smtpd_client_recipient_rate_limit = 100

# Ayni IP'den dakikada kurulabilecek yeni TLS oturumu
smtpd_client_new_tls_session_rate_limit = 30

# Bu sayaclardan muaf tutulacaklar (varsayilan: mynetworks)
smtpd_client_event_limit_exceptions = $mynetworks

# Tek mesajda kabul edilecek azami alici sayisi (varsayilan 1000)
smtpd_recipient_limit = 200

sudo postfix check && sudo systemctl reload postfix

Sayıları seçerken kendi trafiğinize bakın. Bir ofis, tek bir NAT arkasından çıkıyorsa o ofisteki tüm kullanıcılar sunucuya aynı IP ile görünür; dakikada 30 mesaj sınırı yoğun bir gün ortasında meşru gönderimi bloklayabilir. smtpd_client_event_limit_exceptions ile bilinen ofis IP'lerinizi muaf tutabilirsiniz, ama bunu yaparken o IP'nin gerçekten sizin kontrolünüzde olduğundan emin olun — muafiyet listesi, open relay testi ve kapatma yazısında anlattığım mynetworks şişmesiyle aynı riski taşır.

Kullanıcı Başına Kota: postfwd ile#

Asıl koruma budur. postfwd, Postfix'in politika delegasyonu arayüzüne bağlanan hafif bir servistir ve SASL kullanıcı adı, gönderen adresi, alıcı alan adı gibi kriterlere göre kural yazmanıza izin verir. Kurulum ve temel yapılandırma şöyle işler:

sudo apt install -y postfwd
sudo systemctl enable --now postfwd

# /etc/postfix/main.cf
# Politika servisini role kararindan SONRA cagirin
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10040

# Servis yanit vermezse mail dusmesin, gecici ret donsun
smtpd_policy_service_default_action = 451 4.3.5 Policy service unavailable

Kural dosyasında hesap başına saatlik ve günlük tavan tanımlarsınız. rate() eylemi anahtar/adet/süre/yanıt biçiminde çalışır:

# /etc/postfwd/postfwd.cf

# Kullanici basina saatte 200 mesaj
id=SAAT_LIMIT
  sasl_username=~/^.+$/
  action=rate(sasl_username/200/3600/450 4.7.1 Saatlik gonderim limitiniz doldu)

# Kullanici basina gunde 1000 mesaj
id=GUN_LIMIT
  sasl_username=~/^.+$/
  action=rate(sasl_username/1000/86400/450 4.7.1 Gunluk gonderim limitiniz doldu)

# Bulten hesabina daha genis tavan
id=BULTEN
  [email protected]
  action=rate(sasl_username/5000/3600/450 4.7.1 Limit asildi)

# Kural dosyasini test et
# postfwd3 --file /etc/postfwd/postfwd.cf --test

Bu kuralların en güzel tarafı, sınırı aşan gönderimin kalıcı olarak reddedilmemesidir: 450 geçici bir rettir, meşru kullanıcının istemcisi biraz sonra yeniden dener ve mesaj kaybolmaz. Ele geçirilmiş bir hesap ise bu tavan yüzünden saatte 200 mesajın ötesine geçemez ve siz uyarıyı görecek zamanı bulursunuz.

Sınırları belirlerken gerçekçi olun. Kurumsal bir kullanıcı günde tipik olarak 50-150 mesaj gönderir; 1000'lik günlük tavan onu hiç rahatsız etmezken bir spam kampanyasını anlamlı biçimde keser. Toplu pazarlama gönderimi yapıyorsanız o trafiği ayrı bir hesaba ve ideal olarak ayrı bir alan adına taşıyın — nedenini pazarlama maillerini alt alan adına ayırma yazısında ayrıntılı anlattım.

Alıcı Sunucuya Göre Yavaşlatma#

Üçüncü katman, sizin dışarı doğru teslimat hızınızı yönetir. Büyük sağlayıcılar yeni ya da düşük itibarlı bir IP'den ani hacim gördüğünde teslimatı yavaşlatır ve 421 ya da 4.7.x geçici hataları döndürür. Bu durumda daha hızlı denemek işleri kötüleştirir; doğru cevap kasten yavaşlamaktır.

# /etc/postfix/main.cf

# Tum hedefler icin es zamanli baglanti tavani
default_destination_concurrency_limit = 10

# Tek mesajda ayni hedefe kac alici adreslensin
default_destination_recipient_limit = 50

# Her teslimat arasinda bekleme (0s = beklemeden)
# DIKKAT: bunu genel olarak acmak tum trafigi yavaslatir
default_destination_rate_delay = 0s

Genel bir yavaşlatma yerine, yalnızca sorunlu hedefe özel bir taşıyıcı tanımlamak çok daha akıllıdır. master.cf içinde yavaş bir SMTP taşıyıcısı oluşturun:

# /etc/postfix/master.cf
yavas     unix  -       -       n       -       5       smtp
  -o syslog_name=postfix/yavas
  -o smtp_destination_rate_delay=2s
  -o smtp_destination_concurrency_limit=2

Sonra hangi alan adlarının bu taşıyıcıdan gideceğini eşleyin:

# /etc/postfix/transport
# ornek.com ve alt alan adlari yavas taşıyıcıdan gitsin
ornek.com       yavas:
.ornek.com      yavas:

sudo postmap /etc/postfix/transport
sudo postconf -e 'transport_maps = hash:/etc/postfix/transport'
sudo systemctl reload postfix

# Uygulandigini dogrula
postconf -n transport_maps

smtp_destination_rate_delay = 2s ayarı, o hedefe iki teslimat arasında en az iki saniye bekletir; yani saatte kabaca 1800 mesaj tavanı koyar. Yeni bir IP'yi ısıtırken (warm-up) bu yöntem çok işe yarar: ilk hafta yavaş taşıyıcıdan gönderir, itibar oturdukça gecikmeyi kademeli azaltırsınız. Büyük sağlayıcıların 2024 sonrasında yürürlüğe koyduğu gönderen gereksinimleri de bu tempoyu doğrudan etkiler; ayrıntıları Gmail ve Yahoo yeni gönderici kuralları yazısında bulabilirsiniz.

Yavaş taşıyıcı yöntemini kullanırken kuyruğun büyümesine hazırlıklı olun: saniyede bir mesaj yerine iki saniyede bir mesaj gönderdiğinizde, aynı hacim kuyrukta iki kat daha uzun bekler. Bu normaldir ve teslimatın başarısız olduğu anlamına gelmez, ancak disk alanı ve maximal_queue_lifetime süresi (varsayılan beş gün) sizin için sınır oluşturur. Yoğun bir kampanya gününde kuyruk boyutunu izleyin; sürekli büyüyüp hiç boşalmıyorsa gecikmeyi azaltmak yerine gönderim hacmini günlere yaymak daha doğru bir karardır.

Sınıra Takılan Mesaja Ne Olur#

Bu, en çok kafa karıştıran kısım. Cevap hangi katmanın devreye girdiğine bağlıdır:

Dördü de geçici (4xx) davranır, yani mesaj kaybolmaz. Bunu bilmek önemlidir çünkü sınır koymaktan çekinmenin en yaygın sebebi "ya meşru mail kaybolursa" korkusudur. Kalıcı ret (5xx) döndürmedikçe kaybolma riski yoktur; en kötü ihtimalle teslimat gecikir. Neler olduğunu loglardan takip edin:

# Anvil sinirina takilanlar
grep -E 'too much mail|Message delivery rate|Connection rate' /var/log/mail.log | tail

# postfwd kararlari
sudo journalctl -u postfwd -n 50 --no-pager

# Kuyrukta bekleyen mesajlar ve sebepleri
postqueue -p | head -20
mailq | grep -c '^[A-F0-9]'

İzleme ve Doğru Sayıyı Bulma#

Sınır koymanın en zor tarafı sayıyı seçmektir; çok gevşek koyarsanız işe yaramaz, çok sıkı koyarsanız kullanıcılarınızı engellersiniz. Yöntem şudur: önce ölçün, sonra tavanı gerçek tepe değerin iki-üç katına koyun.

# Son 24 saatte kullanici basina gonderim sayisi
grep -o 'sasl_username=[^ ,]*' /var/log/mail.log \
  | sort | uniq -c | sort -rn | head -20

# Saat bazinda gonderim dagilimi (tepe saatleri gormek icin)
grep 'status=sent' /var/log/mail.log \
  | awk '{print $3}' | cut -d: -f1 | sort | uniq -c

# Anvil'in kendi ozet satirlari (periyodik olarak loga yazar)
grep 'statistics:' /var/log/mail.log | tail

Bir haftalık veriyle bakın: en yoğun kullanıcınız saatte 60 mesaj atıyorsa saatlik tavanı 200 yapmak güvenli bir aralık bırakır. Tavanı koyduktan sonra ilk hafta 450 yanıtlarını izleyin; meşru kullanıcı takılıyorsa sınırı yükseltin, hiç takılan yoksa kademeli olarak indirin. Gönderim hacminin bant genişliği ve depolama tarafındaki karşılığını kabaca kestirmek için bant genişliği hesaplayıcı aracını kullanabilirsiniz.

Bir de alarm kurun. Hız limiti sizi korur ama sorunu çözmez; ele geçirilmiş hesabı bulup şifresini değiştirmeniz gerekir. Kuyruk uzunluğu ya da saatlik gönderim sayısı eşiği aşınca size mail atan basit bir cron işi yeterlidir. Sunucunun geri kalan güvenlik maddelerini topluca gözden geçirmek için mail sunucusu sertleştirme kontrol listesi yazısındaki tabloyu kullanın.

Sık Yapılan Hatalar#

Birinci ve en yaygın hata, anvil sınırlarını koyup "hesap bazlı korumam var" sanmaktır. Yukarıda anlattığım gibi bu sayaçlar IP başına çalışır; ele geçirilmiş bir hesap farklı IP'lerden kullanıldığında hiçbir sınıra takılmaz. Hesap bazlı koruma istiyorsanız mutlaka postfwd gibi bir politika servisi kurun.

İkinci hata, politika servisini permit_sasl_authenticated satırından önce koymaktır. Kural listesinde permit ile biten bir eşleşme olduğunda Postfix o noktada kararı verir ve sonraki kontrolleri çalıştırmaz; yani politika servisiniz hiç çağrılmaz. check_policy_service satırı listede permit_sasl_authenticated satırından sonra gelmelidir.

Üçüncü hata, politika servisi çöktüğünde ne olacağını düşünmemektir. Varsayılan davranış mesajın geçici olarak reddedilmesidir ve bu doğrudur, ama servis günlerce kapalı kalırsa tüm gönderim durur. smtpd_policy_service_default_action değerini bilinçli olarak ayarlayın ve servisi izleme listenize ekleyin.

Dördüncü hata, default_destination_rate_delay değerini genel olarak açmaktır. Bu parametre tüm hedefleri yavaşlatır; birkaç saniyelik bir gecikme, yoğun bir sunucuda kuyruğun hiç boşalmamasına yol açabilir. Yavaşlatmayı her zaman özel bir taşıyıcıya ve belirli alan adlarına sınırlayın.

Beşinci hata, sınırları koyup kullanıcılara haber vermemektir. Bülten gönderen bir pazarlama ekibi aniden 450 yanıtları almaya başladığında sorunu size değil kendi yazılımlarına yükler ve saatlerce yanlış yerde arar. Limitleri belgeleyin ve toplu gönderim yapan ekiplere ayrı bir hesap ile daha geniş tavan tanımlayın.

Sıkça Sorulan Sorular#

Postfix'te kullanıcı başına günlük mail limiti nasıl koyulur#

Postfix'in kendi içinde SASL kullanıcı adına göre kota koyan bir parametre yoktur; anvil sayaçları yalnızca IP başına çalışır. Kullanıcı bazlı kota için postfwd gibi bir politika servisi kurar, smtpd_recipient_restrictions listesine check_policy_service satırını ekler ve kural dosyasında rate(sasl_username/1000/86400/...) biçiminde bir tavan tanımlarsınız. Sınırı aşan gönderim geçici ret alır, dolayısıyla mesaj kaybolmaz.

Hız limiti koyarsam meşru mailler kaybolur mu#

Hayır, doğru yapılandırıldığında kaybolmaz. Hem anvil hem postfwd sınırları geçici ret (4xx) döndürür; gönderen istemci ya da sunucu bir süre sonra yeniden dener. Kayıp yalnızca kalıcı ret (5xx) döndürürseniz olur, bu yüzden kural dosyalarınızda yanıt kodunun 450 veya 451 ile başladığını doğrulayın. Hedef bazlı rate_delay ise hiç ret döndürmez, sadece kuyrukta bekletir.

Gmail 421 hatası veriyor, hız limitini nasıl ayarlamalıyım#

Bu, alıcı tarafın sizi yavaşlattığı anlamına gelir; çözüm daha hızlı denemek değil, kasten yavaşlamaktır. master.cf içinde smtp_destination_rate_delay ve smtp_destination_concurrency_limit değerleri düşürülmüş özel bir taşıyıcı tanımlayıp o alan adını transport_maps ile bu taşıyıcıya yönlendirin. Aynı zamanda gönderdiğiniz içeriğin ve kimlik doğrulama kayıtlarınızın doğru olduğunu kontrol edin, çünkü yavaşlatma çoğu zaman itibar sorununun belirtisidir.

Limitlerin çalıştığını nasıl test ederim#

En pratik yöntem, test hesabıyla arka arkaya sınırın üstünde mesaj göndermeye çalışmaktır. swaks ile bir döngü içinde birkaç düzine mesaj gönderip log dosyasında 450 yanıtının ortaya çıktığı noktayı gözlemleyebilirsiniz. Testi mutlaka üretim dışı bir hesapla ve kendi kontrolünüzdeki bir alıcı adresle yapın; başkasının kutusuna yüzlerce test mesajı göndermek kendi itibarınıza zarar verir.

Sınırı aşan kullanıcıyı otomatik olarak nasıl engellerim#

postfwd kural dosyasında rate() yerine daha sert bir eylem tanımlayabilir ya da belirli bir eşiği aşan kullanıcıyı bir betikle Dovecot tarafında devre dışı bırakabilirsiniz. Ancak otomatik engellemede dikkatli olun: meşru bir toplu gönderim yanlışlıkla hesabı kapatırsa iş durur. Pratikte en dengeli yöntem, sınırı geçici ret olarak uygulayıp aynı anda size uyarı maili göndermek ve kararı insana bırakmaktır.

Paylaşımlı hostingde gönderim limitini değiştirebilir miyim#

Hayır, paylaşımlı barındırmada saatlik gönderim limiti sunucu genelinde sağlayıcı tarafından belirlenir ve genellikle hesap başına birkaç yüz mesajdır. Bu limit, aynı sunucudaki diğer müşterilerin IP itibarını korumak içindir. Daha yüksek hacim gerekiyorsa doğru çözüm limiti zorlamak değil, gönderimi ayrılmış bir SMTP altyapısına taşımaktır.

anvil ile postfwd birlikte kullanılabilir mi#

Evet ve birlikte kullanılmaları önerilir, çünkü farklı tehditleri karşılarlar. anvil bot trafiğini ve tek IP'den gelen bağlantı fırtınalarını keser, postfwd ise ele geçirilmiş bir hesabın toplam hacmini sınırlar. İkisi çakışmaz; bir mesaj her iki kontrolden de geçmek zorundadır ve hangisi önce dolarsa o geçici ret döndürür.

Kapanış#

Gönderim hız limiti, koymadığınızda bedelini yalnızca bir kez ödediğiniz ama o bir kezin çok pahalıya patladığı bir önlemdir. Aklınızda dört şey kalsın: anvil IP başına, postfwd kullanıcı başına çalışır ve ikisi birbirinin yerine geçmez; politika servisi çağrısı mutlaka permit_sasl_authenticated satırından sonra gelmelidir; tüm sınırlar geçici ret döndürdüğü için meşru mail kaybolmaz; ve doğru sayıyı bulmanın tek yolu önce kendi trafiğinizi ölçmektir. Sınır koyduktan sonra da alarmı kurmayı unutmayın — limit zararı sınırlar, sorunu çözmez.

Bu ayarları kendi sunucunuzda kurmak yerine hazır gelmesini isterseniz SMTP sunucu paketimiz gönderim limitleri, DKIM imzası ve rDNS kaydı tanımlı olarak teslim edilir. Düzenli bülten ve kampanya gönderimi yapıyorsanız e-posta pazarlama tarafında ayrılmış bir gönderim altyapısı kullanmak hem limit hem itibar sorununu birlikte çözer. Sunucunuzu kendiniz işletiyor ama bakımını devretmek istiyorsanız sunucu yönetimi hizmetimiz bu ayarların kurulumunu ve izlemesini üstlenir.