DigitalOcean يمنع SMTP ويجبر على استخدام SendGrid

[MachineScholar]

لست متأكدًا بالضبط أين يجب نشر هذا، ولكني أتساءل عما إذا كان أي شخص آخر يواجه هذا. لقد اتبعت دليل التثبيت الرسمي باستخدام DigitalOcean و Mailgun. ولكن لاحظت مؤخرًا أن لدي الكثير من استثناءات المهمة Jobs::UserEmail وغير قادر على إرسال رسائل بريد إلكتروني تجريبية.

سجلات الأخطاء

Message (20584 copies reported)

Job exception: execution expired

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `open'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `tcp_socket'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:672:in `block in do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:671:in `do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:642:in `start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in <class:Config>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'

لم أتمكن من معرفة سبب المشكلة، لأنه لم يتم تغيير أي إعدادات، نسختي محدثة، وحساب Mailgun الخاص بي ضمن حدود الاستخدام المجاني. لذلك، قمت بإنشاء تذكرة دعم مع DigitalOcean لأنني اعتقدت أنهم ربما قاموا بحظر المنفذ 587، وقد تلقيت ردًا قصيرًا يفيد بأنهم فرضوا قيودًا على حركة مرور SMTP وأنهم يوصون باستخدام شريكهم SendGrid.

بريد DigitalOcean الإلكتروني

نتفهم أن لديك مخاوف بشأن قيود SMTP المفروضة على حسابك. DigitalOcean ليس مضيف بريد إلكتروني مخصص، وإيقاف البريد العشوائي هو معركة مستمرة. لهذا السبب، تم فرض قيود على جميع الحسابات.

نود أيضًا تقديم بعض الخلفية الإضافية حول هذه المشكلة. نظرًا لأن عناوين IP في البيئات السحابية يتم استخدامها وإعادتها إلى المجمعات المتاحة بشكل متكرر، فإنها تعتبر ديناميكية وغير جديرة بالثقة. على سبيل المثال، يتم تعيين عنوان IP لك حاليًا وأنت مستخدم بريد إلكتروني مسؤول. تتبع جميع أفضل الممارسات للبريد ولا ترسل أبدًا بريدًا عشوائيًا أو غير مرغوب فيه. لاحقًا، عندما لم تعد بحاجة إلى هذا الـ Droplet، تقوم بتدميره ويصبح عنوان IP متاحًا للمستخدم آخر في DigitalOcean. يستغل هذا المستخدم الفرصة لإرسال حجم كبير من البريد العشوائي قبل أن يتخذ فريق الأمان لدينا إجراءً بشأن الحساب المخالف.

لا يمكن لموفري البريد مثل Gmail و Microsoft وغيرهم تحديد ما إذا كان البريد الوارد من عنوان IP شرعيًا أم لا حتى يكتسب سمعة سيئة. بحلول ذلك الوقت، كان الضرر قد حدث بالفعل. من الأسلم ببساطة حظر جميع رسائل البريد الإلكتروني الواردة من منصات، مثل مزودي خدمة الإنترنت وبيئات الاستضافة السحابية، حيث يتم تعيين عناوين IP ديناميكيًا وهي محفوفة بالمخاطر بطبيعتها.

بينما يقلل هذا من الوسائل المتاحة للمرسلين العشوائيين، فإنه يؤثر أيضًا على المستخدمين الشرعيين. يعمل فريق عمليات الإساءة لدينا مع SBLs لإزالة عناوين IP من القوائم السوداء. بسبب هذا، نقوم بتقييد حركة مرور SMTP عبر منصة DigitalOcean. هذا يعني أننا غير قادرين على إزالة قيد SMTP المفروض على حسابك.

نتفهم أن سير عملك قد يتطلب احتياجات البريد الإلكتروني. كحل لهذا القيد، عقدنا شراكة مع SendGrid لتقديم حل أفضل لجميع عملائنا حيث لن تحتاج إلى القلق بشأن سمعة IP والقوائم السوداء. يمكنك قراءة المزيد عن هذا في مقالنا هنا. من خلال SendGrid، ستتمكن من إرسال 100 بريد إلكتروني مجاني يوميًا وإذا كان متطلبك يتجاوز المستوى المجاني، فلا تتردد في التواصل مع دعم SendGrid لاختيار خطة أفضل لتلبية متطلباتك.

