رسائل البريد الإلكتروني لـ Discourse يتم ربطها بشكل غير صحيح

ساهم خلل
1

في discuss python org، نناقش الجانب المتعلق بالبريد الإلكتروني في Discourse. أكبر شكوى هي عدم وجود سلاسل مترابطة. لقد بحثت قليلاً في الرؤوس ويبدو أن:

  • رأس Message-ID فريد على الأقل
  • رؤوس Reply-To و References لا تشير إلى Message-IDs لرسائل أخرى، ناهيك عن معرف الرسالة التي تم الرد عليها
  • بدلاً من ذلك، تشير إلى معرف رسالة وهمي يعتمد على رقم الموضوع

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

هذا سيء، وينتهك RFC 5322. ويجعل تجربة البريد الإلكتروني أسوأ بكثير مما يمكن أن تكون عليه بسهولة.

على سبيل المثال، هناك سلسلة مترابطة هناك تحتوي رسالتها الأولى على الرؤوس التالية:

Message-ID: <topic/17208.dc83577b18fc3ecc438ed42a@discuss.python.org>
References: <topic/17208@discuss.python.org>

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

الرسالة الثانية تحتوي على الرؤوس التالية:

Message-ID: <topic/17208/60568.898edf234f56cf6f3a661c1a@discuss.python.org>
In-Reply-To: <topic/17208@discuss.python.org>
References: <topic/17208@discuss.python.org>

مرة أخرى، Message-ID مقبول، ولكن In-Reply-To و References غير منطقيين تمامًا.

يجب أن يكون هذا سهلاً الإصلاح. يجب ألا تحتوي الرسالة الأولى على رؤوس In-Reply-To أو References. يجب أن تحتوي الرسالة الثانية على Message-ID الخاص بالرسالة الأولى في رؤوس In-Reply-To و References.

يرجى الرجوع إلى القسم 3.6.4 من RFC5322 للحصول على التفاصيل:

كما هي الحال، يرى مستخدمو البريد الإلكتروني مناقشات مسطحة غير منظمة. مع هذه الإصلاحات، يمكنهم الحصول على عرض مترابط منطقي وسهل المتابعة.

9 إعجابات
3

في حال كان أي شخص مهتمًا، فإن أرشيف المناقشة التي يشير إليها كاميرون موجود على \u003chttps://mail.python.org/archives/list/python-dev@python.org/message/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/\u003e.

إعجابَين (2)
4

يبدو أن هذا تراجع، انظر الموضوع القديم والإصلاح.

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

ألقي نظرة على الفرق بين HEAD وهذا الإصلاح.

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

In-Reply-To أكثر صحة قليلاً، من حيث أنه يتم تعيينه فقط إذا كان post.post_number!=1، ولكنه لا يزال يعود إلى topic_canonical_reference_id:

@message.header['In-Reply-To'] = referenced_post_message_ids[0] || topic_canonical_reference_id

يبدو أن هذا به مشكلتان في نظري:

  • يجب أن يكون البديل هو Message-ID للمنشور رقم 1 إذا لم تكن هناك referenced_post_message_ids، وليس topic_canonical_reference_id
  • يجب أن يقوم شيء ما في كود receipt-of-reply-emails بإسقاط رأس In-Reply-To لرسائل الرد، لأنها كان يجب أن تملأ بشكل صحيح مصفوفة referenced_post_message_ids (“قائمة”؟ أنا جديد على Ruby)
3 إعجابات
6

كامرون، شكراً لك على فتح هذا الموضوع للنقاش وتقديم الكثير من التفاصيل في منشوراتك. أنا مسؤول عن هذا “الوضع المعقد”، من هاتين الالتزامين:

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

ومن المثير للاهتمام أننا أضفنا ترويسة References هذه إلى البريد الإلكتروني الأول المرسل وكل بريد لاحق في ذلك الوقت، حيث إنها تجعل الترابط يعمل بشكل صحيح في Gmail، ولكني أتفق على أنها ليست مثالية ومن المحتمل أنها تسبب مشكلات الترابط إلى جانب عدم استخدام Message-ID الأصلي في ترويسات In-Reply-To و References للبريد الإلكتروني اللاحق.

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

7 إعجابات
7

لقد كتبت ردًا طويلاً، لكنني تلقيت:

نأسف، ولكن رسالة البريد الإلكتروني الخاصة بك إلى
["incoming+8349bd9eb1f2b582df4f32dbe85c3363@meta.discoursemail.com"]
(بعنوان Re: [Discourse Meta] [bug] Discourse email messages are
incorrectly threaded) لم تنجح.

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

سأقوم بوضعها في المنتدى حيث يمكنني التقاطها ومراجعتها…

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

كاميرون، شكراً لك على فتح هذا الموضوع للنقاش وتقديم
الكثير من التفاصيل في منشوراتك. أنا مسؤول عن هذا الأمر المعقد،
من هاتين الالتزامين:

3b13f1146b2a406238c50d6b45bc9aa721094f46

هذا يبدو جيدًا. هل يقوم بحفظ هذا المعرف مع سجل قاعدة البيانات بحيث يمكن ربط الردود الواردة بالرسالة الأصلية للمنتدى؟

أيضًا، هل تريد مني التحقق من أن اللاحقة قانونية نحويًا لـ RFC5322، من حيث الأحرف المسموح بها؟

82cb67e67b83c444f068fd6b3006d8396803454f

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

إلى: المنتدى
النسخة الكربونية: أحد المشاركين

سيتلقى المشارك (حسنًا، قد يتلقى) نسخة من المنتدى ونسخة مباشرة من المؤلف، وستكون هاتان رسالتان مميزتان لديهما لأنهما ستحملان معرفات رسائل مختلفة.

كنت سأقوم بإنشاء تقرير خطأ ثانٍ حول هذه المشكلة بعد فرز مشكلة رؤوس in-reply-to و references، وهي أكثر أهمية بكثير.

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

أنا والعديد من الآخرين نستخدم mutt. أنا سعيد بالقيام بأي شيء مطلوب للمساعدة
في تصحيح الأخطاء ومراجعة الكود. لقد كنت أيضًا مسؤول نظام بريد إلكتروني لسنوات عديدة في حياتي السابقة.

[quote=“Cameron Simpson, post:1, topic:233499,
username:cameron-simpson”]
إنها الرسالة الأولى. لا ينبغي أن تحتوي على رأس References، لأنه لا توجد رسالة في أي مكان بهذا المعرف.
[/quote]

ومن المثير للاهتمام، أننا أضفنا رأس References هذا إلى البريد الإلكتروني الأول المرسل وكل بريد لاحق منذ ذلك الحين لأنه يجعل الترابط يعمل بشكل صحيح في Gmail،

أعتقد أن رأس References الصحيح (غير موجود في المنشور الأول، مثل
in-reply-to في الردود) يجب أن يعمل أيضًا. لكن Gmail لديه علاقة فضفاضة إلى حد ما بمعايير البريد الإلكتروني في بعض الأحيان. لدي اتفاقية Gmail؛ يمكنني القيام ببعض تصحيح الأخطاء هناك أيضًا. ومن حيث المبدأ، يمكننا استخدام هذا النقاش نفسه كساحة اختبار، ربما.

