كيف تمنع إغراق الاشتراكات في نماذج التسجيل؟

ما هو إغراق الاشتراكات؟

إغراق الاشتراكات هو هجوم يستخدم نموذج التسجيل لديك لإغراق صندوق وارد يخص شخصاً آخر. يحصل المهاجم على عنوان البريد الإلكتروني لضحية واحدة، ثم يرسله إلى مئات أو آلاف النماذج غير المحمية خلال فترة قصيرة. يرسل كل موقع من تلك المواقع رسالة ترحيب أو رسالة تأكيد إلى ذلك العنوان. وتخفي هذه الرسائل مجتمعةً البريد الذي تحتاج الضحية فعلاً إلى قراءته.

الشخص المستهدف هو مالك صندوق الوارد. وبينما يمتلئ الصندوق بتأكيدات الاشتراك، ينفق المهاجم أموالاً باستخدام بطاقة ذلك الشخص أو يعيد تعيين كلمة مرور في أحد حساباته. يصل تنبيه الاحتيال من البنك أيضاً. لكنه يصل أسفل ألفي رسالة أخرى وصلت خلال الساعة نفسها، لذلك لا يراه أحد في الوقت المناسب.

خادمك هو الأداة التي يُنفَّذ الهجوم من خلالها. لا يوجد عطل في أي شيء على خادمك. ولم يُخترق أي حساب يخصك. أدخل شخص ما عنواناً في نموذج عام، ونفّذ برنامجك ما صُمّم لتنفيذه: أرسل رسالة إلى ذلك العنوان. وهذا ما يجعل اكتشاف الهجوم صعباً. لا يوجد اختراق في سجلاتك، لأنه لم يحدث اختراق.

كيف يبدو الهجوم من جهتك

يصل الهجوم بأحد شكلين.

الشكل الصاخب هو موجة مفاجئة. تصل عدة مئات من طلبات POST إلى نموذج واحد خلال بضع دقائق، من عناوين IP مصدر مختلفة، وتحمل عناوين ضمن نطاقات لم ترسل إليها من قبل. يسهل اكتشاف هذا الشكل بمجرد أن تبحث عنه.

أما الشكل الهادئ فهو الذي يفوتك عادةً. يحتفظ المهاجم بقائمة تضم آلاف النماذج المعرضة للاستغلال، لذلك لا يحتاج نموذجك إلا إلى استقبال إرسال أو إرسالين في الساعة. وقد وصف Jye Cusch هجوماً بهذا الشكل تماماً على موقع يديره: لم تحدث زيادة مفاجئة في حركة الشبكة، بل وصلت تسجيلات ثابتة في ساعات لا تتوافق مع جمهوره. يبدو النموذج الواحد سليماً لأنّه لا ينفّذ إلا القليل جداً. لكن الضرر هو مجموع ما يحدث في كل نموذج ضمن قائمة المهاجم.

يشترك الشكلان في علامة واحدة تظهر لاحقاً: لا يحدث شيء بعد ذلك. لا يؤكد أصحاب العناوين اشتراكهم مطلقاً. ولا يفتحون أي رسالة أو ينقرون أي رابط. وفي قائمة تعتمد الاشتراك المؤكد، تبقى هذه العناوين بالحالة unconfirmed إلى الأبد، وتُعد هذه المجموعة أوضح دليل ستحصل عليه.

ابدأ بحساب عمليات الإرسال في الدقيقة ضمن access log.

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

يمثل $4 في تنسيق السجل المدمج الافتراضي الطابع الزمني المحاط بأقواس مربعة، ولذلك يطبع هذا الأمر عدداً لكل دقيقة، بدءاً بالأعلى. إذا كان النموذج يستقبل عادةً أربعة تسجيلات يومياً، ثم أظهر ستين تسجيلاً خلال دقيقة واحدة، فهذه ليست نتيجة طبيعية.

الاشتراك المؤكَّد: الإجراء الأكثر تأثيراً

