Abonelik bombardımanı nasıl engellenir?

Abonelik bombardımanı nedir?

Abonelik bombardımanı, kayıt formunuzu kullanarak başka birinin gelen kutusunu mesaj yağmuruna tutan bir saldırı türüdür. Saldırgan, tek bir kurbanın e-posta adresini alır ve kısa bir zaman dilimi içinde yüzlerce veya binlerce korumasız forma girer. Bu sitelerin her biri, söz konusu adrese bir hoş geldin veya onay mesajı gönderir. Bu mesajların tamamı, kurbanın aslında okuması gereken iletileri gizler.

Hedef, o gelen kutusunun sahibidir. Gelen kutusu abonelik onaylarıyla dolarken, saldırgan o kişinin kredi kartından harcama yapar veya hesaplarından birinin parolasını sıfırlar. Bankadan gelen dolandırıcılık uyarısı yine de ulaşır. Ancak bu uyarı, aynı saat içinde gelen diğer iki bin mesajın altında kaldığı için kimse tarafından zamanında fark edilmez.

Sunucunuz, saldırının üzerine inşa edildiği araçtır. Sunucunuzda herhangi bir arıza yoktur. Hiçbir hesabınız ele geçirilmemiştir. Birisi herkese açık bir forma bir adres girmiş ve yazılımınız, kendisinden beklenen görevi yerine getirerek o adrese posta göndermiştir. Bu durum, saldırının fark edilmesini zorlaştıran temel etkendir. Log kayıtlarınızda herhangi bir izinsiz giriş görünmez, çünkü ortada bir izinsiz giriş yoktur.

Saldırının sizin tarafınızdan görünümü

Saldırı iki farklı biçimde gerçekleşir.

Gürültülü biçim, ani bir yoğunluktur. Birkaç dakika içinde tek bir forma, farklı kaynak IP adreslerinden yüzlerce POST isteği gelir ve bu istekler daha önce hiç gönderim yapmadığınız alan adlarını içerir. Bu türü, logları incelediğinizde kolayca fark edebilirsiniz.

Sessiz biçim ise gözden kaçan türdür. Saldırgan binlerce savunmasız formdan oluşan bir listeye sahip olduğundan, sizin formunuz saatte yalnızca bir veya iki gönderimle katkıda bulunur. Jye Cusch, yönettiği bir sitede tam olarak bu biçimde bir saldırıyı tanımlamıştır: trafik artışı olmaz, sadece hedef kitlenizle eşleşmeyen saatlerde sürekli kayıtlar gelir. Tek bir form masum görünür çünkü tek bir form neredeyse hiçbir şey yapmıyordur. Hasar, saldırganın listesindeki her bir formun toplamıdır.

Her iki biçimin de sonrasında paylaştığı tek bir imza vardır: devamında hiçbir şey olmaz. Adresler asla onaylanmaz. Asla bir iletiyi açmaz ve asla bir bağlantıya tıklamazlar. Çift aşamalı onaylı (confirmed opt-in) bir listede sonsuza kadar unconfirmed durumunda kalırlar ve bu yığın, elde edebileceğiniz en net kanıttır.

İşe, access log dosyanızdaki dakika başına gönderim sayısını sayarak başlayın.

sudo awk '/POST \/subscription\/form/ {print substr($4, 2, 17)}' \
  /var/log/nginx/access.log | uniq -c | sort -rn | head

Varsayılan birleşik log biçimindeki $4, parantez içindeki zaman damgasıdır; bu nedenle bu komut, en yüksek sayıdan başlayarak her dakika için bir sayım çıktısı verir. Normalde günde dört kayıt alan bir formun bir dakika içinde altmış kayıt göstermesi, normal bir durum değildir.

Onaylı katılım: en etkili savunma yöntemi

Genellikle çift aşamalı onay (double opt-in) olarak adlandırılan onaylı katılım, bir e-posta adresinin, o adrese gönderilen bir iletideki bağlantıya tıklanana kadar abone sayılmaması anlamına gelir. Bu özelliği etkinleştirdiğinizde, gönderilen her adres için yalnızca bir adet ileti oluşturulur. Adres listeye eklenmediği için herhangi bir kampanya veya karşılama dizisi almaz.

listmonk, kendi sunucunuzda barındırdığınız bülten sunucusu üzerinde bu ayar liste bazlıdır: bir liste ya tek aşamalı ya da çift aşamalı onay ile çalışır. Dokümantasyon, aradaki farkı net bir şekilde belirtir. Çift aşamalı onay listesinde aboneler, "kendilerine ulaşan onay e-postasına tıklayarak aboneliği açıkça kabul ederler. O zamana kadar kampanya iletileri almazlar." Bir abone unconfirmed durumunda bekler, tıklama ile confirmed durumuna geçer ve yalnızca confirmed durumundaki aboneler kampanya postası alır.

Bu yöntemin size ne kazandırdığı konusunda dürüst olun. Onaylı katılım, katkınızı sıfıra indirmez. Yalnızca adres başına gönderilen ileti sayısını bir ile sınırlandırır. Mağdur kişi yine de o iletiyi alır; bin farklı siteden gelen birer ileti ise saldırının tamamını oluşturur. Onaylı katılımın ortadan kaldırdığı şey, bu ilk iletiden sonraki süreçtir: listeniz temiz kalır ve ilkini hiç istememiş birine asla ikinci bir ileti göndermemiş olursunuz.

İki ayar daha önemlidir ve ikisini de unutmak kolaydır. İlk olarak, onay iletilerinin yeniden gönderimini sınırlayın. Aynı adres tekrar gönderilip her seferinde yeni bir onay e-postası alabiliyorsa, saldırganın bin farklı forma ihtiyacı kalmaz; çünkü sadece sizin formunuz binlerce ileti gönderebilir. Listede zaten unconfirmed durumunda bekleyen bir adres, en az bir gün boyunca başka bir ileti almamalıdır. İkinci olarak, onaylanmamış satırları belirli bir takvime göre silin. Otuz gün boyunca onay vermeyen bir adres, bekleyen bir abone değildir. Bu adresi tutmak, ileride yanlışlıkla bir ileti gönderilme riskini doğurur.

Kayıt formuna reverse proxy seviyesinde hız sınırlaması (rate limit) uygulama

Sınırlamayı uygulamanın içinde değil, önünde konumlandırın. Proxy katmanında engellenen bir istek, veritabanı bağlantısı açmaz ve SMTP (simple mail transfer protocol) oturumu başlatmaz. Uygulama içindeki bir sınırlama, istek zaten bir worker sürecine ve sorgu maliyetine yol açtıktan sonra çalışır; birçok yapıda ise mesaj, herhangi bir kötüye kullanım denetimi yapılmadan önce kuyruğa alınır. Proxy sınırlaması, uygulama güncellemelerinden de etkilenmez çünkü değiştirdiğiniz kodun içinde yer almaz.

Aşağıdaki örnek Nginx içindir. Mantık, uygulamanızın önünde çalıştırdığınız reverse proxy ne olursa olsun geçerlidir, ancak direktif isimleri farklılık gösterebilir.

Bunu http bloğuna, /etc/nginx/conf.d/signup-limit.conf gibi bir dosya içine yerleştirin:

map $request_method $signup_key {
    POST    $binary_remote_addr;
    default "";
}

limit_req_zone $signup_key zone=signup:10m rate=2r/m;
limit_req_status 429;
limit_req_log_level warn;

map gerçek işi yapan kısımdır. Nginx, anahtarı boş bir dizge olan istekleri saymaz, bu nedenle yalnızca POST istekleri bölgeye dahil edilir. Kayıt sayfasını birkaç kez yükleyen bir kullanıcı herhangi bir kota harcamaz. Bu harita (map) olmasaydı, sayfayı iki kez yenileyen biri, henüz hiçbir şey göndermeden kendi bütçesini tüketirdi.

$binary_remote_addr, paketlenmiş biçimdeki istemci adresidir; bu nedenle 10 megabaytlık bir bölge yaklaşık 160.000 adres tutabilir. rate=2r/m, otuz saniyede bir gönderime izin verir. limit_req_status 429, Nginx'in varsayılan 503 hatası yerine HTTP 429 Too Many Requests döndürür; bu, doğru HTTP kodudur ve istemci kütüphanelerinin beklediği yanıt budur.

Ardından siteniz için server bloğunda:

location = /subscription/form {
    limit_req zone=signup burst=3 nodelay;
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

burst=3 nodelay, butona çift tıklayan bir kullanıcının geçmesine izin verir ve dördüncü isteği kuyruğa almak yerine doğrudan reddeder.

sudo nginx -t && sudo systemctl reload nginx

nginx -t, configuration file /etc/nginx/nginx.conf test is successful çıktısını vermelidir. Şimdi formu hızlıca beş kez gönderin ve hata günlüğünü (error log) izleyin:

sudo tail -f /var/log/nginx/error.log

Engellenen her istek bir satır yazar; aramanız gereken dizge şudur:

2026/08/13 09:14:22 [warn] 812#812: *4412 limiting requests, excess: 3.400 by zone "signup", client: 203.0.113.10, server: news.example.com, request: "POST /subscription/form HTTP/1.1", host: "news.example.com"

Hiç satır oluşmuyorsa sınırlama uygulanmıyor demektir. Yaygın neden, limit_req ifadesinin isteğin asla ulaşmadığı bir location bloğunda yer almasıdır; bu yüzden curl -si -X POST https://news.example.com/subscription/form komutunu arka arkaya birkaç kez çalıştırın ve 429 yanıtını aldığınızdan emin olun.

IP bazlı sınırlamalara güvenmeden önce iki tuzağı bilmekte fayda vardır.

Bir CDN veya başka bir proxy arkasındaysanız, $binary_remote_addr o proxy'dir. Tüm ziyaretçiler tek bir sepete düşer, bu nedenle her dakikanın ilk birkaç gönderimi diğer herkesi kilitler. Bunu gerçek IP modülü ile düzeltin: CDN'nizin yayınlanan her aralığı için set_real_ip_from (Cloudflare kendi aralıklarını cloudflare.com/ips adresinde listeler) ve real_ip_header CF-Connecting-IP kullanın. Erişim günlüğünüzde $remote_addr değerini okuyarak ve bunun CDN adresiniz yerine gerçek bir ziyaretçi adresi olduğunu doğrulayarak düzeltmeyi teyit edin.

IPv6, adres bazlı sınırlamayı zayıflatır. $binary_remote_addr, tam /128 adresini tutar; konut tipi bir IPv6 tahsisatı ise genellikle /64 veya daha büyüktür. Bu, bir saldırganın kullanabileceği, her biri kendi temiz bütçesine sahip çok sayıda adresten fazlasıdır. Uç noktanın kendisine bir tavan sınırı koymak için sabit bir anahtara dayalı ikinci bir bölge ekleyin; böylece form, kaç farklı kaynak adresi kullanılırsa kullanılsın toplam bir hız sınırına sahip olur:

map $request_method $signup_total_key {
    POST    "signup";
    default "";
}

limit_req_zone $signup_total_key zone=signup_total:1m rate=30r/m;

Aynı location içine limit_req zone=signup_total burst=10 nodelay; ekleyin. Hız sınırını, en yoğun gerçek saatlik trafiğinizin üzerinde, pay bırakacak şekilde ayarlayın. Bu kaba bir kontroldür: bir saldırı sırasında gerçek kayıtları da engeller. Bu doğru bir takastır, çünkü alternatif, sunucunuzun postayı göndermesidir.

Adres başına limitin neden proxy katmanında uygulanamadığı

E-posta adresi POST gövdesi içerisinde gelir ve Nginx istek gövdelerini ayrıştırmaz. limit_req_zone değişkeninin anahtar olarak kullanabileceği her veri; istek satırından, başlıklardan veya bağlantıdan gelir. Bu nedenle "bu adres günde en fazla bir onay alabilir" gibi bir kural, gövdeyi okuyan ilk bileşende, yani uygulamanızda yer almalıdır.

$arg_email değişkeninin kullanılabilmesi için adresi sorgu dizisine (query string) taşıyarak bu durumu aşmaya çalışmayın. Bu yöntem, her abonenin adresini açık metin olarak erişim loglarınıza ve bu logları işleyen tüm alt sistemlere yazılmasına neden olur. Bir hız sınırlaması elde etmek uğruna gizlilik sorunu yaratmış olursunuz.

Burada tek bir istisna mevcuttur. Nginx JavaScript modülü olan njs, istek gövdesini okuyabilir ve buradan bir değişken atayabilir; bu da proxy katmanında adres başına bir anahtar oluşturmanıza olanak tanır. Bu geçerli bir seçenektir ancak istek yolunuza yeni bir kod ekler. Çoğu site için adres başına sınırlama, bu adresin bekleyen bir onayı olup olmadığını zaten bilen veritabanının yanında yer almalıdır; proxy ise kendi uzmanlık alanı olan IP ve uç nokta başına limitleri yönetmelidir.

Gönderilen metni mesaj içerisinde tekrarlamayın

Saldırgan tarafından sağlanan hiçbir dizgiyi gönderdiğiniz mesajın içine dahil etmeyin. Bunun iki ayrı nedeni vardır ve her ikisi de gerçek saldırılarda kullanılmıştır.

Eğer onay e-postanız okuyucuyu formdan alınan bir isimle karşılıyorsa, saldırgan kendi mesajını isim alanına yazar. Sunucunuz daha sonra bu metni, sizin alan adınız üzerinden ve DKIM (DomainKeys Identified Mail) anahtarınızla imzalanmış olarak kurbana iletir. Siteniz başkasının kötü niyetli kullanımı için bir dağıtım servisine dönüşür ve alıcı sağlayıcı, e-postanın üzerinde sizin alan adınızı görür.

İkinci neden daha kötüdür. Eğer gönderilen herhangi bir alan elle e-posta başlığına ekleniyorsa, bu alandaki bir satır başı karakteri, Bcc dahil olmak üzere saldırganın seçtiği başlıkları eklemesine olanak tanır. Modern e-posta kütüphaneleri başlık değerlerindeki satır başlarını reddeder. Metni bir shell script üzerinden sendmail içine aktaran kodlar ise genellikle bunu yapmaz.

Güvenli bir onay mesajı, site adınızı, tek bir bağlantıyı ve bir cümlelik açıklamayı içerir. Adresin kendisi yalnızca e-posta aktarım aracının ihtiyaç duyduğu To başlığında görünmelidir. Bunu test edin: formu, içinde satır başı ve belirgin bir bağlantı bulunan bir isim alanı ile gönderin, ardından aldığınız ham mesajı less ile okuyun ve her ikisinin de mesajda yer almadığından emin olun.

Bu aşamadayken, başarı sayfasının her adres için aynı şeyi söylemesini sağlayın. Bir adres için "zaten abonesiniz", diğeri için "gelen kutunuzu kontrol edin" diyen bir sayfa, formunuzu elinde adres listesi olan herkes için bir üyelik doğrulama aracına dönüştürür.

Hangi bot denetimini kullanmalısınız?

Erişilebilirlik kriterlerini en az etkinlik kriterleri kadar ciddiye alın. Görsel seçimi gerektiren bir captcha, görme engelli bir kullanıcı tarafından çözülemez; sesli alternatifler ise normal işitme yetisine sahip kişiler için bile zorlayıcı olabilir. Gerçek bir kullanıcının kaydolmasını engelleyen bir denetim, savunma sağladığı kadar maliyet de yaratır. İşte deneme sırasına göre dört seçenek.

Tarayıcı tabanlı iş kanıtı (Proof of work). Tarayıcı, sunucunun düşük maliyetle doğrulayabileceği bir hash hesaplar; kullanıcının çözmesi gereken bir işlem yoktur. listmonk, Ayarlar (Settings) ve ardından Güvenlik (Security) altında, herhangi bir üçüncü taraf hizmeti gerektirmeyen ALTCHA ile bu özelliği sunar. Ağustos 2026 itibarıyla, listmonk'un kendi önerisi, kullanımdan kaldırılan hCaptcha seçeneği yerine bu yöntemdir. Maliyet, en çok gönderim yapan tarafa, yani saldırgana yüklenir.

Yönetilen, etkileşim gerektirmeyen denetim. Cloudflare Turnstile, ziyaretçilerin çoğuna hiçbir şey göstermez ve yalnızca sinyaller şüpheli göründüğünde bir sınama sunar. Etkilidir ancak kayıt sürecinize üçüncü bir tarafı dahil eder.

Honeypot alanı. İnsanların görmediği ancak basit botların doldurduğu bir metin girişi. Formunuzda başka hiçbir yerde kullanılmayan bir isim verin ve autocomplete="off", tabindex="-1" ve aria-hidden="true" ayarlarını yaparak parola yöneticilerinin burayı doldurmasını ve ekran okuyucuların burayı seslendirmesini engelleyin. email2 veya address gibi isimler tarayıcı tarafından otomatik doldurulur ve bu durumda gerçek kullanıcıları reddetmiş olursunuz.

<div style="position:absolute; left:-9999px;" aria-hidden="true">
  <label for="hp_ref">Leave this field empty</label>
  <input type="text" id="hp_ref" name="hp_ref" autocomplete="off" tabindex="-1">
</div>

Gönderim süresi denetimi. Sayfa oluşturulduğunda gizli bir alana imzalı bir zaman damgası yerleştirin ve iki saniyeden kısa sürede gelen gönderimleri reddedin. Bir insan formu okuyup bir adresi bu kadar hızlı yazamaz. Zaman damgasını imzalayın, aksi takdirde bot eski bir zaman damgasını kolayca gönderebilir.

Hangi yöntemi seçerseniz seçin doğrulamanız gereken bir husus vardır: token tek seferlik kullanılmalıdır. Eğer bir betik denetimi bir kez çözüp elde ettiği token'ı binlerce adrese karşı tekrar kullanabiliyorsa, denetim sadece bir tarayıcının bir kez çalıştığını kanıtlamış olur, başka bir şey değil.

Kötüye kullanım bildirimi gelmeden durumu nasıl anlarsınız?

Kendi grafiklerinizin, bir barındırma sağlayıcısının kötüye kullanım biriminden önce sizi uyarmasını istersiniz. İki noktayı izleyin.

Log dosyası üzerinden kaynak adres başına gönderim sayısını hesaplayın:

sudo awk '/POST \/subscription\/form/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Ardından, nginx tarafından zaten yazılan limiting requests satırlarını fail2ban'in okumasını sağlayın ve tekrarlayan ihlalcileri engelleyin. fail2ban, tam olarak bu amaç için bir filtre ile gelir. /etc/fail2ban/jail.d/nginx-limit-req.local dosyasını oluşturun:

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 3600

sudo systemctl reload fail2ban
sudo fail2ban-client status nginx-limit-req

Durum çıktısı, jail filtresini ve o anki başarısızlık ile yasaklama sayılarını listeler. Sakin bir günde Currently banned: 0 çıktısının alınması normaldir. Eğer jail hiç görünmüyorsa, fail2ban dosyayı yüklememiştir; bu durumda sudo fail2ban-client -d | grep nginx-limit-req komutu, sistemin gerçekten ayrıştırdığı yapılandırmayı döker. Gelen filtre, her limit_req bölgesini eşleştirir. Bunu, /etc/fail2ban/filter.d/nginx-limit-req.local dosyasının bir [Definition] bölümünde ngx_limit_req_zones = signup ayarını yaparak yalnızca kayıt bölgenizle sınırlandırın. Jail dosya yapısı ve yasaklama komutları, Ubuntu 24.04 için fail2ban rehberi içerisinde daha derinlemesine ele alınmıştır.

İkinci sinyal bir orandır ve yeni bir yazılım gerektirmez: gönderimlerin onaylara bölünmesi. Sağlıklı bir listede, bir adres gönderen kişilerin çoğu bağlantıya tıklar; bu oran genellikle yarısından fazladır. Gönderimler artarken bu oran düştüğünde, sisteminiz kötüye kullanılıyor demektir. Hangi zamanlamayla rapor alıyorsanız alın, son bir saat içinde oluşturulan unconfirmed abonelerin sayısını, confirmed olanlarla karşılaştırın.

Maliyeti: gönderici itibarı ve kara listeler

Bu kısım, bir rahatsızlığı faturaya dönüştüren bölümdür.

Bombardıman için kullanılan adres listeleri toplanmış verilerden oluşur ve bu listeler spamtraps içerir: hiçbir yere kaydolmamış, yalnızca izinsiz gönderim yapanları yakalamak için yayınlanmış adresler. Onay mesajınız bunlardan birine ulaştığında, bazı kara liste operatörleri için bu tek başına yeterli bir gerekçedir.

Mesajınızı talep etmeyen alıcılar abonelikten çıkma bağlantısına tıklamaz. Bunun yerine "spam bildir" butonuna tıklarlar. Şubat 2024 itibarıyla yürürlükte olan Google toplu gönderici kuralları, Gmail'e günde 5.000 veya daha fazla mesaj gönderenlerin Postmaster Tools üzerindeki spam bildirim oranını %0,3'ün altında tutmasını şart koşar. Daha küçük ölçekli göndericiler bu rakama göre ölçülmese de, aynı şikayet sinyali postalarınızı spam klasörüne düşüren filtreleme kararlarını besler. Gönderim sırasındaki sahte adresler ayrıca hard bounce ile sonuçlanır ve artan bir hard bounce oranı, her büyük sağlayıcı nezdinde başlı başına bir itibar sinyalidir.

Eğer kendi posta sunucunuzu bir VPS üzerinde mailcow ile çalıştırıyorsanız, kara listeye alınma durumu doğrudan IP adresinizi ve alan adınızı etkiler. Spamhaus gibi bir operatörden listeden çıkarılmak, bir form doldurup beklemeyi gerektirir; siz beklerken faturalarınız ve şifre sıfırlama e-postalarınız da alıcıya ulaşmaz. Eğer bunun yerine paylaşımlı bir sağlayıcı üzerinden gönderim yapıyorsanız, sağlayıcının önce hesabınızı askıya alıp sonra açıklamanızı dinlemesini beklemelisiniz; çünkü trafiğiniz o IP üzerindeki diğer tüm göndericiler için bir risk oluşturur.

Buna karşılık, yapılması gereken iş oldukça azdır. Onaylı katılımı (confirmed opt-in) bugün aktif edin, çünkü her liste için tek bir ayardan ibarettir. Ardından proxy hız sınırını ekleyin, çünkü bu sadece bir dosya ve bir yeniden yükleme işlemidir. Bot kontrolü ve uyarı mekanizmaları bu hafta içinde tamamlanabilir.

FAQ

Çift aşamalı doğrulama (double opt-in) abonelik saldırılarını (subscription bombing) engeller mi?

Listenizin kirlenmesini engeller ve gönderilen her adres başına mesaj sayısını bir ile sınırlar; bu, elinizdeki en büyük iyileştirmedir. Kurbanın gelen kutusunun dolmasını engellemez, çünkü saldırı binlerce farklı siteden gelen birer mesajın toplamından oluşur. Bunu, proxy seviyesinde IP başına hız sınırlaması (rate limit) ve onay mesajı gönderim sınırı ile birleştirin; böylece aynı adres iki kez girildiğinde ikinci bir mesaj üretilmez.

Bir saldırı dalgasını, gerçek aboneliklerin yoğun olduğu iyi bir günden nasıl ayırt ederim?

Gönderimden sonra ne olduğuna bakın. Gerçek aboneler onay verir ve genellikle saatler içinde onaylarlar. Bir saldırı dalgası, asla onaylanmayan, açılmayan ve tıklanmayan bir adres yığını bırakır. Gönderimler de tuhaf bir şekilde kümelenir: daha önce hiç görmediğiniz kaynak adresler, genellikle gönderim yapmadığınız alıcı alan adları ve hedef kitlenizin uyanık olduğu saatleri takip etmek yerine günün tamamına eşit dağılmış varış zamanları görülür.

Gönderilen adresleri silmeli miyim?

Evet. Yaklaşık otuz günden eski olan onaylanmamış kayıtları silin ve bunu elle değil, bir zaman çizelgesine göre yapın. Bu adreslere özür mesajı veya "bu siz miydiniz?" gibi başka hiçbir şey göndermeyin; çünkü bu, zaten mesaj yağmuruna tutulmuş birine gönderilen ikinci istenmeyen mesajdır. Eğer bu adreslerden herhangi biri spam tuzağı (spamtrap) ise, bir takip mesajı göndermek, kara liste operatörünün beklediği onay anlamına gelir.

Hız sınırlaması gerçek aboneleri reddeder mi?

IP başına otuz saniyede bir gönderim ve üçlük bir patlama (burst) sınırı, formu bir kez dolduran bir kişi için fark edilmezdir. Bu sınır, tek bir NAT (network address translation) ağ geçidi arkasındaki bir ofis gibi birçok gerçek kişinin aynı IP adresini paylaştığı durumlarda veya proxy'niz ziyaretçinin IP'si yerine CDN'nizin IP'sini gördüğünde fark edilebilir hale gelir. Herhangi bir kısıtlamayı sıkılaştırmadan önce erişim loglarınızdaki $remote_addr değerini inceleyin ve uç nokta tavanını en yoğun gerçek saatlerinizin üzerinde tutun.

Bir saldırı dalgasından sonra gönderim IP'm kara listeye alındı. İlk ne yapmalıyım?

Herhangi bir talepte bulunmadan önce o IP üzerinden gönderimi durdurun. Kampanya kuyruğunu duraklatın, formu düzeltin ve onaylanmamış adresleri silin; çünkü listeden çıkarılma talebinin ardından aynı trafiğin devam etmesi, IP'nizin ilk seferden daha hızlı kara listeye alınmasına neden olur. Ardından hangi listede olduğunuzu bulun, çünkü çoğu operatörün IP adresinize göre sorgulama yapabileceğiniz bir sayfası vardır; bu sayfadaki kaldırma sürecini izleyin. Bekleme süresinin günler sürebileceğini göz önünde bulundurun ve bu süreyi SPF (sender policy framework) kaydınızın ve DKIM imzanızın hala geçerli olduğunu doğrulamak için kullanın.