بعد التثبيت، يمكن لـ Curl إرسال البريد الإلكتروني، ولكن Discourse لا يمكنه ذلك. المساعدة في الإصلاح؟

الدعم تثبيت
1

مرحبًا!

في النص أدناه، استبدل \u003cDOT\u003e بـ . - لأنني مستخدم جديد ولا يسمح لي discourse بنشر الروابط.

لقد قمت بتثبيت discourse على خادم سحابي جديد من Hetzner، وعنوان URL الخاص به يحل بشكل صحيح: forum.thewizardofosc.com

ومع ذلك، لا يتم إرسال البريد الإلكتروني الذي سجلت به أبدًا. في ملف السجل، تظهر رسالة سجل discourse كـ Net::ReadTimeout إذا كان ذلك يعني شيئًا.

يتصل telnet - كتابة "telnet mail.thewizardofosc.com 465" تؤدي إلى "Connected to thewizardofosc.com".

أيضًا، يرسل curl بريدًا إلكترونيًا بنجاح!

كتابة ما يلي:
curl --ssl smtps://mail.thewizardofosc.com --mail-from discourse@thewizardofosc.com --mail-rcpt <عناوين مختلفة تعمل> --upload-file email.txt --user 'discourse@thewizardofosc.com:<كلمة المرور>'

ترسل بنجاح.

لكن لماذا لا يفعل discourse ذلك إذن؟

فيما يلي الأقسام التي أعتقد أنها ذات صلة من ملف التطبيق الخاص بي:

## على سبيل المثال عند التسجيل الأولي 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'iliasb@thewizardofosc.com'

## TODO: خادم البريد SMTP المستخدم للتحقق من الحسابات الجديدة وإرسال الإشعارات
# عنوان SMTP واسم المستخدم وكلمة المرور مطلوبة
# تحذير: قد يتسبب الحرف '#' في كلمة مرور SMTP في حدوث مشاكل!
DISCOURSE_SMTP_ADDRESS: mail.thewizardofosc.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: discourse@thewizardofosc.com
DISCOURSE_SMTP_PASSWORD: <كلمة المرور>
#DISCOURSE_SMTP_ENABLE_START_TLS: true           # (اختياري، الافتراضي true)

## إذا أضفت قالب Lets Encrypt، قم بإلغاء التعليق أدناه للحصول على شهادة SSL مجانية
LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
2

يحتاج الأمر إلى مراجعة سجل الأخطاء لمعرفة ما يحدث في إعدادات البريد الخاصة بك

4

لقد اتبعت الخطوات هنا: Troubleshoot email on a new Discourse install - #2

دون الكثير من النجاح. عند تشغيل discourse-doctor، تظهر لي نفس المخرجات: Net::ReadTimeout،
والتي أراها أيضًا في shared/standalone/log/rails/production.log

5

مرحبًا!

هل تقصد shared/standalone/log/rails/production.log؟

هناك أحصل على:

تم تسليم البريد الإلكتروني 5208d56b-b84b-4de6-a13e-76b60179af46@forum.thewizardofosc.com (60142.6ms)
استثناء المهمة: Net::ReadTimeout

6

غريب. إذا كان بإمكانك الاتصال من خارج الحاوية، فيمكنك التحقق مما إذا كان أمر curl سيعمل داخل الحاوية. تخميني الوحيد هو أن لديك مشكلة في الشبكة مع Docker.

7

جايز على حق.

الخطوة المنطقية التالية، @onar3d، هي تجربة اختبار curl من داخل الحاوية.

لقد تحققت لك للتو، وcurl مثبت بالفعل في الحاوية، لذا على الأقل لا تحتاج إلى تثبيته.

docker exec -it app bash
root@hostname-app/# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

آمل أن يكون هذا مفيدًا.

8

اقتراح مثير للاهتمام!

لكنني دخلت إلى Docker باستخدام الأمر “docker exec -it DOCKERID bash”، واستخدمت نفس أمر curl، وقد نجح ذلك أيضًا.

9

شكرًا لك، لقد جربته للتو وعمل بشكل ممتاز!

إذن لا يمكن أن يكون Docker محظورًا…

10

مرحبًا @onar3d

هذا مجرد تخمين بعيد، لكن بما أنك تستخدم المنفذ 465 بدلاً من المنفذ 587، يمكنك تجربة إضافة السطر التالي في ملف yml الخاص بالحاوية:

