حل مشكلة all hosts have been failing for a long time (and retry time not reached)
عدم إرسال الإيميلات إلى STC - مشكلة الإرسال إلى stc.com.sa
retry time not reached for any host for 'stc.com.sa'
Remote host closed connection in response to initial connection
SMTP error from remote mail server after initial connection
554 5.7.1 You are not allowed to connect
all hosts have been failing for a long time
Exim defer عند الإرسال إلى STC
cPanel Track Delivery يظهر Deferred أو retry timeout

قد تواجه مشكلة في سيرفرات cPanel/WHM أو Exim أن الإيميلات تعمل بشكل طبيعي مع أغلب الدومينات مثل Gmail و Outlook و Yahoo وباقي الشركات، لكن عند الإرسال إلى إيميلات STC فقط على الدومين stc.com.sa تبدأ الرسائل في الفشل أو تدخل في حالة Retry، ثم تظهر أخطاء في Track Delivery أو Exim Mainlog مثل: retry time not reached for any host for 'stc.com.sa' أو Remote host closed connection in response to initial connection أو SMTP error from remote mail server after initial connection: 554 5.7.1 You are not allowed to connect.


المشكلة

هنا تكون غريبة لأن السيرفر يستقبل الإيميلات بشكل طبيعي، ويرسل إلى أغلب الجهات بشكل طبيعي، لكن الفشل يحدث فقط مع STC. في البداية قد تظهر الرسالة على أنها Deferred أو Retry، ومع تكرار محاولات Exim للإرسال وفشل الاتصال بسيرفرات STC، يبدأ Exim في تأجيل المحاولات التالية تلقائيًا، فتظهر رسالة retry time not reached for any host. وهذا لا يعني بالضرورة أن قاعدة بيانات Exim بها خلل، بل يعني أن Exim حاول أكثر من مرة، وكل المحاولات فشلت، فأصبح ينتظر وقت إعادة المحاولة التالي.
السسيرفر و الاى بى و الدومينات كلها Clean من RBL
مفيش اى مستوى بلوك سواء ليفل او غيره نهائيا
نظيف تماما !


وصف المشكلة

من البداية أن يتم إرسال رسالة من بريد على السيرفر إلى عنوان تابع لـ STC مثل user@stc.com.sa، لكن الرسالة لا تخرج بنجاح، وتظهر في Track Delivery بحالة Deferred أو Failure. وعند فحص اللوج يظهر أن سيرفر STC إما يرفض الاتصال مباشرة أو يغلق الاتصال فور بدايته. أحيانًا يظهر الرفض برسالة 554 5.7.1 You are not allowed to connect، وأحيانًا يظهر Remote host closed connection in response to initial connection، وبعد تكرار المحاولات يظهر retry time not reached for any host for 'stc.com.sa'.


سبب المشكلة بعد الفحص أن المشكلة ليست من بريد العميل نفسه، وليست من كلمة مرور الإيميل، وليست من Webmail أو Outlook، وليست غالبًا من SPF أو DKIM أو DMARC. السبب أن الرفض يحدث من STC في بداية الاتصال، قبل أن يبدأ السيرفر في إرسال بيانات الرسالة نفسها، وقبل مراحل EHLO و MAIL FROM و RCPT TO و DATA. وهذا يدل أن STC ترفض اتصال IP السيرفر من البداية، وليس محتوى الرسالة أو إعدادات الدومين فقط.


الأهم من ذلك أنه عند وجود أكثر من سيرفر من نفس مقدم الخدمة أو نفس الداتا سنتر، قد تظهر نفس المشكلة على أكثر من سيرفر في نفس الوقت. وهذا يؤكد أن المشكلة غالبًا ليست في دومين معين أو عميل معين، بل في شبكة مقدم الخدمة أو IP Range أو ASN الخاص بالداتا سنتر، حيث إن STC قد تكون رافضة أو مفلترة هذه الشبكة داخليًا.


