هل من الممكن تحسين فترة الملخص لكل ألف مجتمع؟ كل يوم اثنين يرسل Discourse بضع آلاف من رسائل البريد الإلكتروني خلال ثانية أو ثانيتين، مما يؤدي إلى مشكلة SPAM مع خادم البريد المخصص لدينا.
كيف يمكن إعادة تعيين “last_digest_time” لكل حساب وتوحيده مع آلاف الحسابات الأخرى؟
الهدف هو الحصول على 100-200 ملخص يومياً بدلاً من 5000 يوم الاثنين. لقد استخدمنا Discourse خلال الأربع سنوات الماضية، ربما تكون هناك مشكلة في الترقية التي نقوم بها بشكل متكرر إلى أحدث إصدار.
أيضاً، ربما توجد تلميح حول كيفية الوصول إلى قاعدة بيانات PostgreSQL في صورة Docker وأين “تحديث” السجلات في قاعدة البيانات.
ما هي أفكارك؟ الخادم يرسل الرسائل فقط إلى الوجهات التي تضع رسالتنا في مجلد البريد العشوائي. سأفعل نفس الشيء إذا أرسل لي شخص ما 2000 رسالة في ثانية واحدة.
إذا كنت تستضيف خادم SMTP الخاص بك، فإنك تقع في المزالق المعتادة المرتبطة بذلك. تستخدم شركات تسليم البريد مثل Mailgun و SendGrid مجموعة من التقنيات لضمان موثوقية خوادمها واعتبارها موثوقة من قبل شبكات الوجهة. لذلك يوصي التوثيق باستخدام إحدى هذه المنتجات بدلاً من الاستضافة الذاتية.
بالضبط - بينما ترسل هذه الرسائل في فترات ذروة متقطعة، فإن خدمات البريد التابعة لجهات خارجية موثوقة يمكنها تسليم مئات الآلاف من رسائل البريد الإلكتروني إلى صناديق بريد جهات خارجية بشكل موثوق كل ساعة.
لسوء الحظ، لا يمكننا تقديم أي مساعدة إذا أصررت على تشغيل خادم بريدك الخاص. إذا قررت عدم اتباع التوصيات، فإنك تقبل التعقيد الإضافي الذي تخلقه.
كل شيء على ما يرام مع SMTP بما في ذلك DMARC و SPF و DKIM. لقد كنت أستخدم خادم SMTP خاصًا بي منذ عام 2005. لم تكن هناك خدمات “آلة مال” غير مفيدة في ذلك الوقت. دعونا نتخيل أن شخصًا ما سيحاول فرض رسوم على الهواء غدًا…
لذا، لنتراجع إلى المشكلة. أعرف أن أسهل طريقة للمختبر الأولي هي تحويلي إلى مكان أو خدمة مدفوعة. هل يمكن لأحد تقديم مساعدة حول كيفية إصلاح خطأ حرج في Discourse؟ لا زلت لا أوافق على أن يقوم Discourse بإرسال 10 آلاف رسالة في ثانية واحدة. يجب أن يكون هناك خدمة تدوير أو ما شابه ذلك لتطبيع “last_digest_timestamp” بين الحسابات.
أنا لست موظفًا لدى CDCK، وليس لدي أي مصلحة مالية في توجيهك إلى أي خدمات تابعة لجهات خارجية.
إذا لم ترغب في اتباع التوصية والوثائق، فهذا قرارك. في هذه الحالة، يؤدي ذلك إلى إخراجك من مسار الدعم المجاني الذي نقدمه هنا للمجتمع، وبالتالي فإن خيارك الوحيد هو التواصل مع مستشار عبر #السوق.
هذه ليست مشكلة في Discourse، بل تكمن المشكلة في أن عنوان IP لخادم البريد الخاص بك لا يُعتبر موثوقًا. لا يمكننا مساعدتك في إصلاح ذلك، وأنت ترفض النظر في الخيارات المتاحة لهذا الغرض.
نعم، أعمل مع مجتمعات ترسل أضعافًا مضاعفة من هذا الحجم، حيث يعمل العديد من الأشخاص الذين يديرون مجتمعات كبيرة على هذا النطاق أو أكبر.
يبدو أن احتياجاتك من البريد الإلكتروني تتجاوز الآن خبرتك في البروتوكول اللازم لتسليم البريد الإلكتروني بموثوقية وبأحجام كبيرة، وهذا هو السبب في وجود شركات البريد الإلكتروني الانتقالي. لا أحد هنا يروج لـ ‘البريد الإلكتروني الضخم’ - إنها مجرد تحدي تسليم البريد الإلكتروني عالي الحجم.
يمكنك جعل خادم بريدك يحتفظ بالرسائل ويوزع عملية التسليم. هذه في الواقع مشكلة تتعلق بخادم البريد الخاص بك وليست مشكلة في Discourse. لقد أدرت خوادم بريد من أوائل التسعينيات حتى حوالي عام 2005، عندما أصبحت الرسائل غير المرغوب فيها (Spam) عائقًا كبيرًا. اليوم، أصبح الأمر أكثر صعوبة بكثير.
لديني بعض حدود المعدل. حتى لو لم تفعل ذلك، فإن خوادم SMTP النموذجية تحتوي على إعدادات مسبقة من أجلك. أصبحت خوادم البريد أكثر ذكاءً اليوم ويمكنها بسهولة اكتشاف التأخير بين رسائلك.
نعم، لأنهم يستخدمون الخدمة التي ذكرتها سابقًا. ما زلت لا تفهم الفرق بين تلك الخدمات وخدمة SMTP الشخصية. يستخدمون مجموعة هائلة من عناوين IP ويحاكون مرسلين مختلفين. هذه تقنية جيدة للشركات التي تقوم بـ “إرسال البريد المزعج الصارم”. بالطبع، سيدفعون مقابل هذه الخدمة.
لا أرى سببًا لاستخدام الناس لهذه “آلات المال” لـ Discourse إذا كان Discourse لا يرسل بريدًا مزعجًا. أوه… آسف… بسبب خطأ برمجي، يمكنه إرسال 100 ألف رسالة في ثانية واحدة يوم الاثنين لأن @Stephensays يقول إن هذا السلوك حقيقي.
حسنًا، لا أرى فائدة في الدردشة مع الأشخاص الذين يحملون تاجًا فوق رؤوسهم. نعم، Discourse رائع وشكرًا جزيلاً لمساهمتك.
أتمنى أن يكون للأشخاص العاديين بدون بعض الأفكار هنا.
وفقًا للإجابات السابقة من فريق Discourse، لا يرون أي مشاكل في Discourse. قمت بحل هذه المشكلة بطريقة غير نظيفة عن طريق التلاعب المباشر بقاعدة البيانات. إليك حلّي:
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
يرجى تحديث نطاق last_emailed_at في استعلام SQL. كان لدي 4000 قيمة لـ last_emailed_at في يوم واحد في 16 مارس. لذا، تم الآن تحسين جميع المستخدمين لمدّة 3 أيام بفارق زمني قدره 30 ثانية.
لم يُصمم Discourse للاستخدام مع خدمة SMTP شخصية. آسف لأن ذلك لم يُشرح بوضوح؛ فمن المؤكد أنه يمكن أن يعمل، لكنه ليس فكرة جيدة لمجتمع ينشط عبر البريد الإلكتروني بانتظام. هذا قيد ناتج عن حالة البريد الإلكتروني الحالية، ونحن جميعًا نتفاعل معه قدر الإمكان.
فوق رؤوسهم. نعم، Discourse رائع وشكرًا جزيلاً لمساهمتك.