DISCOURSE_SMTP_ENABLE_START_TLS: false

ثم إعادة بناء الحاوية ورؤية ما إذا كان الحظ حليفك :slight_smile:

مرجع:

يقدم Gmail (على سبيل المثال للمقارنة) المنافذ وطرق المصادقة التالية:

  • TLS/STARTTLS (يُسمى أحيانًا TLS الصريح): يستخدم المنفذ 587
  • SSL (يُسمى أحيانًا TLS الضمني): يستخدم المنفذ 465

… مجرد تجربة حظ في هذه الحالة… :slight_smile: ولكن ربما يكون الحظ حليفنا

إذا لم ينجح الأمر، يمكنك دائمًا التراجع إلى الإعدادات السابقة.

11

شكرًا لك!

لقد جربت هذا للتو، ولم يتم إرسال البريد الإلكتروني من Discourse :confused:

12

نعم، كان ذلك مجرد أمل بعيد… آسف على إضاعة وقتك في هذا الأمر!

فكرتي “الجنونية” الوحيدة الأخرى في الوقت الحالي هي التحقق مما إذا كان بإمكانك الدخول إلى خادم البريد الإلكتروني الخاص بك (مهما كان مزوِّده) وتعيين المنفذ على 587 (فالعديد من مزوِّدي SMTP يمنحونك خيارًا) ومحاولة “إلقاء النرد مرة أخرى” مع DISCOURSE_SMTP_ENABLE_START_TLS: true بالطبع.

بصراحة، لستُ عادةً من محبي “إلقاء النرد” وأكون أكثر اعتمادًا على الحقائق؛ لذا إذا لم ترغب في المحاولة، فأنا أفهم ذلك تمامًا يا @onar3d!!

14

شكرًا لك! للأسف، لا أملك صلاحية تغيير ذلك، فهو أحد الأنظمة الجاهزة التي قام مقدم الخدمة الخاص بي بإعدادها.

15

مرحبًا @onar3d

فهمت. لقد نفدت مني حاليًا جميع “الأفكار المجنونة”، وقد حان وقتي للاستعداد للنوم هنا؛ بالتوفيق، وآمل أن يكون لدى أحد أعضاء الفريق الأذكياء هنا بعض الأفكار الأفضل للتجربة.

كل التوفيق.

16

بعد بضع محاولات أخرى (شكرًا جزيلاً لك @IAmGav!)، تأكد أن إعدادات Discourse الخاصة بي تعمل مع خادم بريد إلكتروني مختلف، مما يستبعد عددًا من الخيارات الأخرى للتجربة.

عاد مزود خدمة البريد الإلكتروني الخاص بي إليّ برسالة سجل خطأ من جهته مع اقتراح:

قام المهندس بفحص السجلات، والخطأ المرئي من عنوان IP الخاص بهم يتعلق بإعدادات SSL. على الأرجح أنهم يستخدمون إصدارًا قديمًا أو إعدادات اتصال قديمة.

دليل:
خطأ TLS في الاتصال من [95.216.139.49]:33568 SSL_accept: تم إغلاق اتصال TCP من الطرف الآخر

جرّب تشغيل وضع SSL معطلًا فقط لمعرفة ما إذا كان ذلك سيعمل.

جربت تعيين DISCOURSE_SMTP_ENABLE_START_TLS إلى false كما هو موضح أعلاه، على المنفذ 465 وكذلك على المنفذ 26 (الذي حدده مزودي كمنفذ للاتصال غير المشفر)، ولم ينجح أي منهما.

هل يمكن أن يكون السبب أنني لم أشتري شهادة SSL للنطاق thewizardofosc.com؟ أدركت ذلك الآن بعد قراءة المزيد قليلاً؟

17

إذا لم يعمل مع خيار عدم استخدام SSL، فلن يعمل مع شهادة SSL مدفوعة. يجب أن يزودك مُضيف البريد الإلكتروني بشهادة SSL مجانية من Let’s Encrypt.

18

عزيزي @onar3d

قد تفكر في تشغيل اختبارات curl الخاصة بك مع تفعيل خيار التفصيل -v من الذاكرة، حتى تتمكن من تحليل عملية المصافحة الناجحة بالكامل؛ ثم العمل بشكل عكسي من هذا التحليل.

image
image750×389 93 KB

يمكنك استخدام خيار التفصيل هذا لعكس هندسة ما يعمل :slight_smile:

آمل أن يكون ذلك مفيدًا