تواريخ خاطئة بعد ترحيل Zoho إلى Microsoft 365

ما الذي حدث في صندوق بريدك

انتهيت للتو من ترحيل نطاقك من Zoho Mail إلى Microsoft 365. البنية التحتية لـ Exchange Online في مكانها، وصناديق البريد جاهزة، وسجلات MX محدّثة. ثم يأتي صباح الاثنين ويفتح أحد المستخدمين Outlook ليكتشف أن رسائله من عام 2021 تحمل تاريخ اليوم. ومستخدم آخر يجد رسائل العام الماضي في أعلى صندوق الوارد، كأنها وصلت للتو. تبدأ التذاكر تتراكم.

هذه ليست مشكلة في Outlook، ولا هي خاصة بـ Zoho. هذا هو السلوك المتوقع (لكن غير الموثّق جيداً) لأي ترحيل IMAP إلى Exchange Online. فهم السبب الدقيق هو الخطوة الأولى نحو الإصلاح الصحيح.

السبب التقني: INTERNALDATE ورؤوس Received

الرسالة المخزّنة على خادم IMAP مكوّنة من شيئين منفصلين: المحتوى الخام للرسالة (رؤوس RFC 2822، والنص، والمرفقات) وبيانات التعريف التي يديرها الخادم، وأبرزها INTERNALDATE. هذه البيانات هي ما يعتمد عليها عملاء البريد لعرض الرسائل وترتيبها.

الرأس Date: الموجود في الرسالة الخام (RFC 2822) يمثّل التاريخ الذي كُتبت أو أُرسلت فيه الرسالة من طرف المُرسل. أما INTERNALDATE فهو تاريخ استلام أو تخزين الرسالة على خادم IMAP. في الأوضاع الطبيعية، تكون هاتان القيمتان متقاربتين. بعد الترحيل، القصة مختلفة تماماً.

كيف يفسد ترحيل IMAP التواريخ

حين ينقل أداة الترحيل (سواء كان Zoho Migration Wizard أو imapsync أو BitTitan أو أي أداة أخرى) رسالةً من Zoho Mail إلى Exchange Online، يتم ذلك عبر بروتوكول IMAP. الأداة تتصل بـ Zoho، تجلب الرسالة، ثم تدرجها في Exchange Online. وهنا تبدأ المشكلة.

Exchange Online، عند استلام كل رسالة، يولّد رأساً جديداً Received: يُضاف في مقدمة الرسالة. هذا الرأس يحمل التاريخ والوقت الدقيق للإدراج، أي تاريخ الترحيل. بعض أدوات الترحيل تحاول الحفاظ على INTERNALDATE الأصلي بتمريره كمعامل، وبعضها لا يفعل ذلك أو يفعله بشكل خاطئ، فيُسنّد Exchange Online تاريخ الاستلام تلقائياً كـ INTERNALDATE.

النتيجة: سواء كانت الرسالة مُرسلة في 2019 أو 2022، فإن INTERNALDATE الخاص بها يشير الآن إلى أسبوع الترحيل. Outlook يقرأ هذه القيمة بالأولوية. يتهاوى الترتيب الزمني بالكامل.

السلوك الخاص بـ Zoho Migration Wizard

تقدّم Zoho أداتها الخاصة للترحيل: Zoho Migration Wizard. هذه الأداة عملية للترحيلات البسيطة، لكنها تحمل سلوكاً موثّقاً في منتديات المديرين: لا تنقل دائماً INTERNALDATE الأصلي بشكل صحيح عند الإدراج في خادم الوجهة.

بالتحديد، المشكلة تطال أساساً الترحيلات نحو خوادم تُضيف رأساً Received: لكل رسالة واردة، وهذا هو بالضبط سلوك Exchange Online. حتى لو أرسلت Zoho Migration Wizard التاريخ الأصلي عبر معامل APPEND، فإن الرأس Received: الذي يولّده Exchange Online يتصدّر سلسلة الرؤوس، ويستعمله Outlook لتحديد "متى وصلت الرسالة".

المديرون الذين يستخدمون أدوات IMAP عامة مثل imapsync للخروج من Zoho يواجهون المشكلة ذاتها، وأحياناً بصورة أسوأ، لأن الإعداد الافتراضي لـ imapsync غير محسّن لـ Exchange Online. (وإن كنت قد تصفّحت يوماً سجل imapsync سطراً سطراً بحثاً عن خطأ مزامنة في الثانية صباحاً، فأنت تعرف أنها أداة قوية لكنها غير متسامحة مع الحالات الاستثنائية.)

لماذا يعرض Outlook التاريخ الخاطئ

Outlook لا يعتمد حصراً على رأس Date: لعرض تاريخ الرسالة. في معظم العروض، يُستخدم INTERNALDATE المقدَّم من خادم IMAP/Exchange، لا سيما عند ترتيب صندوق الوارد. الرأس Date: الأصلي موجود في الرسالة وسليم، لكنه يُتجاهل لصالح INTERNALDATE.

لهذا السبب، خيار "الترتيب حسب تاريخ الإرسال" في Outlook لا يحل المشكلة فعلياً. يعرض تاريخاً مختلفاً، نعم، لكن سلوك الترتيب يبقى غير مستقر تبعاً لإصدار Outlook وطريقة العرض (المحادثات المجمّعة أو لا). الترتيب حسب تاريخ الإرسال ليس حلاً. إنه لاصقة جرح تسقط عند أول تحديث للعميل.

الحجم الحقيقي للمشكلة

في ترحيل متوسط الحجم من Zoho إلى Microsoft 365، يمكن أن يصل عدد الرسائل المتضررة بسهولة إلى ما بين 50,000 و500,000 رسالة، وذلك حسب عمر الصناديق وحجم المؤسسة. كل رسالة نُقلت خلال نافذة الترحيل تحمل التاريخ الفاسد نفسه، ما يجعل المشكلة مرئية فوراً للمستخدمين منذ أول فتح لـ Outlook.

مجلدات العناصر المُرسلة هي الأشد إشكالية في الغالب. مندوب مبيعات يبحث عن عرض أسعار أرسله في مارس 2022 يجد نفسه يتصفّح مئات الرسائل التي تحمل كلها تاريخ الترحيل. الأثر التشغيلي حقيقي، لا مجرد مسألة شكلية.

وخلافاً لما قد يتوقعه البعض، لا تختفي المشكلة مع الوقت. INTERNALDATE تُحدَّد لحظة الإدراج. لا تصحيح تلقائي لها. دون تدخل فعلي، ستحتفظ الرسائل بتواريخها الفاسدة إلى أجل غير مسمى.

لماذا يكون الإصلاح اليدوي أكثر خطورة مما يبدو

الإغراء مفهوم: طالما أن الرأس Date: الأصلي لا يزال في الرسالة، يكفي تصحيح بيانات التعريف. منطقياً، هذا معقول. عملياً، على صندوق إنتاج يحتوي 80,000 رسالة، العملية يمكن أن تنتهي بكارثة.

إليك بعض الحالات الاستثنائية التي يرجّح أن سكريبت محلياً لن يتعامل معها بشكل صحيح:

• الرسائل الموقّعة بـ S/MIME، حيث تشمل التوقيع مجموع الرؤوس. أي تعديل في بنية الرسالة يُبطل التوقيع التشفيري.
• الرسائل المشفّرة بـ PGP، حيث المحتوى معتم وأي تلاعب بمغلفات MIME قد يُفسد الرسالة.
• الرؤوس غير ASCII المشفّرة وفق RFC 2047 (أسماء مُرسلين تحتوي أحرفاً خاصة)، التي تتكسّر إن لم يُعالج السكريبت الترميز بشكل صحيح.
• المرفقات المُشفّرة بـ base64 ذات الأسطر المنتهية بشكل خاطئ، أو حدود MIME غير قياسية، أو بنى multipart متداخلة.
• الرسائل الخالية من رأس Date: صالح (وهذا موجود فعلاً، لا سيما في التصديرات القديمة من Zoho)، حيث على السكريبت أن يقرر ماذا يفعل.

