Import_mbox.sh لا يعمل مع رسائل البريد الإلكتروني من هاتف Samsung مرسلة عبر خادم listserv

ظهرت مشكلة غريبة في إعداد الاختبار الخاص بي حيث أقوم بنسخ رسائل البريد الإلكتروني إلى خادم Discourse الخاص بي وتشغيل import_mbox.sh لدمج رسائل البريد الإلكتروني هذه. رسائل البريد الإلكتروني الأصلية من قائمة بريدية.

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

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

لا يمكنني وضع نسخ من رسائل البريد الإلكتروني التي تسبب هذه المشكلة هنا لأنها سرية. رسائل البريد الإلكتروني التي لا يتم استيرادها تحتوي على أقسام مثل هذه (ولا يوجد محتوى قابل للقراءة البشرية - كل شيء مشفر بترميز base64):

[تم اقتطاع الرؤوس هنا]
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_341310020171250"

----_com.samsung.android.email_341310020171250
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

VGhlIGxlZ2lzbGF0aW9uI[تم اقتطاع]
[...]
[تم اقتطاع]X19fX19fX19fX18NCg==
----_com.samsung.android.email_341310020171250
Content-Type: multipart/related;
	boundary="--_com.samsung.android.email_341310031317791"

لذلك ستحتاج إلى تعديل import_mbox.sh لاقتطاع البريد الإلكتروني وإزالة هراء سامسونج.

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

أو ربما سيتعرف شخص ما على هذه المشكلة في النواة ويصلحها.

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

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

لقد حاولت نسخ البريد الإلكتروني الأصلي من Gmail (عبر عرض الأصل) وكذلك تصدير نفس الرسالة من Thunderbird، مع نفس النتائج.

يبدو أن رسائل البريد الإلكتروني التي تم إنشاؤها بواسطة سامسونج تحتوي على هذا في أسفل الرؤوس:

Content-Type: multipart/alternative;

	boundary="--_com.samsung.android.email_396413402758380"

----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVz[يتم هنا ترميز نص الرسالة العادي بـ base64]

وينتهي هذا بـ

[المزيد من البيانات المشفرة بـ base64 هنا]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[ترميز base64 مرة أخرى، هذه المرة ترميز النسخة HTML من نفس الرسالة]

وينتهي هذا بـ

[المزيد من البيانات المشفرة بـ base64]NCg==
----_com.samsung.android.email_396413402758380--

الآن إذا قمت بتغيير الجزء الأوسط بإضافة سطر فارغ (بعد جزء “email_396413402758380”)، فإن كل شيء يعمل بشكل مثالي!

[المزيد من البيانات المشفرة بـ base64 هنا]19fDQo=
----_com.samsung.android.email_396413402758380

Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[ترميز base64 مرة أخرى، هذه المرة ترميز النسخة HTML من نفس الرسالة]

هل يشير هذا إلى وجود خطأ في المستورد؟

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

ومع ذلك، فإن أسهل حل سيكون إضافة gsub في نص الاستيراد الذي يضيف السطر الفارغ الذي تصفه.

ربما يكون من الأسهل إدراج سطر قبل Content-Transfer-Encoding: base64

نأمل ألا يؤدي ذلك إلى كسر أي شيء آخر.

لكن جيرهارد يكتب إجابة أفضل… في الوقت الحالي

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

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

هل يمكنك بأي حال من الأحوال تقديم مثال كامل لمثل هذا البريد الإلكتروني الإشكالي؟ ربما يمكنك أن تطلب من أحد مؤلفي رسائل البريد الإلكتروني السرية الخاصة بك إرسال بريد إلكتروني غير سري إليك؟

إعجابَين (2)

لقد حاولت صياغة بريد إلكتروني عن طريق فك تشفير base64، وتغيير الصياغة، ثم إعادة التشفير ووجدت شيئًا آخر مثيرًا للاهتمام.

إن إزالة حرف مسافة في منتصف الرسالة الأصلية يمكن أن يؤدي إلى استخراج الرد المكتوب أعلاه بشكل صحيح.

في هذا المثال، في منتصف رسالة HTML المشفرة بـ base64، إذا وجدت سطرًا يحتوي على [مسافة] قبل علامة /div وقمت بإزالته، فتغيير

21  20:17  (GMT+00:00) </div><div>To: LIST@LISTS

إلى

21  20:17  (GMT+00:00)</div><div>To: LIST@LISTS

من خلال إزالة حرف [المسافة] قبل /div، ثم إعادة التشفير إلى base64 ووضعه مرة أخرى في مربع اختبار الرسالة في إعدادات المسؤول، فإن الفلتر يعمل.

هل يمكنني نشر بريد إلكتروني عبر رسالة مباشرة إذا كان ذلك مفيدًا؟

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

From someone@gmail
Delivered-To: someone@gmail
Importance: Normal
MIME-Version: 1.0
Message-ID: <E1mt6gg-00H2OV-6N@relay01.mail.eu.clara.net>
Date: Fri, 3 Dec 2021 11:25:05 +0000
From: someone <someone@somewhere.net>
Subject: Re: Example e-mail
To: <LIST@LISTSERV>
In-Reply-To: <007301d7e834$c268a3e0$4739eba0$@sslmc.co.uk>
Precedence: list
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_7076959834053910"

