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

لماذا يفسد ترحيل CloudM تواريخ البريد في Gmail

يرفع CloudM Migrate (المعروف سابقا بـ Cloud Migrator) الرسائل إلى Google Workspace باستخدام Gmail API. أثناء الرفع، يسجل Gmail الطابع الزمني للإدراج كـ INTERNALDATE للرسالة. يبقى رأس Date الأصلي داخل نص الرسالة سليما. لكن INTERNALDATE - الحقل الذي تقرأه عملاء IMAP لتحديد تاريخ استقبال الرسالة - يستبدل بشكل دائم بتاريخ الترحيل.

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

"الترحيل نجح والتواريخ تبدو صحيحة." هذا ما تخبرك به لوحة تحكم CloudM. وهذا ما يخبرك به Gmail. لكن 60% من مستخدميك يتصلون عبر Outlook، وبالنسبة لهم انهار 14 شهرا من تاريخ البريد في يوم واحد.

لا تشير لوحة تحكم CloudM في لوحة إدارة Google (المسؤول > التطبيقات > تطبيقات Google Workspace Marketplace > CloudM Migrate) إلى هذه المشكلة. لا يوجد خطأ ولا تحذير ولا تقرير بعد الترحيل يذكر تلف INTERNALDATE. إنها مشكلة صامتة في جودة البيانات لا تظهر إلا عندما يشتكي المستخدمون.

كيف يؤثر ذلك على مستخدمي Gmail

يعتمد التأثير كليا على طريقة وصول المستخدمين إلى صناديق بريدهم. Gmail على الويب؟ يبدو طبيعيا. Outlook أو Apple Mail أو Thunderbird عبر IMAP؟ كل رسالة تعرض تاريخ الترحيل في عمود الاستقبال. هذا التناقض يولد بلاغات دعم محيرة ويجعل شرح المشكلة صعبا للمستخدمين غير التقنيين.

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

يصحح Redate.io هذا من خلال تحليل سلسلة الرؤوس وإعادة بناء بيانات التاريخ الوصفية مستهدفا فقط عناصر الترحيل المحقونة من CloudM. تبقى تجربة Gmail على الويب (التي كانت تعرض التواريخ بشكل صحيح أصلا) دون تغيير. تبدأ عملاء IMAP وGoogle Vault وأدوات النسخ الاحتياطي جميعها في قراءة التاريخ الأصلي. يتم التحقق من كل رسالة بشكل فردي قبل التصحيح وبعده لضمان عدم فقدان أي بيانات.

الأسئلة الشائعة

هل يفسد CloudM Migrate التواريخ دائما في Gmail؟

يرفع CloudM الرسائل عبر Gmail API الذي يضبط INTERNALDATE على الطابع الزمني للرفع. يحفظ رأس Date لذا تعرض واجهة Gmail على الويب عادة التاريخ الصحيح. لكن عملاء IMAP تعرض تاريخ الترحيل لأنها تقرأ INTERNALDATE. يصحح Redate.io INTERNALDATE ليطابق التاريخ الأصلي.

لماذا تبدو الرسائل صحيحة في Gmail لكنها خاطئة في Outlook بعد ترحيل CloudM؟

تستخدم واجهة Gmail على الويب رأس Date من نص الرسالة للعرض وهو ما يحافظ عليه CloudM. يستخدم Outlook وعملاء IMAP الأخرى IMAP INTERNALDATE الذي يضبط على تاريخ الترحيل أثناء الرفع. يصلح Redate.io INTERNALDATE حتى تتفق جميع العملاء على التاريخ الصحيح.

هل يمكن لـ Redate.io إصلاح تواريخ ترحيل CloudM عبر نطاق Google Workspace بأكمله؟

نعم. يستخدم Redate.io تفويضا على مستوى النطاق في Google Workspace عبر حساب خدمة مما يسمح للمسؤولين بمعالجة جميع صناديق البريد المتأثرة عبر المؤسسة دون الحاجة لبيانات اعتماد المستخدمين الفردية أو مشاركتهم.

هل سيؤثر الإصلاح على التصنيفات والمرفقات وبيانات البريد الأخرى؟

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

أدلة الإصلاح ذات الصلة

فحص مجاني