ولكنني أتفق على أنه ليس مثاليًا ومن المحتمل أن يتسبب في مشكلات الترابط
إلى جانب عدم استخدام Message-ID الأصلي في رسائل البريد الإلكتروني اللاحقة
رؤوس In-Reply-To و References.

يرجى التحلي بالصبر معي بينما أبحث في المناقشات القديمة والكود وأعمل على حل هذه المشكلة.

لا مشكلة.

في هذه الأثناء، هل أنت على علم بعملاء بريد إلكتروني آخرين يتم
استخدامهم ويواجهون مشكلات؟ على سبيل المثال، أعرف أن هذه مشكلة في Thunderbird، ولكن ماذا عن أي عملاء آخرين؟ شكرًا.

بالتأكيد mutt. على الأقل مع mutt، من السهل جدًا رؤية الرؤوس
ورؤية سلسلة شجرة الردود، والتي غالبًا ما تكون محجوبة في العملاء الآخرين.

ترابط البريد الإلكتروني معرف بالكامل بواسطة رؤوس Message-ID و In-Reply-To. بدأ رأس References مع USENET للمتابعات، ودعم (هناك) معرفات رسائل متعددة؛ يدعم In-Reply-To معرفًا واحدًا فقط. يبدو أن References موجود أيضًا الآن في RFC5322، وسأتحقق من دلالاته.

5 إعجابات
9

أنا فقط أجمع أفكاري في منشور كبير حول هذا لاحقًا اليوم، شكرًا لك على المعلومات الإضافية حتى الآن!

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

حسنًا، هذا أمر ضخم نوعًا ما، يرجى التحلي بالصبر معي. أولاً، شكرًا على رد آخر مفصل وعرض تصحيح الأخطاء / المراجعة، إنه مفيد حقًا :+1: لقد كنت أبحث في هذا هذا الصباح، وبشكل مفاجئ، يعمل تنظيم الرسائل في عرض موحد في Thunderbird في معظم الحالات، وأعتقد أن رأس References الذي يشير باستمرار إلى الموضوع الأصلي يساعد في ذلك (على سبيل المثال، الموضوع Reference في هذه السلسلة الموجود دائمًا هو \u003ctopic/53@discoursehosted.martin-brennan.com\u003e).

image
image3042×492 188 KB

الحالة التي لا يعمل فيها تنظيم الرسائل كما هو مقصود هي:

  1. يتم إنشاء منشور داخل Discourse وإرسال بريد إلكتروني إلى أولئك الذين يتابعون الموضوع ثم
  2. يرد شخص آخر على هذا المنشور ويتم إرسال بريد إلكتروني إلى أولئك الذين يتابعون الموضوع

في حالة البريد الإلكتروني الثاني، يحصل على رأس In-Reply-To و References غير صحيحين لأنه ينشئ واحدًا في هذا السطر discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub بدلاً من استخدام واحد موجود. يجب أن يستخدم Message-ID للبريد الإلكتروني الذي تم إرساله أولاً. في لقطة الشاشة، هذا هو المكان الذي يجب أن توضع فيه الرسائل التي تتبع هذا النمط:

image
image2586×389 147 KB

image

الجواب هو - يعتمد. إذا تم إنشاء منشور في Discourse من بريد إلكتروني وارد، مثل هذا الخاص بك، فإننا نستخدم Message-ID الأصلي للبريد الإلكتروني الوارد عند الرد عليه لرؤوس In-Reply-To و References كما هو موضح في:

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

أعتقد أنني أفهم ما تقصده، هل يحدث ذلك كالتالي:

  1. يرسل كاميرون بريدًا إلكترونيًا إلى Discourse من mutt يحصل على Message-ID: 74398756983476983@mail.com
  2. ينشئ Discourse منشورًا ويخزن Message-ID مقابل المنشور مع سجل IncomingEmail
  3. يتابع جون دو الموضوع، لذلك يتم إرسال بريد إلكتروني إليه من Discourse مع Message-ID: topic/222/44@discourse.com ولا يوجد مرجع إلى Message-ID: 74398756983476983@mail.com الأصلي.

هل هذا يبدو صحيحًا، أننا يجب أن “نمرر” هذا Message-ID لمن يتابعون الموضوع بدلاً من إنشاء معرف خاص بنا لأنه فريد بالفعل؟ ماذا يحدث بعد ذلك في عميل البريد الإلكتروني لـ johndoe إذا قام كاميرون أيضًا بنسخه في هذا البريد الإلكتروني الصادر الأصلي؟ يبدو هذا مشكلة منفصلة، لذا سيكون من الجيد فتح موضوع خطأ آخر لها.

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

خط تفكيري لمعالجة هذه المشكلات هذا الصباح كان التخلص من اللواحق التي تم إنشاؤها عشوائيًا عند إرسال رؤوس Message-ID في رسائل البريد الإلكتروني وبدلاً من ذلك التغيير إلى مخطط نستخدم فيه user_id لكل من المستخدم المرسل والمستقبل. فائدة هذا هي أنه لا حاجة لتخزين Message-ID في أي مكان (باستثناء عندما ينشئ بريد إلكتروني وارد منشورًا) وبالتالي ستكون رؤوس References و In-Reply-To متسقة دائمًا. دعني أعطي مثالاً. لنفترض أن لدينا هؤلاء المستخدمين:

  • مارتن - user_id 25
  • كاميرون - user_id 44
  • سام - user_id 78
  • بوب - user_id 999

ولدينا هذا الموضوع، topic_id 233499، مع منشورات تبدأ من post_id 100 كموضوع أصلي. سيصبح التنسيق topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}. سيبدو ترتيب العمليات كالتالي:

  1. مارتن ينشئ الموضوع الأصلي
  • يتم إرسال بريد إلكتروني إلى كاميرون مع هذه الرؤوس:
  • Message-ID: topic/233499.s25r44@meta.discourse.org
  • References: topic/233499@meta.discourse.org
  • يتم إرسال بريد إلكتروني إلى سام مع هذه الرؤوس:
  • Message-ID: topic/233499.s25r78@meta.discourse.org
  • References: topic/233499@meta.discourse.org
  1. كاميرون يرد عبر البريد الإلكتروني
  • يتم إرسال بريد إلكتروني إلى Discourse مع هذه الرؤوس من mutt:
  • Message-ID: 43585349859734@test.com
  • References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org
  • In-Reply-To: topic/233499.s25r44@meta.discourse.org
  1. Discourse (باسم كاميرون، من البريد الإلكتروني أعلاه) ينشئ المنشور 101
  • يتم إرسال بريد إلكتروني إلى سام من Discourse مع هذه الرؤوس:
  • Message-ID: topic/233499/101.s44r78@meta.discourse.org
  • References: 43585349859734@test.com topic/233499@meta.discourse.org
  • In-Reply-To: 43585349859734@test.com
  1. سام يرد عبر البريد الإلكتروني على كاميرون
  • يتم إرسال بريد إلكتروني إلى Discourse مع هذه الرؤوس من Gmail:
  • Message-ID: 5346564746574@gmail.com
  • References: topic/233499/101.s44r78@meta.discourse.org topic/233499@meta.discourse.org
  • In-Reply-To: topic/233499/101.s44r78@meta.discourse.org
  1. Discourse (باسم سام، من البريد الإلكتروني أعلاه) ينشئ المنشور 102
  • يتم إرسال بريد إلكتروني إلى كاميرون من Discourse مع هذه الرؤوس:
  • Message-ID: topic/233499/102.s78r44@meta.discourse.org
  • References: 5346564746574@gmail.com topic/233499@meta.discourse.org
  • In-Reply-To: 5346564746574@gmail.com
  1. بوب ينشئ المنشور 103 في الموضوع، وليس ردًا على أي شخص (لاحظ أن المراجع هنا تتضمن Message-ID المرسل إلى كلا المستخدمين للبريد الإلكتروني للموضوع الأصلي)
  • يتم إرسال بريد إلكتروني إلى كاميرون مع هذه الرؤوس:
  • Message-ID: topic/233499/103.s999r44@meta.discourse.org
  • References: topic/233500@meta.discourse.org topic/23499.s25r44@meta.discourse.org
  • يتم إرسال بريد إلكتروني إلى سام مع هذه الرؤوس:
  • Message-ID: topic/233499/103.s999r78@meta.discourse.org
  • References: topic/233499@meta.discourse.org topic/23499.s25r78@meta.discourse.org
  1. كاميرون يرد عبر البريد الإلكتروني
  • يتم إرسال بريد إلكتروني إلى Discourse مع هذه الرؤوس من mutt:
  • Message-ID: 6759850728742572@test.com
  • References: topic/233499@meta.discourse.org topic/233499/103.s999r44@meta.discourse.org
  • In-Reply-To: topic/233499/103.s999r44@meta.discourse.org