يعني الاشتراك المؤكَّد، الذي يُسمّى عادةً الاشتراك المزدوج، أن العنوان لا يصبح مشتركاً حتى ينقر شخص على رابط في رسالة تُرسل إلى ذلك العنوان. فعِّل هذا الخيار، وسيؤدي كل عنوان مُرسَل إلى إنتاج رسالة واحدة بالضبط. لا ينضم العنوان إلى القائمة مطلقاً، ولذلك لا يتلقى أي حملة أو سلسلة ترحيب.

في خادم النشرات المستضاف ذاتياً listmonk، هذا إعداد خاص بكل قائمة: إما أن تكون القائمة باشتراك أحادي أو باشتراك مزدوج. توضّح الوثائق الفرق بعبارة مباشرة. في قائمة الاشتراك المزدوج، يؤكد المشتركون اشتراكهم صراحةً عبر النقر على رسالة التأكيد الإلكترونية التي يتلقونها. وحتى يفعلوا ذلك، لا يتلقون رسائل الحملات. يبقى المشترك في unconfirmed، ثم ينتقل إلى confirmed بعد النقر، ولا يتلقى رسائل الحملات في قائمة الاشتراك إلا المشتركون الموجودون في confirmed.

كن واضحاً بشأن الفائدة الفعلية. لا يلغي الاشتراك المؤكَّد مساهمتك في الهجوم تماماً. بل يحدّها برسالة واحدة لكل عنوان. سيظل الضحية يتلقى تلك الرسالة، وقد تكون رسالة واحدة من كل موقع من ألف موقع كافية لتنفيذ الهجوم. ما يزيله الاشتراك المؤكَّد هو كل ما يأتي بعد ذلك: تظل قائمتك نظيفة، ولا ترسل رسالة ثانية إلى شخص لم يطلب الرسالة الأولى أصلاً.

هناك إعدادان آخران مهمان، ومن السهل نسيانهما. أولاً، حدِّد عدد مرات إعادة إرسال رسالة التأكيد. إذا أمكن إرسال العنوان نفسه مرة أخرى، والحصول على رسالة تأكيد جديدة في كل مرة، فلن يحتاج المهاجم إلى ألف نموذج، لأن نموذجك وحده سيرسل ألف رسالة. يجب ألا يتلقى العنوان الموجود مسبقاً في unconfirmed ضمن تلك القائمة أي شيء إضافي لمدة يوم واحد على الأقل. ثانياً، احذف الصفوف غير المؤكَّدة وفق جدول زمني. العنوان الذي لم يُؤكَّد خلال ثلاثين يوماً ليس مشتركاً معلّقاً. إبقاؤه لا يؤدي إلا إلى زيادة احتمال إرسال رسالة إليه عن طريق الخطأ لاحقاً.

فرض حد لمعدل إرسال نموذج التسجيل على الـReverse Proxy

ضع الحد أمام التطبيق بدلاً من وضعه داخله. فالطلب الذي يحظره الـProxy لا يفتح اتصالاً بقاعدة البيانات ولا يبدأ محادثة SMTP (بروتوكول نقل البريد البسيط). أما الحد داخل التطبيق فيُطبَّق بعد أن يكون الطلب قد استهلك عملية عامل واستعلاماً، وفي كثير من البنى تُوضَع الرسالة في قائمة الانتظار قبل تنفيذ أي فحص لإساءة الاستخدام. كما يستمر حد الـProxy بعد ترقية التطبيق، لأنه لا يوجد في الشفرة التي تستبدلها.

يستخدم المثال أدناه nginx. ويمكن تطبيق الفكرة نفسها مع الـReverse Proxy الذي تستخدمه أمام تطبيقك، رغم اختلاف أسماء التوجيهات.

ضع ما يلي في كتلة 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 الطلب الذي يكون مفتاحه سلسلة فارغة، ولذلك لا تدخل المنطقة إلا طلبات POST. ولا يستهلك القارئ الذي يحمّل صفحة التسجيل عدة مرات أيّاً من الحد. ومن دون هذه الخريطة، سيستهلك من أعاد تحميل الصفحة مرتين ميزانيته قبل أن يرسل أي شيء.

يمثل $binary_remote_addr عنوان العميل بصيغته المضغوطة، ولذلك تستوعب منطقة بحجم 10 megabyte نحو 160,000 عنوان. وتسمح rate=2r/m بإرسال واحد كل thirty seconds. وتعيد limit_req_status 429 حالة HTTP 429 Too Many Requests بدلاً من 503 الافتراضية في nginx، وهي الحالة الصحيحة والتي تتوقعها مكتبة العميل.

ثم ضع ما يلي في كتلة 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 أو Proxy آخر، تكون $binary_remote_addr هي ذلك الـProxy. يصل كل زائر إلى السلة نفسها، ولذلك تؤدي الطلبات الأولى لكل دقيقة إلى منع جميع الزوار الآخرين. أصلح ذلك باستخدام وحدة IP الحقيقية: set_real_ip_from لكل نطاق من النطاقات المنشورة لدى CDN الذي تستخدمه (تسرد 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 نفسها. اضبط المعدل أعلى من أكثر ساعاتك الفعلية ازدحاماً مع هامش كافٍ. هذا إجراء صارم: فهو أثناء الهجوم يمنع أيضاً عمليات التسجيل الفعلية. وهذه هي المفاضلة الصحيحة، لأن البديل هو أن يرسل خادمك البريد.

لماذا لا يمكن وضع الحد لكل عنوان في الـproxy

يصل عنوان البريد الإلكتروني داخل نص POST، ولا يحلّل nginx نصوص الطلبات. تأتي كل متغيرات limit_req_zone التي يمكن استخدامها كمفتاح من سطر الطلب أو الرؤوس أو الاتصال. لذلك يجب أن تكون قاعدة مثل «لا يجوز لهذا العنوان تلقي أكثر من رسالة تأكيد واحدة يومياً» في أول مكوّن يقرأ النص، أي في تطبيقك.

لا تتجاوز ذلك بنقل العنوان إلى سلسلة الاستعلام حتى يصبح $arg_email متاحاً. سيؤدي ذلك إلى كتابة عنوان كل مشترك بنص واضح في access log، وفي أي أداة لشحن السجلات downstream منه. وستستبدل تحديد المعدل بمشكلة في الخصوصية.

هناك استثناء فعلي واحد. يمكن لوحدة JavaScript في nginx، المسماة njs، قراءة نص الطلب وتعيين متغير انطلاقاً منه، ما يتيح لك إنشاء مفتاح لكل عنوان في الـproxy. هذا خيار حقيقي، لكنه يضيف أيضاً شيفرة جديدة إلى مسار الطلب. في معظم المواقع، يجب وضع الحد لكل عنوان بجوار قاعدة البيانات التي تعرف مسبقاً ما إذا كان لهذا العنوان تأكيد معلّق، بينما يتولى الـproxy حدود كل IP وكل endpoint التي يتعامل معها جيداً.

لا تُعد عرض النص الذي أرسله المستخدم في الرسالة

هناك سببان منفصلان لإبقاء كل نص يرسله المهاجم خارج الرسالة التي ترسلها. وقد استُخدم كلاهما في هجمات فعلية.

إذا خاطبت رسالة التأكيد القارئ باسم مأخوذ من النموذج، يمكن للمهاجم كتابة رسالته في حقل الاسم. ثم يرسل خادمك ذلك النص إلى الضحية من نطاقك، ويوقّعه باستخدام مفتاح DKIM (DomainKeys Identified Mail) الخاص بك. بذلك يصبح موقعك خدمة لإرسال إساءة يرسلها شخص آخر، ويرى مزود البريد المستلم نطاقك في الرسالة.

السبب الثاني أخطر. إذا أُضيف أي حقل مُرسل إلى رأس رسالة يدوياً، فإن محرف سطر جديد في ذلك الحقل يضيف رؤوساً يختارها المهاجم، بما فيها Bcc. ترفض مكتبات البريد الحديثة محارف السطر الجديد في قيم الرؤوس. أما التعليمات البرمجية التي تمرر النص إلى sendmail من برنامج shell script فلا تفعل ذلك غالباً.

تحتوي رسالة التأكيد الآمنة على اسم موقعك ورابط واحد وجملة تفسيرية واحدة. يظهر العنوان نفسه فقط في الموضع الذي يحتاج إليه وكيل نقل البريد، أي في الرأس To. اختبر ذلك: أرسل النموذج مع وضع محرف سطر جديد ورابط واضح في حقل الاسم، ثم اقرأ الرسالة الأولية التي تتلقاها باستخدام less وتحقق من عدم بقاء أيٍّ منهما.

وأثناء ذلك، اجعل صفحة النجاح تعرض الرسالة نفسها لكل عنوان. فالصفحة التي تقول "أنت مشترك بالفعل" لعنوان، وتقول "تحقق من صندوق الوارد" لعنوان آخر، تحوّل النموذج إلى أداة للتحقق من العضوية لأي شخص يملك قائمة بالعناوين المراد اختبارها.

أي فحص للروبوتات ينبغي أن تستخدم؟

اختر الحل الذي يراعي إمكانية الوصول بالقدر نفسه الذي يراعي فيه الفعالية. لا يستطيع القارئ الكفيف حل CAPTCHA لاختيار الصور، كما أن البديل الصوتي صعب على الأشخاص ذوي السمع العادي. والفحص الذي يتسبب في فقدان شخص شرعي إمكانية التسجيل هو وسيلة دفاع تفرض تكلفة أيضاً. إليك 4 خيارات، بالترتيب الذي ينبغي تجربتها به.

إثبات العمل في المتصفح. يحسب المتصفح قيمة hash يستطيع الخادم التحقق منها بتكلفة منخفضة، ولا يتعين على الشخص حل أي شيء. يوفّر listmonk هذا الخيار ضمن Settings، ثم Security، باستخدام ALTCHA الذي لا يحتاج إلى خدمة تابعة لجهة خارجية. اعتباراً من August 2026، هذه هي توصية listmonk نفسها بدلاً من خيار hCaptcha المهمل. تقع التكلفة على الطرف الذي يرسل أكبر عدد من الطلبات، وهو المهاجم.

فحص مُدار وغير تفاعلي. لا يعرض Cloudflare Turnstile شيئاً لمعظم الزوار، ولا يفرض تحدياً إلا عندما تبدو إشاراته سيئة. وهو فعال، لكنه يضع جهة خارجية ضمن مسار التسجيل لديك.

حقل honeypot. هو حقل نصي لا يراه الشخص، ويملؤه روبوت بسيط. امنحه اسماً لا تستخدمه النماذج لديك لأي غرض آخر، واضبط autocomplete="off" وtabindex="-1" وaria-hidden="true" حتى لا يملأه مدير كلمات المرور تلقائياً ولا يعلنه قارئ الشاشة. سيملأ المتصفح تلقائياً حقلاً اسمه email2 أو address، وعندها سترفض المستخدمين الحقيقيين.

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

فحص مدة الإرسال. ضع طابعاً زمنياً موقّعاً في حقل مخفي عند عرض الصفحة، وارفض أي إرسال يصل بعد أقل من ثانيتين. لا يستطيع الشخص قراءة نموذج وكتابة عنوان بهذه السرعة. وقّع الطابع الزمني، وإلا سيرسل الروبوت ببساطة طابعاً قديماً.

هناك أمر واحد يجب التحقق منه أياً كان اختيارك: يجب استهلاك الرمز مرة واحدة. إذا استطاع script حل الفحص مرة واحدة ثم إعادة استخدام ذلك الرمز مع ألف عنوان، فإن الفحص أثبت فقط أن متصفحاً شغّله مرة واحدة، ولم يثبت شيئاً آخر.

كيف تعرف بالمشكلة قبل وصول بلاغ إساءة الاستخدام؟

تريد أن تعرض لك الرسوم البيانية الخاصة بك ما يحدث، لا أن تعرفه من مكتب بلاغات الإساءة لدى مزود الاستضافة. راقب أمرين.

احسب عدد عمليات الإرسال لكل عنوان مصدر في السجل:

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

ثم اجعل fail2ban يقرأ أسطر limiting requests نفسها التي يكتبها nginx مسبقاً، ويحظر المسيئين المتكررين. يوفّر fail2ban مرشحاً لهذا الغرض تحديداً. أنشئ /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

يعرض ناتج الحالة مرشح jail وعدد حالات الفشل والحظر الحالية فيه. وجود Currently banned: 0 في يوم هادئ صحيح. إذا لم يظهر jail إطلاقاً، فهذا يعني أن fail2ban لم يحمّل الملف، ويعرض sudo fail2ban-client -d | grep nginx-limit-req الإعدادات التي حلّلها فعلياً. يطابق المرشح المرفق كل مناطق limit_req. احصره في منطقة التسجيل لديك عبر ضبط ngx_limit_req_zones = signup في قسم [Definition] من /etc/fail2ban/filter.d/nginx-limit-req.local. يشرح دليل fail2ban الخاص بـ Ubuntu 24.04 بنية ملفات jail وأوامر الحظر بمزيد من التفصيل.

الإشارة الثانية هي نسبة لا تحتاج إلى برنامج جديد: عدد عمليات الإرسال مقسوماً على عدد التأكيدات. في القائمة السليمة، ينقر معظم الأشخاص الذين يرسلون عنواناً على الرابط، وعادةً ما تزيد نسبتهم بكثير على النصف. عندما تنهار هذه النسبة بينما يرتفع عدد عمليات الإرسال، فهذا يعني أن خدمتك تُستغل. قارن عدد المشتركين unconfirmed الذين أُنشئوا خلال الساعة الأخيرة بعدد المشتركين confirmed، وفق الجدول الزمني الذي تستخدمه أصلاً لتشغيل التقارير.

ما الذي يكلّفك إياه ذلك: سمعة المُرسِل وقوائم الحظر

هذا هو الجزء الذي يحوّل الإزعاج إلى فاتورة.

تُجمع عناوين القوائم المستخدمة في الإغراق آلياً، وتحتوي هذه القوائم على مصائد البريد المزعج: عناوين لم يسجّل أصحابها في أي خدمة قط، ونُشرت فقط لاصطياد المُرسِلين الذين يرسلون رسائل دون إذن. تصل رسالة التأكيد إلى أحد هذه العناوين. ولا يحتاج بعض مشغّلي قوائم الحظر إلى أكثر من ذلك.

المستلمون الذين لم يطلبوا رسالتك لا ينقرون على إلغاء الاشتراك. بل ينقرون على «الإبلاغ عن بريد مزعج». وتنص قواعد Google للمرسلين بكميات كبيرة، السارية منذ February 2024، على أن يحافظ المرسلون الذين يرسلون 5,000 رسالة أو أكثر يومياً إلى Gmail على معدل البلاغات عن البريد المزعج في Postmaster Tools دون 0.3%. لا يُقاس المرسل الأصغر وفق هذا الرقم، لكن إشارة الشكاوى نفسها تدخل في قرارات التصفية التي تضع رسائلك في مجلد البريد المزعج. كما أن العناوين الوهمية في العملية تؤدي إلى ارتدادات نهائية كثيرة، ويُعد ارتفاع معدل الارتدادات النهائية إشارة مستقلة إلى السمعة لدى كل مزوّد كبير.

إذا كنت تدير خادم البريد الخاص بك على VPS باستخدام mailcow، فستُدرج عناوين IP ونطاقك في القائمة. وتتطلب إزالة الإدراج لدى مشغّل مثل Spamhaus تعبئة نموذج والانتظار. وأثناء الانتظار، لن تصل فواتيرك ولا رسائل إعادة تعيين كلمات المرور. وإذا أرسلت الرسائل عبر مزوّد مشترك بدلاً من ذلك، فتوقّع أن يعلّق حسابك أولاً وأن يقرأ تفسيرك لاحقاً، لأن حركة الشبكة الخاصة بك تشكّل خطراً على كل مُرسِل آخر يستخدم عنوان IP نفسه.

مقابل ذلك، العمل المطلوب محدود. فعّل الاشتراك المؤكَّد اليوم، لأن ذلك يتطلب إعداداً واحداً لكل قائمة. أضف حد معدل الطلبات في الـproxy بعد ذلك، لأنّه يتطلب ملفاً واحداً وإعادة تحميل. ويمكن إضافة فحص الروبوتات والتنبيهات خلال هذا الأسبوع.

FAQ

هل يوقف الاشتراك المزدوج حملة إغراق الاشتراكات؟

يمنع تلويث قائمتك، ويحدّ مساهمتك في رسالة واحدة لكل عنوان مُدخَل. وهذا أكبر تحسّن منفرد يمكنك تحقيقه. لكنه لا يمنع امتلاء صندوق الوارد لدى الضحية، لأن الهجوم يتكوّن من رسالة واحدة من كل موقع من أصل ألف موقع. اقرنه بحدّ لمعدل الطلبات لكل IP على الـproxy، وبحد أقصى لإعادة إرسال رسائل التأكيد، حتى لا يؤدي إدخال العنوان نفسه مرتين إلى إرسال رسالة ثانية.

كيف أميّز بين حملة إغراق ويوم عادي من الاشتراكات الحقيقية؟

راقب ما يحدث بعد إرسال النموذج. يؤكد المشتركون الحقيقيون اشتراكهم، وعادةً ما يفعلون ذلك خلال ساعات. تخلّف حملة الإغراق مجموعة من العناوين التي لا تؤكد الاشتراك ولا تفتح الرسائل ولا تنقر الروابط. كما تتجمع عمليات الإرسال بطريقة غير معتادة: عناوين مصدر كثيرة لم ترها من قبل، ونطاقات مستلمين لا ترسل إليها عادةً، وأوقات وصول موزعة بالتساوي على مدار اليوم بدلاً من اتباع ساعات نشاط جمهورك.

هل يجب أن أحذف العناوين التي أُرسلت؟

نعم. احذف السجلات غير المؤكدة التي مضى على إنشائها نحو ثلاثين يوماً، ونفّذ ذلك وفق جدول زمني بدلاً من الحذف اليدوي. لا ترسل إلى هذه العناوين أي شيء آخر، بما في ذلك رسالة اعتذار أو رسالة «هل كان هذا طلبك؟»، لأن ذلك يرسل رسالة ثانية غير مطلوبة إلى شخص امتلأ صندوقه بهذه الرسائل. إذا كان أي من تلك العناوين عبارة عن spamtrap، فستكون المتابعة هي الدليل الذي ينتظره مشغّل blocklist.

هل سيؤدي تحديد معدل الطلبات إلى رفض المشتركين الحقيقيين؟

يكون حدّ لكل IP بمعدل إرسال واحد كل ثلاثين ثانية، مع burst من ثلاث طلبات، غير ملحوظ لشخص يملأ نموذجاً مرة واحدة. لكنه يصبح ملحوظاً عندما يشترك عدة أشخاص حقيقيين في عنوان واحد، مثل موظفي مكتب يمرّون عبر بوابة NAT واحدة (ترجمة عناوين الشبكة)، أو عندما يرى الـproxy عنوان CDN الخاص بك بدلاً من عنوان الزائر. اقرأ $remote_addr في access log قبل تشديد أي إعداد، واجعل الحد الأقصى لنقطة النهاية أعلى من معدل نشاطك الحقيقي خلال أكثر ساعاتك ازدحاماً.

عنوان IP الذي أرسل منه موجود على blocklist بعد الحملة. ما أول إجراء أتخذه؟

أوقف الإرسال منه قبل أن تطلب أي إجراء. أوقف طابور الحملة مؤقتاً، وأصلح النموذج، واحذف العناوين غير المؤكدة، لأن إزالة العنوان من القائمة ثم مواصلة إرسال النوع نفسه من traffic ستؤدي إلى إدراجه مجدداً أسرع من المرة الأولى. بعد ذلك، حدّد القائمة التي أُدرجت فيها، إذ يوفّر معظم المشغّلين صفحة lookup تعتمد على عنوان IP الخاص بك، ثم اتبع إجراءات الإزالة لديهم. توقّع أن تُقاس مدة الانتظار بالأيام، واستغل هذه المدة للتأكد من أن سجل SPF (إطار سياسة المرسل) وتوقيع DKIM لا يزالان ينجحان في التحقق.