Cara Mencegah Serangan Pengeboman Langganan E-mel

Apakah itu pengeboman langganan?

Pengeboman langganan ialah serangan yang menggunakan borang pendaftaran anda untuk membanjiri peti masuk orang lain. Penyerang mengambil alamat e-mel mangsa dan menghantarnya ke ratusan atau ribuan borang yang tidak dilindungi dalam tempoh masa yang singkat. Setiap tapak tersebut menghantar mesej alu-aluan atau mesej pengesahan ke alamat itu. Secara kolektif, mesej-mesej ini menyembunyikan e-mel yang sebenarnya perlu dibaca oleh mangsa.

Sasaran serangan ini ialah pemilik peti masuk tersebut. Semasa peti masuk dipenuhi dengan pengesahan langganan, penyerang sedang membelanjakan wang menggunakan kad mangsa atau menetapkan semula kata laluan pada salah satu akaun mereka. Makluman penipuan daripada bank tetap sampai. Namun, ia sampai di bawah dua ribu mesej lain yang masuk dalam jam yang sama, menyebabkan tiada sesiapa yang melihatnya tepat pada masanya.

Pelayan anda merupakan alat yang digunakan untuk membina serangan ini. Tiada apa-apa yang rosak pada pelayan anda. Tiada akaun anda yang diceroboh. Seseorang menaip alamat ke dalam borang awam dan perisian anda melakukan tugas yang telah ditetapkan: ia menghantar e-mel ke alamat tersebut. Inilah yang menjadikannya sukar untuk dikesan. Tiada pencerobohan dalam log anda, kerana memang tiada pencerobohan yang berlaku.

Bagaimana serangan ini kelihatan dari sisi anda

Ia muncul dalam salah satu daripada dua bentuk.

Bentuk yang ketara ialah lonjakan trafik. Beberapa ratus permintaan POST menyerang satu borang dalam masa beberapa minit, daripada banyak alamat IP sumber yang berbeza, membawa alamat e-mel pada domain yang tidak pernah anda hantar sebelum ini. Serangan ini mudah dikesan sebaik sahaja anda memeriksanya.

Bentuk yang senyap adalah bentuk yang sering terlepas pandang. Penyerang memegang senarai beribu-ribu borang yang terdedah, jadi borang anda hanya perlu menyumbang satu atau dua penyerahan setiap jam. Jye Cusch menghuraikan serangan yang tepat seperti ini pada tapak yang dikendalikannya: tiada lonjakan trafik, hanya pendaftaran berterusan yang tiba pada waktu yang tidak sepadan dengan khalayak beliau. Satu borang kelihatan tidak berbahaya kerana satu borang itu hampir tidak melakukan apa-apa. Kerosakan yang berlaku adalah hasil tambah merentasi setiap borang dalam senarai penyerang.

Kedua-dua bentuk serangan berkongsi satu tanda selepas itu: tiada tindakan susulan. Alamat e-mel tersebut tidak pernah membuat pengesahan. Mereka tidak pernah membuka mesej dan tidak pernah mengklik pautan. Dalam senarai opt-in yang disahkan, mereka kekal pada status unconfirmed selama-lamanya, dan timbunan itu adalah bukti paling jelas yang akan anda perolehi.

Mulakan dengan mengira jumlah penyerahan seminit dalam access log anda.

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

$4 dalam format log gabungan lalai ialah cap masa dalam kurungan, jadi arahan ini mencetak kiraan untuk setiap minit, dengan jumlah tertinggi dipaparkan dahulu. Borang yang biasanya menerima empat pendaftaran sehari tetapi menunjukkan enam puluh pendaftaran dalam satu minit bermakna borang tersebut sedang mengalami masalah.

Confirmed opt-in: pertahanan yang paling berkesan

Confirmed opt-in, yang biasanya dipanggil double opt-in, bermaksud sesuatu alamat tidak dianggap sebagai pelanggan sehingga seseorang mengklik pautan dalam mesej yang dihantar ke alamat tersebut. Aktifkan tetapan ini dan satu alamat yang diserahkan hanya akan menghasilkan tepat satu mesej sahaja. Alamat tersebut tidak akan dimasukkan ke dalam senarai, jadi ia tidak akan menerima kempen atau urutan alu-aluan.