صندوق وارد كاميرون

  • مارتن - الموضوع الأصلي
  • تم الإرسال → إلى: Discourse، إعادة: الموضوع الأصلي
  • سام - رد على المنشور الثاني
  • بوب - رد في الموضوع ليس على أي منشور معين
  • تم الإرسال → إلى: Discourse، إعادة: منشور بوب

صندوق وارد سام

  • مارتن - الموضوع الأصلي
  • كاميرون - المنشور الثاني
  • تم الإرسال → إلى: Discourse، إعادة: المنشور الثاني
  • بوب - رد في الموضوع ليس على أي منشور معين

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

كملاحظة جانبية، نظرت أيضًا في ما تفعله GitHub مع رسائل البريد الإلكتروني الخاصة بالإشعارات الخاصة بها، ولاحظت أنها تفعل شيئًا مشابهًا حيث لديها Reference دائم (discourse/discourse/pull/252@github.com) يتم استخدامه في جميع رسائل البريد الإلكتروني المتعلقة بهذا “الموضوع” والذي هو في هذه الحالة طلب سحب GitHub:

References: \u003cdiscourse/discourse/pull/252@github.com\u003e \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e
In-Reply-To: \u003cdiscourse/discourse/pull/252/issue_event/7042100517@github.com\u003e
6 إعجابات
11

بواسطة مارتين برينان عبر Discourse Meta في 22 يوليو 2022 الساعة 06:34:

حسنًا، هذا أمر ضخم إلى حد ما، لذا أرجو أن تتحملوا معي. أولاً، شكرًا لكم
على الرد التفصيلي الآخر وعلى عرضكم للمساعدة في تصحيح الأخطاء أو المراجعة، فهذا مفيد حقًا :+1: في الواقع، كنت أبحث في هذا الأمر هذا الصباح
وبشكل مفاجئ، فإن الترتيب الخيطي في العرض الموحد يعمل في Thunderbird
في معظم الحالات، وأعتقد أن رأسية References التي تشير باستمرار
إلى المنشور الأصلي (OP) تساهم في ذلك (على سبيل المثال، رأسية Reference في هذه السلسلة والتي تكون موجودة دائمًا هي
<topic/53@discoursehosted.martin-brennan.com>).

لقد أعدت قراءة القسم 3.6.4 من RFC5322 عن كثب للتو. لقد تطور عن
الإصدارات السابقة (822 و 2822)، وقد دمجت رؤوس البريد الإلكتروني In-Reply-To
مع رؤوس References الخاصة بـ USENET، بالإضافة إلى اقتباس الردود الحديثة
التي تشير إلى أكثر من رسالة سابقة واحدة.

ملخص مختصر:

  • Message-ID هو معرف فريد ومستمر للرسالة.
  • تحتوي In-Reply-To على جميع معرفات الرسائل التي يُعد هذا الرد ردًا مباشرًا عليها، لذا إذا قمت بالرد على زوج من الرسائل، فستحتوي على هذين المعرفين.
  • References هي سلسلة ردود من معرفات الرسائل السابقة بدءًا من المنشور الأصلي (OP) وصولًا إلى الرسالة السابقة. لذا، يجب بالفعل أن تبدأ دائمًا
    بمعرف الرسالة الأصلي (OP).

لذلك، في مناقشات مثل هذه، وبافتراض أن التسميات هي معرفات رسائل:

المنشور الأصلي (OP)
  -> الرد1
    -> الرد2 ---+
  -> الرد3      |
    -> الرد4    |
      -> الرد5 <+

سيحتوي الرد5 على:

  • message-id=الرد5
  • in-reply-to=“الرد2 الرد4”
  • references=“المنشور الأصلي الرد3 الرد4”

ويُعتبر قانونيًا أيضًا تضمين “الرد1 الرد2” في حقل References (السلسلة الأخرى المؤدية إلى الرد5)، لكن RFC ينصح صراحةً ضد ذلك
لأن بعض العملاء يتوقعون أن تكون References سلسلة خطية واحدة من الردود، وليس رسمًا بيانيًا مسطحًا.

لذلك، توصيتي لبناء حقل References هي استخدام References الخاصة بـ"الرسالة السابقة الأولية" مع إرفاق معرف الرسالة الخاصة بالرسالة السابقة الأولية. بهذه الطريقة، تحصل دائمًا على سلسلة خطية بالترتيب الصحيح.

image
image3042×492 188 KB

من المثير للاهتمام أن يبدو أن هناك بعض الترتيب الخيطي هناك.

ولكن لاحظ: أن المنشور العلوي يحتوي على سهم صغير يقول “هو رد”. على الرغم من أنه
المنشور رقم 1. أتوقع أن يكون ذلك بسبب إدخال “الموضوع” في References،
والذي يجعل Thunderbird يعتقد أن هناك رسالة سابقة (وهو أمر لم يحدث بالطبع).

في عالم Mutt، نرى عمليًا لا يوجد أي ترتيب خيطي على الإطلاق:

23Jul2022 06:24 Olha via Discus - ┌>[Py] [Users] I need an advise  discuss-users 5.7K
22Jul2022 17:12 Paul Jurczak vi - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 13:21 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.8K
22Jul2022 12:53 vasi-h via Disc - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 11:38 Cameron Simpson - ├>[Py] [Users] I need an advise  discuss-users  14K
22Jul2022 10:27 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.6K
22Jul2022 06:14 vasi-h via Disc r ┴>[Py] [Users] I need an advise  discuss-users 6.5K

