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

خلل
26

أعتذر مقدمًا عن بعض النبرة أدناه. أبدو منفعلًا،
لأنني منفعل قليلاً.

بقلم مايكل براون عبر Discourse Meta في 27 يوليو 2022 14:06:

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

[اقتباس=“Cameron Simpson، post:8، topic:233499، username:cameron-simpson”]
يبدو أن هذا الالتزام الثاني يعالج مشكلة أخرى واجهناها: إذا كان
تم إرسال منشور من بريد إلكتروني، فإن معرف الرسالة الصادر إلى مستخدمي البريد الإلكتروني هو
ليس معرف الرسالة للرسالة المصدر من المؤلف.
[/اقتباس]

[اقتباس=“Cameron Simpson، post:11، topic:233499، username:cameron-simpson”]
Message-ID هو معرف فريد للرسالة
[/اقتباس]

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

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

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

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

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

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

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

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

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

أرى أنك تستمر في اقتباس ما كنت سأستشهد به للتو :slight_smile:

5322 يقول أيضًا:

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

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

أعتقد أنك أسأت قراءة الأمور هنا. دعني أؤكد:

في جميع الحالات، المعنى الذي
يرغب مرسل الرسالة في نقله (أي، ما إذا كانت هذه هي نفس الرسالة
أو رسالة مختلفة) هو ما يحدد ما إذا كان
حقل “Message-ID:” يتغير

المرسل هو المؤلف، وليس MTA مثل Discourse.

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

إنها لا تزال نفس الرسالة.

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

بالتأكيد لا. إنها لـ مستخدم يعيد إرسال رسالة. على سبيل المثال، إذا قمت بإعادة توجيه رسالة إلى شخص آخر. إنها ليست لوسطاء البريد (مثل القوائم و Discourse).

[اقتباس=“Cameron Simpson، post:8، topic:233499، username:cameron-simpson”]
يبدو أن References موجود أيضًا الآن في RFC5322
[/اقتباس]

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

أوتش. اعتقدت أنه كان خاصًا بـ USENET في ذلك الوقت. أنا مصحح.

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

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

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

يقول لي أن الحقلين يغطيان نفس المعلومات:

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

[اقتباس=“Martin Brennan، post:19، topic:233499، username:martin”]
هذا مثير للاهتمام، اعتقدت أن كل مستلم للبريد الإلكتروني يجب أن يكون لديه Message-ID فريد؟ في الواقع أعتقد أن هذا هو السبب الذي دفعنا إلى إضافة التفرد إلى Message-ID لكل مستلم، لتجنب سلوكيات البريد العشوائي، بالنظر إلى موضوعنا الداخلي. ربما يمكن لـ @supermathie ، الذي هو في فريق البنية التحتية لدينا وكان يقوم بالكثير من الاختبارات مع البريد الإلكتروني في وقت سابق من هذا العام، أن يساهم هنا أيضًا؟
[/اقتباس]

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

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

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

هل يمكنك إظهار بعض هذه الحالات. لأن معرفات الرسائل تسمح
إزالة التكرار على مستوى المستخدم النهائي. وخذ في الاعتبار أن العديد من
“مكافحة البريد العشوائي” هي هراء مضلل. عدد الأشياء التي تم رفضها كبريد عشوائي محتمل لأسباب زائفة تمامًا… كسر البريد الإلكتروني للعمل حول تصفية البريد العشوائي المعطل هو خيار سيء.

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

[اقتباس=“Cameron Simpson، post:22، topic:233499،
username:cameron-simpson”]
لذلك سأكون بخير تمامًا إذا أضفت رابط إلغاء الاشتراك الخاص بك الخاص بالمستلم وحافظت على معرف الرسالة الأصلي. الفوائد تفوق بكثير فقدان التجميع إذا أعطيت كل نسخة من الرسالة معرف رسالة فردي.
[/اقتباس]

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

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

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

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

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

