رسائل بريد إلكتروني مزعجة (Spam) بدون عنوان "إلى:" (to:). هل يمكن تصفيتها باستخدام Postfix؟

يتم قصف منتدى الخاص بي مؤخرًا بسلسلة من رسائل البريد العشوائي المماثلة. إنهم يستخدمون مرسلًا ونطاقًا وعنوان IP مختلفًا في كل مرة. (لكنها دائمًا ما تكون حول مؤتمر صناعة بناء في مكان ما.)

تنتهي هذه الرسائل في “مرفوض” مع Email::Receiver::BadDestinationAddress، ويحاول النظام إرسال رسالة رفض إلى عنوان المرسل غير الصالح. يا للعار، تلوث السجلات.

في الواقع، ليس لديهم عنوان to: أو cc: على الإطلاق. لقد علمت أن المستلمين يتم تعريفهم فعليًا في مظروف SMTP، وليس في الرأس، وأن أنظمة القوائم البريدية قد تحذف to:/cc: من الرؤوس عن قصد.

لا أستمتع بالغوص في إعدادات Postfix، ولكن يبدو أنه يمكنه إجراء عمليات فحص الرأس

أتساءل عما إذا كان أي شخص قد جرب هذا بالفعل ولديه أي نصائح؟

مثال على رأس رسالة بريد عشوائي، للعلم
Received: from 103-191-76-30.cprapid.com (unknown [103.191.76.30])	by forum-mail-receiver.localdomain (Postfix) with ESMTPS id 0845A2FB2B6; Thu, 08 Jan 2026 02:30:19 +0000
Received: from [::1] (port=57140 helo=103-191-76-30.cprapid.com)	by 103-191-76-30.cprapid.com with esmtpa (Exim 4.99.1)	(envelope-from <alexg@connectconsortiumplaceru.com>)id 1vdfl5-00000000rLO-0bcP; Wed, 07 Jan 2026 21:28:18 -0500
Date: Wed, 07 Jan 2026 21:26:55 -0500
From: alexg@connectconsortiumplaceru.com
Message-ID: <093f4b04eb0e41f70390cf63dcce77d4@connectconsortiumplaceru.com>
Subject: 5th Annual Modular Construction & Prefabrication Symposium - Toronto,
 Canada | March 2026 (Limited Seats Left)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_605ba79265fcf8605b02d6716c2455fc";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Authentication-Results: forum-mail-receiver.localdomain; dmarc=none (p=none
 dis=none) header.from=connectconsortiumplaceru.com
Authentication-Results: forum-mail-receiver.localdomain; dkim=pass (2048-bit
 key; unprotected) header.d=connectconsortiumplaceru.com
 header.i=@connectconsortiumplaceru.com header.a=rsa-sha256 header.s=default
 header.b=hljdS4ya; dkim-atps=neutral
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=103.191.76.30;
 helo=103-191-76-30.cprapid.com;
 envelope-from=alexg@connectconsortiumplaceru.com; receiver=forum.tasat.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=connectconsortiumplaceru.com; s=default; h=Content-Type:Message-ID:Subject:
 To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QsuKb3maShWc9C0uTAfGJZlp0GLvUFzREukTJkY4TbE=; b=hljdS4yaocpaFXSAbqnR+pvdM5
 W02vREZeWNQEtDMCqxEmI17jqjL5k+VGWi6vcruI2QBIi+C3omMWl1MrzAZ18EotG4/SfmY0jqcyV
 G5lu46MfkyxsUUdqQoKIHChQ5T0aa7jfc7LzZzM8bIBUk6VnV4lNn5SItSDEMAzRqrq66rL7ugL3u
 16OkrMph0Kjw7YP2swVhZY9y0TqJBy0L05XHy5BfLjh5K7UGbNxnnN6daXlpCJ/zsQPFjjkiTNicc
 WLIuKHpH+sCQt2VqnbvGVcdYJmapKCzXn0sS08BspidViHbf/2hOAHkDlbVyWduINyn44Es5oj2Jh
 B9+D9w8g==;
User-Agent: Roundcube Webmail/1.6.12
X-Sender: alexg@connectconsortiumplaceru.com
X-AntiAbuse: This header was added to track abuse, please include it with any
 abuse report
X-AntiAbuse: Primary Hostname - 103-191-76-30.cprapid.com
X-AntiAbuse: Original Domain - forum.tasat.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - connectconsortiumplaceru.com
X-Get-Message-Sender-Via: 103-191-76-30.cprapid.com: authenticated_id:
 alexg@connectconsortiumplaceru.com
X-Authenticated-Sender: 103-191-76-30.cprapid.com:
 alexg@connectconsortiumplaceru.com
X-Source: 
X-Source-Args: 
X-Source-Dir:

عادةً ما يرسلون إلى قائمة طويلة من رسائل البريد الإلكتروني التي تم جمعها كنسخة مخفية (bcc)، وقد رأيت هذا السلوك في عدد قليل من المواقع، ولكن ليس لدي أي حل عملي حتى الآن.

نعم، هذه هي الطريقة التي يتم بها تنفيذ BCC:، حيث لا يصل العنوان إلى الرأس.

ديسكورس (Discourse) مختلف قليلاً لأنه لا يستخدم مستلم المظروف على الإطلاق، بل يستخدم الرؤوس فقط. يمكن القول إن هذا خطأ، ولكن يعتمد الكثير من الأشخاص على السلوك الحالي، لذا من الصعب تغييره.

تمت إزالة الرفض السريع (Fast Rejection) لأنه كان معطلاً. علاوة على ذلك، كان المنطق يتحقق من مستلم المظروف، وهو ما لا يتطابق مع ما يبحث عنه ديسكورس (Discourse). يعني هذا التناقض أن الرفض السريع قد يرفض البريد القابل للتسليم بخلاف ذلك، ويسمح بالبريد غير القابل للتسليم.

للأسف، فإن التوفيق بين هذا الأمر سيكون جهدًا شاقًا مقابل مكاسب قليلة نسبيًا.

أرى… شكرًا على التفاصيل.

أنا حاليًا أستخدم فقط الرد عبر البريد الإلكتروني، لذلك اعتقدت أنه من المنطقي حظر أي شيء لا يحتوي على ترويسة TO:/CC:. ولكن يمكنني أن أتخيل كيف يمكن أن يكون هذا إشكاليًا للمواقع التي تستخدم النشر عبر البريد الإلكتروني.

إن تسوية هذا الأمر ستكون للأسف جهدًا شاقًا مقابل مكاسب قليلة نسبيًا.

من المؤكد أنني متحيز - فقد كتبت رمز الرفض السريع الذي تمت إزالته - ولكني أختلف حول قيمة المفهوم، خاصة إذا بدأ الارتداد في وضع خوادم Discourse الخاصة بالأشخاص على قوائم حظر البريد العشوائي، أو بدأت خدمات مثل Mailgun في الشكوى بشأنه (أو الأسوأ من ذلك، أنهم لا يشتكون منه ويتقاضون منك رسومًا مقابل إرسال الكثير من رسائل البريد الإلكتروني الوهمية عندما تضرب موجة كبيرة من مرسلي البريد العشوائي).

إذا ساهم شخص آخر برمز لحل المخاوف (تحليل الرؤوس بدلاً من الظرف، وما إلى ذلك)، فهل سيكون هذا شيئًا ترغب Discourse في إعادة دمجه، أم أن هذا مجرد شيء ليس لدى أي شخص وقت للعبث به بأي شكل في الوقت الحالي؟

(كلا الأمرين جيد، أتفهم تمامًا أن الجميع يبذلون قصارى جهدهم بأوقات وموارد محدودة!)

مرحباً، إليك بعض النصائح التي كنت أجربها لهذا النوع من الرسائل المزعجة (السبام):

- بالنسبة للرسائل التي لا تحتوي على ترويسات To:/Cc:، فإن إسقاطها على مستوى Postfix يعمل بشكل جيد إذا كنت تستخدم الرد عبر البريد الإلكتروني فقط.

- يمكنك أيضاً إضافة فحص بسيط لـ SPF/DKIM لتصفية النطاقات المزيفة قبل وصولها إلى Discourse.

- خدعة أخرى رأيتها هي تحديد معدل البريد الوارد لكل عنوان IP أو لكل نطاق مرسل — فهذا يساعد في إبطاء موجات البريد المزعج دون التأثير على المستخدمين العاديين.

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

لا شيء معقد، مجرد بعض الأفكار التي ساعدتني في تقليل الضوضاء قليلاً :slightly_smiling_face: