Signup form subscription bombing कसे थांबवावे

सब्स्क्रिप्शन बॉम्बिंग म्हणजे काय?

सब्स्क्रिप्शन बॉम्बिंग हा असा हल्ला आहे, ज्यामध्ये तुमचा signup form वापरून दुसऱ्या व्यक्तीचा inbox संदेशांनी भरून टाकला जातो. हल्लेखोर एका पीडित व्यक्तीचा email address घेतो आणि अल्प कालावधीत शेकडो किंवा हजारो असुरक्षित forms मध्ये तो address submit करतो. त्यानंतर प्रत्येक साइट त्या address वर welcome message किंवा confirmation message पाठवते. हे सर्व संदेश एकत्रितपणे पीडित व्यक्तीला प्रत्यक्षात वाचणे आवश्यक असलेले mail झाकून टाकतात.

लक्ष्य त्या inbox च्या मालकाला केले जाते. तो inbox subscription confirmations ने भरत असताना, हल्लेखोर त्या व्यक्तीच्या card वर पैसे खर्च करत असतो किंवा तिच्या एखाद्या account चा password reset करत असतो. बँकेकडून येणारा fraud alert तरीही पोहोचतो. तो त्याच तासात आलेल्या इतर दोन हजार संदेशांखाली दडतो. त्यामुळे तो वेळेवर कोणाच्याही लक्षात येत नाही.

तुमचा server हे आक्रमण उभारण्यासाठी वापरले जाणारे साधन असते. तुमच्या box मधील काहीही बिघडलेले नसते. तुमच्या कोणत्याही account शी तडजोड झालेली नसते. कोणीतरी public form मध्ये एक address टाइप केला आणि तुमच्या software ने त्याला जसे लिहिले होते तसेच काम केले: त्या address वर mail पाठवले. त्यामुळे हे ओळखणे कठीण होते. तुमच्या logs मध्ये intrusion दिसत नाही, कारण intrusion झालेलीच नसते.

तुमच्या बाजूने हा हल्ला कसा दिसतो

हा दोनपैकी एका स्वरूपात दिसतो.

ठळक स्वरूप म्हणजे अचानक वाढलेली विनंतींची लाट. काही मिनिटांत अनेक वेगवेगळ्या source IP addresses कडून एकाच form वर शेकडो POST requests येतात. त्यामध्ये तुम्ही यापूर्वी कधीही पाठवलेले नसलेले domains असलेले addresses असतात. एकदा लक्ष दिल्यावर हे स्वरूप सहज दिसते.

शांत स्वरूप अनेकदा लक्षात येत नाही. attacker कडे हजारो vulnerable forms ची यादी असते. त्यामुळे तुमच्या form कडून दर तासाला फक्त एक किंवा दोन submissions पुरेसे असतात. Jye Cusch यांनी चालवत असलेल्या site वर याच स्वरूपातील हल्ल्याचे वर्णन केले आहे: traffic spike नव्हता; फक्त त्याच्या audience शी जुळत नसलेल्या वेळांमध्ये signups सातत्याने येत होते. एकच form निरुपद्रवी वाटतो, कारण एकच form जवळजवळ काहीच करत नसतो. प्रत्यक्ष नुकसान attacker च्या यादीतील प्रत्येक form वरील एकत्रित परिणामामुळे होते.

नंतर दोन्ही स्वरूपांमध्ये एकच लक्षण दिसते: त्यानंतर काहीही घडत नाही. ते addresses कधीही confirm होत नाहीत. ते message कधीही उघडत नाहीत आणि link वर click करत नाहीत. confirmed opt-in list मध्ये ते कायम unconfirmed status मध्ये राहतात. तुम्हाला मिळणारा हा सर्वात स्पष्ट पुरावा असतो.

सुरुवात access log मधील प्रति मिनिट submissions मोजण्यापासून करा.

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

