Subscription bombing को कैसे रोकें

Subscription bombing क्या है?

Subscription bombing एक ऐसा हमला है जो किसी और के इनबॉक्स को भरने के लिए आपके साइनअप फॉर्म का उपयोग करता है। हमलावर पीड़ित का ईमेल पता लेता है और उसे कम समय में सैकड़ों या हजारों असुरक्षित फॉर्मों में सबमिट कर देता है। उन साइटों में से प्रत्येक उस पते पर एक स्वागत संदेश या पुष्टिकरण संदेश भेजती है। ये सभी संदेश मिलकर उन ईमेल को छिपा देते हैं जिन्हें पीड़ित को वास्तव में पढ़ने की आवश्यकता होती है।

इसका लक्ष्य वह व्यक्ति है जिसके पास वह इनबॉक्स है। जब इनबॉक्स सब्सक्रिप्शन पुष्टिकरणों से भर जाता है, तो हमलावर उस व्यक्ति के कार्ड से पैसे खर्च कर रहा होता है या उनके किसी खाते का पासवर्ड रीसेट कर रहा होता है। बैंक से आने वाला धोखाधड़ी का अलर्ट (fraud alert) अभी भी आता है। लेकिन वह उसी घंटे में आए दो हजार अन्य संदेशों के नीचे दब जाता है, इसलिए कोई भी उसे समय पर नहीं देख पाता।

आपका सर्वर वह उपकरण है जिससे यह हमला किया जाता है। आपके सर्वर में कुछ भी खराब नहीं है। आपका कोई भी खाता breached नहीं हुआ है। किसी ने एक सार्वजनिक फॉर्म में एक पता टाइप किया और आपके सॉफ़्टवेयर ने वही किया जिसके लिए उसे लिखा गया था: उसने उस पते पर मेल भेजा। यही कारण है कि इसे पहचानना मुश्किल है। आपके logs में कोई घुसपैठ नहीं होती, क्योंकि कोई घुसपैठ हुई ही नहीं थी।

आपकी तरफ से हमला कैसा दिखता है

यह दो रूपों में आता है।

तेज रूप एक विस्फोट की तरह है। कुछ ही मिनटों के भीतर कई अलग-अलग source IP addresses से एक ही फॉर्म पर सैकड़ों POST requests आती हैं, जिनमें ऐसे domains के addresses होते हैं जिन पर आपने पहले कभी ईमेल नहीं भेजे। एक बार देखने पर इसे पहचानना आसान है।

धीमा रूप वह है जो अक्सर छूट जाता है। हमलावर के पास हजारों vulnerable forms की सूची होती है, इसलिए आपके फॉर्म को प्रति घंटे केवल एक या दो submissions ही भेजने होते हैं। Jye Cusch ने बिल्कुल इसी तरह के एक हमले का वर्णन किया है जो उनकी एक साइट पर हुआ था: इसमें traffic का कोई अचानक उछाल नहीं था, बस ऐसे समय पर लगातार signups आ रहे थे जो उनके audience के व्यवहार से मेल नहीं खाते थे। एक अकेला फॉर्म निर्दोष दिखता है क्योंकि वह लगभग कुछ नहीं कर रहा होता है। नुकसान हमलावर की सूची में मौजूद हर फॉर्म का कुल योग होता है।

दोनों रूपों में बाद में एक ही संकेत मिलता है: आगे कुछ नहीं होता। ये addresses कभी confirm नहीं होते। वे कभी कोई message open नहीं करते और कभी किसी 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

डिफ़ॉल्ट combined log format में $4 ब्रैकेट में दिया गया timestamp होता है, इसलिए यह हर मिनट के लिए गिनती दिखाता है, जिसमें सबसे अधिक संख्या सबसे ऊपर होती है। जिस फॉर्म पर सामान्यतः दिन में चार signups आते हों, यदि उस पर एक मिनट में साठ signups दिखें, तो वह सामान्य स्थिति नहीं है।

Confirmed opt-in: सबसे प्रभावी सुरक्षा उपाय