مثال توضيحي: سيرفر 1 من نفس مقدم الخدمة يفشل في الإرسال إلى STC، وسيرفر 2 من نفس مقدم الخدمة يفشل أيضًا، وسيرفر 3 من نفس مقدم الخدمة تظهر عليه نفس المشكلة. لكن عند تجربة الإرسال من سيرفر آخر موجود عند مزود سيرفرات مختلف، يتم قبول الرسالة من STC بنجاح. هنا نستنتج أن المشكلة ليست عامة في STC، وليست في الدومين المرسل فقط، بل في قبول STC لاتصالات شبكة أو IPs مقدم الخدمة الأول.


لا يكون الحل في هذه الحالة هو تعديل SPF أو DKIM أو DMARC فقط؛ لأن هذه الفحوصات تتم عادة بعد وصول الرسالة إلى مرحلة متقدمة من الحوار بين السيرفرين. أما في هذه الحالة، STC ترفض الاتصال من البداية أو تغلق الاتصال مباشرة، قبل أن يتم إرسال بيانات الرسالة أصلًا. لذلك تعديل SPF أو DKIM أو DMARC وحده لن يحل المشكلة إذا كان IP السيرفر نفسه مرفوضًا من STC.


كذلك التواصل مع STC ليس حلًا عمليًا في أغلب الحالات، لأنه لا توجد طريقة واضحة أو مضمونة للتواصل مع فريق Email Security داخل STC لطلب مراجعة IP أو فك الحظر. قد يتم إرسال رسائل إلى عناوين دعم عامة، أو محاولة الوصول لقسم مختص، لكن غالبًا لا يكون هناك رد سريع أو آلية واضحة مثل بعض مزودي البريد الذين يوفرون نماذج Delisting أو IP Review. ولهذا السبب، في بيئة استضافة بها عملاء وشركات تحتاج إرسال البريد فورًا، لا يكون انتظار رد STC حلًا عمليًا.
تم تجربة حلول كثيرة لكنها لا تعالج السبب الحقيقي، مثل تغيير DNS Resolver، ومسح Retry Database فقط، وإعادة تشغيل Exim، وتعطيل CSF مؤقتًا، وتعديل SPF أو DKIM أو DMARC، وإعادة إرسال الرسالة أكثر من مرة، أو نقل البريد من حساب إلى حساب آخر على نفس السيرفر. هذه الخطوات قد تفيد في مشاكل أخرى، لكنها لن تحل المشكلة إذا كان سببها رفض STC لاتصال IP السيرفر أو شبكة مقدم الخدمة.


حل المشكلة

العملي كان استخدام Relay من سيرفر آخر موجود عند مزود سيرفرات مختلف. بمعنى أن السيرفر الأساسي الذي عليه العملاء يظل كما هو، وكل الإيميلات إلى Gmail و Outlook و Yahoo وباقي الدومينات تخرج طبيعيًا من نفس السيرفر، لكن الإيميلات المرسلة إلى stc.com.sa فقط يتم توجيهها إلى سيرفر Relay آخر، وهذا السيرفر الآخر يكون عند مقدم خدمة مختلف و IP الخاص به مقبول لدى STC. بعد ذلك يقوم سيرفر الـ Relay بإرسال الرسالة إلى STC بنجاح.


وبذلك يكون المسار: السيرفر الأساسي → Relay Server عند مزود آخر → STC، بدلًا من السيرفر الأساسي → STC مباشرة. الميزة في هذا الحل أنه لا يغير نظام الإرسال لكل العملاء، ولا يحول السيرفر بالكامل إلى Smart Host، ولا يؤثر على Gmail أو Outlook أو باقي الدومينات. التعديل يكون مخصصًا فقط لدومين STC، بمعنى أن stc.com.sa فقط يخرج عبر Relay Server، أما باقي الدومينات فتخرج طبيعيًا من السيرفر الأساسي.


