كانت هناك الكثير من التحديثات مؤخرًا. أحدها أفسد سطر الموضوع (لم يعد يتضمن الفئة) والآن لا يتم إرسال أي بريد على الإطلاق. المستخدمون غير راضين للغاية. لا أعرف من أين أبدأ في تصحيح أخطاء هذه المشكلة. أين يمكنني العثور على سجلات الأخطاء وأتذكر أن هناك صفحة حول قوائم انتظار Sidekiq وما إلى ذلك، لكنني لا أستطيع العثور عليها. أي مساعدة ستكون محل تقدير كبير.
نعم، لقد لاحظت أن إشعارات البريد الإلكتروني لا يبدو أنها تعمل في الوقت الحالي بعد تحديث الأمس، على الرغم من أن الملخصات/الخلاصات لا تزال تعمل. هل نحن وحدنا في هذا؟
إعجابَين (2)
قد يكون سبب هذا هو فشل Sidekiq في معالجة المهام المجدولة عندما ينبغي له ذلك.
حددنا المشكلة نفسها في وقت سابق اليوم على مواقع النشر المستمر (CD) الخاصة بنا. تأكد من أنك على الأقل عند التثبيت:
(أعتقد أن هذا هو التثبيت، لست متأكداً بنسبة 100٪)
لمعرفة ما إذا كانت المشكلة هي نفسها، تحقق من المهام المجدولة في /sidekiq وانظر ما إذا كان هناك أي شيء في الماضي.
3 إعجابات
نعم، لقد وقعنا في ذلك. تحديث قام بحل المشكلة.
إعجابَين (2)
تم تقسيم 4 مشاركات إلى موضوع جديد: Email From: headers lost their “via SITENAME” text
أؤكد مئات من وظائف sidekiq الفاشلة على latest-release +103
تم الإصلاح في latest-release +153
لقد قمت بالتحديث إلى الأحدث ولا أزال أواجه مشكلة في إرسال البريد الإلكتروني على أحد مواقعي. أحصل فقط على رسالة خطأ عند إرسال بريد إلكتروني تجريبي.
خطأ - تم الوصول إلى نهاية الملف
أنا الآن على الهاتف المحمول، وسأتحقق من sidekiq والسجلات عندما أكون على جهاز الكمبيوتر الخاص بي. أي اقتراحات أخرى أين أبحث؟
مرحباً توبياس!
مشكلتك مختلفة - يتم تعليق الاتصال في انتظار استجابة بعد فترة وجيزة من الاتصال الناجح الأولي.
أخمن أنك تحاول التحدث بالبروتوكول الخاطئ إلى المنفذ الخاطئ… ما هي الإعدادات التي تستخدمها؟
هل تعرض مهمة rake emails:test (بالمنطق ورسائل الخطأ المحدثة مؤخرًا) أي خطأ مختلف؟
مرحباً مايكل! شكراً على الرد. أفتقدكم كثيراً! 
هممم.. لقد نقلت موقعي للتو من DO إلى Hetzner وعمل بشكل جيد لبضعة أسابيع. موقعي الآخر يعمل بشكل جيد أيضاً. إنه لغز. توقف عن العمل فقط في وقت ما قبل أسبوع تقريباً وعندما بحثت في الأمر رأيت الأخطاء. تواصلت مع Hetzner (رفضوا المساعدة) ومع Mailgun. وفقاً لـ Mailgun:
شكراً على ردك، آخر حدث مصادق عليه تم قبوله نراه كان في 11 يناير وتم إرساله عبر SMTP.
هل يمكنك تأكيد ما إذا كانت هناك أي تغييرات قد أُجريت؟ يرجى تقديم لقطة شاشة لتكوين تطبيق الإرسال الخاص بك لمراجعتنا، بالإضافة إلى أي أخطاء ذات صلة في سجلات تطبيق الإرسال/إرسال SMTP الخاص بك.
لقد قمت للتو بتغيير كلمة المرور الخاصة بـ mailgun في حال كان هذا هو السبب وحاولت مرة أخرى، ولكن دون جدوى.
مُخرج rake emails:test:
root@ubuntu-4gb-nbg1-1-app:/var/www/discourse# rake emails:test
Testing sending to using smtp.mailgun.org:587, username:postmaster@domain with plain auth.
====================================================================================== ERROR =======================================================================================
UNKNOWN ERROR!
EOFError: end of file reached
===================================================================================== SOLUTION =====================================================================================
This is not a common error. No recommended solution exists!
Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
====================================================================================================================================================================================
إعجاب واحد (1)
أعتقد أنه يفشل قبل محاولة تسجيل الدخول حتى.
لإزالة Discourse كعامل، حاول من المضيف ومن داخل الحاوية:
$ openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
يجب أن تحصل على الكثير من المخرجات ثم تكون قادرًا على محاولة المصادقة:
○ → openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Connecting to 34.160.63.108
CONNECTED(00000003)
…
SSL-Session:
…
---
read R BLOCK
EHLO localhost
250-2ed1d46f4d7dec773e2a97b59f3a3bf8a2d6db54f94eead5dcf49e3ea1caac18
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250-8BITMIME
250-SMTPUTF8
250 PIPELINING
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
501 Username used for auth is not valid email address
535 Authentication failed
closed
السلاسل النصية التي ستقوم بكتابتها هي:
EHLO localhost
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
(هذه السلسلة النصية هي بيانات الاعتماد michael/password لذا من الواضح أنها لن تعمل، ولكن يمكنك الاطلاع على هذا المنشور لمعرفة كيفية إنشاء السلسلة النصية لبيانات الاعتماد الفعلية الخاصة بك إذا كنت ترغب في المحاولة يدويًا)
نأمل أن يساعدك رؤية ما ينجح وما يفشل بشكل مباشر.
قد ترغب أيضًا في محاولة استخدام swaks إذا كان متاحًا - فمن المحتمل أن يكون حزمة نظام تشغيل يمكنك تثبيتها.
إنه أسهل قليلاً ويمكنك على سبيل المثال:
swaks --to frodo@shire.net --from bilbo@shire.net --auth PLAIN --auth-user bilbo --auth-password ring --server smtp.mailgun.org:587 --tls
باستثناء أنه يمكنك استخدام بيانات الاعتماد الحقيقية الخاصة بك.
قد تساعد مخرجات ذلك أيضًا في الكشف عن المشكلة.
لقد جربت swaks وحصلت على ما يلي:
=== Trying smtp.mailgun.org:587...
=== Connected to smtp.mailgun.org.
*** Remote host closed connection unexpectedly.
هذا ألهمَني للتحقق من خادمي الآخر، حيث حصل swaks على “Great success” - الرسالة لطيفة للغاية!
<~ 250 Great success
~> QUIT
<~ 221 See you later. Yours truly, Mailgun
=== Connection closed with remote host.
إذًا المشكلة إما أن mailgun تحظر خادمي، أو أن خادمي مُعد بشكل خاطئ بطريقة ما. سأتحقق مع mailgun وبعد ذلك إذا لم يكن هذا هو السبب فسأقوم بتدمير وإعادة بناء خادمي.
إعجاب واحد (1)
منطقي؛ هذا هو في الأساس نفس الخطأ الذي حدث في
كما تشك، فإن السبب الأكثر ترجيحًا هو أن شيئًا ما خارجيًا يتداخل مع الاتصال.
إعجاب واحد (1)
لدي شك في أنك بحاجة إلى استخدام المنفذ 2525 بدلاً من 587
تذكر هتزنر بشكل صريح أنها لا تحظر المنفذ 587.
أيضًا، إذا كانت تفعل ذلك، فمن المحتمل أن يظهر ذلك على شكل فشل في إنشاء اتصال.
هذا يستبعد تقريبًا تكوين Discourse و Mailgun.
في هذه المرحلة، يكون التشخيص الأكثر فائدة هو تجربة منفذ إرسال Mailgun بديل من الخادم المتأثر:
openssl s_client -connect smtp.mailgun.org:2525 -starttls smtp
(أو نفس الاختبار باستخدام swaks).
يدعم Mailgun المنفذ 2525 تحديدًا للبيئات التي يتم فيها التدخل في المنفذ 587 بواسطة جدران الحماية، أو التصفية الصادرة، أو قواعد الشبكة على مستوى المزود.
إذا:
- نجح المنفذ 2525 وفشل المنفذ 587 ← فمن المرجح جدًا وجود تداخل في الشبكة / عنوان IP / التوجيه
- فشل كلاهما ← حالة أقوى على أن شيئًا خارجيًا يمنع الاتصال أو ينهيه
في كلتا الحالتين، يتطابق السلوك مع “التدخل في الاتصال الخارجي” أكثر بكثير من تراجع في Discourse أو Sidekiq.
لم أتلق رداً من Mailgun بعد.. خطتي إذا لم يتمكنوا من المساعدة هي البدء من جديد بخادم Hetzner جديد.
لقد جربت swaks مع منافذ أخرى، ومن المثير للاهتمام أنني حصلت على نفس الخطأ مع 2525، وفوراً بدون أي تأخير.
=== محاولة smtp.mailgun.org:2525...
=== تم الاتصال بـ smtp.mailgun.org.
*** أغلق المضيف البعيد الاتصال بشكل غير متوقع.
لكنني حصلت على خطأ مختلف مع 25 و 465، واستغرق الأمر بضع ثوانٍ حتى جاء الرد.
=== محاولة smtp.mailgun.org:25...
*** خطأ في الاتصال بـ smtp.mailgun.org:25:
*** انتهت مهلة الاتصال
=== محاولة smtp.mailgun.org:465...
*** خطأ في الاتصال بـ smtp.mailgun.org:465:
*** انتهت مهلة الاتصال
لست متأكداً مما يجب أن أستنتجه من ذلك. ربما هناك جدار حماية (firewall) مُعد بشكل خاطئ على الخادم يحظر بعض المنافذ.
هذا مقصود ومتوقع.
تقوم Hetzner بحظر تلك المنافذ افتراضيًا.
إعجاب واحد (1)
منطقي.. ولكن من المثير للاهتمام أن المنفذين 25 و 465 استغرقا وقتًا أطول للفشل من المنافذ الأخرى. على أي حال، هذا ليس عاجلاً وسأنتظر الرد من Mailgun. هذا لموقع عائلتي لذا أنا فقط أشجع الجميع على تسجيل الدخول والتحقق من الإشعارات للتغيير، وليس مجرد انتظار البريد الإلكتروني!
سأسافر إلى ألمانيا لزيارة العائلة وحضور جنازة غدًا.. الأسبوع المقبل سأعود للنظر في هذا الأمر مرة أخرى ومن المحتمل أن أبدأ من جديد بخادم جديد.
شكرًا على كل التوجيه! لقد تعلمت الكثير من خلال هذه العملية. حقًا أحببت أداة swaks تلك.
يمكن أن يكون التوقيت معلومات مفيدة بالفعل.
عندما يتم حظر منفذ (أو بشكل عام، حركة المرور)، يمكن حظره عن طريق الإسقاط (رفض صامت) أو الرفض (يتم إرسال رسالة “غير قابلة للوصول” (مثل المنفذ غير قابل للوصول) مرة أخرى إلى المرسل).
يسبب الإسقاط الصامت ما تراه مع 25/465 - تتم محاولة الاتصال ولا يحدث شيء حتى يتم الوصول إلى المهلة.
يسبب الرفض رسالة مثل “تم رفض الاتصال” أو “المنفذ غير قابل للوصول”.
هذا يدل على سلوك مقصود - أنت تحصل على اتصال ثم يتم إغلاق الاتصال على الفور.
لقد قمت بتغيير المصدر، لذا شيء آخر يمكنك تجربته هو تغيير الوجهة. جرب نفس الأمر على سبيل المثال smtp.gmail.com أو smtp.office365.com. يجب أن تحصل على فشل في المصادقة، وهذا مؤشر قوي على أن Mailgun يرفضك تحديدًا.
إعجاب واحد (1)
هذا الشرح من @supermathie دقيق 
فرق التوقيت هو في الواقع إشارة مفيدة، وليس ضوضاء.
لتلخيص ما تراه:
- 25 من أصل 465 انتهت مهلتها (انقطاع صامت - حظر على مستوى سياسة Hetzner، متوقع)
- 2525 يتصلون ثم يغلقون فورًا ← مسار TCP سليم، لكن الطرف البعيد ينهي الجلسة
هذه النقطة الأخيرة هي التفصيل الأساسي.
لأن:
- مصافحة TCP تنجح
- مفاوضات TLS لا تبدأ أبدًا حقًا
- ويحدث ذلك على الفور
…فهذا يشير بقوة إلى أن Mailgun ترفض الاتصال مبكرًا، وليس Discourse أو Sidekiq أو Ruby.
هذا يتماشى مع بعض الأشياء التي رأيناها مؤخرًا:
- سمعة عنوان IP / التصفية القائمة على المنطقة
- نطاقات IP الجديدة لـ Hetzner لم يتم الوثوق بها بعد
- أو فحوصات السياسة على جانب Mailgun قبل تبادل لافتة SMTP
لا شيء في Discourse سيؤدي إلى إغلاق المقبس البعيد فورًا بهذا الشكل - Sidekiq يقوم فقط بتسليم الرسالة إلى Net::SMTP وينتظر.
إذا كنت تريد تأكيدًا قويًا آخر لاحقًا (لا يوجد إلحاح على الإطلاق):
openssl s_client -connect smtp.gmail.com:587 -starttls smtp
يجب أن تحصل على لافتة SMTP صحيحة ثم فشل في المصادقة - وهو ما سيثبت عمليًا أن بروتوكول SMTP الصادر سليم وأن Mailgun هو نقطة النهاية الوحيدة التي تتصرف بشكل مختلف.
أتفهم تمامًا تعليق هذا الأمر - خاصة بالنظر إلى الظروف.
أنا آسف حقًا لأنك تتعامل مع هذا بالإضافة إلى كل شيء آخر 
إذا عادت Mailgun بشيء مفيد، فهذا رائع - ولكن بصراحة، البدء من جديد أو تغيير المزودين (Brevo، Postmark، إلخ) غالبًا ما يكون أسرع من انتظار إصلاحات سمعة SMTP.
لقد قمت بالفعل بتصحيح هذا بالطريقة الصحيحة تمامًا - لا يوجد شيء هنا يشير إلى أنك أغفلت شيئًا أو أخطأت في تكوين Discourse.
رحلة آمنة إلى ألمانيا، واعتنِ بنفسك.
إعجاب واحد (1)