دعني أكرر المشكلتين الأساسيتين هنا:

  • يستشهد In-Reply-To و References الخاص بالمنشور الأصلي بمعرف رسالة “موضوع” وهمي “قبل المنشور الأصلي”، لذلك لا يمتلك أي مستخدم بريد إلكتروني موضوعًا برسالة بداية (المنشور الأصلي) - كل شيء بما في ذلك المنشور الأصلي يبدو كمتابعة
  • رسائل البريد الإلكتروني المستلمة عبر Discourse ورسائل البريد الإلكتروني المستلمة مباشرة على سبيل المثال عبر النسخ المتماثل لها معرفات رسائل مختلفة على الرغم من أنها نفس الرسالة من الناحية الدلالية؛ هذا يكسر التجميع وإزالة التكرار

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

هناك أشخاص في Pythonland وجدوا أن “وضع القائمة البريدية” كان أكثر من اللازم. يريدون الحصول على بريد إلكتروني لمواضيع مستهدفة ولكن ليس كل شيء. يجب أن تكون معالجة معرف الرسالة هي نفسها لجميع جوانب البريد الإلكتروني.

أنا شخص “وضع القائمة البريدية” على discuss.python.org. لكنني قمت بتشغيله هنا (discourse.org) وأوقفته فورًا. أحتاج إلى وضع مستهدف هنا.

4 إعجابات
27

بواسطة مايكل براون عبر Discourse Meta في 27 يوليو 2022 الساعة 22:37:

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

{receiver_user_id} يضعك في معرفات رسائل مميزة لكل مستخدم نهائي لنفس المنشور المصدر. هذا سيء بمجرد أن يتواصل المستخدمون النهائيون خارج discourse أو يحصلون على نسخ ليست عبر discourse.

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

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

وبالمثل، مع رأس References، أميل إلى جعله غائبًا للمنشور رقم 1 في موضوع

وكذلك In-Reply-To. لا ينبغي أن يكون أي منهما موجودًا، لأنه لكي يكون موجودًا يجب أن يشير إلى رسالة وهمية لكل OP.