وذلك لأن In-Reply-To في كل رسالة تشير مباشرة إلى
معرف الرسالة الوهمي للموضوع “topic”. ربما يتجاهل Mutt حقل References
لأنه قارئ بريد إلكتروني، وReferences أصلها في أخبار USENET. ربما
يستخدم Thunderbird حقل References أو يعزز حقل In-Reply-To بمعلومات من References.

تحتاج فقط إلى الرجوع إلى أحد حقلين In-Reply-To أو References للقيام
بالترتيب الخيطي؛ الأول يأتي من البريد الإلكتروني والثاني من USENET. أنت
تدعم كلاهما (وهو أمر رائع!) لذا نحتاج إلى جعلهما متسقين.

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

[…]

[quote=“Cameron Simpson, post:8, topic:233499,
username:cameron-simpson”]
هذا يبدو جيدًا. هل يتم حفظ هذا المعرف مع سجل قاعدة البيانات بحيث يمكن ربط
الردود الواردة بالرسالة السابقة في المنتدى؟
[/quote]

الإجابة هي – الأمر يعتمد. إذا تم إنشاء منشور في Discourse من بريد إلكتروني وارد، مثل هذا الخاص بك، فنحن نستخدم معرف الرسالة الأصلي للبريد الوارد (Message-ID) لذلك المنشور عندما يرد عليه شخص ما في رؤوس In-Reply-To و References وفقًا لما يلي:

discourse/lib/email/sender.rb at 98bacbd2c6b9fe57167cd32af5eb4839b4a5d1f6 · discourse/discourse · GitHub

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

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

في رأيي، تحتاج إلى القيام بثلاثة أشياء:

  1. امتلاك معرف رسالة مستقر وعدم استبدال معرف الرسالة من رسالة واردة.
  2. توليد In-Reply-To صحيح، والذي يمكن حسابه بسهولة من الرسالة السابقة المباشرة (أو الرسائل) أي معرفات الرسائل السابقة-Message-ID.
  3. توليد References صحيح، والذي يمكن حسابه بسهولة كـ
    الرسائل السابقة-References + معرف الرسالة السابقة-Message-ID.

بالنسبة للنقطة 1، بالنظر إلى الكود الذي أشرت إليه، ربما تريد أن يكون معرف رسالة البريد الإلكتروني (بناء جملة شبيه بـ Python، آسف):

def message_id(post):
    return post.incoming_email.message_id or discourse_message_id(post)

أي أن يكون معرف رسالة البريد الإلكتروني للمنشور إذا نشأ من البريد الإلكتروني،
وإلا فإن معرف الرسالة الخاص بـ Discourse باستخدام خوارزمية مثل ما شرحت لاحقًا في هذه الرسالة: أي شيء (أ) مستقر و (ب) صالح نحويًا.

ثم تكون حساب حقول In-Reply-To و References أمرًا ميكانيكيًا بسيطًا كما هو موضح في النقطتين 2 و 3.

أعتقد أنني أدرك ما تقصده، هل الأمر كالتالي:

  1. يرسل Cameron بريدًا إلكترونيًا إلى Discourse من Mutt ويحصل على Message-ID: 74398756983476983@mail.com
  2. ينشئ Discourse منشورًا ويخزن Message-ID مقابل المنشور مع سجل IncomingEmail

صحيح.

  1. يراقب johndoe الموضوع، لذا يتم إرسال بريد إلكتروني إليه من Discourse يحتوي على Message-ID: topic/222/44@discourse.com ولا يوجد أي مرجع للمعرف الأصلي Message-ID: 74398756983476983@mail.com

لا. أنت حقًا تريد تمرير IncomingEmail.message_id كـ
Message-ID في البريد الإلكتروني الموجه إلى johndoe. إنها نفس الرسالة.

هل يبدو ذلك صحيحًا، أنه يجب علينا ببساطة “تمرير” ذلك Message-ID إلى أولئك الذين يراقبون الموضوع بدلاً من توليد معرف خاص بنا لأنه فريد بالفعل؟ وماذا يحدث بعد ذلك في عميل البريد الإلكتروني الخاص بـ johndoe إذا
قام Cameron أيضًا بإرسال نسخة منه (CC) إليه في تلك الرسالة الصادرة الأصلية؟ يبدو هذا وكأنه مشكلة منفصلة، لذا سيكون من الجيد فتح موضوع خطأ آخر لها.

عن طريق تمريره، تكون الرسالة الأصلية (Cameron->cc:johndoe) والرسالة
الموجهة من Discourse (Cameron->Discourse->johndoe) لهما نفس
معرف الرسالة ونفس محتوى الرسالة. يقوم نظام البريد المستلم بتخزين كلاهما. يرى قارئ البريد كلاهما، ويعرض إما كلاهما أو يحتفظ بواحد فقط (هذا قرار سياسي لقارئ البريد - الاحتفاظ بواحد فقط هو أمر شائع). لأنهما نفس الرسالة، بشكل عام لا يهم أيهما يتم الاحتفاظ به.

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

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

يسعدني المساعدة في الإعدادات. لعرض الخيوط، تحتاج إلى تعيين الترتيب إلى خيطي. Mutt قابل للتكوين للغاية.

كان خط تفكيري لمعالجة هذه المشاكل هذا الصباح هو التخلص من
اللاحقات المولدة عشوائيًا التي نولدها عند إرسال رؤوس Message-ID في رسائل البريد الإلكتروني وبدلاً من ذلك ننتقل إلى مخطط نستخدم فيه
معرف المستخدم (user_id) لكل من المستخدم المرسل والمستقبل. الفائدة
من ذلك هي عدم الحاجة إلى تخزين Message-ID في أي مكان
(إلا عندما ينشئ بريد إلكتروني وارد منشورًا) وبالتالي ستكون رؤوس References
و In-Reply-To متسقة دائمًا.

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

(تستخدم معظم أنظمة البريد سلاسل عشوائية لأنه لا يوجد سياق محيط مثل هيكل موضوع Discourse - تُعتبر الرسائل بمفردها؛ لكن المتطلب الحقيقي الوحيد هو التفرد المستمر.)

دعني أعطي مثالًا. لنفترض أن لدينا هؤلاء المستخدمين:

  • martin - user_id 25
  • cameron - user_id 44
  • sam - user_id 78
  • bob - user_id 999

ثم لدينا هذا الموضوع، topic_id 233499، مع منشورات تبدأ من post_id 100 كمنشور أصلي (OP). سيكون التنسيق topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}.

ستبدو عملية الترتيب كالتالي:

  1. martin ينشئ المنشور الأصلي (OP)
  • يتم إرسال بريد إلكتروني إلى cameron يحتوي على هذه الرؤوس:
    • Message-ID: topic/233499.s25r44@meta.discourse.org
    • References: topic/233499@meta.discourse.org
  • يتم إرسال بريد إلكتروني إلى sam يحتوي على هذه الرؤوس:
    • Message-ID: topic/233499.s25r78@meta.discourse.org
    • References: topic/233499@meta.discourse.org

  1. لا يجب أن يكون هناك رأسية References في المنشور الأصلي (OP). فهي غير
    ضرورية للترتيب الخيطي وتفترض فعليًا وجود “منشور 0” غير موجود. هذا يعني أن كل منشور أصلي (أ) يبدو وكأنه رد، وهو ليس كذلك، و (ب) يبدو أن الشيء الذي هو رد عليه مفقود من صندوق بريد القارئ.

  2. هذا يجعل معرفات رسائل مختلفة لكل نسخة صادرة من المنشور الأصلي. هذا
    سيء. يجب أن تكون هي نفسها. لنفترض أن sam أرسل نسخة من الرسالة (CC) إلى cameron مباشرة في رد. سيحتوي In-Reply-To على معرف رسالة لم يتلقه cameron أبدًا.