default combined log format मधील $4 हा bracket मध्ये असलेला timestamp असतो. त्यामुळे हा command प्रत्येक मिनिटासाठी count छापतो आणि सर्वाधिक count प्रथम दाखवतो. एखाद्या form वर साधारणपणे दिवसाला चार signups होत असतील आणि एका मिनिटात साठ signups दिसत असतील, तर तो सामान्य दिवस नाही.

पुष्टी केलेले opt-in: सर्वाधिक परिणाम करणारे संरक्षण

पुष्टी केलेले opt-in, ज्याला सामान्यतः double opt-in म्हणतात, याचा अर्थ असा की एखाद्या पत्त्यावर पाठवलेल्या संदेशातील दुव्यावर व्यक्ती क्लिक करेपर्यंत तो पत्ता subscriber होत नाही. हे सुरू केल्यावर सबमिट केलेल्या प्रत्येक पत्त्यावरून आयुष्यात फक्त एकच संदेश पाठवला जातो. तो पत्ता list मध्ये कधीच जोडला जात नाही. त्यामुळे त्याला campaign किंवा welcome sequence मिळत नाही.

self-hosted newsletter server listmonk मध्ये ही per-list setting आहे: एखादी list single opt-in किंवा double opt-in असते. या फरकाबाबत documentation स्पष्ट आहे. double opt-in list मध्ये subscribers "त्यांना मिळालेल्या confirmation e-mail मधील दुव्यावर क्लिक करून subscription स्पष्टपणे स्वीकारतात. तोपर्यंत त्यांना campaign messages मिळत नाहीत." Subscriber unconfirmed स्थितीत असतो, क्लिक केल्यानंतर confirmed स्थितीत जातो आणि opt-in list वरील फक्त confirmed subscribers ना campaign mail मिळतो.

यातून नेमका काय फायदा होतो, याबाबत प्रामाणिक रहा. Confirmed opt-in मुळे तुमचे योगदान शून्यावर येत नाही. ते प्रत्येक पत्त्यामागे एक संदेश इतके मर्यादित होते. पीडिताला तो संदेश तरी मिळतो. हजार sites कडून प्रत्येकी एक संदेश हाच संपूर्ण हल्ला असू शकतो. Confirmed opt-in मुळे त्यानंतरचे सर्व काही थांबते: तुमची list स्वच्छ राहते आणि पहिलाच संदेश न मागणाऱ्या व्यक्तीला तुम्ही दुसरा संदेश कधीच पाठवत नाही.

आणखी दोन settings महत्त्वाच्या आहेत आणि दोन्ही सहज विसरल्या जातात. प्रथम, confirmation चे resends मर्यादित करा. तोच पत्ता पुन्हा submit करता येत असेल आणि प्रत्येक वेळी आणखी एक confirmation email मिळत असेल, तर attacker ला हजार forms ची गरज नाही. कारण तुमचा form स्वतःच हजार messages पाठवेल. त्या list वर आधीपासून unconfirmed स्थितीत असलेल्या पत्त्याला किमान एका दिवसासाठी पुढे कोणताही संदेश मिळू नये. दुसरे, unconfirmed rows ठरावीक वेळापत्रकानुसार delete करा. तीस दिवसांत confirm न केलेला पत्ता pending subscriber नाही. तो ठेवण्यामुळे नंतर चुकून त्याला काहीतरी mail जाण्याची शक्यता निर्माण होते.

Reverse proxy वर signup form साठी rate limit लागू करा

हे limit application च्या आत न ठेवता त्याच्या पुढे लागू करा. Proxy वर block केलेल्या request मुळे database connection उघडत नाही आणि SMTP (simple mail transfer protocol) conversation सुरू होत नाही. Application मधील limit request मुळे worker process आणि query चा खर्च झाल्यानंतर लागू होते. अनेक stacks मध्ये abuse check सुरू होण्यापूर्वीच message queue मध्ये ठेवला जातो. हे proxy limit application upgrade नंतरही लागू राहते, कारण ते तुम्ही बदलून टाकता अशा code मध्ये नसते.

खालील उदाहरण nginx साठी आहे. हीच कल्पना तुम्ही application च्या पुढे चालवत असलेल्या reverse proxy ला लागू करता येते; मात्र directive ची नावे वेगळी असतात.