----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVzIGFuZCB3ZSBhcmUgZ2V0dGluZyBsb3RzIGluIEFCQyBhbmQgdXJnZW50IGNhcmUsIGFsb25n
IHdpdGggdmFjY2luYXRpb24gc2lkZSBlZmZlY3RzIGZyb20gZmx1ICsgYm9vc3Rlci4gQXBwYXJl
bnRseSBERUYxMTEgY2FuJ3QgZGVhbCB3aXRoIHRoaXMgc29ydCBvZiBxdWVyeS4gTG9va2luZyBn
b29kIGZvciBYbWFzIGFuZCBOWSB3ZWVrICAgIDIyMjIKClNhbQoKRHIgU2FtIFNtaXRoeSAKCgot
LS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IFNvdXRoIFNvdXRocyBYWVog
PGVucXVpcnlAU1NYWVouQ08uVUs+CkRhdGU6IDAzLzEyLzIwMjEgMTA6NTkgKEdNVCswMDowMCkK
VG86IExJU1RTQExJU1RTRVJWLkFCQy5PUkcuVUsKU3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBi\nYWNrIGF0IG91ciBkb29yIQoKUHJhY3RpY2VzIHJlcG9ydGluZyB0byBnZXQgIDIgb3IgMyBxdWVy
aWVzL2RheSBmcm9tIHBhdGllbnRzIHJlZ2FyZGluZyBmaXZlcyB2YWNjaW5lIGlzc3VlcyB3aG8g
aGF2ZSBiZWVuIHJlZmVycmVkIHRvIHRoZWlyIEdQIGJ5IFhZWiAxMjMgb3IgdGhlIE5CUy4gIFRo
ZXNlIHF1ZXJpZXMgaW5jbHVkZSBzY2hlZHVsaW5nIGRvc2VzIGZvciBpbW11bm9zdXBwcmVzc2Vk
IHB0cyBhcyB3ZWxsIGFzIHBoYXJtYWNldXRpY2FsIHF1ZXN0aW9ucy4gIA==
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh
dXRvIj5ZZXMgYW5kIHdlIGFyZSBnZXR0aW5nIGxvdHMgaW4gQUJDIGFuZCB1cmdlbnQgY2FyZSwg
YWxvbmcgd2l0aCB2YWNjaW5hdGlvbiBzaWRlIGVmZmVjdHMgZnJvbSBmbHUgKyBib29zdGVyLiBB
cHBhcmVudGx5IERFRjExMSBjYW4ndCBkZWFsIHdpdGggdGhpcyBzb3J0IG9mIHF1ZXJ5LiBMb29r
aW5nIGdvb2QgZm9yIFhtYXMgYW5kIE5ZIHdlZWsmbmJzcDsgJm5ic3A7IDIyMjI8L2Rpdj48ZGl2
IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TYW08L2Rpdj48ZGl2IGRpcj0i
YXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJhdXRvIj48
bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1VVEYtOCI+RHIgU2FtIFNtaXRoeSZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k
aXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGFsaWduPSJsZWZ0IiBkaXI9ImF1dG8i
IHN0eWxlPSJmb250LXNpemU6MTAlO2NvbG9yOiMwMDAwMDA7Ij48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFs
IG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFNvdXRoIFNvdXRocyBYWlombHQ7ZW5x
dWlyeUBTU1hZWouQ08uVUsmc2h0OyA8L2Rpdj48ZGl2PkRhdGU6IDAzLzEyLzIwMjEgIDEwOjU5
ICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBMSVNUU0BMSVNUU0VSVi5BQkMuT1JHLlVLIDwv
ZGl2PjxkaXY+U3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBiYWNrIGF0IG91ciBkb29yISA8L2Rp
dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseS Z0aGUgT05TVCBhbmQgVEhFIE5CUy4gIFRo
ZXNlIHF1ZXJpZXMgaW5jbHVkZSBzY2hlZHVsaW5nIGRvc2VzIGZvciBpbW11bm9zdXBwcmVzc2Vk
IHB0cyBhcyB3ZWxsIGFzIHBoYXJtYWNldXRpY2FsIHF1ZXN0aW9ucy4mbmJzcDsgPC9zcGFuPjwvc
D48L2Rpdj48L2JvZHk+PC9odG1sPg==
----_com.samsung.android.email_7076959834053910--

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

إعدادي الحالي هو أنني قمت بتثبيت Discourse على خادم منزلي، ويتم إرسال رسائل البريد الإلكتروني إلى قائمة بريدية (والتي تذهب إلى حساب Gmail). إذا تطابق فلتر “إلى:” مع اسم القائمة البريدية، فقد قمت بتعيين Gmail لإعادة توجيه نسخة من البريد الإلكتروني إلى mailinglist@mydiscoursedomain.org.uk. لدى Discourse فئة معدة لتعكس قائمة بريدية تبحث عن هذا البريد الإلكتروني.

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

هل هناك أي طريقة لجعل Discourse يمر بسرعة عبر جميع رسائل البريد الإلكتروني المستوردة المخزنة مسبقًا ويحاول إعادة تنسيقها باستخدام الجزء النصي العادي من رسائل البريد الإلكتروني الأصلية في حالة كان ذلك حلاً مؤقتًا للمشكلة المذكورة أعلاه؟ قبل الاستيراد، تم ضبطه لاستخدام جزء HTML. من خلال إلقاء نظرة خاطفة باستخدام ‘rails c’، يمكنني رؤية أن كل مشاركة تبدو وكأنها تحتوي على النص الكامل للرسائل الواردة المخزنة (بما في ذلك رؤوس البريد الإلكتروني). لقد حاولت تشغيل ‘rake posts:rebuild’ بعد إيقاف تشغيل خيار HTML وبينما يمضي ببطء عبر جميع الرسائل، لست متأكدًا مما إذا كان أي شيء قد تغير، على سبيل المثال، حاولت تشغيل وإيقاف تشغيل خيار عرض المحتوى المقصوص أيضًا ولكن الصندوق الصغير بثلاث نقاط لا يزال يبدو موجودًا في المشاركات بعد انتهاء الـ rake.