Confirmed opt-in, जिसे आमतौर पर double opt-in कहा जाता है, का अर्थ है कि जब तक कोई व्यक्ति किसी पते पर भेजे गए संदेश में मौजूद लिंक पर क्लिक नहीं करता, तब तक वह पता subscriber नहीं बनता। इसे चालू करने पर, सबमिट किया गया प्रत्येक पता केवल एक ही संदेश उत्पन्न करता है। वह पता कभी भी सूची में शामिल नहीं होता, इसलिए उसे कभी कोई campaign या welcome sequence प्राप्त नहीं होता।

listmonk, the self-hosted newsletter server में यह प्रति-सूची (per-list) सेटिंग है: एक सूची या तो single opt-in हो सकती है या double opt-in। इसके अंतर के बारे में documentation स्पष्ट है। एक double opt-in सूची पर, subscribers "प्राप्त confirmation e-mail पर क्लिक करके सदस्यता को स्पष्ट रूप से स्वीकार करते हैं। तब तक, उन्हें कोई campaign संदेश प्राप्त नहीं होता।" एक subscriber unconfirmed पर रहता है, क्लिक करने पर confirmed पर चला जाता है, और केवल opt-in सूची के confirmed subscribers को ही campaign mail प्राप्त होते हैं।

इस बात को लेकर ईमानदार रहें कि इससे आपको क्या लाभ मिलता है। Confirmed opt-in आपके योगदान (contribution) को शून्य नहीं करता है। यह इसे प्रति पता केवल एक संदेश तक सीमित कर देता है। पीड़ित को अभी भी वह संदेश प्राप्त होता है, और एक हजार अलग-अलग साइटों से एक-एक संदेश आना ही पूरा हमला है। Confirmed opt-in उसके बाद की हर चीज को हटा देता है: आपकी सूची साफ रहती है, और आप कभी भी ऐसे व्यक्ति को दूसरा संदेश नहीं भेजते जिसने पहले के लिए कभी अनुरोध ही नहीं किया था।

दो और सेटिंग्स मायने रखती हैं और दोनों को भूलना आसान है। पहला, confirmation के पुनः भेजने (resends) की सीमा तय करें। यदि एक ही पते को बार-बार सबमिट किया जा सकता है और हर बार एक और confirmation email प्राप्त हो सकता है, तो हमलावर को एक हजार forms की आवश्यकता नहीं है, क्योंकि केवल आपका form ही एक हजार संदेश भेज देगा। जो पता पहले से ही उस सूची में unconfirmed पर है, उसे कम से कम एक दिन तक कुछ भी नहीं मिलना चाहिए। दूसरा, unconfirmed पंक्तियों (rows) को एक schedule पर हटा दें। जो पता तीस दिनों में confirm नहीं हुआ है, वह pending subscriber नहीं है। उसे बनाए रखने से केवल यह संभावना पैदा होती है कि बाद में गलती से उसे कुछ मेल हो जाए।

रिवर्स प्रॉक्सी पर साइनअप फॉर्म को रेट लिमिट करें

लिमिट को एप्लिकेशन के अंदर रखने के बजाय उसके सामने रखें। प्रॉक्सी पर ब्लॉक की गई रिक्वेस्ट कभी भी डेटाबेस कनेक्शन नहीं खोलती और न ही SMTP (simple mail transfer protocol) कन्वर्सेशन शुरू करती है। एप्लिकेशन के अंदर की लिमिट तब चलती है जब रिक्वेस्ट पहले ही आपके वर्कर प्रोसेस और क्वेरी का खर्च उठा चुकी होती है, और कई स्टैक में तो किसी भी एब्यूज चेक के चलने से पहले ही मैसेज को क्यू (queue) में डाल दिया जाता है। प्रॉक्सी लिमिट एप्लिकेशन अपग्रेड के बाद भी बनी रहती है, क्योंकि यह उस कोड में नहीं होती जिसे आप बदलते हैं।

नीचे दिया गया उदाहरण nginx का है। यह विचार उस रिवर्स प्रॉक्सी पर भी लागू होता है जिसे आप अपने ऐप के सामने चलाते हैं, हालांकि डायरेक्टिव के नाम अलग हो सकते हैं।

