لقد قمت مؤخرًا بمراجعة رسائل البريد الإلكتروني: المهمة والتعليمات البرمجية ذات الصلة بهدف اختبار جميع مسارات فشل التعليمات البرمجية وتعديل نص الخطأ.
اكتشفت أيضًا أن آثار تعيين DISCOURSE_SMTP_ENABLE_STARTTLS=false هي (في الغالب) صفرية. لم يؤدِ تعيين هذا إلى تعطيل STARTTLS فعليًا ، وفي الواقع ، يمكن أن يتعايش بشكل جيد مع TLS عند الاتصال (DISCOURSE_SMTP_FORCE_TLS=true).
قبل أن أقوم بدمج هذا ، أعتقد أن تحذيرًا إداريًا في لوحة التحكم عند تعيين DISCOURSE_SMTP_ENABLE_STARTTLS=false مناسب. أتخيل أن هناك على الأقل مستضيفًا ذاتيًا واحدًا قام بتعيين هذا ولكنه لا يحتاجه ويعتمد فعليًا على STARTTLS.
هذا يبدو عملاً جيدًا! شيء واحد لاحظته (أعتقد أنني لاحظته) هو أن مهمة rake لا تستخدم في الواقع نفس الكود الذي يستخدمه الإرسال الفعلي (مثل صفحة اختبار البريد الإلكتروني /admin/email). أنا متأكد من أنني واجهت حالة عمل فيها في تجربة المستخدم ولكن ليس في مهمة rake (أو ربما كان العكس؟)
بينما لا يزال الأمر حاضرًا في ذهنك، إذا كان بإمكانك التأكد من أنه عند الإرسال الفعلي، فإنه يستخدم نفس الكود الذي يستخدمه Discourse، فسيكون ذلك رائعًا.
@supermathie هل يستحق هذا إرسال رسالة خاصة لكل مسؤول على كل موقع لديه هذا المتغير معينًا؟ سيقوم نظام فحص المشكلات الحالي لدينا بذلك، ولست متأكدًا من أن هذا مبرر هنا، نظرًا لأنه في الغالب، يكون لهذا تأثير nil. من الناحية المثالية، أود فقط عرض هذا على لوحة المعلومات دون إرسال إشعارات للمستخدمين المسؤولين، ولست متأكدًا من أن بنية فحص المشكلات الحالية لدينا تدعم حالة الاستخدام هذه.
أعتقد ذلك - أجد أنه من المحتمل للغاية أنه نظرًا لمدى ارتباك العديد من المسؤولين حول إعداد البريد الإلكتروني، فإن شخصًا ما لديه هذا المتغير معينًا بينما يعتمدون فعليًا على starttls.
لا ينبغي لأحد أن يكون لديه هذا المتغير معينًا، على الأرجح.
أفضل أن يكون لدي تحذير خاطئ بدلاً من كسر إعداد البريد الإلكتروني لشخص ما بصمت.
البديل هو إزالة التحقق وتعطيل المتغير بحيث لا يفعل شيئًا على الإطلاق.
سيكون من الجيد ألا يظهر التحذير عندما يكون خادم SMTP الصادر هو localhost (أي يتطابق مع اسم نطاق Discourse) حيث أن بروتوكول TLS بين حاوية Docker والجهاز المضيف غير مطلوب لأنهما نفس الجهاز.