وجعله يشير إلى الموضوع (لذلك topic/#{topic_id}) والمنشور

الذي يرد عليه، إن وجد.
لا يمكنك الإشارة إلى معرف الرسالة “للموضوع” _ما لم يكن هناك منشور بهذا المعرف الذي تم إرساله كبريد إلكتروني. إذا كنت تريد الذهاب في هذا الاتجاه، فقم بحالة خاصة لمعرف الرسالة الخاص بـ OP ليكون معرف الرسالة “للموضوع” بدلاً من ...../1.

3 إعجابات
29

يجب أن يكون هذا “قبل العملية”. آسف، كاميرون سيمبسون

30

كما تقول، هذه هي بالضبط المشكلة التي تُحبطنا:

أتفق على أنه يجب تغيير هذا. يجب أن يكون معرف الرسالة الأصلي (بدلاً من معرف وارد عبر البريد) (مبسط) topic/1 ولا يشير إلى رسالة أخرى.

لن يتغير معرف الرسالة، حتى لو كان مجرد منشور Discourse ولم يكن بريدًا إلكترونيًا أبدًا.

يمكن للرسائل الإضافية الإشارة إلى هذا.

لماذا يجب أن يكون هناك بريد إلكتروني؟ من الناحية الدلالية، وجود المنشور فقط يلبي المعايير. الرسالة التي يرد عليها موجودة، فقط ليست في مجلد البريد الإلكتروني الخاص بهذا الشخص. لقد توصلنا للتو إلى استنتاج مفاده أن الرسالة هي ما يهم، سواء كانت نص المنشور أو نص البريد الإلكتروني. يتبع ذلك أن topic/#{topic_id}/1@site هو معرف رسالة فريد يشير إلى هذا المنشور، سواء كان في رسالة بريد إلكتروني أم لا.

لا يختلف الأمر عن تلقي رد على بريد إلكتروني يشير إلى بريد إلكتروني غير موجود في صندوق الوارد الخاص بك. لا يزال ردًا، لذا فإن References شرعي وصحيح.

في الأساس، أتفق معك. يريد الكمالي في داخلي أن يكون هذا صحيحًا. لكن الجانب العملي للحاجة إلى إيصال البريد الإلكتروني إلى صناديق الوارد الخاصة بالأشخاص هو ما أدى إلى ذلك. للأسوأ، يستخدم الكثير من الأشخاص Gmail ولا يقومون بتدريب مرشحاته أبدًا، ويستخدمونه بشكل غير صحيح، و “يلغون الاشتراك” عن طريق الإبلاغ كبريد عشوائي [1].

أتفق، أعتقد أننا قرأنا حرفيًا بعض الشيء

يتعلق معرف الرسالة بإنشاء واحد بالضبط لرسالة معينة

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

  • معرف_الرسالة_من_البريد_الوارد || topic/#{topic_id}/#{post_num}@site (رقم منشور الموضوع الأصلي هو 1)

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

  1. ليس أن Gmail يبلغنا بذلك، على الرغم من أننا قمنا بتطبيق حلقة التغذية الراجعة. ↩︎

5 إعجابات
31

شكراً لردودكم @supermathie و @cameron-simpson، أعتقد أننا توصلنا إلى توافق في الآراء. سأقوم بتجميع المهام المعلقة في منشور واحد، وآمل أن أتمكن من البدء في العمل عليها قريبًا جدًا:

  1. تغيير تنسيق Message-ID الذي تم إنشاؤه ليكون دائمًا \u003cdiscourse/post/:post_id@:hostname\u003e، هذا فريد بما فيه الكفاية، وهو في الأساس عودة إلى ما كنا نفعله سابقًا. الإشارة إلى الموضوع الأصلي ستستخدم الآن معرف المشاركة الأولى بدلاً من معرف الموضوع المجرد.
  2. إذا كانت هناك مشاركة مرتبطة بسجل IncomingEmail، فإننا نستخدم دائمًا معرف الرسالة هذا عند إرسال البريد الإلكتروني، وإلا فإننا ننشئ واحدًا باستخدام التنسيق أعلاه.
  3. لا تستخدم References عند إرسال رسائل البريد الإلكتروني للموضوع الأصلي للموضوع، لا يوجد شيء للإشارة إليه (Reference) بعد لأنه البريد الإلكتروني الأول في السلسلة.
  4. التأكد من إنشاء رؤوس In-Reply-To و References الصحيحة بناءً على سجلات PostReply.

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

3 إعجابات
32

للتوضيح فقط… هل سيكون هذا هو hostname الخادم الذي نشأ منه، أم عنوان URL للموقع؟ إذا كان hostname، فإننا نفقد كل الاستقرار عندما تخدم 3 مضيفين مختلفين نفس الموقع.

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

عذرًا، نعم، أعني اسم نطاق الموقع على سبيل المثال meta.discourse.org والذي يأتي من Email::Sender.host_for(Discourse.base_url)، وهو ما نستخدمه بالفعل.

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

استدعاء جيد، لم أفكر في الانتقالات. هل :post_id هو معرف المنشور (post.id) أم رقمه (ضمن الموضوع)؟

إذا كان معرف المنشور، يمكننا التبسيط واستخدام \u003cpost/:post_id@:hostname\u003e فقط نظرًا لأنه لن يتغير أبدًا، فلن نحتاج إلى تخزين Message-ID إلا إذا تم تجاوزه من الافتراضي.

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

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

إنه المعرّف الفعلي وليس رقم المنشور.

هذه نقطة جيدة، \u003cpost/:post_id@:hostname\u003e سيعمل على الأرجح بشكل جيد ويتجنب الحاجة إلى عمود إضافي. ربما لجعله أكثر تحديدًا لـ Discourse، يمكننا إضافة discourse في البداية على سبيل المثال \u003cdiscourse/post/543563@meta.discourse.org\u003e (مع الأخذ في الاعتبار أن العديد من المواقع لن يكون لديها ذكر لـ Discourse في اسم المضيف). إنها تفاصيل دقيقة في هذه المرحلة.

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

مجرد التفكير بصوت عالٍ، يجب أن يكون الأمر جيدًا، وسأغطي هذه الأمور عندما أختبر التغييرات على أي حال :+1:

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

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

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

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

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

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

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

بناءً على هذه المناقشات الإضافية @cameron-simpson، قمت بتحديث قوائم المهام إلى هذا، ونشرها هنا حتى تحصل على التحديث نظرًا لأن تعديلات Discourse لن تصل عبر البريد الإلكتروني:

  1. تغيير تنسيق Message-ID الذي تم إنشاؤه ليكون دائمًا \u003cdiscourse/post/:post_id@:hostname\u003e، هذا فريد بما فيه الكفاية، إنه في الأساس عودة إلى ما كنا نفعله سابقًا. الإشارة إلى المنشور الأصلي ستستخدم الآن معرف المنشور الأول بدلاً من معرف الموضوع المجرد.
  2. إذا كان للمنشور سجل IncomingEmail مرتبط به، فإننا نستخدم دائمًا Message-ID هذا عند إرسال البريد الإلكتروني، وإلا فإننا ننشئ واحدًا باستخدام التنسيق أعلاه.
  3. إضافة عمود جديد outbound_message_id إلى سجلات Post والذي سيتم ملؤه إما أ) بواسطة Message-ID للبريد الإلكتروني الوارد إذا كان ينشئ المنشور أو ب) بواسطة Message-ID الصادر الذي ننشئه في حالة المنشورات التي تم إنشاؤها بواسطة واجهة مستخدم Discourse على الويب.
  4. لا تستخدم رؤوس References أو In-Reply-To عند إرسال رسائل البريد الإلكتروني للمنشور الأصلي للموضوع، لا يوجد شيء للإشارة إليه أو الرد عليه بعد لأنه البريد الإلكتروني الأول في السلسلة.
  5. التأكد من إنشاء رؤوس In-Reply-To و References الصحيحة بناءً على سجلات PostReply.