بعد تطبيق الحل وتوجيه رسائل STC فقط عبر Relay Server من مزود آخر، بدأت الرسائل تُقبل بنجاح، وظهر في Track Delivery أن الرسالة تم إرسالها إلى STC بحالة Accepted. كما ظهر في لوج السيرفر أن الرسالة خرجت من السيرفر الأساسي إلى سيرفر الـ Relay، ثم خرجت من الـ Relay إلى سيرفرات STC، وتم قبولها برد مثل 250 2.0.0 OK. وهذا يؤكد أن المشكلة كانت في قبول STC لاتصال IP السيرفر الأساسي أو شبكة مقدم الخدمة، وليست في الرسالة نفسها.


بعد نجاح الحل، من الأفضل إضافة IP سيرفر الـ Relay في SPF الخاص بالدومين المرسل، حتى تكون الرسائل المرسلة عبر الـ Relay مصرحًا بها رسميًا. لكن DMARC لا يفضل تشديده مباشرة إلى quarantine أو reject إلا بعد التأكد من أن الرسائل الحقيقية تمر بنجاح وأن DKIM/SPF/DMARC تعمل بشكل صحيح بعد استخدام الـ Relay.


الخلاصة:

إذا كانت الإيميلات تعمل مع كل الدومينات، لكنها تفشل فقط عند الإرسال إلى STC / stc.com.sa، وتظهر أخطاء مثل retry time not reached for any host for 'stc.com.sa' أو Remote host closed connection in response to initial connection أو 554 5.7.1 You are not allowed to connect، وكانت نفس المشكلة تظهر على أكثر من سيرفر من نفس مقدم الخدمة، بينما تعمل من سيرفر آخر عند مزود مختلف، فغالبًا المشكلة من رفض STC لشبكة أو IPs مقدم الخدمة الأول.


وفي هذه الحالة، الحل العملي هو استخدام Relay Server من مزود سيرفرات آخر لتوجيه رسائل STC فقط، مع بقاء باقي الإرسال كما هو. بمعنى: STC فقط تخرج عبر Relay Server، وكل باقي الدومينات تخرج من السيرفر الأساسي بشكل طبيعي. وهذا حل فعال للمشكلة بدون التأثير على باقي العملاء أو تغيير إعدادات الإرسال لكل السيرفر.

شاهد ايضا :
حل مشكلة retry timeout exceeded

حل مشكلة all hosts have been failing for a long time (and retry time not reached)

الويب ميل webmail راوند كيوب Roundcube حل مشكلة بطىء loading بعد فتح الايميل
حل مشكلة Webmail (Roundcube) يفضل Loading في إيميل واحد فقط داخل cPanel



المشكلة:

سبب المشكلة:

غالبًا لا تكون المشكلة من السيرفر نفسه، بل تكون مرتبطة بالحساب المتأثر فقط، ومن أشهر الأسباب:

جلسة تسجيل دخول (Session) تالفة أو معلّقة داخل Roundcube.
تعارض في المصادقة بين كلمة مرور البريد والجلسات القديمة.
كاش (Cache) قديم محفوظ للحساب داخل نظام الويب ميل.
أحيانًا رسالة معينة ثقيلة أو تالفة تسبب بطء عند تحميل القائمة.

حل المشكلة:

تغيير كلمة مرور ال سي بنايل و الويب ميل

او

إعادة فهرسة البريد للحساب



إذا كان Roundcube على cPanel يستخدم SQLite لكل حساب فغالبًا ملف قاعدة البيانات يكون بهذا الشكل:
/home/USER/etc/example.com/user.rcube.db
قبل أي شيء خذ نسخة احتياطية:



للتأكد من الجداول الموجودة داخل القاعدة:






ثم تنظيف الكاش والجلسات:






بعد تنفيذ الأوامر يتم فتح الويب ميل مرة أخرى وغالبًا تختفي المشكلة مباشرة.
إذا لم تُحل المشكلة بعد ذلك يمكن إعادة إنشاء قاعدة Roundcube للحساب دون المساس بالرسائل: