CloudM Migrate: كيفية إصلاح تواريخ البريد الخاطئة

مشكلة التواريخ في CloudM Migrate التي لا يحذرك منها أحد

أنهى CloudM Migrate المهمة. لوحة التحكم تعرض 100% مكتمل، جميع المستخدمين تم ترحيلهم، صفر أخطاء. تغلق تذكرة المشروع وتنتقل إلى العميل التالي.

ثم بعد أسبوع يتصل مدير تقنية المعلومات. "لماذا يعرض كل بريد إلكتروني في صندوق الوارد تاريخ 2 أبريل؟"

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

هذا ليس خللا في CloudM. وثائق دعم CloudM نفسها تعترف بذلك صراحة. المشكلة تكمن عند تقاطع طريقة نقل أدوات الترحيل للرسائل وطريقة معالجة خوادم البريد الوجهة للبيانات الوصفية للبريد الوارد. لكن معرفة ذلك لا يساعد عميلك الذي أصبح صندوق بريده غير قابل للفرز.

كيف ينقل CloudM رسائل البريد الإلكتروني فعليا

يتصل CloudM Migrate بالمنصتين المصدر والوجهة عبر واجهات برمجة التطبيقات الخاصة بهما. بالنسبة لـ Google Workspace، يعني ذلك حساب خدمة مع تفويض على مستوى النطاق (يتم تكوينه في وحدة تحكم Google Admin تحت الأمان > عناصر تحكم API). بالنسبة لـ Microsoft 365، يستخدم Exchange Web Services أو Microsoft Graph API، حسب مسار الترحيل.

عندما يقرأ CloudM رسالة من المصدر، يحصل على محتوى RFC 2822 الكامل، بما في ذلك جميع الرؤوس الأصلية ونص الرسالة. رأس Date: الأصلي (الذي ختمه خادم بريد المرسل عند إرسال البريد لأول مرة) يصل سليما. وكذلك جميع رؤوس Received: الأصلية التي تتبع مسار تسليم الرسالة.

تحدث المشكلة في جانب الوجهة. عندما يكتب CloudM تلك الرسالة في صندوق البريد المستهدف، يعاملها خادم الوجهة كتسليم جديد. يضع رأس Received: جديدا بالتاريخ والوقت الحاليين ويضبط INTERNALDATE (الطابع الزمني الذي يستخدمه IMAP للفرز) على لحظة الإدراج.

هكذا تبدو سلسلة الرؤوس بعد ترحيل CloudM إلى Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

رأس 2019 موجود هناك. رأس Date: الأصلي لا يزال يقول 23 سبتمبر 2019. لكن Outlook يقرأ أحدث رأس Received: لتحديد ترتيب العرض، وذلك يقول الآن 2 أبريل 2026.

إعداد "Strip Received Headers" في CloudM

يقدم CloudM إعدادا لمعالجة هذه المشكلة. في الإعدادات المتقدمة للمنصة الوجهة، تحت خيارات الرسائل، يوجد مفتاح "Strip Received Headers". عند تفعيله، يزيل CloudM رؤوس received قبل إدراج الرسالة ويستبدلها برأس واحد يطابق رأس Date: للبريد الإلكتروني.

يبدو وكأنه يحل كل شيء، أليس كذلك؟ ليس تماما.

أولا، يجب أن تعرف عن هذا الإعداد قبل تشغيل الترحيل. معظم المسؤولين يكتشفون مشكلة التواريخ بعد اكتمال الترحيل. في تلك المرحلة، الرسائل موجودة بالفعل في الوجهة بتواريخ خاطئة. إعادة تشغيل CloudM مع تفعيل الإعداد ينشئ نسخا مكررة فقط، ولا يصلح ما هو موجود بالفعل.

ثانيا، هذا الإعداد له قيد خطير عندما تكون الوجهة Google Workspace. وثائق Google نفسها تؤكد ذلك: Gmail يعيد كتابة رؤوس Received: دائما على الرسائل المدرجة عبر API، مع ختمها بطابع وقت الإدراج. هذا قيد على مستوى المنصة لا يستطيع CloudM تجاوزه. حتى مع تفعيل "Strip Received Headers"، يضيف Google Workspace رأس Received: الخاص به بتاريخ الترحيل.