سكريبت يعمل على 50 رسالة اختبار لن يعمل على صندوق إنتاج Zoho يحتوي سنوات من الرسائل. وكيف تتحقق، رسالةً رسالة، أن كل تصحيح صحيح وأن المرفقات لم تُقتطع؟ التحقق معقّد بالقدر ذاته الذي يكون عليه التصحيح.

ثمة أيضاً مسألة الحصص. واجهة برمجة Exchange Online عبر Microsoft Graph تفرض حدوداً صارمة للطلبات (أخطاء 429 Too Many Requests الشهيرة). دفعة غير مُعدَّلة على 100,000 رسالة قد تُطلق قيوداً مؤقتة أو أخطاء صامتة يصعب تشخيصها لاحقاً. دون آلية للاستئناف من نقطة الفشل، تبدأ من الصفر.

كيف تُصلح Redate.io التواريخ بعد ترحيل Zoho

Redate.io تتصل بمستأجر Microsoft 365 الخاص بك عبر أذونات Azure AD القياسية، دون الحاجة إلى صلاحيات مسؤول شامل. الفحص الأولي مجاني: تُحدّد Redate.io الصناديق المتضررة وتقدّر حجم الرسائل ذات التواريخ الخاطئة، بمقارنة INTERNALDATE مع القيم المحمولة في سلسلة رؤوس الرسالة.

يعتمد التصحيح على محرك خاص يُحلّل سلسلة الرؤوس الكاملة لكل رسالة، ويُحدّد البصمات المميّزة لأدوات ترحيل Zoho (سواء كان Zoho Migration Wizard أو imapsync المُهيّأ للخروج من Zoho)، ويُعيد بناء بيانات التعريف الخاصة بالتاريخ عبر خط أنابيب تحقق متعدد المراحل. كل رسالة مُصحَّحة تخضع للتحقق بشكل فردي: سلامة المحتوى، والحفاظ على المرفقات، والتوافق مع RFC. تُحتفظ بالرسائل الأصلية في مجلد نسخ احتياطي يمكن الوصول إليه لمدة 30 يوماً.

لا إعادة ترحيل. لا توقف عن العمل. يواصل المستخدمون استخدام Outlook بينما يجري التصحيح في الخلفية.

التسعير قائم على دفعة واحدة حسب الحجم، دون اشتراك. التفاصيل متاحة مباشرة على الموقع.

سيناريوهات مجاورة مفيد معرفتها

إن كنت تُدير ترحيلات متعددة بالتوازي، أو كنت مزوّد خدمات مُدارة (MSP) تُشرف على عملاء يغادرون Zoho، فاعلم أن المشكلة ذاتها تحدث عند الترحيل من منصات أخرى نحو Exchange Online. الآلية متطابقة: الرأس Received: الذي يولّده Exchange يُلغي INTERNALDATE بصرف النظر عن المصدر.

بالنسبة للترحيلات من Google Workspace أو Exchange on-premises أو عبر أدوات مثل BitTitan MigrationWiz أو CloudM، تتوفّر مقالات مخصصة على مدونة Redate.io توضح السلوك الخاص بكل أداة. صفحة تواريخ بريد خاطئة بعد ترحيل Exchange Online تقدّم نظرة شاملة على جميع السيناريوهات التي تنتهي على هذا المستأجر.

إن كان ترحيلك يشمل صناديق بريد مشتركة أو موارد Exchange (قاعات، معدات)، فالمشكلة ذاتها قائمة وتنطبق عليها الأدوات نفسها. أدلة إصلاح ترحيل Exchange IMAP في Outlook على موقع Redate.io تشرح خطوات الاتصال بمستأجرك.

للفرق التي تستخدم imapsync تحديداً للخروج من Zoho، صفحة imapsync: التواريخ غير المحفوظة توثّق خيارات إعداد imapsync ولماذا لا تكفي لتفادي المشكلة في Exchange Online.

هل لا تزال تواريخ الترحيل من Zoho تظهر خاطئة في Outlook؟ افحص صناديق بريدك مجاناً على Redate.io لقياس الحجم الحقيقي للمشكلة قبل أن تقرر كيف تتصرف.