हे http block मध्ये, उदाहरणार्थ /etc/nginx/conf.d/signup-limit.conf सारख्या file मध्ये ठेवा:

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 प्रत्यक्ष काम करते. key ची value रिकामी string असल्यास nginx request मोजत नाही. त्यामुळे फक्त POST requests zone मध्ये येतात. Signup page अनेकदा उघडणाऱ्या reader चा कोणताही budget खर्च होत नाही. हा map नसता, तर page दोनदा refresh करणाऱ्या व्यक्तीचा form submit करण्यापूर्वीच स्वतःचा budget खर्च झाला असता.

$binary_remote_addr हा client address चा packed form आहे. म्हणून 10 megabyte zone मध्ये साधारण 160,000 addresses ठेवता येतात. rate=2r/m दर तीस सेकंदांनी एक submission अनुमत करते. limit_req_status 429 nginx च्या default 503 ऐवजी HTTP 429 Too Many Requests परत करते. हा योग्य status code आहे आणि client library ला अपेक्षित असतो.

त्यानंतर तुमच्या site साठी असलेल्या server block मध्ये हे जोडा:

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 मुळे button वर double-click करणारी व्यक्ती request करू शकते. चौथी request queue मध्ये ठेवण्याऐवजी ती लगेच reject केली जाते.

sudo nginx -t && sudo systemctl reload nginx

nginx -t ने configuration file /etc/nginx/nginx.conf test is successful print केले पाहिजे. आता form पाच वेळा पटकन submit करा आणि error log monitor करा:

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

Block केलेल्या request साठी एक line लिहिली जाते. तुम्ही शोधत असलेली string ही आहे:

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"

एकही line दिसत नसल्यास limit लागू झालेली नाही. सामान्य कारण असे असते की limit_req हे अशा location block मध्ये आहे, जिथे request पोहोचत नाही. त्यामुळे curl -si -X POST https://news.example.com/subscription/form सलग काही वेळा तपासा आणि तुम्हाला 429 मिळत असल्याची खात्री करा.

Per-IP limit वर अवलंबून राहण्यापूर्वी दोन अडचणी लक्षात ठेवा.

CDN किंवा दुसऱ्या proxy च्या मागे $binary_remote_addr हा तो proxy असतो. प्रत्येक visitor एकाच bucket मध्ये जातो. त्यामुळे प्रत्येक minute मधील सुरुवातीच्या काही submissions नंतर इतर सर्व visitors lock out होतात. हे दुरुस्त करण्यासाठी real IP module वापरा: तुमच्या CDN ने प्रकाशित केलेल्या प्रत्येक range साठी set_real_ip_from (Cloudflare चे ranges cloudflare.com/ips येथे दिले आहेत) आणि real_ip_header CF-Connecting-IP. Access log मधील $remote_addr वाचून दुरुस्तीची खात्री करा. त्यात तुमच्या CDN च्या address ऐवजी visitor चा address दिसला पाहिजे.

IPv6 मुळे per-address limit कमकुवत होते. $binary_remote_addr मध्ये संपूर्ण /128 ठेवले जाते, तर residential IPv6 allocation सहसा /64 किंवा त्याहून मोठे असते. त्यामुळे attacker वापरून पाहू शकणाऱ्या addresses ची संख्या खूप मोठी असते आणि प्रत्येक address कडे स्वतंत्र clean budget असतो. Endpoint वर ceiling म्हणून दुसरा zone जोडा. त्याची key constant वर ठेवा. त्यामुळे कितीही source addresses वापरले तरी form साठी एकूण rate मर्यादित राहतो:

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

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

त्याच location मध्ये limit_req zone=signup_total burst=10 nodelay; जोडा. तुमच्या सर्वाधिक व्यस्त वास्तविक hour पेक्षा rate अधिक ठेवा आणि पुरेशी अतिरिक्त क्षमता ठेवा. हे blunt control आहे. Attack दरम्यान यामुळे वास्तविक signups देखील नाकारले जातात. हा योग्य trade आहे, कारण पर्याय म्हणजे तुमच्या server ने mail पाठवत राहणे.