يسعدنا دائمًا المساعدة إذا كانت لديك أسئلة إضافية، لذا لا تتردد في التواصل معنا.

----

هذا رد آلي للمساعدة في تسريع الخدمة من خلال الحصول على جميع المعلومات التي نحتاجها لمساعدتك. يجب عليك الرد على هذا البريد الإلكتروني للحصول على مزيد من المساعدة.

فريق دعم DigitalOcean

هل واجه أي شخص آخر هذه المشكلة العشوائية؟ بالتأكيد لا أريد أن أضطر إلى التبديل إلى SendGrid دون سبب وجيه.

تعديل…
لاحظت للتو هذا الموضوع Looks like DO is disabling Smtp in their Discourse hosting plans لذلك يبدو أن أي شخص يستخدم DigitalOcean قد يكون في ورطة.

[Don]

مرحباً

لست متأكداً مما إذا كنت على خادم الاتحاد الأوروبي، ولكن Mailgun تواجه بعض مشاكل الاتصال الآن، لذا لا يمكن إرسال رسائل البريد الإلكتروني. لدي أيضاً الكثير من الأخطاء في /logs.

انظر: https://status.mailgun.com/

[MachineScholar]

شكرًا لك! أنا على خادم الاتحاد الأوروبي، ومع ذلك، فقد استمر هذا منذ عدة أيام وللأسف، ليس خطأ Mailgun. ولدي مثال آخر لا يوجد به مستخدمون وهو أيضًا مُعد على خادم Mailgun في الاتحاد الأوروبي، وهذا المثال يرسل رسائل اختبارية ولا توجد أخطاء في البريد الإلكتروني. لذا، استنتجت أن هذه المشكلة لا يمكن أن تكون خطأً من Mailgun

[pequiste]

DigitalOcean ليست الخيار الوحيد المتاح. قد تفكر في الانتقال إلى مزود أوروبي لخادمك الافتراضي الخاص (VPS).

لقد فعلت الشيء نفسه لمنصة رسائل البريد الإلكتروني للمعاملات وكان الأمر رائعًا.

أعلم أن Digital Ocean هو الخيار الافتراضي لتثبيت Discourse، لكن عرض الخادم الافتراضي الخاص بهم ليس مميزًا بأي شكل من الأشكال. إذا لم يعد الأمر مناسبًا، فلن يكون مناسبًا.

[MachineScholar]

نصيحة جيدة بالتأكيد، وشكراً لك عليها. ومع ذلك، فإن عروض DO تتوافق بشكل جيد مع بعض الأشياء الأخرى التي أقوم ببنائها ومحاولة ربطها دون عناء، لذا سيكون من الرائع لو لم يقوموا بمثل هذه التحركات المشبوهة. يمكن لأي خادم Ubuntu تقريبًا - من الناحية النظرية - أن يعمل بشكل جيد، لذا فإن وجهة نظرك صحيحة تمامًا.

[MachineScholar]

تحديث! عليك فقط فتح تذكرة دعم والشكاية بما يكفي ليدعمهم لإلغاء حظر المنافذ. يمكنني أن أؤكد أن رسائل الاختبار الآن تُرسل ويبدو أن كل شيء يعمل الآن.

[التفاصيل = “البريد الإلكتروني لدعم العملاء لـ DO”]

مرحبًا،

نحن نتابع مع تحديث.

فريق الأمان لدينا قد قام بإلغاء حظر منافذ SMTP على حسابك.

يجب أن تتمكن الآن من تكوينها، ولكن إذا واجهت أي صعوبة، يرجى إخبارنا حتى نتمكن من التحقيق بشكل أكبر!

نحن دائمًا سعداء للمساعدة إذا كان لديك أسئلة إضافية، لذا لا تتردد في إبلاغنا.

[/details]

[Linus_pi (Linus)]

هل هناك أي تحديثات حول هذا الموضوع؟ لقد تلقيت نفس الرد مرتين قائلين إنهم لن يرفعوا الحظر بسبب سياساتهم. لكن مزود البريد الإلكتروني الذي أستخدمه لا يمكنه فتح المنفذ 2525. لدي الموقع الرئيسي هناك لذلك لا أرغب في ترك هذه الخدمة.

