أخطاء Unexplained Email::Receiver::InvalidPost غير مفسرة

تم نسخ بعض القوائم البريدية لدينا على Mailing Lists - Tor Project Forum

لاحظنا مؤخرًا أن بعض الرسائل لم تتم مزامنتها من القائمة البريدية Mailman3 إلى المنتدى.

تُظهر سجلات رفض البريد الإلكتروني أن هذه الرسائل واجهت خطأ Email::Receiver::InvalidPost.

رسالة الخطأ المسجلة هي إحدى هاتين الرسالتين:

نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى [“tor-relays@lists.torproject.org”] (بعنوان [tor-relays] قياسات عرض النطاق الترددي لشبكات الترحيل وزمن الاستجابة) لم تنجح.

السبب:

تم رفض الوصول

إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.

أو:

نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى [“tor-relays@lists.torproject.org”] (بعنوان [tor-relays] رد: قنوات الويب الموزع لتوزيع تيليجرام) لم تنجح.

السبب:

حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟

إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.

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

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

هل تم تمكين “قبول البريد الإلكتروني من الحسابات المجهولة” في إعدادات كل فئة، وهل يمكنك إرسال سجل البريد الإلكتروني لـ Discourse (مع اختصار إن أمكن)؟

إعجاب واحد (1)

نعم، يمكنني تأكيد تمكين هذا الإعداد.

وهل يمكنك من فضلك إرسال سجل البريد الإلكتروني لـ Discourse (مُعدل قليلاً إن أمكن)؟

هل هذه أشياء أحتاج إلى استخراجها من الحاوية أم من المضيف؟ نقوم أيضًا بمعالجة البريد عبر حاوية mail-receiver. أم أنك تريد السجلات التي يتم عرضها في واجهة المستخدم الرسومية (على سبيل المثال، /admin/email-logs/rejected)؟

هل جاء من Exchange؟

في بعض الأحيان، يرسل Microsoft Exchange بيانات غير مفهومة إذا تم تكوينه بشكل خاطئ ليعتقد أنه يتحدث إلى… لست متأكدًا - خادم Exchange آخر؟ شيء آخر داخل بنيته التحتية؟

يمكنك النظر إلى البريد الخام من وحدة تحكم Discourse باستخدام، على سبيل المثال:

mid = 'message-id from the log'
puts IncomingEmail.find_by(message_id: mid).raw

يعرض هذا البريد الإلكتروني الخام الذي تلقته Discourse. على سبيل المثال، نص الرسالة هذا الذي سحبته للتو من قائمة الرفض الواردة لدينا هو بالفعل غير مفهوم:

This is a multi-part message in MIME format.
--=====003_Dragon855807841081_=====
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64

7bgir+m+vzzIDCLE0mDmZrfIXvvmXjY=

--=====003_Dragon855807841081_=====
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: base64

LP/0L4tqmfZizO0DCDDE10uOzMZqzSHDjq04SLPaBjibLVHz+V94m1M45NDN
55aM8SMIf9XY4EFjP9CCFz+ojfmJqmubaz+bjrzmubw+bjWTiGSuLg==

--=====003_Dragon855807841081_=====--

حيث لا يتم فك تشفير الأجزاء إلى نص صالح.

إعجابَين (2)

كلاهما سيكون رائعًا. إذا كنت تستخدم PuTTy SSH، يمكنك استخراج سجلات الحاوية، ويمكنك اقتطاع واجهة Discourse. ومع ذلك، لا يمكنك البحث عن الكلمات في الصورة بسهولة، لحذفها :face_exhaling:

تمكنت من استخراج بريدين إلكترونيين مع رؤوسهما الكاملة. أحد MUA هو Apple Mail والآخر هو Claws Mail.

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

أعتقد في كلتا الحالتين أنه من المحتمل أن يكون Discourse هو الذي لا يفسر محتوى البريد الإلكتروني بشكل صحيح.

للعلم، لا تزال هذه مشكلة. تسقط Discourse بانتظام رسائل القوائم البريدية من مرسلين مختلفين بخطأ Email::Receiver::InvalidPost، لأسباب لا يمكنني فهمها.