प्रति-पत्त्याची मर्यादा proxy वर का ठेवता येत नाही

ईमेल पत्ता POST body मध्ये येतो आणि nginx request bodies parse करत नाही. limit_req_zone ज्या प्रत्येक variable वर आधारित key तयार करू शकते, ती request line, headers किंवा connection मधून येते. त्यामुळे "या पत्त्यावर दररोज जास्तीत जास्त एक confirmation पाठवता येईल" असा नियम request body वाचणाऱ्या पहिल्या component मध्ये, म्हणजेच तुमच्या application मध्ये, ठेवावा लागतो.

हा अडथळा टाळण्यासाठी पत्ता query string मध्ये हलवू नका, जेणेकरून $arg_email उपलब्ध होईल. त्यामुळे प्रत्येक subscriber चा पत्ता access log मध्ये cleartext स्वरूपात आणि त्यानंतरच्या कोणत्याही log shipper मध्ये लिहिला जाईल. तुम्ही rate limit च्या बदल्यात privacy problem निर्माण कराल.

एक वास्तविक अपवाद आहे. nginx JavaScript module, njs, request body वाचू शकतो आणि त्यावरून variable सेट करू शकतो. त्यामुळे proxy वर प्रति-पत्त्याची key तयार करता येते. हा खरोखर उपलब्ध पर्याय आहे; परंतु त्यामुळे तुमच्या request path मध्ये नवीन code जोडला जातो. बहुतेक sites साठी प्रति-पत्त्याची मर्यादा त्या database जवळ ठेवणे योग्य आहे, ज्याला या पत्त्यासाठी pending confirmation आहे की नाही हे आधीच माहीत असते. Proxy ने मात्र प्रति-IP आणि प्रति-endpoint मर्यादा हाताळाव्यात, कारण त्या कामासाठी तो योग्य आहे.

सबमिट केलेला मजकूर संदेशात पुन्हा देऊ नका

हल्लेखोराने दिलेली कोणतीही string तुम्ही पाठवता त्या संदेशात ठेवू नका. याची दोन स्वतंत्र कारणे आहेत आणि दोन्हींचा प्रत्यक्ष वापर हल्ल्यांमध्ये झाला आहे.

तुमच्या confirmation email मध्ये form मधून घेतलेल्या नावाने वाचकाला अभिवादन केले, तर हल्लेखोर name field मध्ये स्वतःचा संदेश लिहू शकतो. त्यानंतर तुमचा server तो मजकूर victim पर्यंत तुमच्या domain कडून आणि तुमच्या DKIM (DomainKeys Identified Mail) key ने स्वाक्षरी करून पोहोचवतो. तुमची site दुसऱ्याच्या गैरवापरासाठी delivery service बनते आणि प्राप्तकर्त्याच्या provider ला त्या संदेशावर तुमचा domain दिसतो.

दुसरे कारण अधिक गंभीर आहे. कोणतेही submitted field हाताने mail header मध्ये जोडले, तर त्या field मधील newline character हल्लेखोराच्या पसंतीचे headers जोडू शकते. त्यात Bcc चाही समावेश असू शकतो. आधुनिक mail libraries header values मधील newlines नाकारतात. मात्र shell script मधून text ला sendmail कडे pipe करणारा code अनेकदा असे करत नाही.

सुरक्षित confirmation message मध्ये तुमच्या site चे नाव, एक link आणि एक वाक्यातील स्पष्टीकरण असते. Address स्वतः फक्त mail transfer agent ला आवश्यक असलेल्या ठिकाणी, म्हणजे To header मध्ये, दिसतो. याची चाचणी करा: name field मध्ये newline आणि स्पष्टपणे दिसणारा link देऊन form submit करा. त्यानंतर less वापरून मिळालेला raw message वाचा आणि दोन्हीपैकी कोणताही मजकूर त्यात टिकून राहिला नाही याची तपासणी करा.

तसेच success page प्रत्येक address साठी एकच संदेश दाखवेल अशी खात्री करा. एका address साठी "तुमची subscription आधीच आहे" आणि दुसऱ्यासाठी "तुमचा inbox तपासा" असे दाखवणारे page, तपासण्यासाठी address ची यादी असलेल्या कोणासाठीही तुमचे form membership checker बनवते.

कोणती bot check वापरावी?

परिणामकारकतेइतकाच accessibility चा विचार करून निवड करा. Image-selection captcha अंध वापरकर्ता सोडवू शकत नाही आणि audio fallback सामान्य ऐकण्याची क्षमता असलेल्या लोकांसाठीही कठीण असतो. Legitimate वापरकर्त्याला signup पूर्ण करता येत नसेल, तर अशी check संरक्षणासोबतच अतिरिक्त अडथळाही निर्माण करते. खालील चार पर्याय या क्रमाने वापरून पाहा.

Browser मधील proof of work. Browser असा hash compute करतो, जो server स्वस्तपणे verify करू शकतो. वापरकर्त्याला काहीही सोडवावे लागत नाही. listmonk मध्ये Settings, त्यानंतर Security येथे ALTCHA वापरून ही सुविधा उपलब्ध आहे. यासाठी third-party service आवश्यक नाही. August 2026 पर्यंत, deprecated hCaptcha पर्यायापेक्षा listmonk ची स्वतःची शिफारस ALTCHA वापरण्याची आहे. सर्वाधिक submissions करणाऱ्यावर हा खर्च पडतो आणि तो attacker असतो.

Managed non-interactive check. Cloudflare Turnstile बहुतेक visitors ना काहीही दाखवत नाही. त्याचे signals संशयास्पद वाटले तरच ते challenge दाखवते. हे परिणामकारक आहे; मात्र signup path मध्ये third party समाविष्ट होते.

Honeypot field. असा text input जो वापरकर्त्याला दिसत नाही, पण साधा bot त्यात value भरतो. तुमच्या form मध्ये अन्यत्र वापरलेले नसलेले नाव त्याला द्या. तसेच autocomplete="off", tabindex="-1" आणि aria-hidden="true" सेट करा, जेणेकरून password manager तो भरू शकणार नाही आणि screen reader तो जाहीर करणार नाही. email2 किंवा address नावाच्या field मध्ये browser autofill करतो. त्यामुळे वास्तविक वापरकर्ते reject होऊ शकतात.

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

Time-to-submit check. Page render होताना hidden field मध्ये signed timestamp ठेवा. दोन seconds पेक्षा कमी वेळात आलेले submission reject करा. एखादा वापरकर्ता form वाचून इतक्या वेगाने address type करू शकत नाही. Timestamp sign करा; अन्यथा bot जुना timestamp पाठवेल.

तुम्ही कोणताही पर्याय निवडला तरी एक बाब पडताळा: token फक्त एकदाच वापरता आला पाहिजे. एखाद्या script ने check एकदा सोडवून तो token हजार addresses विरुद्ध replay करता आला, तर त्या check ने फक्त एकदा browser चालला हे सिद्ध केले; त्यापेक्षा अधिक काहीही नाही.

अत्याचार अहवाल येण्यापूर्वी हे कसे शोधाल?

हे hosting provider च्या abuse desk कडून कळण्याऐवजी तुमच्या स्वतःच्या graphs मधून कळले पाहिजे. दोन गोष्टी monitor करा.

पूर्ण log मधील प्रत्येक source address कडून झालेल्या submissions ची संख्या मोजा:

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

त्यानंतर nginx आधीच लिहित असलेल्या त्याच limiting requests lines fail2ban कडून वाचून घ्या आणि वारंवार प्रयत्न करणाऱ्या offenders वर ban लावा. fail2ban मध्ये यासाठी नेमका filter उपलब्ध आहे. /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