इसे http ब्लॉक में रखें, जैसे कि /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 वास्तविक काम कर रहा है। nginx उस रिक्वेस्ट को काउंट नहीं करता जिसकी की (key) खाली स्ट्रिंग हो, इसलिए केवल POST रिक्वेस्ट ही ज़ोन में प्रवेश करती हैं। साइनअप पेज को कई बार लोड करने वाले रीडर का कुछ भी खर्च नहीं होता। उस मैप के बिना, जो व्यक्ति पेज को दो बार रिफ्रेश करेगा, वह कुछ भी सबमिट करने से पहले ही अपना बजट खत्म कर लेगा।

$binary_remote_addr पैक्ड फॉर्म में क्लाइंट एड्रेस है, यही कारण है कि 10 मेगाबाइट का ज़ोन लगभग 160,000 एड्रेस रख सकता है। rate=2r/m हर तीस सेकंड में एक सबमिशन की अनुमति देता है। limit_req_status 429 nginx के डिफ़ॉल्ट 503 के बजाय HTTP 429 Too Many Requests रिटर्न करता है, जो कि सही कोड है और जिसकी क्लाइंट लाइब्रेरी अपेक्षा करती है।

फिर अपनी साइट के लिए server ब्लॉक में:

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 बटन पर डबल-क्लिक करने वाले व्यक्ति को जाने देता है, और चौथी रिक्वेस्ट को क्यू में डालने के बजाय तुरंत रिजेक्ट कर देता है।

sudo nginx -t && sudo systemctl reload nginx

nginx -t को configuration file /etc/nginx/nginx.conf test is successful प्रिंट करना चाहिए। अब फॉर्म को पांच बार जल्दी-जल्दी सबमिट करें और एरर लॉग देखें:

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

एक ब्लॉक की गई रिक्वेस्ट एक लाइन लिखती है, और यह वह स्ट्रिंग है जिसे आप ढूंढ रहे हैं:

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"

कोई भी लाइन न दिखने का मतलब है कि लिमिट लागू नहीं हो रही है। इसका सामान्य कारण यह है कि limit_req ऐसे location ब्लॉक में स्थित है जहाँ रिक्वेस्ट कभी पहुँचती ही नहीं है, इसलिए curl -si -X POST https://news.example.com/subscription/form को लगातार कुछ बार चलाकर जाँचें और पुष्टि करें कि आपको 429 मिल रहा है।

प्रति-IP लिमिट पर निर्भर होने से पहले दो बातों का ध्यान रखना जरूरी है।

CDN या किसी अन्य प्रॉक्सी के पीछे, $binary_remote_addr वह प्रॉक्सी ही होता है। हर विज़िटर एक ही बकेट में आ जाता है, इसलिए हर मिनट की पहली कुछ सबमिशन बाकी सभी को लॉक आउट कर देती हैं। इसे रियल IP मॉड्यूल के साथ ठीक करें: अपने CDN की प्रत्येक पब्लिश्ड रेंज के लिए set_real_ip_from (Cloudflare अपनी रेंज cloudflare.com/ips पर लिस्ट करता है) और real_ip_header CF-Connecting-IP का उपयोग करें। अपने एक्सेस लॉग में $remote_addr को पढ़कर और यह पुष्टि करके कि यह विज़िटर का एड्रेस है न कि आपके CDN का, फिक्स की पुष्टि करें।

IPv6 प्रति-एड्रेस लिमिट को कमजोर बनाता है। $binary_remote_addr पूरा /128 रखता है, और रेजिडेंशियल IPv6 एलोकेशन आमतौर पर /64 या उससे बड़ा होता है। यह उन एड्रेस की तुलना में बहुत अधिक है जिनसे एक हमलावर काम कर सकता है, और हर एड्रेस का अपना अलग बजट होता है। एंडपॉइंट पर ही एक सीलिंग के रूप में दूसरा ज़ोन जोड़ें, जो एक कांस्टेंट पर आधारित हो, ताकि फॉर्म की कुल रेट वही रहे चाहे कितने भी सोर्स एड्रेस इस्तेमाल में हों:

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

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

limit_req zone=signup_total burst=10 nodelay; को उसी location में जोड़ें। रेट को अपने सबसे व्यस्त वास्तविक घंटे से ऊपर सेट करें, जिसमें थोड़ा मार्जिन भी हो। यह एक सख्त नियंत्रण है: हमले के दौरान यह वास्तविक साइनअप को भी लौटा देता है। यह सही समझौता है, क्योंकि इसका विकल्प यह है कि आपका सर्वर मेल भेजता रहे।

प्रति-पता सीमा (per-address limit) प्रॉक्सी पर क्यों नहीं हो सकती

ईमेल पता POST बॉडी के अंदर आता है, और Nginx रिक्वेस्ट बॉडी को पार्स नहीं करता है। limit_req_zone जिन भी वेरिएबल्स का उपयोग कर सकता है, वे रिक्वेस्ट लाइन, हेडर्स या कनेक्शन से आते हैं। इसलिए, "यह पता प्रति दिन अधिकतम एक कन्फर्मेशन प्राप्त कर सकता है" जैसा नियम उस पहले घटक में होना चाहिए जो बॉडी को पढ़ता है, जो कि आपका एप्लिकेशन है।

इसे हल करने के लिए पते को क्वेरी स्ट्रिंग में न डालें ताकि $arg_email उपलब्ध हो सके। ऐसा करने से हर सब्सक्राइबर का पता आपके एक्सेस लॉग में प्लेनटेक्स्ट में और उसके बाद के किसी भी लॉग शिपर में चला जाएगा। आप एक रेट लिमिट के बदले प्राइवेसी की समस्या खड़ी कर लेंगे।

इसका एक वास्तविक अपवाद है। Nginx JavaScript मॉड्यूल, njs, रिक्वेस्ट बॉडी को पढ़ सकता है और उससे एक वेरिएबल सेट कर सकता है, जो आपको प्रॉक्सी पर प्रति-पता की (per-address key) बनाने की सुविधा देता है। यह एक वास्तविक विकल्प है और यह आपके रिक्वेस्ट पाथ में नया कोड भी है। अधिकांश साइटों के लिए, प्रति-पता सीमा उस डेटाबेस के पास होनी चाहिए जिसे पहले से पता है कि इस पते के लिए कोई कन्फर्मेशन लंबित है या नहीं, जबकि प्रॉक्सी उन प्रति-IP और प्रति-एंडपॉइंट सीमाओं को संभालता है जिनमें वह सक्षम है।

सबमिट किए गए टेक्स्ट को संदेश में न दोहराएं

आक्रमणकारी द्वारा प्रदान की गई किसी भी स्ट्रिंग को अपने संदेश से बाहर रखें। इसके दो अलग-अलग कारण हैं और दोनों का उपयोग वास्तविक हमलों में किया जा चुका है।

यदि आपका पुष्टिकरण ईमेल फॉर्म से लिए गए नाम के साथ पाठक का अभिवादन करता है, तो आक्रमणकारी अपना संदेश नाम फ़ील्ड में लिख देता है। आपका सर्वर तब उस टेक्स्ट को आपके डोमेन से पीड़ित को भेजता है, जिस पर आपकी DKIM (DomainKeys Identified Mail) कुंजी के हस्ताक्षर होते हैं। आपकी साइट किसी और के दुरुपयोग के लिए एक डिलीवरी सेवा बन जाती है, और प्राप्त करने वाला प्रदाता उस पर आपका डोमेन देखता है।

दूसरा कारण और भी गंभीर है। यदि कोई सबमिट किया गया फ़ील्ड मैन्युअल रूप से मेल हेडर में जोड़ा जाता है, तो उस फ़ील्ड में एक न्यूलाइन कैरेक्टर आक्रमणकारी द्वारा चुने गए हेडर को जोड़ देता है, जिसमें Bcc भी शामिल है। आधुनिक मेल लाइब्रेरी हेडर मानों में न्यूलाइन को अस्वीकार कर देती हैं। जो कोड शेल स्क्रिप्ट से sendmail में टेक्स्ट पाइप करता है, वह अक्सर ऐसा नहीं करता है।

एक सुरक्षित पुष्टिकरण संदेश में आपकी साइट का नाम और एक लिंक होता है, साथ ही स्पष्टीकरण का एक वाक्य होता है। पता केवल वहीं दिखाई देता है जहाँ मेल ट्रांसफर एजेंट को इसकी आवश्यकता होती है, यानी To हेडर में। इसका परीक्षण करें: फॉर्म को एक ऐसे नाम फ़ील्ड के साथ सबमिट करें जिसमें न्यूलाइन और एक स्पष्ट लिंक हो, फिर less के साथ प्राप्त रॉ संदेश को पढ़ें और जांचें कि उनमें से कोई भी जीवित नहीं बचा है।

जब आप वहां हों, तो सफलता पृष्ठ को हर पते के लिए एक ही बात कहने दें। एक पृष्ठ जो एक पते के लिए "आप पहले से ही सब्सक्राइब हैं" और दूसरे के लिए "अपना इनबॉक्स चेक करें" कहता है, वह आपके फॉर्म को उन लोगों के लिए सदस्यता चेकर में बदल देता है जिनके पास परीक्षण करने के लिए पतों की सूची है।

आपको कौन सा bot check उपयोग करना चाहिए?

प्रभावशीलता के साथ-साथ सुलभता (accessibility) का भी उतना ही ध्यान रखें। एक दृष्टिहीन पाठक image-selection captcha को हल नहीं कर सकता, और सामान्य श्रवण क्षमता वाले लोगों के लिए भी audio fallback कठिन होता है। जो check किसी वैध व्यक्ति का signup रोक दे, वह सुरक्षा के साथ-साथ एक बाधा भी है। यहाँ चार विकल्प दिए गए हैं, जिन्हें इसी क्रम में आज़माना चाहिए।

Browser में proof of work. Browser एक ऐसा hash compute करता है जिसे server आसानी से verify कर सकता है, और इसमें व्यक्ति को कुछ भी हल करने की आवश्यकता नहीं होती। listmonk इसे Settings में, फिर Security के अंतर्गत ALTCHA का उपयोग करके प्रदान करता है, जिसके लिए किसी third-party service की आवश्यकता नहीं होती। अगस्त 2026 तक, listmonk अपने deprecated hCaptcha विकल्प के बजाय इसी की अनुशंसा करता है। इसकी लागत उसी पर पड़ती है जो सबसे अधिक submissions भेजता है, यानी attacker पर।

एक managed non-interactive check. Cloudflare Turnstile अधिकांश visitors को कुछ भी नहीं दिखाता और केवल तभी challenge करता है जब signals संदिग्ध हों। यह प्रभावी है, लेकिन यह आपके signup path में एक third-party को शामिल करता है।

एक honeypot field. यह एक ऐसा text input है जिसे व्यक्ति कभी नहीं देखता, लेकिन एक साधारण bot उसे भर देता है। इसे ऐसा नाम दें जिसका उपयोग आपके 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 डालें, और दो सेकंड से कम समय में आने वाली submission को reject कर दें। कोई भी व्यक्ति इतनी तेज़ी से form नहीं पढ़ सकता और address टाइप नहीं कर सकता। Timestamp को sign करें, अन्यथा bot बस एक पुराना timestamp भेज देगा।

आप जो भी चुनें, एक बात अवश्य verify करें: token का उपयोग केवल एक बार होना चाहिए। यदि कोई script एक बार check हल करके उस token को हज़ार addresses के खिलाफ replay कर सकती है, तो उस check ने केवल यह साबित किया कि एक बार browser चला था, और कुछ नहीं।

abuse report आने से पहले आप इसका पता कैसे लगाएँ?

आप चाहते हैं कि आपका अपना ग्राफ आपको सूचित करे, न कि किसी होस्टिंग प्रदाता का abuse desk। दो चीजों पर नजर रखें।

लॉग में प्रत्येक source address से होने वाले submissions की गिनती करें:

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

इसके बाद fail2ban को वही limiting requests लाइनें पढ़ने दें जिन्हें nginx पहले से लिख रहा है, और बार-बार गलती करने वालों को 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 आउटपुट में jail का filter और उसकी वर्तमान failed और banned गिनती दिखाई देती है। शांत दिन पर Currently banned: 0 होना सही है। यदि jail बिल्कुल दिखाई नहीं देती है, तो fail2ban ने फाइल लोड नहीं की है, और sudo fail2ban-client -d | grep nginx-limit-req उस कॉन्फ़िगरेशन को डंप करता है जिसे उसने वास्तव में पार्स किया है। प्रदान किया गया filter हर limit_req ज़ोन से मेल खाता है। इसे अपने signup ज़ोन तक सीमित करने के लिए /etc/fail2ban/filter.d/nginx-limit-req.local के [Definition] सेक्शन में ngx_limit_req_zones = signup सेट करें। jail फाइल लेआउट और ban कमांड के बारे में अधिक जानकारी Ubuntu 24.04 के लिए fail2ban गाइड में दी गई है।