Dalam listmonk, pelayan surat berita yang dihoskan sendiri ini merupakan tetapan bagi setiap senarai: sesuatu senarai boleh ditetapkan sebagai single opt-in atau double opt-in. Dokumentasinya menyatakan perbezaan tersebut dengan jelas. Bagi senarai double opt-in, pelanggan "menerima langganan secara eksplisit dengan mengklik e-mel pengesahan yang mereka terima. Sehingga itu, mereka tidak akan menerima mesej kempen." Pelanggan berada pada unconfirmed, beralih ke confirmed selepas klik dibuat, dan hanya pelanggan confirmed dalam senarai opt-in yang akan menerima e-mel kempen.

Jujurlah tentang manfaat yang anda peroleh. Confirmed opt-in tidak menjadikan sumbangan anda kepada sifar. Ia mengehadkan sumbangan tersebut kepada satu mesej bagi setiap alamat. Mangsa masih menerima mesej tersebut, dan satu mesej daripada setiap seribu tapak adalah keseluruhan serangan itu. Apa yang dihapuskan oleh confirmed opt-in ialah segala-galanya selepas itu: senarai anda kekal bersih, dan anda tidak akan menghantar mesej kedua kepada seseorang yang tidak pernah meminta mesej pertama.

Dua lagi tetapan adalah penting dan kedua-duanya mudah dilupakan. Pertama, hadkan penghantaran semula pengesahan. Jika alamat yang sama boleh diserahkan berulang kali dan menerima e-mel pengesahan baharu setiap kali, penyerang tidak memerlukan seribu borang, kerana borang anda sahaja sudah cukup untuk menghantar seribu mesej. Alamat yang sudah berada pada unconfirmed dalam senarai tersebut tidak sepatutnya menerima apa-apa lagi untuk sekurang-kurangnya satu hari. Kedua, padam baris yang tidak disahkan mengikut jadual. Alamat yang tidak disahkan dalam tempoh tiga puluh hari bukanlah pelanggan yang belum selesai. Menyimpannya hanya akan mewujudkan risiko bahawa sesuatu sistem menghantar e-mel kepadanya secara tidak sengaja pada masa hadapan.

Hadkan kadar borang pendaftaran pada reverse proxy

Letakkan had di hadapan aplikasi dan bukannya di dalam aplikasi tersebut. Permintaan yang disekat di peringkat proksi tidak akan membuka sambungan pangkalan data dan tidak akan memulakan perbualan SMTP (simple mail transfer protocol). Had di dalam aplikasi hanya berjalan selepas permintaan tersebut menggunakan proses pekerja dan pertanyaan (query), dan dalam kebanyakan tindanan (stack), mesej akan diletakkan dalam baris gilir sebelum sebarang pemeriksaan penyalahgunaan dijalankan. Had proksi juga kekal semasa naik taraf aplikasi kerana ia tidak berada dalam kod yang anda ganti.

Contoh di bawah menggunakan nginx. Konsep ini boleh digunakan pada mana-mana reverse proxy yang anda jalankan di hadapan aplikasi anda, walaupun nama direktifnya berbeza.

Letakkan ini dalam blok http, di dalam fail seperti /etc/nginx/conf.d/signup-limit.conf:

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 sedang melakukan kerja sebenar. nginx tidak mengira permintaan yang kuncinya adalah rentetan kosong, jadi hanya permintaan POST yang memasuki zon tersebut. Pengguna yang memuatkan halaman pendaftaran beberapa kali tidak akan menggunakan kuota. Tanpa map tersebut, seseorang yang memuat semula halaman dua kali akan menghabiskan kuota mereka sendiri sebelum mereka sempat menghantar apa-apa.

$binary_remote_addr ialah alamat pelanggan dalam bentuk padat, itulah sebabnya zon 10 megabait boleh memuatkan kira-kira 160,000 alamat. rate=2r/m membenarkan satu penghantaran setiap tiga puluh saat. limit_req_status 429 mengembalikan HTTP 429 Too Many Requests dan bukannya 503 lalai nginx, yang merupakan kod yang tepat dan kod yang dijangkakan oleh pustaka pelanggan.

Kemudian dalam blok server untuk tapak anda:

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 membenarkan seseorang yang menekan butang dua kali untuk melepasi had, dan menolak permintaan keempat serta-merta dan bukannya meletakkannya dalam baris gilir.