status output मध्ये jail चा filter तसेच सध्या failed आणि banned असलेल्या प्रयत्नांची संख्या दिसते. शांत दिवशी Currently banned: 0 दिसणे योग्य आहे. jail अजिबात दिसत नसेल, तर fail2ban ने ती file load केलेली नाही. अशा वेळी sudo fail2ban-client -d | grep nginx-limit-req ने त्याने प्रत्यक्ष parse केलेली configuration दाखवते. उपलब्ध filter प्रत्येक limit_req zone शी match होतो. /etc/fail2ban/filter.d/nginx-limit-req.local मधील [Definition] section मध्ये ngx_limit_req_zones = signup सेट करून तो फक्त तुमच्या signup zone पुरता मर्यादित करा. jail file layout आणि ban commands यांची अधिक सविस्तर माहिती Ubuntu 24.04 साठी fail2ban मार्गदर्शकात दिली आहे.

दुसरा signal म्हणजे ratio. यासाठी नवीन software आवश्यक नाही: submissions भागिले confirmations. निरोगी list मध्ये address submit करणाऱ्या बहुतेक लोकांकडून link वर click केले जाते; सामान्यतः ही संख्या निम्म्यापेक्षा बरीच जास्त असते. Submissions वाढत असताना हा ratio झपाट्याने कमी झाला, तर तुमच्या प्रणालीचा गैरवापर होत आहे. तुम्ही reports ज्या schedule वर आधीच चालवता, त्याच schedule वर मागील तासात तयार झालेल्या unconfirmed subscribers ची संख्या आणि confirmed ones ची संख्या यांची तुलना करा.

तुमच्यावर होणारा परिणाम: sender reputation आणि blocklists

हीच ती बाब आहे जी त्रासाचे रूपांतर खर्चात करते.

बॉम्बिंगसाठी वापरल्या जाणाऱ्या address lists गोळा केलेल्या असतात. अशा lists मध्ये spamtraps असतात. या अशा addresses असतात ज्यांनी कुठेही कशासाठीही signup केलेले नसते. विनापरवानगी mail पाठवणारे senders शोधण्यासाठी त्या मुद्दाम प्रकाशित केल्या जातात. तुमचा confirmation message त्यापैकी एखाद्या address वर पोहोचतो. काही blocklist operators साठी एवढेच पुरेसे असते.

तुमचा message कधीही मागितला नसलेले recipients unsubscribe वर click करत नाहीत. ते "report spam" वर click करतात. February 2024 पासून लागू असलेले Google's bulk sender rules सांगतात की Gmail वर दररोज 5,000 किंवा त्याहून अधिक messages पाठवणाऱ्या senders ने Postmaster Tools मधील reported-spam rate 0.3% पेक्षा कमी ठेवावा. लहान sender चे मोजमाप त्या संख्येच्या आधारे केले जात नाही. तरीही हेच complaint signal तुमचे mail spam folder मध्ये टाकायचे की नाही, या filtering decisions मध्ये वापरले जाते. या run मधील बनावट addresses मुळे hard bounces देखील मोठ्या प्रमाणात होतात. वाढता hard-bounce rate हा प्रत्येक मोठ्या provider कडे स्वतंत्र reputation signal असतो.

तुम्ही VPS वरील mailcow सह स्वतःचा mail server चालवत असाल, तर listing तुमच्या IP address आणि domain वर लागू होते. Spamhaus सारख्या operator कडून delisting साठी form भरावा लागतो आणि प्रतीक्षा करावी लागते. त्या काळात तुमची invoices आणि password resets देखील deliver होत नाहीत. त्याऐवजी तुम्ही shared provider मार्फत mail पाठवत असाल, तर ते प्रथम तुमचे account suspend करतील आणि नंतर तुमचे स्पष्टीकरण वाचतील, अशी अपेक्षा ठेवा. कारण तुमचा traffic त्या IP वरील इतर प्रत्येक sender साठी risk ठरतो.

याच्या तुलनेत करावे लागणारे काम कमी आहे. आजच confirmed opt-in सुरू करा, कारण प्रत्येक list साठी ते एक setting आहे. त्यानंतर proxy rate limit जोडा, कारण त्यासाठी एक file आणि reload पुरेसे आहे. bot check आणि alerting या आठवड्यात नंतर जोडता येतील.

