Signup forms پر subscription bombing کیسے روکیں

سبسکرپشن بمبنگ کیا ہے؟

سبسکرپشن بمبنگ ایسا حملہ ہے جس میں آپ کے signup form کو استعمال کرکے کسی دوسرے شخص کے inbox کو پیغامات سے بھر دیا جاتا ہے۔ حملہ آور ایک متاثرہ شخص کا email address لیتا ہے اور مختصر مدت میں اسے سینکڑوں یا ہزاروں غیر محفوظ forms میں submit کرتا ہے۔ ان میں سے ہر site اس address پر welcome message یا confirmation message بھیجتی ہے۔ یہ تمام پیغامات مل کر وہ mail چھپا دیتے ہیں جسے متاثرہ شخص کو حقیقت میں پڑھنا ہوتا ہے۔

حملے کا ہدف اس inbox کا مالک ہوتا ہے۔ جب inbox subscription confirmations سے بھر رہا ہوتا ہے، حملہ آور اس شخص کے card سے رقم خرچ کر رہا ہوتا ہے یا اس کے کسی account کا password reset کر رہا ہوتا ہے۔ بینک کا fraud alert پھر بھی پہنچتا ہے۔ لیکن اسی گھنٹے میں آنے والے دو ہزار دیگر messages کے نیچے دب جانے کی وجہ سے اسے بروقت کوئی نہیں دیکھتا۔

آپ کا server اس حملے کے لیے استعمال ہونے والا tool ہے۔ آپ کے box میں کوئی خرابی نہیں ہوتی۔ آپ کا کوئی account breach نہیں ہوا ہوتا۔ کسی نے public form میں ایک address درج کیا، اور آپ کے software نے وہی کام کیا جس کے لیے اسے لکھا گیا تھا: اس address پر mail بھیج دیا۔ یہی وجہ ہے کہ اس حملے کا پتا لگانا مشکل ہوتا ہے۔ آپ کے logs میں کوئی intrusion نہیں ہوتا، کیونکہ intrusion ہوا ہی نہیں ہوتا۔

حملہ آپ کی جانب سے کیسا دکھائی دیتا ہے

یہ دو میں سے کسی ایک شکل میں آتا ہے۔

واضح شکل ایک اچانک تیز حملہ ہوتی ہے۔ چند منٹ کے اندر ایک ہی فارم پر کئی سو POST requests آتی ہیں۔ یہ requests بہت سے مختلف source IP addresses سے آتی ہیں اور ان میں ایسے domains کے addresses شامل ہوتے ہیں جنہیں آپ نے پہلے کبھی کوئی message نہیں بھیجا۔ جب آپ لاگز دیکھتے ہیں تو اس شکل کو پہچاننا آسان ہوتا ہے۔

خاموش شکل اکثر نظر انداز ہو جاتی ہے۔ حملہ آور کے پاس ہزاروں vulnerable forms کی فہرست ہوتی ہے، اس لیے آپ کے فارم سے ہر گھنٹے صرف ایک یا دو submissions کافی ہوتی ہیں۔ Jye Cusch نے اپنی چلائی ہوئی site پر بالکل اسی نوعیت کے حملے کی وضاحت کی ہے: traffic spike نہیں تھا، صرف مسلسل signups آ رہے تھے اور ان کے اوقات اس کی audience کے معمول سے مطابقت نہیں رکھتے تھے۔ ایک فارم الگ سے بے ضرر دکھائی دیتا ہے، کیونکہ وہ تقریباً کوئی کام نہیں کر رہا ہوتا۔ اصل نقصان حملہ آور کی فہرست میں شامل تمام forms کے مجموعی اثر سے ہوتا ہے۔

بعد میں دونوں شکلوں میں ایک ہی علامت نظر آتی ہے: اس کے بعد کچھ نہیں ہوتا۔ یہ 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 bracketed timestamp ہوتا ہے، اس لیے یہ command ہر منٹ کی count دکھاتی ہے، زیادہ count پہلے۔ جو فارم عام طور پر روزانہ چار signups لیتا ہو، اگر وہ ایک منٹ میں ساٹھ signups دکھائے، تو یہ معمول کا دن نہیں ہے۔

تصدیق شدہ opt-in: سب سے مؤثر دفاع

تصدیق شدہ opt-in، جسے عموماً double opt-in کہا جاتا ہے، کا مطلب ہے کہ کوئی address اس وقت تک subscriber نہیں بنتا جب تک کوئی شخص اسی address پر بھیجے گئے message میں موجود link پر click نہ کرے۔ اسے فعال کرنے کے بعد جمع کرایا گیا ہر address زیادہ سے زیادہ ایک message پیدا کرتا ہے۔ وہ address فہرست میں شامل نہیں ہوتا، اس لیے اسے کوئی campaign یا welcome sequence موصول نہیں ہوتی۔

listmonk، self-hosted newsletter server میں یہ ہر list کی الگ setting ہے: کوئی list single opt-in یا double opt-in ہوتی ہے۔ documentation اس فرق کو واضح طور پر بیان کرتی ہے۔ double opt-in list میں subscribers "confirmation e-mail پر click کر کے subscription قبول کرتے ہیں۔ اس وقت تک انہیں campaign messages موصول نہیں ہوتے۔" کوئی subscriber unconfirmed حالت میں رہتا ہے، click کرنے کے بعد confirmed میں منتقل ہوتا ہے، اور opt-in list پر صرف confirmed subscribers کو campaign mail ملتی ہے۔

اس سے حاصل ہونے والے فائدے کے بارے میں حقیقت پسند رہیں۔ Confirmed opt-in آپ کی ذمہ داری کو صفر نہیں کرتا۔ یہ اسے ہر address کے لیے ایک message تک محدود کر دیتا ہے۔ متاثرہ شخص کو وہ message پھر بھی موصول ہوتا ہے، اور ایک ہزار sites سے ایک ایک message ہی مکمل attack ہوتا ہے۔ Confirmed opt-in جس چیز کو ختم کرتا ہے وہ اس کے بعد کے تمام messages ہیں: آپ کی list صاف رہتی ہے، اور آپ کسی ایسے شخص کو دوسرا message نہیں بھیجتے جس نے پہلے message کی درخواست نہیں کی تھی۔

دو مزید settings اہم ہیں اور دونوں کو بھولنا آسان ہے۔ پہلی setting confirmation کے resends کی حد مقرر کرنے سے متعلق ہے۔ اگر وہی address دوبارہ submit کیا جا سکتا ہو اور ہر بار اسے ایک اور confirmation email ملتی ہو، تو attacker کو ایک ہزار forms کی ضرورت نہیں، کیونکہ صرف آپ کا form ہی ایک ہزار messages بھیج دے گا۔ اس list پر پہلے سے unconfirmed حالت میں موجود address کو کم از کم ایک دن تک مزید کوئی message نہیں ملنا چاہیے۔ دوسری setting unconfirmed rows کو مقررہ schedule کے مطابق حذف کرنے سے متعلق ہے۔ جو address تیس دن میں confirm نہ ہوا ہو، وہ pending subscriber نہیں ہے۔ اسے محفوظ رکھنا بعد میں غلطی سے کوئی message بھیجے جانے کا امکان پیدا کرتا ہے۔

ریورس پراکسی پر signup form کی rate limit مقرر کریں

یہ limit ایپلیکیشن کے اندر نہیں بلکہ اس کے سامنے لگائیں۔ پراکسی پر block ہونے والی request کبھی database connection نہیں کھولتی اور نہ ہی SMTP (simple mail transfer protocol) conversation شروع کرتی ہے۔ ایپلیکیشن کے اندر لگائی گئی limit اس وقت لاگو ہوتی ہے جب request پہلے ہی ایک worker process اور query استعمال کر چکی ہوتی ہے، اور بہت سے stacks میں abuse check چلنے سے پہلے ہی message queue میں شامل ہو جاتا ہے۔ پراکسی کی limit application upgrade کے بعد بھی برقرار رہتی ہے، کیونکہ یہ اس code کا حصہ نہیں ہوتی جسے آپ replace کرتے ہیں۔