بالنسبة لوجهات Microsoft 365، يعمل الإعداد بشكل أفضل نظريا، لكن خط أنابيب النقل في M365 له سلوكه الخاص. قد يظل Exchange Online يضبط INTERNALDATE بناء على معالجة التسليم الخاصة به، حسب كيفية دخول الرسالة إلى النظام.

أي عمليات ترحيل CloudM تفسد التواريخ (وأيها لا تفعل)

ليس كل ترحيل CloudM ينتج تواريخ خاطئة. النتيجة تعتمد على مزيج المصدر-الوجهة ومسار API المحدد الذي يستخدمه CloudM:

• Google Workspace إلى Microsoft 365: التواريخ تتلف. CloudM يقرأ عبر Gmail API ويكتب في Exchange. طبقة النقل في M365 تختم رؤوس Received جديدة.
• Microsoft 365 إلى Google Workspace: التواريخ تتلف. حتى مع Strip Received Headers، يعيد Google API كتابة رأس Received بتاريخ الإدراج. وثائق دعم CloudM تسمي هذا "قيدا صارما للمنصة".
• Google Workspace إلى Google Workspace: التواريخ تتلف. تغييرات النطاق، توحيد المستأجرين، عمليات الدمج بالاستحواذ - مستأجر Google الوجهة يختم دائما تاريخ الترحيل على الرسائل الواردة.
• Exchange المحلي إلى Microsoft 365: يتلف عادة عبر مسار IMAP. إذا استخدم CloudM EWS على كلا الجانبين، يكون الحفاظ على التواريخ أكثر موثوقية لكن غير مضمون.
• مصدر IMAP عام إلى أي وجهة: التواريخ تتلف. عندما يتصل CloudM بخادم IMAP عام كمصدر، تضيف الوجهة رؤوس التسليم الخاصة بها.

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

CloudM المدار والخدمة الذاتية: نفس مشكلة التواريخ

يقدم CloudM نموذجين للنشر. نسخة SaaS (CloudM Migrate المستضاف) تعمل بالكامل في بنية CloudM التحتية. نسخة الاستضافة الذاتية تتيح نشر خوادم ترحيل أولية وثانوية على شبكتك الخاصة، أو Google Cloud، أو Azure، أو AWS.

بعض مزودي الخدمات المدارة يفترضون أن خيار الاستضافة الذاتية يمنح تحكما أكبر في معالجة التواريخ لأنك تدير خوادم الترحيل مباشرة. لا يمنح ذلك. مشكلة التواريخ تحدث في خادم الوجهة، ليس في عقد معالجة CloudM. سواء كانت مزرعة الترحيل الخاصة بك تعمل في سحابة CloudM أو في Azure VM الخاص بك، يظل خادم البريد الوجهة يختم تاريخ الترحيل على كل رسالة يستقبلها.

يقدم CloudM أيضا "Serviced Migration" المدارة بالكامل حيث يتولى فريقهم المشروع من البداية إلى النهاية. نفس النتيجة للتواريخ. الهندسة متطابقة، فقط الأيدي على لوحة المفاتيح مختلفة.

تعقيد رأس Date غير الصالح

هناك سلوك آخر خاص بـ CloudM يزيد الأمور سوءا. عندما يواجه CloudM بريدا إلكترونيا مصدريا برأس Date: لا يتوافق مع RFC 822 (منطقة زمنية بتنسيق خاطئ، يوم الأسبوع مفقود، تنسيق غير قياسي)، يعدل الرأس لضمان إمكانية ترحيل الرسالة.

هذا يعني أن بعض الرسائل تفقد حتى مرجع تاريخها الأصلي. قد لا يتطابق رأس Date: المعدل مع تاريخ الإرسال الفعلي على الإطلاق. وثائق دعم CloudM تذكر هذا كسلوك معروف تحت "التغييرات المحتملة على العناصر المرحلة" لكن لا تحدد ما يصبح عليه التاريخ المعدل.

بالنسبة لصندوق بريد يحتوي على 12,000 رسالة متراكمة على مدى ثماني سنوات، قد يكون لديك مئات الرسائل برؤوس Date غير قياسية قليلا (خاصة رسائل من خوادم بريد أقدم، أنظمة آلية، أو مرسلين دوليين مع اختلافات في تنسيق المنطقة الزمنية). بعد تعديل CloudM وإعادة كتابة رأس Received من قبل خادم الوجهة، تنتهي هذه الرسائل بتواريخ لا علاقة لها بالواقع.

لماذا لا تنجح الإصلاحات اليدوية على نطاق واسع بعد CloudM

