تم التحقق من النطاق في SES، لذا لا تحتاج إلى معامل المصادقة SMTP.
بالإضافة إلى ذلك، قد تحتاج إلى إخراج حساب SES الخاص بك من وضع العزلة (sandbox) إذا لم يكن ذلك قد تم بالفعل، وطلب زيادة الحد المسموح به. ينطبق شرط وضع العزلة على كل منطقة على حدة.
ما زلتُ حائراً بشأن سبب عدم إرسال أي رسائل بريد إلكتروني عبر AWS SES.
عند إرسال بريد إلكتروني تجريبي عبر صفحة الإدارة في Discourse الخاص بنا، تظهر فقط رسالة ‘تم الإرسال’. كما أن محاولة طلب استعادة كلمة المرور تبدو سليمة من حيث الإجراءات، لكن لا تصل أي رسالة بريد إلكتروني على الإطلاق.
لا أعتقد أن SES يسجل السجلات، لذا لا يمكنني التحقق مما إذا كان يستقبل الرسائل أم لا.
الشيء الوحيد الذي قد يسبب مشكلة هو أن عنوان الرد يستخدم حساباً على gmail.com بدلاً من نطاق موقعنا.
هل واجه أي شخص هذه الحالة أو هذا السيناريو من قبل؟
هذا هو عنوان البريد الإلكتروني الذي سيظهر في سطر المرسل. يجب أن يكون عنوانًا ضمن النطاق الذي سترسل منه خدمة SES. لن ترسل خدمة SES بريدًا إلكترونيًا يتظاهر بأنه قادم من Gmail. لا تملك السيطرة على gmail.com، لذا لن ترسل خدمة SES بريدًا إلكترونيًا يحتوي على ذلك في سطر المرسل. يجب أن يكون notification_email هو something@yourverifieddomain
أنا أستخدم SES أيضًا ويعمل معي بشكل جيد. الاختلاف الوحيد الذي ألاحظه مقارنةً بتكوينك هو أن سطر DISCOURSE_SMTP_AUTHENTICATION: login غير موجود في تكويني. بالإضافة إلى ذلك، فإن DISCOURSE_SMTP_ENABLE_START_TLS: true و DISCOURSE_SMTP_PORT: 587 محذوفان في تكويني (معلّقان)، رغم أن ذلك لا ينبغي أن يحدث فرقًا.
الأسطر الثلاثة الوحيدة التي أقوم بتعديلها في ملف app.yml هي عنوان SMTP واسم المستخدم وكلمة المرور. الباقي مُعلّق كما هو من التثبيت الجديد ويعتمد على الإعدادات الافتراضية. بعد إعادة البناء، أحتاج فقط إلى التأكد من أن إعداد الموقع notification email مضبوط على عنوان يستخدم نطاقًا تم التحقق منه في SES. لم أعد أستخدم علامات الاقتباس حول كلمة المرور، لكن تثبيتاتي الأقدم كانت تستخدمها وعملت بشكل جيد في كلتا الحالتين.
نعم، يستحق الأمر تجربة تغيير عنوان الرد (reply-to) لاستخدام عنوان يستخدم النطاق الموثق في SES كما أوصي به في الرد أعلاه، فقط للتأكد من ما إذا كان ذلك سيؤدي إلى إرسال البريد بشكل صحيح.
إذا لم يعمل الأمر، فأتحقق مما إذا كان المضيف الخاص بك يحجب بعض المنافذ، وأتحقق مرة أخرى من أن بيانات اعتماد SES تم إنشاؤها بشكل صحيح. أرى أنك أكدت أعلاه أن نطاقك قد تم التحقق منه مع SES.
نعم، عنوان الرد على نفس النطاق مثل نطاق المرسل، لكن في بعض الحالات ليس نفس النطاق الفرعي (مع ذلك يظل نفس النطاق الجذر). كلا الحالتين تعملان بشكل جيد بالنسبة لي.
أنا متأكد من أنك لاحظت هذا → هل قمت بالتحقق من عنوان البريد الإلكتروني الصادر الذي يستخدمه Discourse للإرسال؟
إذا كان العنوان notify@yourverifieddomain، فيجب عليك الدخول إلى SES، في الصف الثاني تحت “إدارة الهوية”، وإضافة عنوان الإرسال ثم التحقق منه. لن يتم إرسال أي شيء حتى تقوم بذلك.
لا إنذارات، لا صافرات، فقط لا شيء يحدث.
كون الرد من Gmail أمر رائع. هذا ما فعلته أنا. ثم بدأت رسائل تفويض الأعضاء في الحظر بسبب البريد العشوائي لأن عنوان الإرسال (From) وعنوان الرد (Reply) لم يتطابقا.
في النهاية، قمت بكتابة دالة بسيطة على AWS Lambda (استغرق تعلم كيفية عملها أسبوع واحد) تقوم بتحويل البريد الوارد إلى واجهة برمجة تطبيقات Discourse. أمر نظيف جداً. لا حاجة لـ POSTFIX.