ذیل کی مثال nginx کی ہے۔ یہی تصور اس 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 اصل کام انجام دے رہا ہے۔ nginx اس request کو count نہیں کرتا جس کی key empty string ہو، اس لیے صرف POST requests zone میں داخل ہوتی ہیں۔ signup page کو کئی بار load کرنے والا reader کچھ خرچ نہیں کرتا۔ اس map کے بغیر، جو شخص page کو دو بار refresh کرتا، وہ form submit کرنے سے پہلے ہی اپنا budget استعمال کر دیتا۔

$binary_remote_addr packed form میں client address ہے، اسی لیے 10 megabyte zone تقریباً 160,000 addresses رکھتی ہے۔ rate=2r/m ہر تیس seconds میں ایک submission کی اجازت دیتا ہے۔ limit_req_status 429 nginx کے default 503 کے بجائے HTTP 429 Too Many Requests واپس کرتا ہے۔ یہی درست 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 کو 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

Blocked 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 کے بعد باقی سب lock out ہو جاتے ہیں۔ اسے real IP module کے ذریعے درست کریں: اپنے CDN کی شائع کردہ ہر range کے لیے set_real_ip_from (Cloudflare اپنی ranges cloudflare.com/ips پر درج کرتا ہے) اور real_ip_header CF-Connecting-IP۔ $remote_addr کو access log میں پڑھ کر تصدیق کریں کہ یہ CDN کے address کے بجائے visitor کا address ہے۔

IPv6 کی وجہ سے per-address limit کمزور ہو جاتی ہے۔ $binary_remote_addr مکمل /128 رکھتا ہے، جبکہ residential IPv6 allocation عموماً /64 یا اس سے بڑا ہوتا ہے۔ یہ اتنے زیادہ addresses ہیں کہ attacker ان میں سے بہت سے استعمال کر سکتا ہے، اور ہر address کا budget الگ ہوتا ہے۔ endpoint پر ceiling لگانے کے لیے ایک دوسری zone شامل کریں۔ اسے constant key پر مبنی بنائیں، تاکہ 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; شامل کریں۔ Rate کو اپنی مصروف ترین حقیقی hour کی شرح سے زیادہ رکھیں اور کچھ اضافی گنجائش بھی چھوڑیں۔ یہ ایک سخت control ہے: attack کے دوران یہ حقیقی signups کو بھی روک دے گا۔ یہی درست trade-off ہے، کیونکہ متبادل صورت میں server mail بھیجتا رہے گا۔

پتے کی بنیاد پر حد proxy میں کیوں نہیں لگائی جا سکتی

ای میل address POST body کے اندر آتا ہے، اور nginx request bodies کو parse نہیں کرتا۔ ہر variable limit_req_zone جس کی بنیاد پر key بنائی جا سکتی ہے، request line، headers یا connection سے آتا ہے۔ اس لیے "اس address کو روزانہ زیادہ سے زیادہ ایک confirmation بھیجی جا سکتی ہے" جیسا rule اس پہلے component میں ہونا چاہیے جو body پڑھتا ہے، یعنی آپ کی application میں۔

اس مسئلے کا workaround کرنے کے لیے address کو query string میں منتقل نہ کریں تاکہ $arg_email دستیاب ہو جائے۔ اس سے ہر subscriber کا address آپ کے access log میں cleartext کی صورت میں، اور اس کے بعد موجود ہر log shipper میں، لکھا جائے گا۔ آپ rate limit کے بدلے privacy کا مسئلہ پیدا کر دیں گے۔

ایک حقیقی exception موجود ہے۔ nginx JavaScript module، njs، request body پڑھ سکتا ہے اور اس سے variable set کر سکتا ہے۔ اس طرح proxy میں address کی بنیاد پر key بنائی جا سکتی ہے۔ یہ واقعی قابل عمل option ہے، لیکن اس سے request path میں نیا code بھی شامل ہوتا ہے۔ زیادہ تر sites میں address کی بنیاد پر cap اس database کے قریب ہونی چاہیے جو پہلے ہی جانتا ہے کہ اس address کے لیے pending confirmation موجود ہے یا نہیں۔ Proxy کو per-IP اور per-endpoint limits سنبھالنی چاہییں، کیونکہ وہ کام proxy بہتر طور پر کرتا ہے۔

