الرئيسية › أدلة

مراقبة القوائم السوداء: سكربتات وواجهة API وتنبيهات Webhook

تاريخ النشر 2026-11-03 ／ آخر تحديث 2026-11-03 ／ الناشر Yuki Nakazawa

مراقبة القوائم السوداء تعني الاستعلام من عدة قوائم حظر قائمة على DNS (DNSBL) عن عناوين IP والنطاقات التي ترسل منها وفق جدول زمني، وإطلاق تنبيه فقط حين تتغير النتيجة. فاكتشاف الإدراج لحظة حدوثه، بدلًا من انتظار بلاغات العملاء عن رسائل مرتدة، يمنحك وقتًا لمعرفة السبب وطلب الإزالة قبل أن يتسع الضرر.

هناك طريقتان عمليتان لذلك: أن تشغّل بنفسك سكربتًا صغيرًا يعتمد على dig وcron، أو أن تعهد بالفحوص إلى خدمة عبر واجهة API وwebhooks. وفي الحالتين، هناك تفصيلتان تحددان ما إذا كانت المراقبة تقول الحقيقة: فالاستعلامات المرسلة عبر المحلّلات (resolvers) العامة ترفضها قوائم مثل Spamhaus وتُنتج إجابات مضلِّلة، ورموز الأخطاء يجب ألا تُحتسب إدراجات أبدًا.

تستند قواعد الجهات المشغّلة للقوائم المذكورة هنا إلى صفحاتها الرسمية كما كانت في نوفمبر 2026. والسياسات تتغير، لذا تحقّق منها قبل الاعتماد على أي إعداد. وللاطلاع على خلفية حول طريقة عمل DNSBL، راجع ما هي DNSBL (RBL).

حدّد ما ستراقبه والقوائم التي ستستعلم منها

ابدأ بتدوين العناصر التي تحتاج فعلًا إلى مراقبتها.

• عناوين IP المرسِلة. وهي العناوين التي يرسل منها خادم بريدك أو مزوّد البريد لديك فعليًا. فكثيرًا ما يخرج موقعك وبريدك من أجهزة مختلفة، لذا تأكد من العنوان في ترويسات Received لرسالة أرسلتها. وإن كنت ترسل عبر IPv6، فراقب تلك العناوين أيضًا.
• النطاقات. النطاق الوارد في عنوان From لديك وأي نطاقات تظهر في الروابط داخل رسائلك. وتُفحص النطاقات في قوائم حظر النطاقات، وهي منفصلة عن قوائم IP.

صيغة الاستعلام معرّفة في RFC 5782. ففي IPv4 تعكس ترتيب الثمانيات (octets) وتضيف منطقة القائمة، فيصبح العنوان 192.0.2.99 في قائمة ما 99.2.0.192 متبوعًا باسم المنطقة. وفي IPv6 يُكتب العنوان في صورة 32 nibble ست عشري بترتيب معكوس. أما النطاق فيُوضع ببساطة قبل المنطقة. والإدخال المدرج يُرجع سجل A، يقع بحسب العرف ضمن 127.0.0.0/8؛ وغير المدرج يُرجع NXDOMAIN. وتذكر RFC أيضًا أن القوائم ينبغي أن تنشر سجل TXT يشرح سبب الإدراج.

راقب عدة قوائم لا قائمة واحدة، لأن الجهات المستقبِلة لا تستخدم جميعها القوائم نفسها. ويختلف معنى كل رمز إرجاع باختلاف الجهة المشغّلة؛ ويتناول دليلنا حول رموز الإرجاع في DNSBL الرموز الشائعة.

لماذا تعطي المحلّلات العامة إجابات خاطئة

من الأخطاء الشائعة في أدوات المراقبة المحلية الصنع إرسال الاستعلامات عبر محلّل عام مثل Google Public DNS (8.8.8.8) أو Cloudflare (1.1.1.1). وتشرح الأسئلة الشائعة الرسمية لدى Spamhaus حول استخدام DNSBL ما يحدث:

• يشترط الاستخدام المجاني لقوائم DNSBL لدى Spamhaus أن يكون الاستخدام غير تجاري، وألا تأتي الاستعلامات من محلّل عام أو مفتوح، أو من عنوان IP ذي DNS عكسي عام (generic).
• عبر المحلّلات المفتوحة المجانية مثل Google Public DNS، ستحصل الاستعلامات في معظم الحالات على رد "غير مدرج" (NXDOMAIN). أي إن عنوان IP المدرج قد يبدو نظيفًا.
• وقد تتلقى الاستعلامات عبر محلّل عام أيضًا القيمة 127.255.255.254. وهذا رمز خطأ وليس إدراجًا. وبالمثل، تعني 127.255.255.252 خطأً إملائيًا في اسم DNSBL، وتعني 127.255.255.255 عددًا مفرطًا من الاستعلامات. وتنص Spamhaus على أنه لا يجوز اعتبار هذه الرموز دليلًا على أن العنصر المستعلم عنه مدرج.
• والمحلّلات التي تعيد كتابة إجابات NXDOMAIN تُرجع بدلًا منها عنوان IP، فلا ترى أبدًا إجابة NXDOMAIN الصحيحة.

التوصية الأولى في الأسئلة الشائعة هي أن تشغّل محلّل DNS خاصًا بك. أما المستخدمون الذين لا بد لهم من البقاء على محلّل عام، فتوجّههم Spamhaus إلى Data Query Service (DQS)؛ راجع شروطها لمعرفة ما هو مجاني. وتقترح الأسئلة الشائعة الأمر dig txt whoami.fastly.net لمعرفة المحلّل الذي تستخدمه فعلًا.

وتضيف RFC 5782 فحصًا مدمجًا للتحقق من السلامة: إذ يجب أن تحتوي قائمة IPv4 على إدخال للعنوان 127.0.0.2 وألا تحتوي على 127.0.0.1، وينبغي للعملاء فحص إدخالات الاختبار هذه دوريًا للتأكد من أن القائمة تعمل. وفي مثال Spamhaus، يُرجع 2.0.0.127.zen.spamhaus.org القيم 127.0.0.10 و127.0.0.4 و127.0.0.2، بينما يُرجع 1.0.0.127.zen.spamhaus.org النتيجة NXDOMAIN. وينبغي للمراقبة أن تختبر ذلك أولًا وأن تتجاهل التشغيل كله إذا فشل الاختبار.

الخيار 1: سكربت يعتمد على dig وcron

إليك سكربتًا مبسطًا يفحص عنوان IPv4 واحدًا في Spamhaus ZEN وSpamCop (bl.spamcop.net، التي توثّق SpamCop أنها تجيب بالقيمة 127.0.0.2 عن عنوان IP المدرج). استبدل العنوان والمناطق بما يخصك.

#!/bin/sh
# استعلم عبر محلّلك التكراري الخاص (مثل unbound على الخادم نفسه)، ولا تستخدم محلّلًا عامًا أبدًا
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # إذا لم يُرجع إدخال الاختبار 127.0.0.2 رمز إدراج، فلا تثق بهذا التشغيل
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

ما الذي يفعله السكربت:

• لا تُحتسب نظيفةً إلا حالة NXDOMAIN، و127.255.255.x خطأ، وأي قيمة أخرى من نوع 127.x إدراج. وأي قيمة خارج 127.0.0.0/8 تُعامل بوصفها حالة شاذة، كأن يكون المحلّل يعيد كتابة الإجابات.
• انتهاء المهلة يجعل dig ينتهي برمز خروج غير صفري، بينما ينتهي SERVFAIL وREFUSED بالرمز 0. ولا يُعامل أيٌّ منها على أنه نظيف؛ بل يسجّل السكربت خطأً.
• رموز الإرجاع خاصة بكل قائمة. فبعض القوائم مثلًا تستخدم 127.0.0.1 للدلالة على رفض الاستعلام، لذا اقرأ وثائق كل قائمة تضيفها ووسّع عبارة case عند الحاجة.

ثم دع cron يقارن كل تشغيل بالتشغيل السابق ويرسل بريدًا فقط حين يتغير شيء:

# مثال: التشغيل كل ساعة، وإرسال بريد فقط عند اختلاف المخرجات عن التشغيل السابق
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

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

الخيار 2: واجهة API الدفعية وwebhooks في DNSBL Checker

إذا كنت تفضّل عدم صيانة محلّل وقواعد تحليل خاصة بكل قائمة، فيمكنك أن تدع خدمة تتولى الفحوص. وفيما يلي واجهة API الإصدار v1 لهذا الموقع، مقتصرةً على ما يفعله تنفيذ الخادم فعليًا. والمرجع موجود في /en/api-docs، وتُصدر المفاتيح في صفحة الأعضاء على /account. ولا يتطلب التسجيل سوى عنوان بريد إلكتروني، وتسجّل الدخول عبر رابط يُرسل إليك بالبريد.

المصادقة والحدود

• تبدأ المفاتيح بـ dnsbl_ وتُعرض مرة واحدة فقط، مباشرة بعد إصدارها؛ ولا يُخزَّن إلا تجزئتها (hash). وإعادة إصدار المفتاح تُبطل المفتاح السابق.
• أرسل المفتاح في الترويسة X-API-Key مع كل طلب. الاتصال عبر HTTPS فقط؛ إذ يُعاد توجيه http:// العادي إلى https://، لذا استدعِ https:// من البداية.
• الحدود هي 1,000 فحص يوميًا (كل هدف يُحتسب فحصًا واحدًا)، و100 هدف لكل دفعة، و50 تسجيل مراقبة. وعند تجاوز الحد اليومي تحصل على 429 مع daily_limit_exceeded وطابع زمني resets_at.

الفحوص الدفعية

أرسل مصفوفة targets من أسماء النطاقات أو عناوين IP إلى POST /api/v1/batch:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

إذا كان أي هدف لا يزال بحاجة إلى فحص، فالاستجابة هي 202 مع batch_id. استعلم من GET /api/v1/batch/{batch_id} كل بضع ثوانٍ حتى تصبح قيمة status هي done (مثال مختصر؛ الأرقام واسم القائمة للتوضيح وليست نتيجة حقيقية):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• تكون قيمة verdict هي listed إذا أبلغت قائمة واحدة على الأقل عن إدراج، وإلا فهي clean. والقوائم التي انتهت مهلتها، أو أجابت برمز خطأ مثل 127.255.255.x، تُحتسب في error_count ولا تُحتسب إدراجات أبدًا.
• تُرجع الدفعة نتيجة مخزّنة إن وُجدت نتيجة من آخر 30 يومًا. وفي المراقبة المجدولة، انظر دائمًا إلى checked_at.
• الأهداف ذات الصيغة غير الصحيحة تعود في rejected مع ذكر السبب ولا تُحتسب. وإذا مرّرت رابط URL، فلا يُستخدم إلا اسم المضيف. والنطاقات المخصّصة للتوثيق فقط مثل 192.0.2.0/24 تُرفض، لذا اختبر باستخدام عنوان IP إرسال حقيقي.

المراقبة عبر Webhook

سجّل target وcallback_url عبر POST /api/v1/monitors. بعد ذلك يُفحص كل هدف مسجّل مرة واحدة يوميًا دون استخدام ذاكرة التخزين المؤقت (ويُجرى الفحص الأول في غضون يوم تقريبًا من التسجيل)، ويُرسل طلب POST بصيغة JSON إلى عنوانك فقط عند الفحص الأول (monitor.initial) وحين ينقلب الحكم بين مدرج ونظيف (monitor.status_changed).

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• تُعرض قيمة signing_secret في الاستجابة مرة واحدة فقط. ويحمل كل إرسال ترويسة X-DNSBL-Signature: sha256=...، وهي HMAC-SHA256 للنص الخام (raw body) بمفتاح هو ذلك السر. تحقّق منها من جانبك.
• يجب أن يكون callback_url عبر https على المنفذ 443 وأن يشير إلى عنوان IP عام؛ ولا تُتبع عمليات إعادة التوجيه، والمهلة 10 ثوانٍ، لذا ضع الأعمال الثقيلة في طابور وأجب بسرعة.
• إذا أرجعت نقطة النهاية لديك أي قيمة غير 2xx، أو فشل الاتصال، فتُعاد محاولة الإرسال عند الفحص اليومي التالي. ويظهر السبب في last_delivery_error ضمن GET /api/v1/monitors، ويحذف DELETE /api/v1/monitors/{monitor_id} المراقبة.

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

تصميم التنبيهات: التكرار وتعدد القوائم والإنذارات الكاذبة