يبدو من الغريب أن يكون DO هو المكان الذي يتم فيه استضافة Discourse في الغالب وأن هذا لا يجعلهم يعيدون النظر. أي أفكار؟

[Jagster (Jakke Lehtonen)]

@Linus_pi

أي أفكار؟

واحدة فقط. لماذا تبقى وتدفع في مكان لا يمكنك فيه الحصول على ما تحتاجه؟

[Linus_pi (Linus)]

حسنًا، لأنه نجح لشخص آخر على ما يبدو مما أدى إلى إلغاء حظر المنفذ.

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

[supermathie (Michael Brown)]

للإشارة، إليك منشور DO حول هذا الموضوع:

SMTP restricted by default | DigitalOcean

ويبدو أن المنفذ 587 (الإرسال المصادق عليه) محظور افتراضيًا:

Why is SMTP blocked? | DigitalOcean Documentation

برأيي الشخصي، فإن حظر 25 (SMTP) و 465 (SMTPS) افتراضيًا كإجراء لمكافحة البريد العشوائي أمر معقول، ولكن حظر 587 غير منطقي ويبدو أنه تم بسبب الجهل بوظيفته.

[Linus_pi (Linus)]

شكراً لك، لقد أصررت في التذكرة المفتوحة مع DO على أن يشرحوا لماذا يتأثر بعض المستخدمين والبعض الآخر لا، لكنهم يصرون على سياستهم. أعتقد أن الأمر يتعلق بالحسابات الجديدة كما يشرح الرابط الخاص بك. ولكن لا يزال من الممكن أن تكون هناك طريقة للتحقق من النشاط غير العشوائي للحساب أو حتى مراجعة الحساب. كان ردهم هو “هناك بعض المعايير التي لا يمكننا الكشف عنها لسلامة منصتنا” لذا أعتقد أن هذا هو الحال. إما تغيير خدمة البريد الإلكتروني أو تغيير VPS لـ discourse. ولكن هل يمكن أن يحدث هذا في مكان آخر؟ من يدري…

[pacharanero (Marcus Baw)]

لسبب غير واضح تمامًا من DigitalOcean، بدأوا في حظر المنافذ 465 و 587 في 6 مارس Release Notes | DigitalOcean Documentation “تم الآن حظر منافذ SMTP 465 و 587 على Droplets.” أثر هذا على قطرة تم إنشاؤها منذ أكثر من عامين، وكانت تعمل بشكل جيد في إرسال البريد الإلكتروني سابقًا.

ومع ذلك، لدي بالتأكيد قطرات على DO قادرة على إرسال البريد الإلكتروني باستخدام المنفذ 587، ولدي أيضًا قطرات توقفت فجأة عن القدرة على الإرسال.

أنا مستاء للغاية من أن DO قد فعلت ذلك دون أي شكل من أشكال الإخطار أو التحذير. يخبرونني عن صيانة LON1 المخطط لها حوالي 5 مرات في الأسبوع، لذلك لا يمكنني رؤية كيف لا يمكنهم إخباري بتغيير قد يؤدي إلى تعطل الشبكة. اكتشفت فقط أن هذه القطرة لم تكن ترسل البريد الإلكتروني لأن العميل اتصل بي ليقول أن هناك مشكلة، وهو أمر محرج ويبدو غير مهني. يكفي القول بأنني سأنقل تدريجيًا جميع خوادمي بعيدًا عن DO حيثما أمكن. (أستخدم الكثير من Hetzner هذه الأيام)

بعد ما كان، أخشى أن أقول، بريد إلكتروني حاد اللهجة مني اليوم، قاموا بإلغاء حظر المنافذ وكل شيء يعمل الآن.

هل لدى أي شخص اقتراحات لطريقة “مراقبة وقت التشغيل” لإرسال البريد الإلكتروني؟ هناك عدة طرق يمكن أن يفشل بها البريد الإلكتروني، وما لم تكن تراقب كل البريد الإلكتروني من منتدى، فمن الصعب دائمًا “ملاحظة” أن البريد الإلكتروني لم يعد يخرج.