جمع کرائے گئے متن کو پیغام میں دوبارہ شامل نہ کریں

صارف کی طرف سے فراہم کردہ ہر string کو اپنے بھیجے گئے پیغام سے باہر رکھیں۔ اس کی دو الگ وجوہات ہیں، اور حقیقی حملوں میں دونوں طریقے استعمال ہو چکے ہیں۔

اگر آپ کی confirmation email، form سے حاصل کردہ نام کے ذریعے وصول کنندہ کو مخاطب کرتی ہے، تو attacker نام کے field میں اپنا پیغام لکھ سکتا ہے۔ اس کے بعد server یہ متن victim تک آپ کے domain سے پہنچاتا ہے اور اس پر آپ کی DKIM (DomainKeys Identified Mail) key سے دستخط ہوتے ہیں۔ آپ کی site کسی اور کے abuse کے لیے delivery service بن جاتی ہے، اور وصول کنندہ کا provider اس پیغام پر آپ کا domain دیکھتا ہے۔

دوسری وجہ زیادہ سنگین ہے۔ اگر کسی submitted field کو ہاتھ سے mail header میں جوڑا جائے، تو اس field میں موجود newline character attacker کے منتخب کردہ headers شامل کر سکتا ہے، جن میں Bcc بھی شامل ہے۔ جدید mail libraries header values میں newline کو مسترد کرتی ہیں۔ لیکن shell script سے متن کو 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 کے لیے page کہے کہ "آپ پہلے ہی subscribed ہیں" اور دوسرے کے لیے "اپنا inbox چیک کریں"، تو آپ کا form ان لوگوں کے لیے membership checker بن جاتا ہے جن کے پاس آزمائش کے لیے addresses کی فہرست موجود ہو۔

آپ کو کون سا bot check استعمال کرنا چاہیے؟

Accessibility کو effectiveness جتنی ہی اہمیت دیں۔ Image-selection captcha نابینا صارف حل نہیں کر سکتا، جبکہ audio fallback عام سماعت رکھنے والے افراد کے لیے بھی مشکل ہوتا ہے۔ اگر کسی جائز صارف کے signup میں رکاوٹ آئے تو یہ check دفاع کے ساتھ ایک لاگت بھی ہے۔ کوشش کے لیے چار options یہ ہیں، ترجیحی ترتیب میں۔

Browser میں proof of work۔ Browser ایسا hash compute کرتا ہے جس کی server سستے طریقے سے تصدیق کر سکتا ہے، اور صارف کو کچھ حل نہیں کرنا پڑتا۔ listmonk میں یہ Settings، پھر Security کے تحت ALTCHA کے ذریعے دستیاب ہے، جس کے لیے کسی third-party service کی ضرورت نہیں۔ August 2026 تک listmonk deprecated hCaptcha option کے بجائے اسی کی سفارش کرتا ہے۔ لاگت سب سے زیادہ 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" set کریں تاکہ password manager اسے پُر نہ کرے اور screen reader اسے announce نہ کرے۔ email2 یا address نام والا field browser خودکار طور پر پُر کر دیتا ہے، جس کے بعد آپ حقیقی صارفین کو 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 بھیج دے گا۔

آپ جو بھی option منتخب کریں، ایک بات ضرور verify کریں: token صرف ایک بار consume ہونا چاہیے۔ اگر کوئی script check کو ایک بار حل کرکے اسی token کو ایک ہزار addresses کے خلاف replay کر سکتی ہے، تو check نے صرف یہ ثابت کیا کہ browser ایک بار چلا تھا، اس سے زیادہ کچھ نہیں۔

بدسلوکی کی رپورٹ موصول ہونے سے پہلے آپ کیسے معلوم کریں گے؟

آپ چاہتے ہیں کہ آپ کے اپنے graphs یہ بتائیں، نہ کہ hosting provider کا abuse desk۔ دو چیزوں کی نگرانی کریں۔

Log میں ہر 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 lines پڑھنے دیں جو nginx پہلے ہی لکھتا ہے، اور بار بار خلاف ورزی کرنے والے sources کو 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 counts دکھائی دیتے ہیں۔ پرسکون دن میں Currently banned: 0 درست ہے۔ اگر jail بالکل ظاہر نہ ہو تو fail2ban نے file load نہیں کی، اور sudo fail2ban-client -d | grep nginx-limit-req وہ configuration دکھاتا ہے جسے اس نے حقیقت میں parse کیا ہے۔ فراہم کردہ filter ہر limit_req zone سے match کرتا ہے۔ اسے اپنی signup zone تک محدود کرنے کے لیے ngx_limit_req_zones = signup کو [Definition] section میں /etc/fail2ban/filter.d/nginx-limit-req.local میں set کریں۔ Jail file layout اور ban commands کی مزید تفصیل Ubuntu 24.04 کے لیے fail2ban guide میں دی گئی ہے۔

دوسرا signal ایک ratio ہے، اور اس کے لیے نئے software کی ضرورت نہیں: submissions کو confirmations سے تقسیم کریں۔ صحت مند list میں address submit کرنے والے زیادہ تر لوگ link پر click کرتے ہیں، عموماً آدھے سے کہیں زیادہ۔ جب submissions بڑھتے ہوئے اس ratio میں تیزی سے کمی آئے تو آپ کے system کا غلط استعمال ہو رہا ہے۔ اپنی موجودہ reports کے schedule کے مطابق، آخری گھنٹے میں بنائے گئے unconfirmed subscribers کی تعداد کا موازنہ confirmed subscribers کی تعداد سے کریں۔

آپ کی قیمت: sender reputation اور blocklists

یہ وہ مرحلہ ہے جہاں ایک پریشانی مالی نقصان میں تبدیل ہو جاتی ہے۔

bombing کے لیے استعمال ہونے والی address lists عموماً جمع شدہ ہوتی ہیں، اور ان lists میں spamtraps شامل ہوتے ہیں: ایسے addresses جنہوں نے کہیں بھی کسی چیز کے لیے sign up نہیں کیا ہوتا اور جنہیں صرف ان senders کو پکڑنے کے لیے شائع کیا جاتا ہے جو اجازت کے بغیر mail بھیجتے ہیں۔ آپ کا confirmation message ان میں سے کسی ایک address تک پہنچ جاتا ہے۔ کچھ blocklist operators کے لیے اتنا ہی کافی ہوتا ہے۔

جن recipients نے آپ کا message نہیں مانگا، وہ unsubscribe پر click نہیں کرتے۔ وہ "report spam" پر click کرتے ہیں۔ February 2024 سے نافذ Google کے bulk sender rules کے مطابق، Gmail کو روزانہ 5,000 یا اس سے زیادہ messages بھیجنے والے senders کو Postmaster Tools میں reported-spam rate کو 0.3% سے کم رکھنا چاہیے۔ چھوٹے sender کو اس number کے خلاف measure نہیں کیا جاتا، لیکن یہی complaint signal filtering decisions میں شامل ہوتا ہے، جن کے نتیجے میں آپ کی mail spam folder میں چلی جاتی ہے۔ run میں موجود fake addresses بھی hard bounce پیدا کرتے ہیں، اور بڑھتی ہوئی hard-bounce rate ہر بڑے provider کے ہاں reputation signal شمار ہوتی ہے۔