FAQ

Double opt-in मुळे subscription bombing थांबते का?

यामुळे तुमची list दूषित होण्यापासून वाचते आणि प्रत्येक submit केलेल्या address साठी तुमचा सहभाग एका message पुरता मर्यादित राहतो. तुमच्या नियंत्रणातील हा सर्वात मोठा एकल सुधारणा-उपाय आहे. मात्र victim चा inbox भरून जाणे यामुळे थांबत नाही, कारण या हल्ल्यात हजार sites कडून प्रत्येकी एक message येतो. तुमच्या proxy वर per-IP rate limit लागू करा आणि confirmation resends वर कमाल मर्यादा ठेवा. त्यामुळे तोच address दोनदा submit केला तरी दुसरा message तयार होणार नाही.

चांगल्या दिवशी होणाऱ्या वास्तविक signups आणि bombing run मधील फरक कसा ओळखू?

Submission नंतर काय होते ते पहा. वास्तविक signups confirm होतात आणि सामान्यतः काही तासांत confirm होतात. Bombing run मध्ये confirm न होणारे, open न होणारे आणि click न होणारे अनेक addresses साचतात. Submissions च्या पद्धतीतही विचित्रता दिसते: तुम्ही यापूर्वी न पाहिलेले अनेक source addresses, तुम्ही नेहमी message न पाठवणारे recipient domains आणि तुमच्या audience च्या जागे राहण्याच्या वेळांऐवजी संपूर्ण दिवसात समान अंतराने पसरलेल्या arrival times.

Submit केलेले addresses मी delete करावेत का?

होय. सुमारे तीस दिवसांपेक्षा जुने unconfirmed records delete करा आणि हे manually करण्याऐवजी schedule नुसार करा. त्या addresses ना apology किंवा "was this you?" message यांसह इतर कोणतेही message कधीही पाठवू नका. कारण अशा व्यक्तीला, ज्याच्यावर आधीच असे message मोठ्या प्रमाणात आले आहेत, हा दुसरा न मागितलेला message ठरेल. यापैकी कोणतेही addresses spamtraps असतील, तर follow-up म्हणजे blocklist operator ज्याची वाट पाहत आहे असा confirmation ठरेल.

Rate limiting मुळे वास्तविक subscribers नाकारले जातील का?

प्रत्येक IP साठी दर तीस सेकंदांनी एक submission आणि तीन submissions चा burst अशी मर्यादा, एखाद्या व्यक्तीने form एकदाच भरल्यास, तिला जाणवणार नाही. मात्र अनेक वास्तविक व्यक्ती एकच address share करत असतील, उदाहरणार्थ एकाच NAT (network address translation) gateway मागे असलेले office, किंवा तुमच्या proxy ला visitor च्या address ऐवजी तुमच्या CDN चा address दिसत असेल, तर ही मर्यादा जाणवू शकते. कोणतीही मर्यादा कडक करण्यापूर्वी तुमच्या access log मधील $remote_addr वाचा आणि endpoint ची कमाल मर्यादा तुमच्या सर्वाधिक व्यस्त वास्तविक तासापेक्षा जास्त ठेवा.

एका run नंतर माझा sending IP blocklist वर आहे. प्रथम काय करावे?

काहीही request करण्यापूर्वी त्या IP वरून sending थांबवा. Campaign queue pause करा, form दुरुस्त करा आणि unconfirmed addresses delete करा. कारण delisting नंतर पुन्हा त्याच प्रकारचा traffic आल्यास तुम्हाला पहिल्यापेक्षा अधिक वेगाने relist केले जाईल. त्यानंतर तुम्ही कोणत्या list वर आहात ते शोधा. बहुतेक operators तुमच्या IP address वर आधारित lookup page देतात. त्यांच्या removal process चे अनुसरण करा. प्रतीक्षा काही दिवसांची असेल अशी अपेक्षा ठेवा. त्या काळात तुमचा SPF (sender policy framework) record आणि DKIM signing अजूनही pass होत आहेत याची पडताळणी करा.