GSMMO ومشكلة التواريخ التي لا يحذرك منها أحد
Google Workspace Migration for Microsoft Outlook (GSMMO) هي أداة سطح المكتب التي تقدمها Google لترحيل ملفات PST وملفات تعريف Outlook وأرشيفات البريد الإلكتروني المحلية إلى Gmail. إنها مجانية ومدعومة رسميا، وهي مسار الترحيل الذي توصي به Google عند نقل فريق صغير أو عدد قليل من صناديق البريد الفردية من Outlook إلى Google Workspace.
الأداة تعمل. تصل رسائل البريد الإلكتروني إلى Gmail، ويتم ربط هيكل المجلدات بالتصنيفات، وتمر جهات الاتصال. لكن افتح Gmail بعد ذلك ورتب الرسائل حسب التاريخ. كل رسالة بريد إلكتروني تعرض تاريخ اليوم. ذلك العرض الذي أرسلته في يناير 2021؟ أصبح أبريل 2026. والفاتورة من محاسبك في مارس 2023؟ أبريل 2026 أيضا.
GSMMO لا يحذرك من أن هذا سيحدث. سجل الترحيل يعرض النجاح لكل رسالة. وثائق Google نفسها لا تذكر ذلك كقيد معروف. لا تكتشف الأمر إلا عندما يبحث أحد عن رسالة قديمة حسب نطاق تاريخ ويحصل على صفر نتائج.
كيف يرفع GSMMO بريدك الإلكتروني فعليا
يقرأ GSMMO الرسائل من ملف PST (أو مباشرة من ملف تعريف Outlook) ويرفعها إلى Gmail عبر واجهة برمجة تطبيقات Gmail (Gmail API)، وهذا ما تقوله ملاحظات إصدار الأداة الرسمية من Google. من هنا تنشأ مشكلة التواريخ، ومن المفيد فهم الآلية لأنها توضح لماذا لا يكون الحل بسيطا مثل "أعد الاستيراد فقط".
عندما يرفع GSMMO رسالة عبر واجهة برمجة تطبيقات Gmail، يضيف Gmail رأس Received: جديدا بتاريخ لحظة الرفع. وعندما لا يُمرَّر التاريخ الأصلي مع الرسالة، يتم تعيين INTERNALDATE، وهو الطابع الزمني الذي يستخدمه Gmail داخليا للفرز والعرض، على لحظة الرفع بدلا من تاريخ الإرسال الأصلي.
هذا ما تبدو عليه سلسلة الرؤوس بعد ترحيل GSMMO:
Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200
هل ترى رأس Date: الأصلي من سبتمبر 2019؟ لا يزال هناك، سليما. GSMMO لا يعدل محتوى الرسالة أو الرؤوس الأصلية. لكن Gmail يتجاهله لأغراض العرض ويستخدم INTERNALDATE بدلا منه، الذي يقول الآن أبريل 2026.
GSMMO مقابل أدوات الترحيل من جانب المشرف
هنا غالبا يبدأ الالتباس. لدى Google أدوات ترحيل متعددة، ولا تتصرف كلها بالطريقة نفسها.
GSMMO (تطبيق سطح المكتب) يعمل على جهاز المستخدم. يقرأ من Outlook أو من ملف PST ويرفع رسائل البريد الإلكتروني عبر واجهة برمجة تطبيقات Gmail. يحتاج المستخدم إلى حساب Google Workspace وإلى مكوّن GSMMO الإضافي مثبتا في Outlook. إنها أداة من جانب العميل.
Google Workspace Migration Service (أداة وحدة تحكم المشرف) هي أداة من جانب الخادم. يقوم المشرف بتكوينها في وحدة تحكم Google للمشرفين، ويوجهها إلى خادم Exchange أو إلى مستأجر Google Workspace آخر، ويجري الترحيل داخل بنية Google التحتية. لدى هذه الأداة معالجة أفضل قليلا للتواريخ في بعض التكوينات لأنها تستطيع تعيين INTERNALDATE بناء على البيانات الوصفية للمصدر. لكن "أفضل قليلا" لا تعني "موثوقة"، ويذكر كثير من المشرفين نفس مشكلة التواريخ مع هذه الأداة أيضا.
ما الفرق الجوهري؟ مع GSMMO، لا يوجد ذكاء من جانب الخادم يتخذ قرارات بشأن الحفاظ على التاريخ. كل رسالة يرفعها تحصل على نفس المعاملة، سواء كانت رسالة جديدة أو رسالة مؤرشفة عمرها 10 سنوات: رأس Received: بتاريخ يوم الرفع. لا أكثر.
لماذا لا يعمل الحفاظ على التواريخ في GSMMO
إذا نظرت إلى إعدادات GSMMO، فقد لاحظت أنه لا يوجد فعلا خيار "حافظ على التواريخ". هذا ليس سهوا. يعتمد GSMMO على كيفية تعامل Gmail مع الرسائل المرفوعة عبر واجهته البرمجية، ولا يمكنه تجاوز ذلك.
هذه هي سلسلة الأحداث التقنية:
- يقرأ GSMMO الرسالة من ملف PST، بما في ذلك طوابعها الزمنية الأصلية
- يرفع GSMMO بيانات الرسالة عبر واجهة برمجة تطبيقات Gmail
- يستقبل Gmail الرفع ويخزن الرسالة في صندوق البريد
- يضيف Gmail رأس
Received:جديدا بتاريخ لحظة الرفع (سطرgmailapi.google.comفي المثال أعلاه) - عندما لا يُمرَّر التاريخ الأصلي، يعيّن Gmail INTERNALDATE على الطابع الزمني للرفع
- تصل الرسالة إلى Gmail بتاريخ اليوم
الخطوتان 4 و5 هما الحاسمتان. يضيف Gmail هذا الرأس إلى كل رسالة ترفع عبر واجهته البرمجية، بغض النظر عما ترسله الأداة، ولا يملك GSMMO أي إعداد لتمرير التاريخ الأصلي أو الاحتفاظ به. والنتيجة أن جميع رسائلك القديمة تبدو كأنها وصلت اليوم.
حاول بعض المشرفين تشغيل GSMMO بإعدادات معينة لـ Google Workspace مفعّلة أو تعديل إعدادات ملف تعريف GSMMO. لا يؤثر أي من هذا على سلوك التاريخ. رأس Received: يضاف من جانب Google، ولا يغير أي تكوين من جانب العميل ذلك.
سيناريوهات GSMMO المحددة التي تفسد التواريخ
ليس كل ترحيل عبر GSMMO ينتهي بفوضى في التواريخ، مع أن معظمها ينتهي بذلك. وهنا حيث يهم الأمر:
- ملف PST إلى Gmail: التواريخ تتلف. هذه هي حالة استخدام GSMMO الأكثر شيوعا والأكثر تأثرا.
- ملف تعريف Outlook إلى Gmail: التواريخ تتلف. نفس رفع واجهة برمجة تطبيقات Gmail كما في استيراد PST.
- Exchange Online (Microsoft 365) إلى Gmail عبر GSMMO: التواريخ تتلف. يقرأ GSMMO من خادم Exchange ويرفع عبر واجهة برمجة تطبيقات Gmail.
- Exchange المحلي إلى Gmail عبر GSMMO: التواريخ تتلف. نفس الآلية.
- Gmail إلى Gmail (إعادة استيراد تصدير PST): التواريخ تتلف. حتى لو كانت الرسائل الأصلية تحمل تواريخ صحيحة في ملف PST، فإن إعادة الاستيراد تختمها من جديد.
النمط واضح. كل رسالة ترفع عبر واجهة برمجة تطبيقات Gmail تحصل على رأس Received: بتاريخ يوم الرفع. يستخدم GSMMO هذا المسار دائما.
ما يزيد الإحباط أن تقرير ترحيل GSMMO يعرض كل شيء على أنه نجح. لا تحذيرات بشأن التواريخ، لا أخطاء، لا علامات. سيتعين عليك مقارنة الطوابع الزمنية يدويا قبل الترحيل وبعده لاكتشاف ذلك، ولا يفعل معظم المشرفين ذلك حتى يشتكي مستخدم.
التأثير يتجاوز الفرز
التواريخ الخاطئة بعد ترحيل GSMMO تخلق مشاكل حقيقية تتجاوز صندوق بريد فوضوي.
تخيل أنك محاسب انتقل للتو إلى Google Workspace. تحتاج إلى العثور على جميع مراسلات العملاء من الربع الثالث لعام 2024 لأجل إقرار ضريبي. تبحث في Gmail حسب نطاق التاريخ: من يوليو إلى سبتمبر 2024. صفر نتائج. كل رسالة من تلك الفترة تعرض الآن تاريخ الترحيل، فلا يستطيع مرشح التاريخ في Gmail العثور عليها. تجد نفسك عالقا في التمرير عبر آلاف الرسائل أو البحث بكلمات مفتاحية على أمل أن تتذكر المصطلحات الصحيحة.
بالنسبة للقطاعات المنظمة، هذا أسوأ من كونه مجرد إزعاج. تُستخدم الطوابع الزمنية للرسائل كدليل قانوني. مستشار مالي يحتاج إلى إثبات أنه أرسل إفشاء قبل تاريخ معاملة معينة لا يستطيع ذلك عندما تعرض الرسالة أبريل 2026 بدلا من فبراير 2023. تعتمد عمليات تدقيق الامتثال بموجب SOX أو HIPAA على طوابع زمنية دقيقة للتواصل، والتواريخ الخاطئة تعني فشل التدقيق.
وهناك أيضا مشكلة تسلسل الرسائل. يجمع Gmail المحادثات حسب التاريخ والموضوع. عندما تعرض كل رسالة في سلسلة المحادثة نفس التاريخ، تصبح واجهة المحادثة مشوشة. تظهر الردود قبل الرسالة الأصلية. وينهار هيكل السلسلة بالكامل إلى كومة من الرسائل التي تحمل جميعها التاريخ نفسه.
إصلاح تواريخ GSMMO باستخدام Redate.io
الخبر السار: رأس Date: الأصلي لا يزال سليما داخل كل رسالة بريد مرحّلة. GSMMO لا يعدل محتوى الرسالة. التاريخ الصحيح موجود، لكن منطق العرض في Gmail يتجاهله لأن INTERNALDATE ورأس Received العلوي يشيران إلى تاريخ الترحيل.
يتصل Redate.io بصندوق بريد Google Workspace، ويفحص الرسائل المتأثرة بترحيل GSMMO، ويصحح البيانات الوصفية للتاريخ باستخدام محرك خاص لتحليل سلسلة الرؤوس وإعادة بناء التواريخ. لا يحتاج Redate إلى معرفة أي أداة قامت بالترحيل: فهو يجد الرسائل التي لا يتطابق تاريخها المعروض مع تاريخها الأصلي، ويصححها دون تغيير محتوى الرسالة أو المرفقات أو تسلسل المحادثة.
تخضع كل رسالة مصححة لتحقق فردي: سلامة الرسالة، الحفاظ على المرفقات، تطابق التصنيفات، واتساق تسلسل المحادثة. تبقى الرسائل الأصلية في مجلد نسخة احتياطية مرئي بعنوان Redate.io - Originals في صندوق بريدك الخاص إلى أن تحذفها بنفسك.
هل يمكنك إصلاح هذا بنفسك بسكربت؟ فهم المشكلة أمر، وتصحيح 12000 رسالة دون كسر توقيعات S/MIME، أو إتلاف أجزاء MIME المتداخلة، أو تشويه رؤوس مشفرة بمعيار RFC 2047 عبر صندوق بريد فعلي هو أمر آخر تماما. كيف تتعامل مع الرسالة التي تحمل مرفقا بحجم 38 ميغابايت وحدود MIME تالفة استوردها GSMMO ولكنها بقيت متماسكة بالكاد؟ كيف تتحقق من أن كل رسالة على حدة وصلت سليمة؟ سكربت ينجح مع 20 رسالة اختبارية في بيئة معملية لن يصمد أمام صندوق بريد حقيقي بثماني سنوات من المراسلات.
أدلة خاصة بالمنصة لـ GSMMO
بما أن GSMMO يرحّل إلى Google Workspace على وجه التحديد، يحدث الإصلاح على مستوى Gmail. لكن الرسائل المتأثرة تظهر عبر كل عميل بريد متصل بذلك حساب Gmail:
- إصلاح تواريخ ترحيل GSMMO في Gmail
- إصلاح تواريخ ترحيل GSMMO في Outlook (متصل بـ Google Workspace)
- إصلاح تواريخ ترحيل GSMMO في Apple Mail
هل رحّلت منذ شهور؟ رأس Date الأصلي لا يتدهور مع مرور الوقت. يمكن لـ Redate.io إصلاح الرسائل المتأثرة بـ GSMMO سواء حدث الترحيل الأسبوع الماضي أو قبل ثلاث سنوات.
ترحيل GSMMO ترك رسائلك بتواريخ خاطئة؟ ابدأ فحصا مجانيا لمعرفة العدد الدقيق للرسائل المتأثرة وتكلفة إصلاحها، قبل الالتزام بأي شيء.