اگر آپ اپنا mail server VPS پر mailcow کے ساتھ چلاتے ہیں تو 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 کو آلودہ ہونے سے روکتا ہے اور آپ کی طرف سے ہر submitted address پر زیادہ سے زیادہ ایک message بھیجنے تک محدود کرتا ہے۔ یہ آپ کے لیے دستیاب سب سے بڑی انفرادی بہتری ہے۔ تاہم یہ متاثرہ شخص کے inbox کو بھرنے سے نہیں روکتا، کیونکہ حملہ ایک ہزار sites میں سے ہر site کے ایک message کا مجموعہ ہوتا ہے۔ اسے اپنے proxy پر per-IP rate limit اور confirmation resends کی حد کے ساتھ استعمال کریں، تاکہ ایک ہی address کو دو مرتبہ submit کرنے سے دوسرا message نہ جائے۔

میں bombing run اور حقیقی signups کے اچھے دن میں فرق کیسے کروں؟

Submission کے بعد ہونے والی سرگرمی دیکھیں۔ حقیقی signups confirm ہوتے ہیں، اور عموماً چند گھنٹوں کے اندر confirm ہو جاتے ہیں۔ bombing run میں ایسے addresses کا ڈھیر رہ جاتا ہے جو کبھی confirm، open یا click نہیں کرتے۔ Submissions کا pattern بھی غیر معمولی ہوتا ہے: بہت سے source addresses جنہیں آپ نے پہلے کبھی نہیں دیکھا، ایسے recipient domains جنہیں آپ عموماً message نہیں بھیجتے، اور arrival times جو آپ کی audience کے جاگنے کے اوقات کے بجائے پورے دن میں یکساں طور پر پھیلے ہوتے ہیں۔

کیا مجھے submitted addresses حذف کر دینے چاہییں؟

ہاں۔ تقریباً تیس دن سے پرانے unconfirmed records حذف کریں، اور یہ کام دستی طور پر نہیں بلکہ schedule کے مطابق کریں۔ ان addresses کو کوئی اور message کبھی نہ بھیجیں، حتیٰ کہ معذرت یا "کیا یہ آپ تھے؟" والا message بھی نہیں، کیونکہ ایسے شخص کو دوسری غیر مطلوبہ message بھیجنا ہوگا جو پہلے ہی اس قسم کے messages سے بھر چکا ہے۔ اگر ان addresses میں کوئی spamtrap تھا تو follow-up ہی blocklist operator کے منتظر ثبوت کے طور پر کام کرے گا۔

کیا rate limiting حقیقی subscribers کو reject کرے گی؟

ہر IP سے ہر تیس سیکنڈ میں ایک submission، اور تین کی burst limit، اس شخص کو محسوس نہیں ہوگی جو form صرف ایک مرتبہ بھر رہا ہو۔ یہ اس وقت محسوس ہوگی جب بہت سے حقیقی لوگ ایک ہی address استعمال کر رہے ہوں، مثلاً ایک office جو ایک NAT (network address translation) gateway کے پیچھے ہو، یا جب آپ کا proxy visitor کے بجائے آپ کے CDN کا address دیکھ رہا ہو۔ کسی بھی حد کو سخت کرنے سے پہلے اپنے access log میں $remote_addr پڑھیں، اور endpoint ceiling کو اپنے مصروف ترین حقیقی گھنٹے کی شرح سے زیادہ رکھیں۔

ایک run کے بعد میرا sending IP blocklist میں شامل ہو گیا ہے۔ مجھے سب سے پہلے کیا کرنا چاہیے؟

کسی بھی درخواست سے پہلے اس IP سے sending روک دیں۔ Campaign queue کو pause کریں، form درست کریں، اور unconfirmed addresses حذف کریں، کیونکہ مزید اسی قسم کا traffic بھیجنے کے بعد delisting کرانے سے آپ پہلی مرتبہ کی نسبت زیادہ تیزی سے دوبارہ list ہو جائیں گے۔ پھر معلوم کریں کہ آپ کس list میں شامل ہیں، کیونکہ زیادہ تر operators آپ کے IP address کی بنیاد پر lookup page فراہم کرتے ہیں، اور ان کے removal process پر عمل کریں۔ توقع رکھیں کہ انتظار دنوں میں شمار ہوگا۔ اس دوران تصدیق کریں کہ آپ کا SPF (sender policy framework) record اور DKIM signing اب بھی کامیابی سے pass ہو رہے ہیں۔