إعجاب واحد (1)
39

هل يشمل هذا الاقتباسات أيضًا (على سبيل المثال: منشور يقتبس 10 منشورات أخرى مختلفة، لذا فهو يشير إليها؟)

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

بواسطة سام سافرون عبر Discourse Meta في 29 يوليو 2022 02:31:

هل يشمل هذا الاقتباسات أيضًا (على سبيل المثال: منشور يقتبس 10 منشورات أخرى مختلفة
، لذا فهو يشير إليها؟)

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

سأكون بخير مع أي منهما لـ References ولكن سأميل إلى الحذر. الحساب السهل هو:

  • In-Reply-To: استخدم معرف الرسالة لأول رسالة مقتبسة (أو أي اقتباس فردي تختاره بناءً على سياسة ما)
  • References: References لنفس المنشور السابق المختار بالإضافة إلى معرف الرسالة لنفس المنشور

ستكون هذه مستقرة ويمكن التنبؤ بها وصحيحة.

تحياتي،
كاميرون سيمبسون cs@cskk.id.au

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

References غير مستحسن (discouraged) استخدامه بهذه الطريقة:

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

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

بواسطة Martin Brennan عبر Discourse Meta في 29 يوليو 2022 01:57:

بناءً على هذه المناقشات الإضافية @cameron-simpson، قمت بتحديث قائمة المهام
إلى هذا، ونشرتها هنا حتى تحصل على التحديث نظرًا لأن تعديلات Discourse
لن تصل عبر البريد الإلكتروني:

  1. قم بتغيير تنسيق Message-ID الذي تم إنشاؤه ليكون دائمًا \u003cdiscourse/post/:post_id@:hostname\u003e، وهذا فريد بما فيه الكفاية، وهو في الأساس عودة إلى ما كنا نفعله سابقًا. سيشير الإشارة إلى المنشور الأصلي فقط باستخدام معرف المنشور الأول الآن بدلاً من معرف الموضوع المجرد.
  2. إذا كان للمنشور سجل IncomingEmail مرتبط به، فإننا نستخدم دائمًا Message-ID هذا عند إرسال البريد الإلكتروني، وإلا فإننا ننشئ واحدًا باستخدام التنسيق أعلاه.
  3. لا تستخدم References عند إرسال رسائل البريد الإلكتروني للمنشور الأصلي للموضوع، لا يوجد شيء للإشارة إليه لأنه البريد الإلكتروني الأول في سلسلة المحادثات.

