SMTP Net::ReadTimeout بدون علاقة بمشاكل الشبكة أو تسجيل الدخول - مضيف SMTP بطيء فقط

[rfk (Roland)]

أهلاً،
منذ بضعة أسابيع، فشلت رسائل البريد الإلكتروني المرسلة من مثيل Discourse الخاص بي. إعدادات SMTP لم تتغير، واختبار curl لا يزال يعمل ولكنه بطيء بشكل ملحوظ. خادم SMTP الخاص بمستضيفنا (الذي نحتاج إلى استخدامه لإرسال رسائل البريد الإلكتروني) لديه وقت إرسال ثابت يبلغ 7 ثوانٍ.

cat testmail | curl -vvv --url 'smtp://smtp.<HOST>:587' --mail-from mail@<DOMAIN> --mail-rcpt <ME> --user "mail@<DOMAIN>:<PW>" -T -

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP>...
* Connected to smtp.<HOST> (<IP>) port 587 (#0)
< 220 mailproxy1.<HOST> Dovecot ready.
> EHLO ecm2
< 250-mailproxy1.<HOST>
< 250-8BITMIME
< 250-AUTH PLAIN LOGIN
< 250-BURL imap
< 250-ENHANCEDSTATUSCODES
< 250-SIZE
< 250-STARTTLS
< 250 PIPELINING
> AUTH PLAIN
< 334 
> xxxxxx=
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0< 235 2.7.0 Authentication successful
  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0> MAIL FROM:<mail@<DOMAIN>>
< 250 2.1.0 Ok
> RCPT TO:< <ME>>
< 250 2.1.5 Ok
> DATA
< 354 End data with <CR><LF>.<CR><LF>
} [89 bytes data]
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    20< 250 2.0.0 Ok: queued as 356C3288C85
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    26
* Connection #0 to host smtp.<HOST> left intact

قارنت هذا بخادم البريد الداخلي الخاص بنا مع أقل من ثانية واحدة لكل بريد. الـ 7 ثوانٍ من مستضيف البريد لن تكون مشكلة حقيقية، لكنني لم أتمكن من تحديد إعداد لرفع مهلة الـ 5 ثوانٍ (التي تبدو مبرمجة بشكل ثابت؟). open_timeout، ويبدو لي أن read_timeout الأكثر صلة مرئي أيضًا في واجهة الاختبار في /admin/email:

• التوقيتات في حاوية تطبيق docker متطابقة مع اختبار محلي أو اختبار على مضيف docker.
• رسائل البريد الإلكتروني المرسلة بواسطة cURL يتم تسليمها بشكل صحيح (بعد انتظار 7 ثوانٍ + لمحة عين).
• لأسباب تتعلق بالخصوصية، فإن الحلول البديلة المعتادة مثل sendgrid و mailgun وما إلى ذلك ليست خيارًا للأسف.
• ربما أدى التبديل إلى ActionMailer 7.0.x إلى هذه المشكلة بالنسبة لي؟
  • rails/actionmailer/CHANGELOG.md at v7.0.3.1 · rails/rails · GitHub

  • يضبط قيمة افتراضية 5 لكل من open_timeout و read_timeout لإعدادات SMTP.

شكراً لأي فكرة حول كيفية تكوين read_timeout.

[Falco]

@rfk

شكراً لأي فكرة حول كيفية تكوين read_timeout.

لذلك من الضروري إضافة هذه الإعدادات الجديدة في

config/environments/production.rb

لذلك يبدو الأمر هكذا

  if GlobalSetting.smtp_address
    settings = {
      address: GlobalSetting.smtp_address,
      port: GlobalSetting.smtp_port,
      domain: GlobalSetting.smtp_domain,
      user_name: GlobalSetting.smtp_user_name,
      password: GlobalSetting.smtp_password,
      authentication: GlobalSetting.smtp_authentication,
      enable_starttls_auto: GlobalSetting.smtp_enable_start_tls,
+     open_timeout: GlobalSetting.smtp_open_timeout,
+     read_timeout: GlobalSetting.smtp_read_timeout
    }

هل يمكنك تقديم طلب سحب بالتغييرات؟

[rfk (Roland)]

مرحباً @Falco،

شكراً على ردك السريع. أنت على حق، هذه التغييرات سارية المفعول:

• مهلة المهلة الجديدة من app.yml مرئية
• يمكن إرسال رسائل البريد الإلكتروني.

بما أن لغة Ruby لدي شبه معدومة، سأبذل قصارى جهدي لإعداد طلب السحب وأنا ممتن بالفعل لمساعدتك ولـ Discourse بشكل عام.

مع خالص التقدير

رولاند

[rfk (Roland)]

الطلب قيد المراجعة (PR) متاح عبر الإنترنت: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

سأكون ممتنًا لأي مدخلات حول كيفية/ما إذا كان بإمكاني تحسين الطلب قيد المراجعة.

[Falco]

نحن بحاجة فقط إلى توقيع CLA في طلب السحب (PR) لكي نتمكن من دمجه.

[rfk (Roland)]

عذرًا، لقد كانت عطلة نهاية أسبوع طويلة. تم الانتهاء.

[RGJ (Richard - Communiteq)]

@rfk

خادم SMTP الخاص بمزود الاستضافة لدينا (الذي نحتاجه لإرسال رسائل البريد الإلكتروني) لديه وقت إرسال ثابت يبلغ 7 ثوانٍ.

للعلم، يفعلون ذلك عن قصد لتثبيط البريد العشوائي. معظم أدوات البريد العشوائي الآلية لديها أيضًا مهلة مدتها 5 ثوانٍ.

[rfk (Roland)]

أتوقع هذا بالضبط، لأن التأخير في جانب خادم SMTP متجانس للغاية. لذا فإن الإصلاح الذي اقترحه @Falco والذي أصبح الآن في PR#17863 قد يكون ذا صلة بالمزيد من المستخدمين.

هناك خطأ في اختبار الوحدة core frontend (Headless Firefox). أنا بعيد كل البعد عن معرفة ما يجري، ولكني لا أتوقع أن يتم تشغيل هذا بسبب تغييرنا هنا.

[Falco]

شكرا على طلب سحب الميزات والاختبار. تم دمجه الآن.