إصلاح تواريخ ترحيل CloudM Migrate في Google Workspace

يعد CloudM Migrate من أكثر الأدوات شيوعا لنقل صناديق البريد إلى Google Workspace، خاصة من بيئات Exchange. أثناء الترحيل يرفع CloudM كل رسالة عبر Gmail API. المشكلة أن بنية بريد Google تضيف رأس Received خاصا بها على كل رسالة مرفوعة مختوما بالوقت الدقيق لحدوث الترحيل وليس تاريخ الإرسال أو الاستقبال الأصلي.

هنا يصبح الأمر غريبا. تقرأ واجهة Gmail على الويب رأس Date الأصلي لأغراض العرض فتبدو الرسائل صحيحة تماما في المتصفح. لكن كل عميل IMAP - سواء Outlook أو Apple Mail أو Thunderbird - يقرأ قيمة INTERNALDATE بدلا من ذلك. تعكس هذه القيمة الطابع الزمني للترحيل. فينتهي بك الأمر بواقع منقسم: نصف مستخدميك لا يبلغون عن أي مشكلة بينما يصر النصف الآخر على أن كل رسالة تعرض نفس التاريخ.

تخيل ما يفعله هذا ببلاغ دعم فني. يفتح المسؤول Gmail في المتصفح ويرى تواريخ صحيحة ويغلق البلاغ بـ "لا يمكن إعادة إنتاج المشكلة." في هذه الأثناء مستخدم Outlook يحدق في 47,000 رسالة مؤرخة جميعها بـ 15 مارس. هذا التباين بين Gmail على الويب وعملاء IMAP يجعل عمليات ترحيل CloudM إلى Google Workspace صعبة التشخيص بشكل خاص مما يؤخر الحل أسابيع في كثير من الأحيان.

يتجاوز الضرر مجرد إرباك المستخدمين. تشير أدوات إدارة Google Workspace إلى INTERNALDATE لتطبيق السياسات. سياسات الاحتفاظ المهيأة في لوحة إدارة Google وعمليات الحجز القانوني في Google Vault وحلول منع فقدان البيانات من جهات خارجية التي تتصل عبر IMAP - جميعها تعمل على الطابع الزمني للترحيل بدلا من التاريخ الحقيقي. رسالة من 2019 كان يجب حذفها وفق سياسة الاحتفاظ لمدة 3 سنوات؟ يظن Google Workspace أنها وصلت الشهر الماضي.

بالنسبة للمؤسسات في القطاعات المنظمة (الرعاية الصحية والمالية والقانون)، هذا ليس مجرد إزعاج. تنتج عمليات تدقيق الامتثال التي تعتمد على نطاقات تواريخ دقيقة للبريد نتائج غير موثوقة. وتستمر المشكلة إلى أجل غير مسمى - لا يوجد تصحيح تلقائي ولا انتهاء صلاحية ولا إصلاح ذاتي. كل عميل IMAP متصل بكل صندوق بريد Google Workspace متأثر سيستمر في عرض تواريخ خاطئة حتى تصحح البيانات الوصفية الأساسية على مستوى الخادم.