يمكنك ببساطة إسقاط sender_user_id و receiver_user_id من حقل
معرف الرسالة والحصول على معرف فريد واحد يراه كل مستقبل.

شرط التفرد هو المنشور نفسه، وليس كائن “الرسالة” على مستوى البريد الإلكتروني الفردي.

بخصوص References، لا يجب أن يكون للمنشور الأصلي (OP) واحد. سيكون Thunderbird وكل شيء آخر على ما يرام. إذا كانوا يستخدمون References للترتيب الخيطي بدلاً من In-Reply-To، فإن References في رسائل الرد كافية.

إليك بداية سلسلة مناقشة في قائمة بريدية في Mutt:

16Jul2022 01:09 Rob Boehne      - │├>[Python-Dev] Re: [SPAM] Re: Swit python-dev 9.2K
16Jul2022 01:33 Peter Wang      - │├>                                 python-dev 3.0K
16Jul2022 00:24 Skip Montanaro  - ├>[Python-Dev] Re: Switching to Dis python-dev 4.2K
16Jul2022 04:49 Erlend Egeberg  - ├>[Python-Dev] Re: Switching to Dis python-dev  10K
16Jul2022 04:20 Mariatta        - ├>[Python-Dev] Re: Switching to Dis python-dev  10K
15Jul2022 21:18 Petr Viktorin   - [Python-Dev] Switching to Discourse python-dev 4.2K

تجاهل أنني أرتب بريدي الإلكتروني الأحدث في الأعلى. لاحظ أنه لا يوجد سهم على
المنشور الأولي (في الأسفل). تلك الرسالة ليس لها References ولا
In-Reply-To. جميع الرسائل الأخرى لها In-Reply-To (وربما
References، لكن هذا قائمة بريدية إلكترونية لذا ليس بالضرورة؛ كما ذكرت سابقًا فهي مكملة لبعضها البعض.)

إذا كررت مثال Discourse الخاص بي من سابقًا:

23Jul2022 06:24 Olha via Discus - ┌>[Py] [Users] I need an advise  discuss-users 5.7K
22Jul2022 17:12 Paul Jurczak vi - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 13:21 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.8K
22Jul2022 12:53 vasi-h via Disc - ├>[Py] [Users] I need an advise  discuss-users 5.5K
22Jul2022 11:38 Cameron Simpson - ├>[Py] [Users] I need an advise  discuss-users  14K
22Jul2022 10:27 Rob via Discuss - ├>[Py] [Users] I need an advise  discuss-users 6.6K
22Jul2022 06:14 vasi-h via Disc r ┴>[Py] [Users] I need an advise  discuss-users 6.5K

لاحظ أن لديهم جميعًا سهمًا قياديًا؟ هذا لأن عميل البريد الإلكتروني
يعتقد أنها جميعًا ردود على رسالة جذر مشتركة (وغير موجودة)،
وهو ما يرجع إلى معرف الرسالة “الموضوع” في رأسية References. بينما المنشور 1 هو في الواقع الرسالة السفلية المعروضة أعلاه.

ملخص:

  • خطتك جيدة، بشرط أن تسقط المرسل والمستقبل من
    معرف الرسالة - فهما غير ضروريين وفي الواقع سيؤدي المستقبل إلى مشاكل (المرسل مجرد تكرار).
  • اسقط معرف الرسالة الوهمي “الموضوع” من References - فهو يضلل
    عملاء البريد الإلكتروني (بما في ذلك Thunderbird، حتى لو لم يكن ذلك واضحًا بصريًا)
  1. cameron يرد عبر البريد الإلكتروني
  • يتم إرسال بريد إلكتروني إلى discourse يحتوي على هذه الرؤوس من Mutt:
    • Message-ID: 43585349859734@test.com
    • References: topic/233499@meta.discourse.org topic/233499.s25r44@meta.discourse.org
    • In-Reply-To: topic/233499.s25r44@meta.discourse.org

نعم، مرة أخرى مع التحذير من أنه لا يجب أن يكون هناك مرجع “موضوع”.
كما هو متوقع، هناك مرجع لمعرف رسالة المنشور الأصلي (OP). ومع ذلك، يجب أن
يكون نفس معرف الرسالة الذي يراه sam للمنشور الأصلي.

  1. ينشئ discourse (بصفتي cameron، من البريد الإلكتروني أعلاه) المنشور 101
  • يتم إرسال بريد إلكتروني إلى sam من discourse يحتوي على هذه الرؤوس:
    • Message-ID: topic/233499/101.s44r78@meta.discourse.org
    • References: 43585349859734@test.com topic/233499@meta.discourse.org
    • In-Reply-To: 43585349859734@test.com

وهنا يحدث الخطأ. يجب أن يكون Message-ID هو
43585349859734@test.com من حقل .incoming_post.message_id. (حسنًا، في رأيي هذا هو post.message_id()، الذي يعيد
post.incoming_post.message_id لمنشور تم إنشاؤه بواسطة البريد الإلكتروني ورسالة Discourse المولدة في غير ذلك).

تخيل: أنا أكتب وأرسل ردّي بمعرف رسالة 43585349859734@test.com. لأسباب الاستمرارية، احتفظ بنسخة منه في مجلدي المحلي، حيث يظهر كرد على المنشور الأصلي. بشكل مثالي، ترسل لي Discourse أيضًا نسخة من منشوري (هذا إعداد سياسة في العديد من القوائم البريدية)، لذا أحصل أيضًا على نسخة Discourse. يجب أن يكون لها نفس معرف الرسالة، لأنها نفس الرسالة، فقط عبر مسار مختلف.

رسالة Discourse ليست “ردًا على” رسالتي. إنها رسالتي، فقط تم توجيهها.

هذا التأثير يتسلسل عبر الأمثلة التالية الخاصة بك. يجب أن تكون العملية الفعلية
أبسط مما جعلتها.

فكر في الأمر بهذه الطريقة. إذا قمت بالرد على منشور من البريد الإلكتروني، فهو فعليًا
مثل إرسال بريدي إلى sam (والآخرين) عبر Discourse. يقوم Discourse
بتوجيه رسالتي إلى المشتركين المستلمين للبريد الإلكتروني، و
“عن طريق الصدفة” يحتفظ بنسخة على المنتدى :slight_smile:

كإشارة جانبية، لقد بحثت أيضًا في ما يفعله GitHub مع رسائل
الإشعار الخاصة به، ولاحظت أنهم يفعلون شيئًا مشابهًا حيث لديهم مرجع دائم
(discourse/discourse/pull/252@github.com) يُستخدم في جميع رسائل البريد الإلكتروني
المرتبطة بهذا “الموضوع” والذي في هذه الحالة هو طلب سحب (pull request) على GitHub:

