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: الأصلية التي تتبع مسار تسليم الرسالة.

تحدث المشكلة عند كتابة النسخة. تحتفظ الوجهة بالتاريخ الذي تحصل عليه: يحتفظ Microsoft 365 و Gmail بالتاريخ الأصلي عندما تحمله النسخة. وعندما لا تحمله، تحصل النسخة على لحظة الإدراج كتاريخ لها. وفي Google Workspace، تحصل كل رسالة تُكتب عبر Gmail API أيضا على رأس Received: جديد بتاريخ لحظة الإدراج.

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

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

رأس Date: الأصلي من عام 2019 لا يزال موجودا، وكذلك سلسلة Received: الأصلية. لكن في Microsoft 365، التاريخ الذي يعرضه Outlook كتاريخ استلام هو سجل صندوق البريد الخاص به لوقت وصول كل رسالة: إذا لم يمرر CloudM التاريخ الأصلي، فإن هذا السجل يقول 2 أبريل 2026.

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

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

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

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

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

بالنسبة لوجهات Microsoft 365، يهم الإعداد بدرجة أقل: يحتفظ Microsoft 365 بالتاريخ الذي يحصل عليه، فما يحدد التاريخ المعروض هو ما إذا كان CloudM يمرر تاريخ كل رسالة الأصلي.

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

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

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

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

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

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

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

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

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

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

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

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

لماذا لا تنجح الإصلاحات اليدوية على نطاق واسع بعد 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) ويفحص الرسائل التي لا يتطابق تاريخها المعروض مع تاريخها الأصلي. الفحص مجاني ويستغرق بضع دقائق لكل صندوق بريد، ويعرض العدد الدقيق للرسائل المتأثرة قبل أي التزام.

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

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

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

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

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

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

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

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