sudo nginx -t && sudo systemctl reload nginx

nginx -t sepatutnya mencetak configuration file /etc/nginx/nginx.conf test is successful. Sekarang, hantar borang lima kali dengan pantas dan perhatikan log ralat:

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

Permintaan yang disekat akan menulis satu baris, dan ini adalah rentetan yang anda cari:

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"

Tiada baris bermakna had tersebut tidak digunakan. Punca biasa ialah limit_req berada dalam blok location yang tidak dicapai oleh permintaan tersebut, jadi semak dengan curl -si -X POST https://news.example.com/subscription/form beberapa kali berturut-turut dan pastikan anda mendapat 429.

Dua perangkap perlu diketahui sebelum anda bergantung pada had setiap IP.

Di sebalik CDN atau proksi lain, $binary_remote_addr ialah proksi tersebut. Setiap pelawat akan berada dalam satu baldi yang sama, jadi beberapa penghantaran pertama setiap minit akan menyekat orang lain. Selesaikan masalah ini dengan modul real IP: set_real_ip_from untuk setiap julat yang diterbitkan oleh CDN anda (Cloudflare menyenaraikan julat mereka di cloudflare.com/ips) dan real_ip_header CF-Connecting-IP. Sahkan pembaikan dengan membaca $remote_addr dalam log akses anda dan pastikan ia adalah alamat pelawat dan bukannya alamat CDN anda.

IPv6 menjadikan had setiap alamat lemah. $binary_remote_addr memegang /128 penuh, dan peruntukan IPv6 kediaman biasanya adalah /64 atau lebih besar. Itu adalah jumlah alamat yang jauh lebih banyak daripada yang boleh digunakan oleh penyerang, dengan setiap satu mempunyai kuota bersihnya sendiri. Tambahkan zon kedua sebagai siling pada titik akhir itu sendiri, yang dikunci pada pemalar, supaya borang tersebut mempunyai kadar jumlah tidak kira berapa banyak alamat sumber yang digunakan:

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

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

Tambahkan limit_req zone=signup_total burst=10 nodelay; ke location yang sama. Tetapkan kadar melebihi jam paling sibuk anda dengan ruang tambahan. Ini adalah kawalan kasar: semasa serangan, ia juga akan menolak pendaftaran sebenar. Itu adalah pertukaran yang betul, kerana alternatifnya ialah pelayan anda menghantar e-mel tersebut.

Mengapa had per-alamat tidak boleh diletakkan pada proksi

Alamat e-mel tiba di dalam badan POST, dan Nginx tidak menghuraikan badan permintaan. Setiap pemboleh ubah yang boleh dijadikan kunci oleh limit_req_zone datang daripada baris permintaan, pengepala (headers) atau sambungan. Oleh itu, peraturan seperti "alamat ini hanya boleh menerima maksimum satu pengesahan sehari" perlu diletakkan pada komponen pertama yang membaca badan permintaan, iaitu aplikasi anda.

Jangan cuba mengatasi perkara ini dengan memindahkan alamat ke dalam rentetan pertanyaan (query string) supaya $arg_email boleh digunakan. Tindakan itu akan menulis alamat setiap pelanggan ke dalam log akses anda dalam bentuk teks jelas, dan ke dalam mana-mana penghantar log di hiliran. Anda akan menukar had kadar dengan masalah privasi.

Terdapat satu pengecualian sebenar. Modul JavaScript Nginx, njs, boleh membaca badan permintaan dan menetapkan pemboleh ubah daripadanya, yang membolehkan anda membina kunci per-alamat pada proksi. Ia merupakan pilihan yang sah namun ia juga merupakan kod baharu dalam laluan permintaan anda. Bagi kebanyakan laman web, had per-alamat sepatutnya berada di sebelah pangkalan data yang sudah mengetahui sama ada alamat ini mempunyai pengesahan yang belum selesai, sementara proksi mengendalikan had per-IP dan per-endpoint yang memang menjadi kelebihannya.

Jangan ulangi teks yang dihantar semula dalam mesej

Pastikan setiap rentetan yang dibekalkan oleh penyerang tidak dimasukkan ke dalam mesej yang anda hantar. Terdapat dua sebab berasingan dan kedua-duanya telah digunakan dalam serangan sebenar.

