طلبات الميزات: حساب بريد إلكتروني منفصل للتلخيصات

ساهم ميزة
1

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

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

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

الاقتراح

إضافة مجموعة أخرى من متغيرات app.yml تسمح للمسؤولين بإعداد وسيط بريد إلكتروني مختلف للملخصات.

أثناء عملية الإعداد، يمكن أن يظهر حوار يسأل: هل ترغب في إعداد خادم SMTP مختلف للملخصات؟، ويمكن للمستخدم استخدام نفس وسيط SMTP إذا رغب في ذلك.

المبررات

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

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

النقاش

ليست مشكلة كبيرة، لكنني أعتقد أنه سيكون من الجيد فصل رسائل البريد الإلكتروني الخاصة بـ الملخصات عن رسائل البريد الإلكتروني الحرجة؛ لأنه حتى لو كانت أولوية الطابور أعلى للرسائل الحرجة, فإن وسيط SMTP قد يُحظر بسبب العدد المفرط من الملخصات، مما يؤدي إلى حظر الرسائل الحرجة أيضًا.

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

شكرًا لك على اهتمامك المتأنّي.

TangentialDuck

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

يرجى ملاحظة أن استخدام Gmail المجاني لإرسال أي بريد إلكتروني من Discourse غير مدعوم. يعود ذلك مرة أخرى إلى شروط خدمة Google. استخدام Gmail بهذه الطريقة يقترب من #تثبيت غير مدعوم.

من الصعب تصور كيف أن طلب الميزة هذا منطقي للتنفيذ؛ فلو كنت قد استخدمت آلية بريد إلكتروني مدعومة، لما حدث هذا الحادث.

3

هذا غير صحيح.

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

أرجوكِ منحي بعض المرونة بعد إدارة منتدى لمدة 20 عامًا… لم نخرج للتو من بيضة بالأمس، يا ستيفن.

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

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

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

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

لقد سجلت للتو الدخول إلى حساب GSuite الخاص بنا وتحققت من شروط الخدمة، وما تقوله غير صحيح:

@Stephen، أنت متسرع جدًا في اتخاذ القرار. لم أطلب ميزة “لتجاوز شروط خدمة Google”، لذا يرجى الامتناع عن وضع كلمات في منشوراتي.

أنت متسرع جدًا في اتخاذ القرار وتتهم الناس كذبًا @Steven، لذا ربما دع الآخرين يردون على طلبي من لا يتسرعون في اتخاذ القرار؟

6

هناك بعض التناقض في ما تقولونه هنا:

Gmail ليست G-Suite. حسابات G-Suite المدفوعة لديها القيود التالية:

نوع الحد الحد
الرسائل يوميًا
الحد اليومي للإرسال* 2,000 (500 لحسابات التجربة)

حسابات Gmail المجانية دائمًا ما يكون لها حد 500 رسالة بريد إلكتروني.

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

قراءة إضافية حول الموضوع

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

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

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

نعم، كنت أعرف كل ذلك قبل أن أنشر يا @ستيفن.

يجب عليك حقًا الامتناع عن التقليل من شأن معرفة شخص كان على الإنترنت منذ ما قبل وجود متصفح Mosaic، في رأيي، وأن تكون حذرًا في طريقة ردك. لا تسرق متعة Discourse والتكنولوجيا بشكل عام من خلال توجيه اتهامات对其他.

أولاً، أخبرتني بأنه “لا يوجد Gmail مجاني” (وكنت أعرف أن ذلك خطأ)، ثم اتهمتني بأنشطة خبيثة، ثم قمت بواجبك المنزلي واكتشفت أن GSuite لديها حد 2,500 يوميًا، وهو ما كنت أعرفه منذ فترة طويلة لأنني أدير حساب GSuite هذا لسنوات.

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

إنه ليس ممتعًا حقًا، أن تنشر طلب ميزة بسيط وتضطر للرد على هذه الطاقة السلبية.

8

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

لكنك تستخدم Gsuite، وهو أمر مقبول تمامًا. كان من المستحيل معرفة ذلك من منشورك الأصلي. لذلك يبدو أنك تُعامل بطريقة غير عادلة.

إلا أن Gsuite لا يعمل فعليًا على منتدى ذو حركة مرور عالية، كما وصفت. فأنت تطلب ميزة جديدة لكي يعمل Discourse بطريقة ما مع خدمة بريد تقيدك بـ 2500 رسالة يوميًا.

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

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

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

مجرد متابعة، هذا الموضوع مكرر. تم طلب خدمات SMTP متعددة مسبقًا:

حالة الاستخدام هنا مختلفة قليلاً، لكن المشكلة نشأت من سوء تكوين رسالة الملخص. يحتوي Unix.com على 138,062 مستخدمًا، بينما الحد الأقصى لـ 2000 بريد إلكتروني يوميًا، حتى للأمور الحرجة مثل إعادة تعيين كلمات المرور، سيغطي فقط 1.8% من هؤلاء المستخدمين القادرين على التفاعل يوميًا.

