n8n Cloud: عقدة إرسال البريد الإلكتروني (SMTP) تتوقف وتفشل بصمت — هل SMTP الخارجي (465/587) محظور على Cloud؟

هل يمكنك الإجابة على الأسئلة التالية:

  1. هل تحظر n8n Cloud أو تقيد أو تحد من معدل الاتصالات الصادرة عبر SMTP على المنافذ 465 أو 587 من البنية التحتية الخاصة بها؟
  2. إذا كان هناك تقييد، هل هو مخصص لمستوى خطتي، أم أنه ينطبق على جميع حسابات n8n Cloud؟
  3. هل هناك حل موصى به لإرسال البريد الإلكتروني عبر SMTP من خلال n8n Cloud بشكل محدد (على عكس n8n الموزع ذاتيًا)؟

مرحبا @Kalon أهلا وسهلا!
بما أن n8n Cloud يستخدم عناوين IP ديناميكية لحركة المرور الصادرة، فإذا كان مزود SMTP الخارجي الخاص بك يحظر الاتصالات، يمكنك محاولة إضافة نطاقات عناوين IP الصادرة من n8n Cloud إلى القائمة البيضاء.

أعتقد أن هذا هو السبب الأكثر احتمالا.

نعم، هذا هو السلوك المتوقع على n8n Cloud وليس شيء معطل من جانبك. Cloud يحظر SMTP الخام على المنافذ 25 و465 و587 عبر جميع المستويات، لذا فإن عقدة Send Email تبقى معلقة حتى انقضاء المهلة الزمنية للاتصال، وهذا هو السبب في حدوث تعليق بدون شيء مفيد في السجل. الردود الأخرى محقة بأن الحل هو التوقف عن استخدام SMTP الخام والإرسال عبر واجهة برمجية (API) بدلاً من ذلك. عقد Gmail أو Microsoft Outlook تعمل لأنها تمر عبر واجهة برمجية المزود على https، وليس SMTP، وبالنسبة لأي شيء معاملات مزود مثل Resend أو SendGrid أو Mailgun عبر عقدة HTTP Request (أو عقدتهم المخصصة) هو المسار النظيف. إذا كنت بحاجة فعلاً إلى SMTP الخام، فاستضافة ذاتية هي المكان الوحيد حيث تتحكم في منافذ الإرسال الخارجي.

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

@Kalon لا يجب أن نحظر منافذ smtp الخارجة، أشك في أن خدمة البريد هي التي تحظر الاتصال بدلاً من أن يكون ذلك من جهة السحابة. قد تكون مشكلة إعدادات ssl/tls.

مرحباً، Kalon :waving_hand:

حول نقاطك الثلاث:

  1. n8n Cloud لا توثق علناً حجب أو تحديد معدل SMTP الصادر على المنافذ 465/587، وهي تعمل بشكل جيد لعدد كبير من مستخدمي Cloud — لذا فإن حجب المنفذ الفعلي غير محتمل. التعليق الصامت يكاد يكون دائماً إما عدم تطابق المنفذ/SSL (465 يحتاج SSL/TLS ON؛ 587 يحتاجه OFF لـ STARTTLS — إذا لم يتطابقا فالاتصال يبقى معلقاً حتى انتهاء المهلة الزمنية) أو رفض المزود لك (Gmail/Outlook عادة تحتاج كلمة مرور للتطبيق، وتحجب عناوين IP الإرسال غير المألوفة). لا يمكنني التحدث عن حدود بنية n8n الداخلية — إذا اشتبهت في وجود حجب فعلي، يمكن للدعم تأكيد ذلك.

  2. لست على علم بأي تقييد SMTP خاص بالمستوى — نفس السلوك عبر حسابات Cloud بقدر ما أعرف.

  3. الحل الموثوق على Cloud: تخطي SMTP الخام والإرسال عبر API بريد معاملات على HTTPS — SendGrid أو Brevo أو Postmark أو Resend أو Mailgun (عقدتهم أو عقدة HTTP Request). يتجنب هذا مشاكل المنفذ/TLS تماماً، ويوفر قابلية تسليم أفضل، وينجح فقط على Cloud. إذا أردت البقاء على SMTP: جرب 587 مع إيقاف SSL، واستخدم كلمة مرور التطبيق، وافتح التنفيذ الفاشل — الخطأ الفعلي (المصادقة مقابل TLS مقابل انتهاء المهلة الزمنية) عادة يكون موجوداً حتى عندما يبدو صامتاً.