Jika e-mel pengesahan anda menyapa pembaca dengan nama yang diambil daripada borang, penyerang akan menulis mesej mereka ke dalam medan nama tersebut. Pelayan anda kemudiannya menghantar teks itu kepada mangsa, daripada domain anda, dan ditandatangani dengan kunci DKIM (DomainKeys Identified Mail) anda. Laman anda telah menjadi perkhidmatan penghantaran untuk penyalahgunaan pihak lain, dan penyedia penerima akan melihat domain anda pada e-mel tersebut.

Sebab kedua adalah lebih buruk. Jika mana-mana medan yang dihantar digabungkan ke dalam pengepala (header) e-mel secara manual, aksara baris baharu dalam medan tersebut akan menambah pengepala mengikut pilihan penyerang, termasuk Bcc. Pustaka e-mel moden menolak baris baharu dalam nilai pengepala. Kod yang menyalurkan teks ke dalam sendmail daripada skrip shell selalunya tidak berbuat demikian.

Mesej pengesahan yang selamat mengandungi nama laman anda dan satu pautan, dengan satu ayat penjelasan. Alamat itu sendiri hanya muncul di tempat yang diperlukan oleh ejen pemindahan mel (mail transfer agent), iaitu dalam pengepala To. Uji perkara ini: hantar borang dengan medan nama yang mengandungi baris baharu dan pautan yang jelas, kemudian baca mesej mentah yang anda terima dengan less dan pastikan tiada satu pun daripada elemen tersebut terselamat.

Sementara anda berada di situ, pastikan halaman kejayaan memaparkan perkara yang sama untuk setiap alamat. Halaman yang menyatakan "anda sudah melanggan" untuk satu alamat dan "semak peti masuk anda" untuk alamat yang lain akan menjadikan borang anda sebagai alat penyemak keahlian bagi sesiapa sahaja yang memegang senarai alamat untuk diuji.

Pemeriksaan bot manakah yang patut anda gunakan?

Pilih untuk kebolehcapaian sama teliti seperti anda memilih untuk keberkesanan. Captcha pemilihan imej tidak dapat diselesaikan oleh pembaca yang buta, dan pilihan audio pula sukar bagi orang yang mempunyai pendengaran biasa. Pemeriksaan yang menyebabkan pengguna sah gagal mendaftar adalah pertahanan yang turut membawa kos. Berikut adalah empat pilihan, mengikut urutan untuk dicuba.

Proof of work dalam pelayar. Pelayar mengira hash yang boleh disahkan oleh pelayan dengan kos rendah, dan tiada apa-apa yang perlu diselesaikan oleh manusia. listmonk menawarkan ciri ini di bawah Settings, kemudian Security, menggunakan ALTCHA, yang tidak memerlukan perkhidmatan pihak ketiga. Setakat Ogos 2026, ini adalah saranan listmonk sendiri berbanding pilihan hCaptcha yang telah ditamatkan. Kos tersebut ditanggung oleh pihak yang menghantar paling banyak, iaitu penyerang.

Pemeriksaan terurus bukan interaktif. Cloudflare Turnstile tidak menunjukkan apa-apa kepada kebanyakan pelawat dan hanya mencabar apabila isyaratnya kelihatan mencurigakan. Ia berkesan, namun meletakkan pihak ketiga dalam laluan pendaftaran anda.

Medan honeypot. Input teks yang tidak dilihat oleh manusia tetapi diisi oleh bot yang naif. Berikan nama yang tidak digunakan oleh borang anda, dan tetapkan autocomplete="off", tabindex="-1" serta aria-hidden="true" supaya pengurus kata laluan tidak mengisinya dan pembaca skrin tidak mengumumkannya. Medan yang dinamakan email2 atau address akan diisi secara automatik oleh pelayar, dan anda akan menolak pengguna sebenar.

<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>

Pemeriksaan masa untuk menghantar. Letakkan cap masa (timestamp) yang ditandatangani dalam medan tersembunyi apabila halaman dipaparkan, dan tolak penghantaran yang tiba kurang daripada dua saat kemudian. Seseorang tidak mungkin membaca borang dan menaip alamat sepantas itu. Tandatangani cap masa tersebut, atau bot akan menghantar cap masa lama dengan mudah.