تعديل: تم التصحيح من 2500 إلى 2000، ليعكس الحد الفعلي.

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

لهذا السبب، أيها @pfaffman، من الأفضل للجميع أن لا يتسرعوا في إصدار اتهامات تجاه الآخرين فيما يتعلق بالتكنولوجيا و/أو دوافعهم. عادةً، يجب أن نطرح الأسئلة قبل أن نسحب الزناد ونبدأ بإطلاق النار، LOL.

نعم، لقد قلت GMAIL بدلاً من GSUITE. لكن عندما أنشأت هذا النطاق قبل عقود، لم يكن هناك GSUITE وكان يُطلق عليه ببساطة GMAIL. علاوة على ذلك، لم أستخدم أي دقة لأن طلب الميزة الخاص بي لا علاقة له على الإطلاق بـ GMAIL. هذا نقاش جانبي تمامًا.

إذا أردت (أو أردت أنت)، يمكننا الذهاب إلى أي خادم، كما يفعل الكثيرون هنا، وكتابة apt install postfix أو apt install sendmail، وفي 15 دقيقة أو أقل يمكننا تشغيل خادم SMTP خاص بنا.

دعنا لا نغير موضوع نقل حركة المرور الثقيلة من عملية الملخصات إلى نقاش حول GMail مقابل GSuite مقابل بلابلابلاب. apt install postfix أمر تافه.

المسألة تتعلق بالموثوقية. إنها أساسيات من المستوى 101.

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

دعنا نبقى، من فضلكم، على المسار الصحيح فيما يتعلق بما أطلبه، لأنني أعرف تمامًا عما أتحدث عندما يتعلق الأمر ببناء تطبيقات حرجة للعمليات.

ها هو الأمر مرة أخرى:

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

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

تباطأوا. كونوا لطفاء مع الآخرين… إذا نشر شخص ما شيئًا ولم تفهم شيئًا أو شعرت بالارتباك، فاسأل؛ لا تطلق النار على الناس @Steven.

يمكنني بناء خادم SMTP في 10 دقائق. جميعنا يستطيع ذلك. apt install postfix تم… إذا أردت استخدام GSuite أو postfix أو donkey kong mail, فهذا يعود لي، وليس للآخرين. كما قلت…

النقطة الرئيسية … (مرة أخرى)

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

يؤدي apt install postfix إلى إنشاء خادم SMTP. أنا أطلب ميزة تسمح بأن يكون البريد الإلكتروني الحرج للعمليات (إعادة تعيين كلمة المرور، بريد التسجيل، تسجيل الدخول عبر البريد الإلكتروني) على قناة مختلفة عن الملخصات لأسباب تتعلق بالموثوقية والأداء.

11

@ستيفن

هذه ليست النقطة الأساسية. إنها جانبية.

ملاحظة جانبية: في الواقع، كان لدينا أكثر من 500 ألف مستخدم، لكنني قمت بتقليصهم :slight_smile:

أنا أتحدث عن وجود بريد إلكتروني حرج على قناة مختلفة (نقل SMTP) عن حركة مرور الملخصات.

بالتأكيد، هذا المفهوم البسيط، ومن السهل جدًا فهم سبب كون قناتين أفضل؟

هذه المناقشة تبتعد تمامًا عن الفكرة الأصلية وراء طلب الميزة الخاص بي.

آسف حتى أنني نشرت وسألت… :frowning:

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

12

لا يجب أن تستخف بأي من الأشخاص الذين يحاولون مساعدتك. لا أحد ضدك.

3 إعجابات
13

هذه آخر مشاركة لي في هذا الموضوع.

بخصوص GSuite (وهو ليس النقطة الأساسية في طلب الميزة الخاص بي)

  • الحد الأقصى لعدد الرسائل التي يمكن للمستخدم إرسالها في فترة 24 ساعة هو 10,000 رسالة. ومع ذلك، قد يختلف هذا العدد اعتمادًا على عدد تراخيص المستخدمين في حساب G Suite الخاص بك.
  • لا يمكن للمستخدم المسجل في G Suite إعادة توجيه الرسائل إلى أكثر من 10,000 مستلم فريد في فترة 24 ساعة.

المصدر: Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

ومع ذلك، فإن هذا الأمر بعيد كل البعد عن موضوعي؛ لأنه حتى لو سمح GSuite بإرسال أكثر من 1000 مليون بريد إلكتروني يوميًا عبر إعادة التوجيه SMTP، فإنني ما زلت أريد قناة إعادة توجيه SMTP مختلفة للبريد الإلكتروني الحرج مقارنة بالبريد الإلكتروني الملخص.

هذه هي النقطة الأساسية.

شكرًا لكم. يرجى النظر في هذا الأمر في الترقية المستقبلية. أعتقد أن إضافة هذه الميزة أمر سهل نسبيًا.

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

يركز طلب الميزة الخاص بي على الموثوقية والحفاظ على البريد الإلكتروني الحرج بعيدًا عن قناة الملخص.

انتهى الأمر… :slight_smile:

14

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

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

هذا ليس ما أعتقد، لكن قد تكون تعرف الكثير أكثر مني حول تطوير إضافات ديسكورد.

3 إعجابات
15

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

4 إعجابات
16

أتفق معك، هناك الكثير من التناقضات في ما نشره @neounix في البداية، وتغيرت الكثير من التفاصيل في الردود اللاحقة.

التأكيد السابق مني، حيث تم توثيق قيود الحسابات المجانية بالفعل في مكان آخر من هذا الموضوع. الحسابات “المجانية” القديمة من G Suite تخضع لهذه القيود أيضًا. إذا كان هذا حساب GSuite مدفوعًا، فإن التعليق أعلاه مضلل ويشرح ردّي.

مرة أخرى، أنت غير واضح بشأن الخدمة التي تستخدمها هنا. إذا كنت تستخدم Google Apps القديمة في المستوى المجاني، فإنك مقيد بـ 500 مستلم يوميًا لكل مستخدم، وهو نفس الحد في منتج Gmail المجاني. أما إذا كنت تستخدم حساب GSuite مدفوعًا، فيجب عليك استخدام خدمة Google SMTP Relay، حيث تكون الحدود 10 آلاف يوميًا لكل مستخدم، وهو أفضل لكنه لا يزال غير كافٍ، خاصة مع أكثر من 130,000 مستخدم يحتاجون إلى طلب إعادة تعيين كلمة المرور. من الرائع سماع أنك قمت بتقليل عدد المستخدمين أثناء الهجرة، رغم أنني لست متأكدًا من مدى أهمية ذلك عمليًا.

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

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

بالمناسبة، أنا @Stephen، وليس @Steven - أنت تُعلّم وتُبلغ مستخدمًا مختلفًا تمامًا.

3 إعجابات
17

في حال كان الأمر كذلك، فلا تتردد في تمويله من خلال النشر في #السوق مع تحديد الميزانية. كما توجد بعض الاقتراحات الممتازة أعلاه :index_pointing_up: لتقليل حجم البريد الإلكتروني، وأقترح الاستفادة منها.

3 إعجابات
18

في الوقت الحالي، انتهينا ببساطة من إيقاف عمليات الملخصات تمامًا؛ وإليك القصة الخلفية المحدثة:

لدينا أيضًا خادم تجريبي، وبما أن Discourse يُفعّل الملخصات الأسبوعية (بنافذة زمنية تمتد إلى 365 يومًا) كإعداد افتراضي خارج الصندوق عند التثبيت، فقد بدأ هذا الخادم التجريبي أيضًا في إرسال ملخص الأسبوع الماضي (وهو ما لم نتوقعه)، LOL

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

بناءً على هذا التلميح، قمت الآن بمراجعة sidekiq - وبالتأكيد وجدت أكثر من 300 ألف رسالة ملخص في الطابور ناتجة عن إعداد الملخص الافتراضي بوضع “تفعيل” و"آخر 365 يومًا".

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

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

إليك الجزء المضحك… LOL

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

عند تثبيت Discourse، تم تعيين جميع المستخدمين المُهاجرين (من منتدى vB3 القديم) افتراضيًا إلى last_seen_at قبل حوالي 50 عامًا.

دخلت إلى قاعدة البيانات وقمت بتغيير جميع المستخدمين يدويًا ليكون آخر ظهور لهم قبل 10 أيام! LOL. لم يكن لدي أي فكرة في ذلك الوقت عن إعدادات الملخصات؛ وظننت أن هذا خطأ في الهجرة جعل جميع المستخدمين يظهر آخر ظهور لهم قبل 50 عامًا بعد الهجرة. هاها… كنت مخطئًا. هناك سبب وجيه لذلك.

أطلق Discourse عملية ملخص أسبوعي ضخمة أثقلت كاهل sidekiq على كل من خادمي الإنتاج والتجريبي؛ لأنني قمت بتعديل قاعدة البيانات “آخر ظهور قبل 10 أيام” على الخادم التجريبي، ثم نقلته إلى الإنتاج. كان هذا هو الخطأ الذي تسبب في هذه المشكلة.

وبما أن معظم الناس لا يدخلون إلى postgres ويقومون بالتلاعب مثلما فعلت أنا، ولا يقومون بأشياء مثل:

UPDATE users SET last_seen_at "اليوم ناقص 10 أيام"

… في هجرة قديمة تضم العديد من المستخدمين…

فلن يواجهوا مثل هذه المشكلة الضخمة المتعلقة بالملخصات.

LOL

أعتذر عن خلق كل هذا التوتر بسبب حيلة UPDATE التي قمت بها في جدول users.

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

ومع ذلك، يمكنني نصح المهاجرين: إذا كنت تهاجر منتدى إلى Discourse (وهو فكرة رائعة)، فاترك الإعداد الافتراضي لـ last_seen_at في جدول users كما هو افتراضيًا :slight_smile:

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

عادةً ما أنصح بوضع Mailhog بين مثيلة الاختبار (staging) والعالم الخارجي. إنه ممتاز في هذا النوع من السيناريوهات.

4 إعجابات
20

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

إعجابَين (2)