هل يمكنك إصلاح هذا بنفسك؟ تقنيا، رأس Date: الأصلي لا يزال مضمنا في معظم الرسائل (باستثناء تلك التي عدلها CloudM للتوافق مع RFC). بعض المسؤولين حاولوا كتابة نصوص برمجية لتصحيح التواريخ بعد ترحيل CloudM.

واقع هذا النهج كالتالي. تحتاج إلى الاتصال بآلاف صناديق البريد المحتملة، كل منها يحتوي على آلاف الرسائل. لكل بريد إلكتروني، تحتاج إلى تحليل سلسلة الرؤوس الكاملة، تحديد أي رؤوس Received: أضافها CloudM أو خادم الوجهة، معالجة الحالات الحدية (رسائل S/MIME الموقعة حيث تعديل الرأس يكسر التوقيع، محتوى PGP المشفر، هياكل MIME متعددة الأجزاء مع حدود متداخلة، رؤوس RFC 2047 المشفرة غير ASCII من مرسلين يابانيين أو كوريين)، وكل ذلك دون فقدان مرفق واحد أو كسر سلسلة البريد الإلكتروني.

نص برمجي يعمل على 50 بريدا تجريبيا من صندوق بريد نظيف لن يصمد أمام بيئة إنتاج تحتوي على 40,000 رسالة تمتد على عقد. ماذا يحدث عندما تصادف بريدا بحجم 47 ميغابايت مع ستة مرفقات متداخلة؟ ماذا عن حدود معدل API (250 وحدة حصة من Google لكل مستخدم في الثانية، تقييد Microsoft عند حوالي 10,000 طلب لكل 10 دقائق)؟ ما خطة التراجع عندما يحدث خطأ في الرسالة رقم 8,347؟

والسؤال الحقيقي الذي لا يطرحه معظم المسؤولين حتى فوات الأوان: كيف تتحقق من أن كل رسالة مصححة سليمة فعلا؟

إصلاح تواريخ ترحيل CloudM باستخدام Redate.io

يتصل Redate.io مباشرة بصناديق البريد المتأثرة (Google Workspace أو Microsoft 365 أو IMAP) ويفحص الرسائل التي تحمل بصمة تاريخ ترحيل CloudM. الفحص مجاني ويستغرق دقيقتين لكل صندوق بريد، ويعرض العدد الدقيق للرسائل المتأثرة قبل أي التزام.

يستخدم التصحيح محرك تحليل سلسلة رؤوس خاصا يحدد أنماط ترحيل CloudM المحددة في سلسلة رؤوس Received. يجري Redate.io تصحيح بيانات وصفية مستهدفا دون تغيير محتوى الرسالة، محافظا على المرفقات والسلاسل والتسميات والمجلدات والتوقيعات الرقمية. كل رسالة مصححة تمر بتحقق فردي، يتحقق من سلامة الرسالة مقارنة بالأصل قبل أن تتقدم العملية.

تحفظ الرسائل الأصلية في مجلد نسخ احتياطي مرئي Redate.io - Originals لمدة 30 يوما. إذا احتاج أي شيء للتراجع، فالأصول موجودة هناك في صندوق البريد، ليست مدفونة في أرشيف خارجي.

لمزودي الخدمات المدارة الذين استخدموا CloudM في بيئات العملاء، يتعامل Redate.io مع تصحيحات صناديق بريد متعددة بنفس التحقق لكل رسالة سواء كنت تصلح صندوق بريد واحدا أو 500. مشكلة التواريخ التي تركها CloudM لا يجب أن تصبح سمة دائمة في بيئة بريد عميلك.

أدلة خاصة بالمنصة لعمليات ترحيل CloudM

تتكيف عملية التصحيح مع المنصة الوجهة. يتعامل Redate.io مع خصائص كل منصة تلقائيا، لكن لتفاصيل إعدادك:

• إصلاح تواريخ ترحيل CloudM في Gmail
• إصلاح تواريخ ترحيل CloudM في Outlook
• إصلاح تواريخ ترحيل CloudM في Google Workspace
• إصلاح تواريخ ترحيل CloudM في Microsoft 365

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

هل قمت بالترحيل باستخدام CloudM وبقيت مع تواريخ خاطئة على كل بريد إلكتروني؟ ابدأ فحصا مجانيا لمعرفة عدد الرسائل المتأثرة وتكلفة إصلاحها بدقة.