إذا نقرت على الخطأ في السجلات، فهل يظهر سبب الارتداد؟

على سبيل المثال:

إذا نقرت على الخطأ في السجلات، فهل يظهر السبب في سبب الارتداد؟

تأتي هذه الرسائل بنكهتين:

نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى ["tor-relays@lists.torproject.org"] (بعنوان [tor-relays] Re: تقرير إساءة من المرحلات في العائلة 7EAAC49A7840D33B62FA276429F3B03C92AA9327) لم تنجح.

السبب:

حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟

إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.

يمكنني التأكيد على أنه لم يحدث أي شيء من هذا القبيل (تم إغلاق الموضوع أو حذفه) في هذه الحالات.

في بعض الأحيان الأخرى، يكون السبب ببساطة هو Access Denied.

مرحباً lavamind - نعتذر عن إثارة موضوع قديم، ولكن أردت التحقق أولاً قبل أن نتعمق أكثر في تصحيح الأخطاء.

هل ما زلت ترى رفضات Email::Receiver::InvalidPost على عكس البريد الإلكتروني للقائمة البريدية حتى الآن (أواخر 2025 / أوائل 2026)؟

إذا كانت الإجابة نعم، هل يمكنك مشاركة لقطة سريعة لـ:

  • عدد مرات حدوث ذلك تقريباً (على سبيل المثال، يومياً / أسبوعياً، نسبة الرسائل)
  • ما إذا كان “سبب” البريد الإلكتروني المرفوض لا يزال “تم رفض الوصول” مقابل “الموضوع مغلق/محذوف”
  • ما إذا كان يؤثر على قائمة/فئة واحدة أم عدة قوائم

بمجرد أن نؤكد أنه لا يزال يحدث، يمكننا المتابعة لجمع الحد الأدنى من التشخيصات لفشل حديث واحد (معرّف الرسالة + البريد الإلكتروني الخام المخزن المقابل، إلخ).

لا داعي للاعتذار، أنا سعيد جداً لأنك تحقق في هذا الأمر.

مرحباً lavamind - آسف لإثارة موضوع قديم، ولكن أردت التحقق أولاً قبل أن نتعمق أكثر في تصحيح الأخطاء.

هل ما زلت ترى رفضات Email::Receiver::InvalidPost على عكس البريد لقائمة المراسلات حتى الآن (أواخر 2025 / أوائل 2026)؟

نعم، المشكلة لا تزال تحدث.

تقريباً كم مرة يحدث ذلك (على سبيل المثال، يومياً / أسبوعياً، نسبة مئوية من الرسائل)

من الصعب تحديد التكرار بالضبط، لكن المشكلة تؤثر على ما لا يقل عن عدة رسائل أسبوعياً، تقدير تقريبي ربما يتراوح بين 5 إلى 10% من الرسائل؟ يبدو أن بعض المرسلين ممثلون بشكل مفرط في سجلات الأخطاء، لذا على الأقل لا يبدو الأمر عشوائياً تماماً.

ما إذا كان “سبب” البريد الإلكتروني المرفوض لا يزال “تم رفض الوصول” بشكل أساسي مقابل “تم إغلاق الموضوع/حذفه”

لا يزال مزيجاً من الاثنين.

ما إذا كان يؤثر على قائمة/فئة واحدة أو متعددة

إنه يؤثر بشكل أساسي على فئة tor-relays، لكن هذه القائمة تتلقى مدخلات منتظمة من مرسلين متعددين على عكس القوائم الأخرى التي نعكسها، والتي تتلقى حركة مرور أقل بكثير.

بمجرد أن نؤكد أنه لا يزال يحدث، يمكننا المتابعة لجمع الحد الأدنى من التشخيصات لفشل حديث واحد (معرّف الرسالة + البريد الإلكتروني الخام المخزن المقابل، إلخ).

يمكننا النظر في هذا الموضوع الأخير. يشير أرشيف Mailman إلى أنه استقبل 5 رسائل، لكن موضوع مرآة المنتدى يحتوي على 3 مشاركات فقط. تحتوي سجلات الرفض على 3 أخطاء InvalidPost لهذا الموضوع (2 من نفس المرسل، وهذا غريب) وبالنسبة للجميع كان سبب الرفض المعروض هو “حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟”

شكرًا lavamind - هذه نقطة بيانات مفيدة حقًا، خاصةً بوجود موضوع مرجعي ملموس مثل “أرشيف بريد يظهر 5، موضوع منتدى يظهر 3”.

نظرًا لأنك ترى هذا عدة مرات في الأسبوع (بشكل تقريبي 5-10% من الرسائل) وأن سبب الارتداد لهذا الحادث هو دائمًا التباين المضلل “الموضوع مغلق/محذوف”، فإن الخطوة التالية الأفضل هي التقاط رسالة فاشلة واحدة من البداية إلى النهاية حتى نتمكن من رؤية ما كان يعتقده Discourse أنه يفعله.


لإحدى رسائل البريد الإلكتروني الثلاثة المرفوضة المرتبطة بذلك الموضوع المرآة، هل يمكنك الحصول على ما يلي:

  1. من /admin/email-logs/rejected، افتح أحد صفوف InvalidPost لهذا الحادث وانسخ:

    • معرّف الرسالة (Message-ID)
    • التاريخ/الوقت
    • (المحذوف) إلى / من / الموضوع المعروض في الصف
    • نص سبب الارتداد الكامل (كما هو معروض)
  2. من وحدة تحكم Rails (في حاوية تطبيق Discourse)، استخرج البريد الإلكتروني الخام الذي قام Discourse بتخزينه:

@supermathie هل لا يزال IncomingEmail هو المكان القياسي لجلب البيانات الخام، وهل هناك أي شيء آخر تود الحصول عليه بجانبه لتصحيح أخطاء InvalidPost؟

mid = "<الصق معرّف الرسالة من سجل البريد الإلكتروني المرتد>"
ie  = IncomingEmail.find_by(message_id: mid)

puts ie&.raw
  1. قم أيضًا بسحب سمات EmailLog المقترنة لنفس معرّف الرسالة (غالبًا ما يكشف هذا ما إذا كان Discourse قد تعامل معه كـ رد مقابل موضوع جديد، وما هي معرّفات الموضوع/الفئة التي تم حلها):
mid = "<نفس معرّف الرسالة المذكور أعلاه>"

log = EmailLog.where(message_id: mid).order(created_at: :desc).first
pp log&.attributes&.slice(
  "id",
  "email_type",
  "to_address",
  "from_address",
  "subject",
  "post_id",
  "topic_id",
  "user_id",
  "status",
  "bounce_error_code",
  "bounce_key",
  "created_at"
)

لماذا هذه الثلاثية؟

  • يخبرنا IncomingEmail.raw عما إذا كانت الرسالة قد وصلت بتنسيق خاطئ / ترميز غريب / تذييل فقط، مقابل اختيار Discourse للجزء MIME “الخاطئ”.
  • يخبرنا EmailLog بما حاول Discourse القيام به (رد مقابل موضوع جديد، معرّفات الموضوع/الفئة التي تم حلها، إلخ).
  • يؤكد صف البريد الإلكتروني المرتد الذي تم فحصه أننا ننظر إلى نفس الحادث ويحتفظ بما يراه المشغلون.

إذا كان الخصوصية مصدر قلق، فلا تتردد في حذف العناوين وأي نص نصي للرسالة داخل البيانات الخام، ولكن يرجى الاحتفاظ بما يلي:

  • رؤوس MIME (Content-Type، والحدود، وcharset، و Content-Transfer-Encoding)
  • هيكل الأجزاء المتعددة (حتى نتمكن من رؤية الأجزاء الموجودة)
  • معرّف الرسالة ورؤوس التوجيه الأساسية (يمكنك حذف النطاقات إذا لزم الأمر)

بمجرد حصولنا على معرّف رسالة فاشل واحد + IncomingEmail.raw + شريحة EmailLog، يجب أن نتمكن من تحديد ما إذا كان هذا:

  • عدم تطابق مفتاح الرد / توجيه الموضوع،
  • حالة طرفية تتعلق بالأذونات،
  • أو فشل في تحليل البريد الإلكتروني / اختيار جزء MIME / فك التشفير.

شكرًا لك على الشرح المفصل للغاية!

دعنا نركز على هذه الرسالة المرسلة إلى موضوع القائمة البريدية.

تُظهر رؤوس سجلات الحادث للرسالة المرفوضة ما يلي:

Message-ID: <20260103080033.5f6d8f90@dorfdsl.de>
Date: Sat, 03 Jan 2026 08:00:33 +0100
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Re: Questions about running an exit relay

نص سبب الرفض الكامل هو كما يلي:

We're sorry, but your email message to ["tor-relays@lists.torproject.org"] (titled [tor-relays] Re: Questions about running an exit relay) didn't work.

Reason:

Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?

If you can correct the problem, please try again.

السجل النصي العادي للبريد الإلكتروني المرسل إلى Discourse من Mailman (IncomingEmail) متاح هنا (لا أعتقد أنه يحتوي على أي بيانات ليست عامة بالفعل، ولكن على أي حال قمت بتعيين هذا الرابط لينتهي مفعوله بمرور الوقت).

لسوء الحظ، لم تسفر محاولاتي لاستخراج EmailLog عن أي نتيجة: يبدو أن Discourse ليس لديه مثل هذا السجل لتلك الرسالة.

شكرًا @lavamind - هذا ممتاز (معرّف الرسالة + نص الرفض + نسخة مما خزنه Discourse).

أيضًا: خطئي بخصوص طلب EmailLog - من المعقول جدًا (وربما متوقع) ألا يكون هناك صف في EmailLog لرفض وارد كهذا. EmailLog مخصص بشكل أساسي للبريد الصادر، بينما البريد الوارد يعيش في IncomingEmail (الذي قمت بسحبه بالفعل). @supermathie هل يمكنك تأكيد أنني لا أوجه الناس إلى المسار الخاطئ هنا؟

نظرًا لأن لدينا IncomingEmail، هل يمكنك لصق حقول البيانات الوصفية (metadata fields) من نفس السجل؟ سيوفر ذلك سياق “ما الذي حاول Discourse القيام به؟” الذي كنت آمل الحصول عليه من EmailLog.

في وحدة تحكم Rails:

# @supermathie تدقيق للتحقق: لتصحيح أخطاء المشاركة غير الصالحة الواردة، هل بيانات `IncomingEmail` الوصفية هي الشيء الصحيح التالي الذي يجب جمعه؟
mid = "<20260103080033.5f6d8f90@dorfdsl.de>"
ie  = IncomingEmail.find_by(message_id: mid)

pp ie&.attributes&.slice(
  "id",
  "message_id",
  "from_address",
  "to_addresses",
  "cc_addresses",
  "subject",
  "created_at",
  "user_id",
  "post_id",
  "topic_id",
  "error"
)

# اختياري: إذا كنت مرتاحًا، فهذا مفيد أيضًا في كثير من الأحيان
# (إنه يوضح ما استخرجه Discourse كنص أساسي مقابل ما خزنه كنص خام)
pp ie&.attributes&.slice("raw", "cooked")

(إذا كانت النصوص الخام/المطبوخة ضخمة، فلا تتردد في استبعادها - لقد شاركت النص الخام بالفعل.)

لماذا هذه الحقول مهمة:

  • topic_id / post_id (إذا كانت موجودة) تخبرنا ما إذا كان Discourse قد حلل هذا كـرد/مشاركة جديدة وما الذي استهدفه.
  • user_id يخبرنا أي مستخدم مُعدّ/حقيقي قام Discourse بتعيين المُرسل إليه (حالات الأذونات / “تم رفض الوصول”).
  • error غالبًا ما يكون أكثر تحديدًا من نص الارتداد العام “تم إغلاق الموضوع/حذفه”.

إذا أظهرت تلك السمات أن دقة topic_id/post_id تشير إلى الموضوع المرآة، فإن الخطوة التالية المحتملة هي معرفة سبب اعتبار المستلم له غير صالح (نص أساسي فارغ مستخرج، فك تشفير MIME، عدم تطابق الأذونات، عدم تطابق مفتاح الرد، إلخ). إذا أظهر عدم وجود دقة للموضوع/المشاركة على الإطلاق، نركز على رؤوس التوجيه / اكتشاف الرد.

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

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

إعجاب واحد (1)

فيما يلي حقول البيانات الوصفية لـ IncomingObject

{"id"=>9785,
"message_id"=>"20260103080033.5f6d8f90@dorfdsl.de",
"from_address"=>"mm@dorfdsl.de",
"to_addresses"=>"tor-relays@lists.torproject.org",
"cc_addresses"=>"",
"subject"=>"[tor-relays] Re: Questions about running an exit relay",
"created_at"=>2026-01-03 07:03:04.639775000 UTC +00:00,
"user_id"=>10477,
"post_id"=>nil,
"topic_id"=>nil,
"error"=>"Email::Receiver::InvalidPost"}

أما بالنسبة للمحتويات الأولية/المطبوخة، فإن خاصية raw فقط هي التي تحتوي على البريد الإلكتروني الكامل مع الرؤوس. خاصية cooked غير موجودة في الكائن.

تشغيل ذلك عبر Email::Receiver.new(rawmessage).select_body يُرجع:

=> ["", "", 2]

لذا أنا واثق مما يحدث هنا هو أن Discourse يختار بشكل غير صحيح جزءًا نصيًا فارغًا كجسم الرسالة، ربما هذا الجزء:

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit


مما قد يكون منشورًا غير صالح.

سنحتاج إلى إجراء بعض التحقيقات حول هذا الأمر وربما استخدامه كحالة اختبار.

البريد له الهيكل التالي:

* #<Mail::Part:39500, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>>>
  "___…tor-relays mailing list…"
* #<Mail::Part:39520, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>>
  * #<Mail::Part:39540, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39560, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39580, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39600, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39620, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39640, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>>,
    ""
  * #<Mail::Part:39660, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>>,
    "On 02.01.2026…"
  * #<Mail::Part:39680, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39700, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39720, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>
    PGP signature

(نعم، هناك ثلاث نسخ من المحتوى الفعلي، ومحتوى فارغ، وتوقيع PGP)

جزء text/plain الأول هذا تتم إضافته بواسطة برنامج القائمة البريدية ويبدو كالتالي:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

وهذا ما يختاره Discourse (في الواقع، gem البريد عبر .text_part) كمحتوى للرسالة:

> puts mail.text_part.to_s
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

ويتم التعامل معه على أنه نص فارغ مع توقيع محذوف.

لولا هذا الجزء الفارغ تقريبًا الذي أضافته القائمة البريدية، لكان Discourse قد استخرج المحتوى التالي للمنشور:

> We received a court order to preserve the data on the system and were
> forbidden from informing the system owner, which was awkward since
> they had informed the system owner...

ما هي البيانات التي طلبوها؟

> Since then I've always run my exit on a separate system on it's own
> IP so if there were a legal demand to turn over "the system" it would
> really only be that system. I'm not a lawyer but I don't think docker
> provides enough isolation for that.

هل يمكنهم منعك من إيقاف تشغيل المرحل؟
إذا كان الأمر كذلك، يمكنك تشغيل "نظام" جديد على عنوان IP آخر.

(الجزء المحذوف أدناه)

On 02.01.2026 18:46 Jon via tor-relays <tor-relays@lists.torproject.org> wrote:

-- 
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

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

كان سيعمل مع gem البريد وسيبدو أفضل أيضًا في عملاء البريد - إليك كيف يبدو في Thunderbird كما تم استلامه في الأصل:

وإصداري “المُصلح” (test-fixed.eml.txt (14.3 كيلوبايت))
مع توقيع القائمة البريدية في الأسفل بدلاً من الأعلى:

لقد تواصلت مع مشترك (بشري) في تلك القائمة، وإليك كيف تبدو هيئة الرسالة الخام في وكيل مستخدم البريد (MUA) الخاص به مع تصفية بعض الرؤوس:

Subject: [tor-relays] Re: Questions about running an exit relay
List-Id: "support and questions about running Tor relays (exit, non-exit,
 bridge)" <tor-relays.lists.torproject.org>
Archived-At: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
List-Archive: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
List-Post: <mailto:tor-relays@lists.torproject.org>
List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
Reply-To: Marco Moock <mm@dorfdsl.de>
Content-Type: multipart/mixed; boundary="===============8958541500975114832=="

--===============8958541500975114832==
Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On 02.01.2026 18:46 Jon via tor-relays
 <tor-relays@lists.torproject.org> wrote:

 > We received a court order to preserve the data on the system and were
 > forbidden from informing the system owner, which was awkward since
 > they had informed the system owner...

Which data did they request?

 > Since then I've always run my exit on a separate system on it's own
 > IP so if there were a legal demand to turn over "the system" it would
 > really only be that system. I'm not a lawyer but I don't think docker
 > provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

--=20
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

-----BEGIN PGP SIGNATURE-----
iQJPBAEBCAA5FiEEpXefSZn9R6zNZtTQE76RLz2tRfAFAmlYvpEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTEsMiwyAAoJEBO+kS89rUXw8kgP/2jkrwfSWHY6EY4WJjn6
EDEqT00pgpwEn9ZpUqLTreS3/ocfHC4g29HIsxpJcj/bH+hNAx96HEz9YmC4JfEt
LDjYc6D+5NBBFQGy0vaJ/LXLQc63CRE/yySSOYxFBZK+uMytNHoZDTjhfRroICbQ
guoO7A4/VuYrGAzCWQkBUmnBjj2LJhuLDW84ObMXhA/EuNy5FIAqyLZxoGmFEfvu
We5d0Hr3+wihzyrgGiG4u8UGFOyL+/PC11CFQyQ0j03cBzhZ5PVdtkqPNHauAcjQ
Gt/HQmaOSGKq0VODRjiHAe5TuRtV6jOfUNgS1Q2vB4FKYmeDQb82ooNfOiJWy3ey
Jpwgg700ppqgZUclpMPlzxKwi2dT/PSO6yYuy+G5sfa0Hxmn5DsQaiSPMTiEP2WC
NwAENYIuHeQOHWiS8B3oVSRW/naLzkmpfChFnTKGsrhLqKQc/iuvv639aHwg9BP7
YEbWbdpFpIU36czfxoTcDYDR1e4JLWryEFKIgo4TIaz4t17NmkxjXB6dHZKLLAdU
AT6LmL6mOTaXe9ewD9pf9Vf2nG0RGVJyZRUDmFzfU0Rx2qi7KdcmmRpZg/2QtJeA
Pmrv8NFuFEL0BrhTvo7C60m+gjLaXPNClgKEN0vkEzjLp/ZKjI9FslP61xUMg8lQ
3xT/HTkNt9uNH2ziBMXLK+5c
=0Euf
-----END PGP SIGNATURE-----

--Sig_/gizYC_1dGsAzUHvksdaMIe2--

--===============8958541500975114832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

--===============8958541500975114832==--

لا يوجد تكرار، والأجزاء مرتبة بشكل صحيح. أتوقع أن يكون هذا أقرب إلى ما يرسله Mailman فعليًا إلى المشتركين في القائمة، وإلا فإذا كان معظم الناس سيتلقون الرسائل مع التذييل في الأعلى، فربما نسمع عن ذلك؟

أنا أتساءل بعد ذلك عما إذا كان شيء آخر في مسار المعالجة قد يسبب مشكلة في نص الرسالة. يقوم خادم Discourse الخاص بنا أولاً بمعالجة البريد الإلكتروني الوارد باستخدام Postfix، والذي تم تكوينه لتسليمه إلى حاوية mail-receiver، والتي تقوم بعد ذلك بتسليمه إلى حاوية Discourse.

أوه! بالنظر إلى هذا، عدت وتحققت مرة أخرى… واتضح أن المشكلة من جانبنا بعد كل شيء.

من البريد الإلكتروني الخام الذي نشرته أعلاه، اكتشفت للتو أن IncomingEmail.raw لا يخزن البريد الإلكتروني الخام فعليًا… بل نقوم بتعديله أولاً باستخدام Email::Cleaner.

يبدو أن هذا خطأ مكتبة Ruby mail… فهي تعيد ترتيب أجزاء رسالة البريد عند كتابتها مرة أخرى:

[1] pry(main)> m = File.open('test.eml').read;
[2] pry(main)> Mail.new(m).parts
=> [
  #<Mail::Part:39680, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; protocol="application/pgp-signature"; micalg=pgp-sha256>>,
  #<Mail::Part:39700, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset="us-ascii">, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>>
]
[3] pry(main)> Mail.new(Mail.new(m).to_s).parts
=> [
  #<Mail::Part:39720, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6966b4914df79_31d5b1d38126@mars.mail>>>,
  #<Mail::Part:39740, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>
]

مما يسبب المشكلة:

[38] pry(main)> puts Email::Receiver.new(m).select_body[0];
=> We received a court order to preserve the data on the system and were
=> forbidden from informing the system owner, which was awkward since
=> they had informed the system owner...

Which data did they request?

=> Since then I've always run my exit on a separate system on it's own
=> IP so if there were a legal demand to turn over "the system" it would
=> really only be that system. I'm not a lawyer but I don't think docker
=> provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

[39] pry(main)> puts Email::Receiver.new(Mail.new(m).to_s).select_body[0];
«no output»
تفاصيل الاختلاف

test.eml: الرسالة الخام كما تم توفيرها
test-rubyparsed.eml: الرسالة التي تم تحليلها بواسطة Ruby ثم إعادتها إلى سلسلة نصية
test-pythonparsed.eml: الرسالة التي تم تحليلها بواسطة Python ثم إعادتها إلى سلسلة نصية

--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-rubyparsed.eml	2026-01-13 16:11:17.767312268 -0500
@@ -1,25 +1,46 @@
+Date: Tue, 13 Jan 2026 16:07:21 -0500
+From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
+Reply-To: Marco Moock <mm@dorfdsl.de>
+Message-ID: <6966b40914df79_31d5b1d38719@mars.mail>
 Subject: [tor-relays] Re: Questions about running an exit relay
+MIME-Version: 1.0
+Content-Type: multipart/mixed;
+ boundary="===============8958541500975114832=="
+Content-Transfer-Encoding: 7bit
 List-Id: "support and questions about running Tor relays (exit, non-exit,
   bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
 List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
 List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
-From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
-Reply-To: Marco Moock <mm@dorfdsl.de>
-Content-Type: multipart/mixed; boundary="===============8958541500975114832=="
+
+
+--===============8958541500975114832==
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset=us-ascii
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline
+Content-ID: <6966b40914ae9_31d5b1d38641@mars.mail>
+
+_______________________________________________
+tor-relays mailing list -- tor-relays@lists.torproject.org
+To unsubscribe send an email to tor-relays-leave@lists.torproject.org
+ 
 --===============8958541500975114832==
-Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
- protocol="application/pgp-signature"; micalg=pgp-sha256
+Content-Type: multipart/signed;
+ boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
+ micalg=pgp-sha256;
+ protocol="application/pgp-signature"
+Content-Transfer-Encoding: 7bit
+ 
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
-Content-Type: text/plain; charset=US-ASCII
+Content-Type: text/plain;
+ charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 On 02.01.2026 18:46 Jon via tor-relays
@@ -39,7 +60,8 @@
 Can they deny you to turn the relay off?
 If so, you could then operate a new "system" on another IP.
 
---=20
+-- =
+
 kind regards
 Marco
 
@@ -47,14 +69,15 @@
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
 Content-Type: application/pgp-signature
+Content-Transfer-Encoding: 7bit
 Content-Description: Digitale Signatur von OpenPGP
 
 -----BEGIN PGP SIGNATURE-----
@@ -69,14 +92,14 @@
 
 --Sig_/gizYC_1dGsAzUHvksdaMIe2--
 
---===============8958541500975114832==
-Content-Type: text/plain; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: inline
-
-_______________________________________________
-tor-relays mailing list -- tor-relays@lists.torproject.org
-To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-
+--===============8958541500975114832==
+
--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-pythonparsed.eml	2026-01-13 16:19:30.385608544 -0500
@@ -1,10 +1,8 @@
 Subject: [tor-relays] Re: Questions about running an exit relay
 List-Id: "support and questions about running Tor relays (exit, non-exit,
  bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
3 إعجابات