لا تكون المراقبة مفيدة إلا إذا ظل الناس يقرؤون تنبيهاتها بعد بضعة أشهر. فالمراقبة التي تطلق التنبيهات باستمرار سرعان ما تُهمَل.

التكرار

• افصل بين عدد مرات الاستعلام وعدد مرات الإشعار. استعلم وفق جدول زمني، لكن أرسل الإشعار فقط عند تغيّر الحالة. فرسالة يومية تقول إن كل شيء سليم تُغرق التنبيه الوحيد المهم.
• تقول RFC 5782 إن قيم TTL للقوائم ينبغي أن تعكس سرعة تغيّر القائمة، وإن قوائم مصادر البريد العشوائي قد تستخدم قيم TTL بالدقائق. فاختر الفاصل الزمني وأنت تعلم أن بعض الإدراجات تظهر وتنتهي بسرعة.
• الاستعلام المكثف قد يخالف شروط استخدام القائمة، أو يجلب لك القيمة 127.255.255.255 (استعلامات مفرطة) بدلًا من الإجابات الحقيقية.

تعدد القوائم

• اذكر اسم القائمة في كل تنبيه. فالقوائم تختلف في عدد الجهات المستقبِلة التي تستخدمها، لذا قد تطلق تنبيهًا فوريًا للقوائم الأهم لدى مستلميك وتجمع البقية في ملخص دوري.
• لا يُطلق الـ webhook المذكور أعلاه إلا حين ينقلب الحكم بين مدرج ونظيف. فإذا كان الهدف مدرجًا بالفعل ثم ظهر في قائمة ثانية، فلن يُرسل أي حدث. راقب last_listed_count في GET /api/v1/monitors، أو شغّل دفعة واقرأ listed_on، لاكتشاف هذه الحالة.

النتائج الإيجابية الخاطئة والإجابات العابرة

• سجّل الأخطاء بمعزل عن الإدراجات. تحذّر Spamhaus المشغّلين من رفض البريد أو تصفيته بناءً على رموز الأخطاء لديها؛ والمنطق نفسه ينطبق على المراقبة. فانتهاء المهلة أو الإجابة 127.255.255.x يجب ألا يطلق تنبيه إدراج أبدًا.
• ولتجنب ردّ الفعل على نتيجة غريبة واحدة، أطلق التنبيه فقط بعد نتيجتين متطابقتين متتاليتين، أو أعد الاستعلام بعد بضع دقائق قبل إرسال أي شيء.
• إذا استمرت الأخطاء، فاشتبه في تغيّر المحلّل أو تغيّر من جانب القائمة، وانظر أولًا إلى نتيجة إدخال الاختبار.
• عنوان IP المنزلي المدرج في Spamhaus PBL إدراج قائم على السياسة وليس اتهامًا: فهو يعني أن العنوان لا ينبغي أن يرسل البريد مباشرة. حدّد لكل قائمة ما يُعد تنبيهًا (راجع الإزالة من Spamhaus).

ما الذي تفعله عند اكتشاف إدراج

1. تأكّد منه. افحص صفحة البحث الخاصة بالجهة المشغّلة، ودوِّن اسم القائمة والوقت وأي سبب معروض.
2. عالج السبب أولًا. ابحث عن الحسابات المخترقة، ونماذج الويب المُساء استخدامها، والأجهزة المصابة، وضعف العناية بالقوائم البريدية، وعدم تطابق DNS العكسي (PTR) أو أسماء HELO. فطلب الإزالة مع بقاء السبب يؤدي عادةً إلى إدراج جديد.
3. اتبع إجراءات الإزالة الخاصة بتلك القائمة. قرار الإزالة يعود إلى كل جهة مشغّلة للقائمة، وتقديم الطلب لا يعني وعدًا برفع الإدراج. وإن لم تكن تتحكم في عنوان IP، كما في الاستضافة المشتركة، فتواصل مع مزوّد الاستضافة أو مزوّد الإنترنت.
4. دع المراقبة تؤكد النتيجة. فالجهات المستقبِلة تشغّل أيضًا مرشحاتها الخاصة، لذا تابع التسليم بعد أن يعود الحكم إلى نظيف.

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

الأسئلة الشائعة

الصفحات الرسمية المعتمدة

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

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

أدلة ذات صلة

جميع الأدلة →