إضافة شهادة TLS مع إعدادات SMTP

الدعم تثبيت
1

أحاول استخدام خادم إرسال خاص بي فقط لإرسال رسائل البريد الإلكتروني. أقوم بتشغيل بوابة SMTP هذه لاستخدام TLS، وبسبب ذلك يتطلب العميل الذي أستخدمه لإرسال رسائل البريد الإلكتروني شهادة. أنا أستخدم شهادة موقعة ذاتيًا، وهي سهلة التكوين للغاية إذا كنت أستخدم postfix/ssmtp لإرسال رسائل البريد الإلكتروني، لكنني لست متأكدًا من كيفية استخدام شهادة مخصصة في عميل البريد الإلكتروني في Discourse.

فقط للحصول على صورة مختصرة في ذهني:

الحالة السهلة:
Discourse —إرسال—بريد—\u003e mailgun —إرسال—بريد—\u003e مستخدم

حالتي:
Discourse —إرسال—بريد—\u003e خادمي الذي يشغل بوابة SMTP —إعادة توجيه البريد باستخدام واجهة برمجة تطبيقات AWS SES—\u003e مستخدم

شكرًا لك.

2

أود تصحيح سؤالي. إذن، لا أحتاج حقًا إلى إضافة أي شهادات لكي يعمل هذا، ومع ذلك لا يزال يفشل في الاتصال عبر TLS. إذا كنت أختبره باستخدام swaks، فإنه يعمل بشكل جيد. مثال على الأمر:

swaks --to user@example.com --from me@example.com --auth PLAIN --auth-user myusername -tls -s smtp.somehost.com:2525
3

يمكنك استخدام بروتوكول SMTP الخاص بـ AWS SES مباشرةً لتحقيق ذلك، فلماذا تريد وجود خادم بريد وسيط محلي؟

4

@itsbhanusharma توفر AWS SES 60 ألف رسالة بريد إلكتروني شهريًا مجانًا، وعلى حد علمي، يجب طلب هذه المكالمات البريدية من مثيل EC2 لتعمل، وإلا سيتم احتسابها كرسائل عادية. مثيل Discourse الخاص بي مستضاف على Digital Ocean Droplet. قد أكون مخطئًا، لكن هذا هو فهمي والسبب وراء ذلك.

5

لذلك، حتى لو كان واجهة برمجة تطبيقات SES الخاصة بك تستقبل رسائل البريد الإلكتروني من عنوان IP تابع لـ DigitalOcean، فسيؤدي ذلك إلى فرض رسوم عليها. قد تقرر استخدام خدمة أخرى أو تشغيل exim على مثيل EC2 ليكون بمثابة جسر بين droplet في DigitalOcean و AWS SES. لا أعتقد أن هذا سيعمل، لكن يمكنك تجربته.

يجب أن يكون (نظريًا على أي حال) كالتالي:

  1. يرسل Discourse (المستضاف على DigitalOcean) رسائل البريد الإلكتروني إلى عنوان IP الخاص بـ exim في EC2.
  2. يقوم EC2 بإعادة توجيه رسائل البريد الإلكتروني المستلمة من DigitalOcean إلى SES.
  3. يوزع SES رسائل البريد الإلكتروني إلى المستخدم النهائي.
6

لقد حللت بالفعل مشكلة التوجيه بتشغيل خادم SMTP محلي في EC2 يقوم في النهاية بتحويل طلبات SMTP إلى SES. المشكلة تكمن في أن Discourse يفشل في عملية المصافحة TLS مع خادم SMTP هذا، بينما تعمل تطبيقات مثل Postfix و Swaks وما شابهها بشكل مثالي.

7

حل هذه المشكلة يجب أن يكون بسيطًا مثل استخدام المنفذ 25 (بدون تشفير)

8

هل توجد طريقة لأرى أين يتم التعامل مع مصافحة SMTP هذه؟ مثل أي مكتبة يستخدمها Discourse في Ruby خلف الكواليس؟ لا أريد تعطيل TLS هنا.

9

استخدم بعد ذلك شهادة SSL صالحة (حتى Let’s Encrypt يجب أن تعمل بشكل جيد)

10

استخدام شهادة صالحة من letsencrypt لم يساعد لسبب ما. لا أعرف السبب.
ولكن بعد تعيين هذا في app.yaml، تعمل الرسائل الإلكترونية الآن.

DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

ربما يتمكن شخص لديه معرفة أكبر بـ SMTP من شرح سبب عمل هذا، لكنني راضٍ الآن على ما يبدو.

11

هل ينتهي الأمر بأن يكون هذا أرخص من مجرد نقل مثيل Discourse إلى S3؟

12

لديك مثيل EC2 بسعر 5 دولارات يعمل على AWS وأستخدمه لإعادة توجيه نطاقات متعددة. نقل discourse إلى EC2 سيكون مكلفًا قليلاً مقارنة بـ Digital Ocean، لكن في الحقيقة ليس كثيرًا (بضعة دولارات إضافية فقط).

لكن النقطة هي أنه حتى لو نقلت discourse إلى EC2، سأظل بحاجة إلى خدمة إعادة التوجيه هذه لدعم باقي القطرات (droplets) التي لدي على DO للنطاقات الأخرى التي أملكها. فلماذا لا نقوم بإصلاح discourse :slight_smile:

13

حسنًا، بما أنك تعترف بأن Discourse ليس معطلاً، فهو يتفاعل مع SES بشكل مثالي.

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

14

هذا صحيح، لكن نظام Discourse لا علاقة له بـ SES هنا. Discourse هو أداة للتواصل مع خادم SMTP، والذي يمكن أن يكون أي شيء (حاليًا هو خدمة وسيطة). كنت أتساءل كيف يعمل postfix و swaks وغيرها بشكل صحيح مع خادم SMTP هذا (من نفس شبكة VPC الخاصة بـ DigitalOcean) بينما لا يعمل Discourse. ومع ذلك، بعد تعيين هذا المتغير، بدأ العمل. لا يزال أود معرفة المكتبة التي يستخدمها Discourse لمصافحة SMTP حتى أتمكن شخصيًا من التحقق مما إذا كان هناك أي شيء يمكننا تحسينه في Discourse.