English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
إصلاح تواريخ ترحيل GSMMO في Gmail
لماذا يفسد ترحيل GSMMO تواريخ البريد في Gmail
يرفع GSMMO (Google Workspace Migration for Microsoft Outlook) الرسائل من ملفات PST أو ملفات تعريف Outlook مباشرة إلى Gmail عبر Gmail API. أثناء الرفع يسجل Gmail الطابع الزمني للرفع كـ INTERNALDATE لكل رسالة. يحفظ رأس Date من نص الرسالة لكن بيانات التاريخ الوصفية على مستوى الخادم تستبدل بتاريخ الترحيل.
ينشئ هذا وضعا خادعا. تقرأ واجهة Gmail على الويب رأس Date من نص الرسالة لتاريخ العرض فتبدو معظم الرسائل بالتاريخ الصحيح في المتصفح. يبدو كل شيء سليما. لكن تحت السطح فإن IMAP INTERNALDATE المخزن على خوادم Google خاطئ. متى يهم هذا؟ في اللحظة التي يصل فيها أي شخص إلى صندوق البريد عبر عميل IMAP - سواء Outlook أو Thunderbird أو Apple Mail - أو عندما تستعلم أداة نسخ احتياطي أو نظام امتثال أو حل أرشفة من صندوق البريد عبر IMAP.
يستخدم GSMMO عادة من المستخدمين النهائيين الذين ينتقلون من Microsoft Outlook إلى Google Workspace باتباع توثيق Google الرسمي للترحيل. قد يمر أسابيع أو أشهر دون أن يلاحظ هؤلاء المستخدمون المشكلة لأنهم يستخدمون واجهة Gmail على الويب بشكل أساسي. ثم يوما ما يجري فريق الامتثال بحثا مبنيا على التاريخ عبر Google Vault أو يهيئ قسم تقنية المعلومات MailStore للأرشفة أو يثبت المستخدم Outlook متصلا بـ Gmail عبر IMAP. فجأة تعرض 40,000 رسالة نفس التاريخ من ستة أشهر مضت. بحلول ذلك الوقت يبدو الترحيل وكأنه تاريخ قديم ويصبح تشخيص السبب الجذري لغزا.
كيف يؤثر INTERNALDATE الخاطئ على مستخدمي Gmail
بالنسبة لمستخدمي Gmail على الويب يكون التأثير المرئي ضئيلا بشكل خادع. تبدو التواريخ صحيحة في المتصفح. لكن INTERNALDATE التالف قنبلة موقوتة تحت السطح. يستخدم أمر IMAP SEARCH DATE في Gmail قيمة INTERNALDATE فأي أداة تعتمد على IMAP تجري عمليات بحث بالتاريخ ضد صندوق البريد تحصل على نتائج غير صحيحة. أدوات النسخ الاحتياطي مثل MailStore وVeeam أو سكريبتات Python المخصصة التي تؤرشف Gmail عبر IMAP تسجل التواريخ الخاطئة. تلك النسخ الاحتياطية؟ غير دقيقة بشكل دائم.
هل جربت ترتيب 50,000 رسالة تتشارك جميعها نفس تاريخ الاستقبال؟ هذا ما يختبره أي عميل IMAP متصل بصندوق بريد مرحل بـ GSMMO. يقرأ Outlook وApple Mail وThunderbird جميعها INTERNALDATE للترتيب والعرض. قد تشير عمليات تصدير Google Takeout إلى INTERNALDATE لتسمية الملفات والبيانات الوصفية مما ينشئ هياكل أرشيف مربكة. حتى عمليات البحث في Google Vault للامتثال يمكن أن تعيد نتائج مضللة عندما لا يتطابق INTERNALDATE مع تاريخ البريد الفعلي.
يحل Redate.io هذا من خلال خط معالجة متعدد المراحل لتحليل الرؤوس يحدد بصمات ترحيل GSMMO ويجري إعادة بناء بيانات التاريخ الوصفية على مستوى الخادم. تحافظ العملية على جميع محتويات الرسائل والتصنيفات والمرفقات مع تصحيح بيانات التاريخ الوصفية فقط. يتم التحقق من كل رسالة بشكل فردي بعد المعالجة.
الأسئلة الشائعة
إذا كانت واجهة Gmail على الويب تعرض التاريخ الصحيح فلماذا نصلح INTERNALDATE؟
يؤثر INTERNALDATE على كل عميل IMAP وأداة نسخ احتياطي وبحث امتثال في Google Vault وتكامل من جهات خارجية يتصل عبر IMAP. حتى لو كان عرض Gmail على الويب صحيحا فإن بيانات الخادم الأساسية خاطئة وستسبب مشاكل في بيئات النسخ الاحتياطي والامتثال والعملاء المتعددين.
هل يغير Redate.io طريقة ظهور الرسائل في واجهة Gmail على الويب؟
لا. تعرض واجهة Gmail على الويب بالفعل التاريخ الصحيح من رأس Date. يصحح Redate.io INTERNALDATE حتى تعرض عملاء IMAP والأدوات الخارجية أيضا التاريخ الصحيح. تبقى تجربة Gmail على الويب متطابقة.
هل يمكن لـ Redate.io إصلاح التواريخ لمستخدم واحد أم يتطلب وصولا على مستوى النطاق؟
يعمل Redate.io على مستوى الحساب الفردي. يمكن لمستخدم Google Workspace واحد توصيل حسابه وإصلاح تواريخه دون الحاجة لصلاحيات المسؤول على مستوى النطاق. يمكن للمسؤولين أيضا معالجة حسابات متعددة إذا لزم الأمر.
ماذا يحدث للرسائل الأصلية أثناء عملية الإصلاح؟
ينقل Redate.io الرسائل الأصلية إلى تصنيف نسخ احتياطي مخصص داخل Gmail قبل تطبيق التصحيحات. هذا يعني أن كل رسالة أصلية محفوظة ويمكن الوصول إليها. إذا احتجت للتراجع في أي وقت يمكن لـ Redate.io استعادة النسخ الأصلية من تصنيف النسخ الاحتياطي.