References: <discourse/discourse/pull/252@github.com> <discourse/discourse/pull/252/issue_event/7042100517@github.com>
In-Reply-To: <discourse/discourse/pull/252/issue_event/7042100517@github.com>

واو، GitHub. كم هي كارثة رسائل قضاياهم :slight_smile:

ومع ذلك، في سيناريوهم، طلب السحب (PR) هو المنشور الأصلي (OP). لذا فإن المرجع المباشر
إلى طلب السحب أمر منطقي. يمكنك استخدام معرف الرسالة “الموضوع” للمنشور 1،
بشرط ألا تستخدم أيضًا معرف “الموضوع/1” أيضًا. ولكن لا يبدو أن هناك فائدة كبيرة - فهو جهد إضافي لتخصيص حالة المنشور 1 - سأستخدم “الموضوع/1” بنفسي.

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

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

7 إعجابات
12

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

إعجابَين (2)
15

بواسطة مارتن برينان عبر Discourse Meta في 25 يوليو 2022 00:28:

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

بالتأكيد. تحياتي، كاميرون سيمبسون

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

بالمناسبة، لاحظت أن هذه المشاركة اللاحقة منك تحتوي على هذه الرؤوس:

Message-ID: <topic/233499/1137586.d14eea2849d76c355ec214fb@meta.discourse.org>
In-Reply-To: <YttEVzlTh/ymDSPT@cskk.homeip.net>
References: <topic/233499@meta.discourse.org>
      <YttEVzlTh/ymDSPT@cskk.homeip.net>

أي أنها حافظت على معرف الرسالة الأصلي الخاص بي. لذا فإن In-Reply-To صحيح، و References على الأقل يحتوي على معرف الرسالة الخاص بي.

لم يكن هذا ما كنا نلاحظه في discuss.python.org.

تحياتي،
Cameron Simpson

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

آه، هذه ملاحظة مثيرة للاهتمام، لم ألاحظ السهم الصغير.

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

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

  • TODO #1 - إذا كان للمنشور سجل IncomingEmail مرتبط به، فإننا نستخدم دائمًا Message-ID هذا عند إرسال البريد الإلكتروني.
  • TODO #2 - لا تستخدم References عند إرسال رسائل بريد إلكتروني متعلقة بـ OP للموضوع. @cameron-simpson سؤال واحد رغم ذلك - إذا تم إنشاء OP عبر بريد إلكتروني وارد، فهل نستخدم Message-ID هذا في References لـ OP أم لا نزال نستبعده؟

هذا مثير للاهتمام، اعتقدت أن كل مستلم للبريد الإلكتروني يجب أن يكون لديه Message-ID فريد؟ في الواقع أعتقد أن هذا هو السبب في أننا سلكنا مسار إضافة التفرد إلى Message-ID لكل مستلم، لتجنب سلوكيات البريد العشوائي، بالنظر إلى موضوعنا الداخلي. ربما @supermathie ، الذي هو في فريق البنية التحتية لدينا وكان يقوم بالكثير من الاختبارات مع البريد الإلكتروني في وقت سابق من هذا العام، يمكنه أيضًا إبداء رأيه هنا؟

ما تقوله هو أن المنشور هو الذي يحدد Message-ID واحدًا لجميع المستلمين. لذا ربما ننشئ واحدًا لكل منشور ينشئ بريدًا إلكترونيًا؟ ثم يمكننا أيضًا نقل IncomingEmail.message_id إلى هنا. بشكل مبدئي، التغيير الذي سنحتاج إلى إجرائه هو:

  • TODO #3 - أضف outbound_message_id إلى جدول Post. أنشئه مرة واحدة عند إرسال بريد إلكتروني لأول مرة فيما يتعلق بالمنشور. استخدمه لرؤوس References و In-Reply-To اللاحقة. قم بتعيين قيمته عند إنشاء منشور من IncomingEmail. يجب أن يكون التنسيق topic/:topic_id/:post_id/:random_alphanumeric_string@host على سبيل المثال topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

بعد هذا التغيير، سيصبح مثالي الأول كالتالي:

  1. martin ينشئ OP
  • يتم إرسال بريد إلكتروني إلى cameron مع هذه الرؤوس:
  • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
  • يتم إرسال بريد إلكتروني إلى sam مع هذه الرؤوس:
  • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

مع الأخذ في الاعتبار أيضًا أن OP لا يحصل على معالجة خاصة، فلن يكون بالتنسيق topic/:topic_id@hostname بعد الآن.

  • TODO #4 - تأكد من إنشاء رؤوس In-Reply-To و References الصحيحة بناءً على سجلات PostReply وعمود outbound_message_id الجديد في جدول Post

أعتقد أن لدينا بعض الاعتبارات لهذا، سأتحقق مرة أخرى.

يبدو بالتأكيد كذلك :ابتسامة عرق:

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

إذا لم يكن الأمر كذلك، فلا بأس - لدي Thunderbird وسأقوم بإعداد mutt ويمكنني اختبار كل شيء هناك :slight_smile:

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

@cameron-simpson أردت توضيح شيء واحد هنا وهو نطاق “message_id”.
الشيء الذي بدأ كل هذه الرقصة كان شكًا قويًا من @supermathie في أن معرفات الرسائل غير الفريدة لدينا كانت تسبب مشاكل.
يقوم Discourse بإنشاء رسائل بريد إلكتروني فريدة لكل مستخدم لكل بريد إلكتروني يرسله. لذا، على سبيل المثال، لنفترض أن مستخدمين اثنين يتابعان هذا الموضوع:

  • يحصل المستخدم 1 على الحمولة 1 برابط إلغاء اشتراك مميز موجه إلى المستخدم 1
  • يحصل المستخدم 2 على الحمولة 2 برابط إلغاء اشتراك مميز موجه إلى المستخدم 2
    إذا كان معرف رسالتنا في كلتا الحالتين هو discourse_topic_100/23 (على سبيل المثال topic_id/post_number)، فسنخبر MTAs هناك بأن discourse_topic_100/23 يمكن أن يكون حمولتين مختلفتين، والفرضية هي أنهم يعاملون هذا كإشارة بريد عشوائي.

مرحبًا Discourse … لقد أرسلت للتو بريدين باسم discourse_topic_100/23، ما الأمر؟

نظرًا لأن Discourse يتحكم في جميع نقل البريد الإلكتروني ولا تتم إضافة رسائل البريد الإلكتروني إلى قائمة BCC أو CC مثل قوائم البريد التقليدية، يمكننا تحمل تكاليف روابط إلغاء اشتراك نظيفة لكل مستخدم.
ما هي أفكارك هنا؟ ماذا عن التغيير البسيط لاستخدام discourse_topic_100/23/7333 على سبيل المثال (topic_id، post_number، user_id) كمعرف فريد للبريد، فهو بالتأكيد حمولة فريدة ويمكننا الإشارة إليه بسهولة عند إنشاء رسائل بريد إلكتروني للمستخدم.

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

بواسطة مارتين برينان عبر Discourse Meta في 26 يوليو 2022 الساعة 00:27:

[quote=“Cameron Simpson, post:11, topic:233499,
username:cameron-simpson”]
Mutt ربما يتجاهل References
لأنه قارئ بريد إلكتروني، و References ينشأ في أخبار USENET.
ربما يستخدم Thunderbird المراجع أو يضيف معلومات الرد إليها
بمعلومات المراجع.

أنت بحاجة فقط إلى الرجوع إلى أحد In-Reply-To أو References للقيام
بترتيب المواضيع؛ الأول يأتي من البريد الإلكتروني والثاني من USENET.
أنت تدعم كليهما (وهذا رائع!) لذا نحتاج إلى جعلهما
متسقين.
[/quote]

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

أعتقد أن mutt سيستخدم كليهما، ولكن ربما فقط In-Reply-To إذا كان موجودًا،
مع العودة إلى References. سأحتاج إلى التحقق من الكود المصدري.

مع References، أنت على الأقل تعرف السلسلة الكاملة إلى المنشئ الأصلي (OP)؛ أما مع
In-Reply-To، فأنت بحاجة تقريبًا إلى الرسائل السابقة المحيطة لـ
تجميع الأمور معًا. بالنسبة للقوائم البريدية، عادةً ما أحافظ على السلسلة
الكاملة محليًا حتى تنتهي على أي حال، وأتوقع أن هذا أمر شائع.

يبدو أننا نفعل ذلك بالفعل، لكنني أظن أنه ليس بشكل متسق؟ بشكل أساسي، نحتاج إلى التأكد من أن:

  • TODO #1 - إذا كان للمنشور سجل IncomingEmail مرتبط به، فنحن نستخدم دائمًا معرف الرسالة (Message-ID) هذا عند إرسال البريد الإلكتروني.

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

  • TODO #2 - لا تستخدم References عند إرسال رسائل بريد إلكتروني تتعلق بالمنشور الأصلي (OP) للموضوع.

نعم. المنشور الأصلي (OP) ليس له سوابق، لذا لا يوجد References أو
In-Reply-To.

@cameron-simpson سؤال واحد فقط – إذا تم إنشاء المنشور الأصلي (OP) عبر بريد
إلكتروني واصل، فهل سنستخدم معرف الرسالة (Message-ID) هذا في References للمنشور
الأصلي (OP) أم نستبعده كما هو؟

استبعده لا يزال. ولكن استخدمه كمعرف رسالة دائم للمنشور الأصلي (OP).

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

[quote=“Cameron Simpson, post:11, topic:233499,
username:cameron-simpson”]
يمكنك ببساطة إسقاط sender_user_id و receiver_user_id من حقل
معرف الرسالة والحصول على معرف فريد واحد يراه كل مستلم.

شرط التفرد هو المنشور نفسه، وليس كائن
«الرسالة» على مستوى البريد الإلكتروني الفردي.
[/quote]

هذا مثير للاهتمام، كنت أعتقد أن كل مستلم للبريد الإلكتروني يجب أن يكون لديه معرف رسالة (Message-ID) فريد؟

لا. معرف الرسالة يحدد «الرسالة». وليس النسخة الفردية. قد
أُنشر في المنتدى وأرسل نسخة معروفة (CC) لشخص ما مباشرة. إذا حصل ذلك الشخص على نسخة
مباشرة مني وأيضًا عبر المنتدى، فيجب أن يكون لديهم نفس
معرف الرسالة.

في الواقع، أعتقد أن هذا هو السبب في أننا سلكنا طريق إضافة
التفرد إلى معرف الرسالة (Message-ID) لكل مستلم، لتجنب سلوكيات البريد العشوائي (spam)،
بالنظر إلى موضوعنا الداخلي. ربما @supermathie، الذي يعمل في
فريق البنية التحتية لدينا وكان يقوم بالعديد من الاختبارات مع البريد الإلكتروني في وقت سابق من
العام، يمكنه أيضًا الإدلاء برأيه هنا؟

ربما. ولكن على وجه النظر، فإن ترتيب المواضيع (threading) معطوب بالفعل. بالتأكيد
إرسال نفس الرسالة إلى العديد من الأشخاص يجب أن يكون له نفس معرف الرسالة،
وبشكل عام، كمرسل للأمام (البريد الإلكتروني → discourse → مستلمي البريد الإلكتروني)
يجب ألا يقوم discourse بتعديل معرفات الرسائل.

ما تقوله هو أنه من الأفضل أن يكون المنشور هو العنصر الذي يحدد معرف رسالة (Message-ID) واحدًا لجميع المستلمين. لذا ربما نقوم فقط بتوليد واحد لكل منشور يولد بريدًا إلكترونيًا؟

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

ثم يمكننا أيضًا نقل IncomingEmail.message_id إلى هنا أيضًا.

بالتأكيد. وجود مجموعة مميزة من الحقول (يبدو أن معرف الرسالة يكفي) تحتوي على حالة جانب البريد الإلكتروني يجب أن يفعل ذلك.

مؤقتًا، التغيير الذي نحتاج إلى إجراؤه هو:

  • TODO #3 - **إضافة outbound_message_id إلى جدول Post. قم بتوليد
    معرف الرسالة مرة واحدة عند إرسال بريد إلكتروني لأول مرة فيما يتعلق بالمنشور.

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

استخدمه في رؤوس References و In-Reply-To اللاحقة. قم بتعيين قيمته
عند إنشاء منشور من IncomingEmail.

نعم. إلى معرف الرسالة من البريد الإلكتروني.

يجب أن يكون التنسيق
topic/:topic_id/:post_id/:random_alphanumeric_string@host على سبيل المثال
topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

بالنسبة لتلك التي تولدها بنفسك، يبدو هذا جيدًا بالنسبة لي.

بعد هذا التغيير، سيصبح مثالِي الأول هكذا:

  1. مارتين ينشئ المنشور الأصلي (OP)
  • يتم إرسال بريد إلكتروني إلى كاميرون مع هذه الرؤوس:
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org
  • يتم إرسال بريد إلكتروني إلى سام مع هذه الرؤوس:
    • Message-ID: topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org

نعم.

ولكن لاحظ: معرف الرسالة يحتاج فقط إلى أن يكون مستقرًا وفريدًا. إذا كان
topic/:topic_id/:post_id@host مستقرًا ولن يتم إعادة توليده أبدًا،
فسيكون ذلك كافيًا. ولكن إذا كنت قلقًا بشأن ذلك (مثل استعادة قاعدة البيانات أو
الهجرات أو الاستيرادات التي تجلب تلك الأرقام نفسها)، فإن السلسلة العشوائية
ستجعلها قوية ضد التصادم.

لاحظ أن الجزء الأيسر من معرف الرسالة هو dot-atom-text، مُعرَّف هنا:

وهو أحرف أبجدية وأرقام ومجموعة محدودة من أحرف الترقيم
(والتي تشمل “/”).

أم، رؤوسك. يجب أن تحتوي على:

Message-ID: <topic/233499/33545/gvy8475y7c45y87554c@meta.discourse.org>

لاحظ الأقواس الزاوية. معرف الرسالة هو رسميًا الجزء بين
الأقواس الزاوية، والأقواس الزاوية إلزامية. الصيغة هنا:

مع مراعاة أيضًا أن المنشور الأصلي (OP) لا يتلقى معالجة خاصة، فلن يكون بعد الآن بتنسيق topic/:topic_id@hostname.