दूसरा संकेत एक अनुपात है और इसके लिए किसी नए सॉफ़्टवेयर की आवश्यकता नहीं है: submissions को confirmations से विभाजित करें। एक स्वस्थ लिस्ट पर, पता सबमिट करने वाले अधिकांश लोग लिंक पर क्लिक करते हैं, आमतौर पर आधे से अधिक। जब submissions बढ़ने के साथ यह अनुपात गिरता है, तो आपका दुरुपयोग हो रहा है। पिछले एक घंटे में बनाए गए unconfirmed सब्सक्राइबर्स की गिनती की तुलना confirmed सब्सक्राइबर्स की गिनती से करें, उस शेड्यूल पर जिस पर आप पहले से रिपोर्ट चलाते हैं।

इसका मूल्य: सेंडर रेपुटेशन और ब्लॉकलिस्ट

यह वह हिस्सा है जो एक परेशानी को वित्तीय नुकसान में बदल देता है।

बमबारी (bombing) के लिए उपयोग की जाने वाली एड्रेस लिस्ट को हार्वेस्ट किया जाता है, और हार्वेस्ट की गई लिस्ट में spamtraps होते हैं: ऐसे पते जिन्होंने कभी कहीं भी साइन-अप नहीं किया, जिन्हें केवल उन सेंडर्स को पकड़ने के लिए प्रकाशित किया जाता है जो बिना अनुमति के मेल भेजते हैं। आपका कन्फर्मेशन मैसेज इनमें से किसी एक तक पहुँच जाता है। कुछ ब्लॉकलिस्ट ऑपरेटर्स के लिए केवल इतना ही काफी होता है।

जिन प्राप्तकर्ताओं ने आपका मैसेज नहीं मांगा, वे unsubscribe पर क्लिक नहीं करते। वे "report spam" पर क्लिक करते हैं। फरवरी 2024 से लागू Google के बल्क सेंडर नियमों के अनुसार, Gmail पर प्रतिदिन 5,000 या उससे अधिक मैसेज भेजने वाले सेंडर्स को Postmaster Tools में रिपोर्ट किए गए स्पैम की दर 0.3% से नीचे रखनी होती है। एक छोटे सेंडर को इस संख्या के आधार पर नहीं मापा जाता है, लेकिन वही शिकायत सिग्नल उन फिल्टरिंग निर्णयों को प्रभावित करता है जो आपके मेल को स्पैम फोल्डर में डाल देते हैं। इस प्रक्रिया में नकली पते hard bounce भी होते हैं, और बढ़ती hard-bounce दर हर बड़े प्रदाता के लिए एक रेपुटेशन सिग्नल होती है।

यदि आप mailcow के साथ VPS पर अपना खुद का मेल सर्वर चलाते हैं, तो लिस्टिंग आपके IP एड्रेस और आपके डोमेन पर आती है। Spamhaus जैसे ऑपरेटर के साथ delisting का मतलब है एक फॉर्म भरना और प्रतीक्षा करना, और जब तक आप प्रतीक्षा करते हैं, तब तक आपके इनवॉइस और पासवर्ड रीसेट भी डिलीवर नहीं हो रहे होते हैं। यदि आप इसके बजाय किसी शेयर्ड प्रदाता के माध्यम से मेल भेजते हैं, तो उम्मीद करें कि वे पहले आपका अकाउंट सस्पेंड करेंगे और बाद में आपका स्पष्टीकरण पढ़ेंगे, क्योंकि आपका ट्रैफिक उस IP पर मौजूद हर दूसरे सेंडर के लिए जोखिम है।

इसके मुकाबले, काम बहुत छोटा है। आज ही confirmed opt-in चालू करें, क्योंकि यह प्रति लिस्ट केवल एक सेटिंग है। इसके बाद proxy rate limit जोड़ें, क्योंकि यह केवल एक फाइल और एक रिलोड का काम है। बॉट चेक और अलर्टिंग को इस सप्ताह पूरा किया जा सकता है।

FAQ

क्या double opt-in subscription bombing को रोकता है?

यह आपकी लिस्ट को दूषित होने से रोकता है और प्रति सबमिट किए गए पते पर आपके योगदान को एक संदेश तक सीमित करता है, जो आपके लिए उपलब्ध सबसे बड़ा सुधार है। यह पीड़ित के इनबॉक्स को भरने से नहीं रोकता है, क्योंकि हमला एक हजार साइटों में से प्रत्येक से एक संदेश का योग होता है। इसे अपने प्रॉक्सी पर प्रति-IP rate limit और confirmation resends पर एक सीमा के साथ जोड़ें, ताकि एक ही पता दो बार सबमिट करने पर दूसरा संदेश न जाए।

मैं bombing run और वास्तविक signups के अच्छे दिन के बीच अंतर कैसे बताऊं?

सबमिशन के बाद क्या होता है, इसे देखें। वास्तविक signups पुष्टि करते हैं, और वे आमतौर पर घंटों के भीतर पुष्टि करते हैं। एक bombing run उन पतों का ढेर छोड़ देती है जो कभी पुष्टि नहीं करते, कभी नहीं खुलते और कभी क्लिक नहीं किए जाते। सबमिशन अजीब तरह से क्लस्टर भी होते हैं: कई स्रोत पते जो आपने कभी नहीं देखे, प्राप्तकर्ता डोमेन जिन पर आप आमतौर पर नहीं भेजते हैं, और आगमन का समय आपके दर्शकों के जागने के घंटों का पालन करने के बजाय पूरे दिन समान रूप से फैला होता है।

क्या मुझे सबमिट किए गए पतों को हटा देना चाहिए?

हाँ। लगभग तीस दिनों से पुराने अपुष्ट रिकॉर्ड्स को हटा दें, और इसे मैन्युअल रूप से करने के बजाय एक शेड्यूल पर करें। उन पतों पर कभी भी कुछ और न भेजें, जिसमें माफी या "क्या यह आप थे?" संदेश शामिल है, क्योंकि यह किसी ऐसे व्यक्ति के लिए दूसरा अनचाहा संदेश है जो पहले से ही उनमें दबा हुआ है। यदि उन पतों में से कोई भी spamtraps था, तो एक फॉलो-अप वह पुष्टि है जिसका blocklist ऑपरेटर इंतजार कर रहा है।

क्या rate limiting वास्तविक subscribers को अस्वीकार कर देगा?

तीस सेकंड में एक सबमिशन की प्रति-IP सीमा, तीन के बर्स्ट के साथ, एक बार फॉर्म भरने वाले व्यक्ति के लिए अदृश्य है। यह तब दिखाई देता है जब कई वास्तविक लोग एक पते को साझा करते हैं, जैसे कि एक NAT (network address translation) गेटवे के पीछे का कार्यालय, या जब आपका प्रॉक्सी आगंतुक के बजाय आपके CDN का पता देखता है। कुछ भी कड़ा करने से पहले अपने access log में $remote_addr पढ़ें, और endpoint ceiling को अपने सबसे व्यस्त वास्तविक घंटे से ऊपर रखें।

हमले के बाद मेरा sending IP एक blocklist पर है। मुझे सबसे पहले क्या करना चाहिए?

कुछ भी अनुरोध करने से पहले उससे भेजना बंद करें। campaign queue को रोकें, फॉर्म को ठीक करें, और अपुष्ट पतों को हटा दें, क्योंकि delisting के बाद उसी तरह का और अधिक traffic आपको पहली बार की तुलना में तेजी से relist करवाता है। फिर पता लगाएं कि आप किस लिस्ट में हैं, क्योंकि अधिकांश ऑपरेटरों के पास आपके IP address पर आधारित एक lookup पेज होता है, और उनकी removal प्रक्रिया का पालन करें। प्रतीक्षा के दिनों में होने की उम्मीद करें, और उस समय का उपयोग यह सुनिश्चित करने के लिए करें कि आपका SPF (sender policy framework) रिकॉर्ड और आपका DKIM signing दोनों अभी भी पास हो रहे हैं।