إعادة صياغة رسائل البريد الإلكتروني: مهمة اختبار rake الإخراج

نعم.

ولكن بغض النظر، كان سيعمل. دون المساس بأي شيء، سيتم استخدام STARTTLS فقط إذا كان الخادم يقدمه.

الحالة الوحيدة التي احتاج فيها الأمر إلى تعطيله صراحة كانت حيث:

  • يقدم الخادم STARTTLS
  • البريد المرسل بدون استخدام STARTTLS سيعمل
  • البريد المرسل باستخدام STARTTLS سيفشل
إعجابَين (2)

من المحتمل أن يكون هذا صحيحًا بالنسبة لمعظم الناس.

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

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

لن يستخدم DISCOURSE_SMTP_ENABLE_START_TLS سوى STARTTLS إذا كان الخادم يقدمه. إذا لم يكن خادم البريد الخاص بك يقدمه، فلن يتم استخدامه.

(يُشار إلى هذا باسم TLS الانتهازي)

السبب في إضافتي للتحذير هو أنه قبل التغيير الذي أجريته، فإن تعيين DISCOURSE_SMTP_ENABLE_START_TLS على خطأ لم يقم فعليًا بتعطيل STARTTLS.

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

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

أنت على حق! لقد اختبرت للتو وأؤكد أن البريد الإلكتروني الصادر لا يزال يعمل لدينا بعد إزالة الإعداد. :+1:

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