أود أيضًا حذف In-Reply-To في رسائل البريد الإلكتروني للمنشور الأصلي.

  1. تأكد من أن رؤوس In-Reply-To و References الصحيحة يتم
    إنشاؤها بناءً على سجلات PostReply.

نعم.

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

أي، اجعله ثابتًا بمجرد إنشائه عن طريق تخزينه.

لديك علاقة IncomingEmail حسب ما يبدو. ربما لديك (أو يمكنك استخدام) علاقة OutgoingEmail للحالة الإضافية لرسائل البريد الإلكتروني الصادرة، والتي تم إنشاؤها في المرة الأولى التي يتم فيها إعادة توجيه منشور عبر البريد الإلكتروني.

أعلم أن التدفق هو أساسًا ما يحدث عند إنشاء منشور، ولكن يمكنني تخيل بعض ميزات المستخدم اللاحقة مثل:

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

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

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

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

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

نعم، أعتقد أن هذا مهم، بغض النظر عن كيفية تنفيذه (علاقة أو عمود أو أي شيء آخر). أعتقد أنني ذكرت ذلك في قائمة المهام المعدلة الخاصة بك.

  1. لا تستخدم References عند إرسال رسائل البريد الإلكتروني للموضوع الأصلي، لا يوجد شيء للإشارة إليه بعد لأنه البريد الإلكتروني الأول في السلسلة.
  2. تأكد من إنشاء رؤوس In-Reply-To و References الصحيحة بناءً على سجلات PostReply والعمود الجديد outbound_message_id في جدول Post.

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

لا يوجد شيء يمكننا فعله للرسائل الحالية. فقط اجعل الأمور متسلسلة بشكل جيد للمضي قدمًا!

شكرا!
كاميرون سيمبسون cs@cskk.id.au

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

لدينا EmailLog ولكن يتم تنظيف هذه السجلات كل 90 يومًا، ولا أعتقد أنها ستكون مناسبة لهذا. سأقوم فقط بما يلي:

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

كان الأمر يتعلق بتجنب تخزينه على الإطلاق… ولكن الآن أفكر في أن معرف المنشور لن يتغير أبدًا ولكن اسم المضيف قد يتغير. لذلك يجب علينا تخزينه فور الحفظ في جميع الحالات.

لا يضر أن يكون messageid خاصية لكل منشور، غير قابل للتغيير إلى الأبد…

ألن يكون هذا إصدارًا مختلفًا من الرسالة؟ من المواصفات:

يوفر حقل “Message-ID:” معرف رسالة فريد يشير إلى إصدار معين من رسالة معينة. … يتعلق معرف الرسالة بإصدار واحد بالضبط من رسالة معينة؛ تحصل المراجعات اللاحقة للرسالة على معرفات رسائل جديدة.

لذلك ربما يجب أن يكون معرف الرسالة الذي تم إنشاؤه: \u003cdiscourse/post/:post_id/rev/:revision_num\u003e (ربما مع حذف /rev/:revision_num للمراجعة الأولى). سيسمح هذا لمستلمي البريد الإلكتروني بالحصول على تحديثات التعديل في المقام الأول، مع الأخذ في الاعتبار أن

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

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

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