Satu perkara untuk disahkan walau apa pun pilihan anda: token mestilah digunakan sekali sahaja. Jika skrip boleh menyelesaikan pemeriksaan sekali dan memainkan semula token tersebut terhadap seribu alamat, pemeriksaan itu hanya membuktikan bahawa pelayar berjalan sekali dan tiada yang lain.

Bagaimana anda mengetahuinya sebelum laporan penyalahgunaan tiba?

Anda mahu graf anda sendiri yang memberitahu anda, bukan meja penyalahgunaan pembekal pengehosan. Pantau dua perkara.

Kira jumlah penyerahan bagi setiap alamat sumber merentasi log:

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

Kemudian, biarkan fail2ban membaca baris limiting requests yang sama yang telah ditulis oleh nginx, dan sekat pesalah berulang. fail2ban menyediakan penapis untuk tujuan ini. Cipta /etc/fail2ban/jail.d/nginx-limit-req.local:

[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

Output status menyenaraikan penapis jail serta kiraan kegagalan dan sekatan semasa. Currently banned: 0 pada hari yang tenang adalah tepat. Jika jail tidak muncul langsung, fail2ban tidak memuatkan fail tersebut, dan sudo fail2ban-client -d | grep nginx-limit-req akan memaparkan konfigurasi yang sebenarnya telah dihurai. Penapis yang disediakan memadankan setiap zon limit_req. Hadkan kepada zon pendaftaran anda dengan menetapkan ngx_limit_req_zones = signup dalam bahagian [Definition] bagi /etc/fail2ban/filter.d/nginx-limit-req.local. Susun atur fail jail dan arahan sekatan dibincangkan dengan lebih mendalam dalam panduan fail2ban untuk Ubuntu 24.04.

Isyarat kedua ialah nisbah dan ia tidak memerlukan perisian baharu: jumlah penyerahan dibahagikan dengan pengesahan. Pada senarai yang sihat, kebanyakan orang yang menyerahkan alamat akan mengklik pautan tersebut, biasanya lebih separuh daripadanya. Apabila nisbah itu merosot sementara penyerahan meningkat, anda sedang dipergunakan. Bandingkan kiraan pelanggan unconfirmed yang dicipta dalam jam terakhir dengan kiraan pelanggan confirmed, mengikut jadual laporan yang anda jalankan sekarang.

Kos yang perlu anda tanggung: reputasi penghantar dan senarai sekat

Ini adalah bahagian yang mengubah gangguan kecil menjadi beban kewangan.

Senarai alamat yang digunakan untuk pengeboman e-mel adalah hasil tuian, dan senarai tuian mengandungi spamtraps: alamat yang tidak pernah mendaftar untuk apa-apa pun, yang diterbitkan semata-mata untuk menangkap penghantar yang menghantar e-mel tanpa kebenaran. Mesej pengesahan anda sampai kepada salah satu alamat ini. Sesetengah pengendali senarai sekat (blocklist) hanya memerlukan bukti itu sahaja.

Penerima yang tidak pernah meminta mesej anda tidak akan menekan butang nyahlanggan. Mereka akan menekan butang "laporkan spam". Peraturan penghantar pukal Google, yang berkuat kuasa sejak Februari 2024, mengarahkan penghantar yang menghantar 5,000 mesej atau lebih sehari ke Gmail untuk mengekalkan kadar laporan spam dalam Postmaster Tools di bawah 0.3%. Penghantar yang lebih kecil tidak diukur berdasarkan angka tersebut, tetapi isyarat aduan yang sama akan mempengaruhi keputusan penapisan yang menyebabkan e-mel anda terus masuk ke folder spam. Alamat palsu dalam siri penghantaran tersebut juga akan mengalami hard bounce, dan kadar hard bounce yang meningkat merupakan isyarat reputasi tersendiri bagi setiap penyedia e-mel utama.

Jika anda menjalankan pelayan e-mel anda sendiri pada VPS dengan mailcow, penyenaraian tersebut akan menjejaskan alamat IP dan domain anda. Proses untuk dikeluarkan daripada senarai sekat dengan pengendali seperti Spamhaus memerlukan pengisian borang dan tempoh menunggu, dan sementara anda menunggu, invois serta tetapan semula kata laluan anda juga tidak akan sampai kepada penerima. Jika anda menghantar melalui penyedia kongsi (shared provider) pula, mereka akan menggantung akaun anda terlebih dahulu sebelum membaca penjelasan anda, kerana trafik anda merupakan risiko kepada setiap penghantar lain yang berkongsi alamat IP tersebut.

Berbanding dengan risiko tersebut, usaha yang diperlukan adalah kecil. Aktifkan confirmed opt-in hari ini, kerana ia hanya melibatkan satu tetapan bagi setiap senarai. Tambahkan had kadar proksi seterusnya, kerana ia hanya melibatkan satu fail dan satu muat semula. Semakan bot dan sistem amaran boleh dilakukan pada minggu ini.

FAQ

Adakah double opt-in menghalang serangan subscription bombing?

Ia menghalang senarai anda daripada dicemari dan mengehadkan sumbangan anda kepada satu mesej bagi setiap alamat yang dihantar, yang merupakan penambahbaikan tunggal paling berkesan yang boleh anda lakukan. Ia tidak menghalang peti masuk mangsa daripada penuh, kerana serangan tersebut adalah hasil daripada satu mesej daripada setiap seribu tapak web. Gandingkan ia dengan had kadar (rate limit) per-IP pada proksi anda dan had pada penghantaran semula pengesahan, supaya alamat yang sama yang dihantar dua kali tidak menghasilkan mesej kedua.

Bagaimanakah saya membezakan serangan bombing daripada hari pendaftaran sebenar yang baik?

Lihat apa yang berlaku selepas penghantaran. Pendaftaran sebenar akan disahkan, dan biasanya ia disahkan dalam masa beberapa jam. Serangan bombing meninggalkan timbunan alamat yang tidak pernah disahkan, tidak pernah dibuka dan tidak pernah diklik. Penghantaran tersebut juga berkelompok secara ganjil: banyak alamat sumber yang tidak pernah anda lihat, domain penerima yang biasanya tidak anda hantar, dan waktu ketibaan yang tersebar secara sekata sepanjang hari dan bukannya mengikut waktu bangun khalayak anda.

Patutkah saya memadamkan alamat yang telah dihantar?

Ya. Padamkan rekod yang tidak disahkan yang berusia lebih daripada kira-kira tiga puluh hari, dan lakukan mengikut jadual dan bukannya secara manual. Jangan sekali-kali menghantar apa-apa lagi kepada alamat tersebut, termasuk permohonan maaf atau mesej "adakah ini anda?", kerana itu adalah mesej kedua yang tidak diminta kepada seseorang yang sudah pun dibanjiri dengan mesej sedemikian. Jika mana-mana alamat tersebut adalah spamtraps, tindakan susulan adalah pengesahan yang ditunggu-tunggu oleh pengendali senarai sekat (blocklist).

Adakah had kadar (rate limit) akan menolak pelanggan sebenar?

Had per-IP sebanyak satu penghantaran setiap tiga puluh saat dengan lonjakan sebanyak tiga adalah tidak ketara kepada seseorang yang mengisi borang sekali sahaja. Ia menjadi ketara apabila ramai orang sebenar berkongsi satu alamat, seperti pejabat di sebalik satu gateway NAT (network address translation), atau apabila proksi anda melihat alamat CDN anda dan bukannya alamat pelawat. Baca $remote_addr dalam access log anda sebelum anda mengetatkan apa-apa, dan pastikan had endpoint berada di atas waktu paling sibuk anda yang sebenar.

IP penghantaran saya berada dalam senarai sekat (blocklist) selepas serangan. Apakah perkara pertama yang perlu saya lakukan?

Berhenti menghantar daripada IP tersebut sebelum anda meminta apa-apa. Jeda baris gilir kempen, baiki borang, dan padamkan alamat yang tidak disahkan, kerana penyahsenaraian yang diikuti dengan trafik yang sama akan menyebabkan anda disenaraikan semula dengan lebih cepat berbanding kali pertama. Kemudian, cari senarai mana yang anda masuki, kerana kebanyakan pengendali mempunyai halaman carian yang dikunci pada alamat IP anda, dan ikuti proses penyingkiran mereka. Jangkakan tempoh menunggu dalam beberapa hari, dan gunakan masa itu untuk mengesahkan rekod SPF (sender policy framework) dan tandatangan DKIM anda masih lulus.