يبدو جيدًا.

  • TODO #4 - التأكد من توليد رؤوس In-Reply-To و References الصحيحة بناءً على سجلات PostReply والعمود الجديد outbound_message_id في جدول Post

شكرًا.

أعتقد أننا لدينا بعض الاعتبارات لهذا، سأتحقق مرة أخرى.

+1

يبدو بالتأكيد كذلك :sweat_smile:

هل يمكنك تأكيد أن مهام TODO هنا تبدو معقولة يا كاميرون؟

يبدو أنها صحيحة بالنسبة لي.

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

بالتأكيد. سعيد للمساعدة بأي طريقة كانت.

إذا لم يكن الأمر كذلك، فلا بأس أيضًا – لدي Thunderbird وسأقوم بإعداد
mutt ويمكنني اختبار كل شيء هناك :slight_smile:

يمكنني مساعدتك في mutt إذا أردت ذلك أيضًا.

3 إعجابات
22

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

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

وكانت هناك مناقشات طويلة حول توقيع المحتوى والتي تتمحور حول ما يجب تغطيته بتوقيع.

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

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

لذا باختصار: لا أعتقد أن نص إلغاء الاشتراك الإضافي البسيط الخاص بك يستدعي معرفات رسائل مميزة. احتفظ بواحد فقط.

4 إعجابات
23

عذرًا، أنا فقط ألحق بالركب الآن، إليك بعض الأفكار، بعضها تم تناوله بالفعل…

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

ما هي الرسالة بالضبط؟ بالنظر إلى 5322 كحقيقة مطلقة:

تتكون الرسالة من حقول رأس، يتبعها اختياريًا جسم الرسالة.

يوفر حقل “Message-ID:” معرف رسالة فريد يشير إلى إصدار معين من رسالة معينة.

[التشديد لي]

هذا “الإصدار المعين” هو ما يجعلني أعتقد أنه سيكون من غير المناسب إعادة إرسال رسالة واردة بمعرف رسالة مختلف. على الرغم من ذلك، إذا غيرت وجهة نظرك من Discourse كـ “برنامج منتدى” إلى Discourse كـ “برنامج قائمة بريدية” فإن ذلك نوعًا ما منطقي، لذلك أفهم وجهة نظرك. يقول 5322 أيضًا:

هناك العديد من الحالات التي يتم فيها “تغيير” الرسائل، ولكن هذه التغييرات لا
تشكل تجسيدًا جديدًا لتلك الرسالة، وبالتالي لن تحصل الرسالة على معرف رسالة جديد. على سبيل المثال، عندما يتم إدخال الرسائل في نظام النقل، غالبًا ما يتم إضافة
حقول رأس إضافية إليها مثل حقول التتبع (الموصوفة في القسم 3.6.7)
وحقول إعادة الإرسال (الموصوفة في القسم 3.6.6). لا يؤدي إضافة حقول الرأس هذه إلى تغيير هوية الرسالة وبالتالي يتم الاحتفاظ بـ “Message-ID:” الأصلي. في جميع الحالات، فإن معنى
المرسل للرسالة الذي يرغب في نقله (أي، ما إذا كانت هذه هي نفس
الرسالة أو رسالة مختلفة) هو ما يحدد ما إذا كان حقل “Message-ID:” يتغير أم لا، وليس أي اختلاف تركيبي معين يظهر (أو لا يظهر) في الرسالة.

أفترض أن الأمر يعود إلى ما إذا كان مرسل الرسالة يتغير عندما يرسلها Discourse؟

ربما يجب أن نستخدم Resent-Message-ID والأصدقاء؟

لقد كان موجودًا دائمًا، منذ 822. ولكن كما تقول لاحقًا، نعم لقد تم تحديثه.

يتحدث 5322 أيضًا مباشرة عن الطريقة التي يستخدم بها Discourse و Github:

قد يتم استخدام حقل “In-Reply-To:” لتحديد الرسالة (أو الرسائل) التي ترد عليها الرسالة الجديدة، بينما قد يتم استخدام حقل “References:” لتحديد “سلسلة” محادثة.

ربما بشكل غير صحيح قليلاً، على الأرجح بسبب عدم وجود “معرف سلسلة” مناسب. ولكن قد لا يكون هذا التفسير هو ما قصده مؤلفو RFC… فهو لا يعالج الرسائل التي تحتوي على “References” ولكن بدون “In-Reply-To”.

الجزء الصعب في هذا هو أننا لا نرسل بريدًا إلكترونيًا واحدًا، بل نرسل N - واحد لكل مستلم - حتى تتمكن بياناتهم الوصفية الفردية (إلغاء الاشتراك، إلخ) من أن تكون صحيحة.

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

الفوائد هنا، بصراحة، تتعلق بالكامل بترتيب رسائل البريد الإلكتروني بشكل صحيح في بعض عملاء البريد على حساب قابلية التسليم.

topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id} الحالي على الأقل يجعله متسقًا للمستخدم في صندوق الوارد الخاص به. الافتراض

أكبر مخاوفي هو قابلية التسليم - من الصعب بما يكفي تسليم البريد الإلكتروني عندما لا يكون هناك أي رؤية من مقدمي الخدمة الرئيسيين.

لكنني أرى حجة قوية لجعل Discourse يتصرف بشكل أكبر مثل برامج القوائم البريدية في وضع القائمة البريدية. @martin أعتقد أننا لا نقوم بتخصيص جسم الرسالة في وضع القائمة البريدية؟ هل تعتقد أنه من المنطقي اتخاذ نهج أكثر صرامة حول الحفاظ على معرفات الرسائل وإعادة استخدامها في وضع القائمة البريدية؟

5 إعجابات
24

لا أريد أن أكون في موقف يكون فيه الكمال عدوًا لما يكفي.

نحن نستخدم “لاحقة عشوائية” الآن في الرسائل وهذا يسبب بلا شك ألمًا.

لدينا 3 خيارات مطروحة:

  1. معرفات رسائل عشوائية لا يمكن الرجوع إليها
  2. معرفات رسائل ثابتة لكل موضوع/منشور/مستخدم
  3. معرفات رسائل ثابتة لكل زوج موضوع/منشور

نحن حاليًا في الكوكب (1) الذي يسبب دمارًا.

أخشى أن نصل إلى شلل في اتخاذ القرار بين (2) و (3).

ربما نبدأ ببساطة بـ (2) مع الاعتراف بأن إضافة نسخ إضافية إلى بريد إلكتروني من Discourse قد تسبب سلوكًا غير متوقع، ونتوقف على الأقل عن غالبية الألم هنا؟

4 إعجابات
25

آه! اعتقدت أننا كنا نقوم بالفعل بـ: topic/#{topic_id}/#{post_id}.s#{sender_user_id}r#{receiver_user_id}

كنت سأميل إلى، لصالح موازنة مخاوف تفرد البريد الإلكتروني وقابلية التسليم مقابل مخاوف وضع القائمة البريدية، القيام بـ (2) لوضع القائمة البريدية معطلاً و (3) لوضع القائمة البريدية ممكّنًا.

وبالمثل، مع ترويسة References، كنت سأميل إلى جعلها غائبة للمنشور رقم 1 في موضوع ما والإشارة إليه (لذا topic/#{topic_id}) والمنشور الذي يرد عليه، إن وجد.

3 إعجابات