ترحيل Google Workspace إلى Google Workspace: تواريخ مكسورة

السيناريو الذي لا يتوقعه أحد

لقد أنهيت للتو ترحيل مستأجر Google Workspace إلى آخر. استحواذ على شركة، تغيير نطاق، أو دمج كيانين كانا يعملان تحت حسابي G Suite منفصلين لسنوات. سارت العملية بسلاسة، صناديق البريد في مكانها، المستخدمون يسجلون الدخول. صباح الاثنين، أول تذكرة دعم: "كل رسائلي تحمل نفس التاريخ." ثم تذكرة ثانية. ثم عشر.

بشكل تلقائي، تفكر: هذه حتماً مشكلة في IMAP، أداة مهيأة بشكل خاطئ، شيء غريب. ليس ترحيلاً من Google إلى Google. ومع ذلك، هذا بالضبط ما يحدث.

هذا السيناريو على الأرجح الأقل توثيقاً في القطاع. معظم مدراء IT الذين يصطدمون به يضيعون ساعات في البحث عن تفسير في جانب عميل البريد، أو Outlook، أو إعدادات الحساب، قبل أن يدركوا أن المشكلة كامنة في رؤوس الرسائل الإلكترونية نفسها.

لماذا يكسر الترحيل من Google إلى Google التواريخ؟

لفهم ما يحدث، لا بد من العودة إلى آلية رؤوس البريد الإلكتروني. كل رسالة RFC 2822 تحتوي على حقل Date: أصلي، يضعه العميل أو الخادم المرسل لحظة الإرسال. هذا هو التاريخ "الحقيقي" للبريد الإلكتروني، أي التوقيت الذي كُتبت فيه الرسالة وأُرسلت.

لكن ثمة آلية أخرى: INTERNALDATE في بروتوكول IMAP. هذه بيانات وصفية مخزنة على جانب الخادم تشير إلى متى أُودع الرسالة في صندوق البريد. وهنا تصبح الأمور مثيرة للاهتمام.

حين تنقل أداة ترحيل بريداً إلكترونياً من مستأجر Google Workspace إلى آخر، تمر عبر بروتوكول IMAP (حتى لو كان الخادمان في البنية التحتية لـ Google). تُقرأ الرسالة من المصدر، ثم تُعاد إدراجها في الوجهة. في لحظة إعادة الإدراج هذه، يضيف خادم الوجهة تلقائياً رأس Received: يحمل توقيت العملية، أي تاريخ الترحيل.

ومشكلة ذلك أن عملاء البريد مثل Outlook يستخدمون أول Received: في السلسلة لعرض تاريخ الرسالة، لا حقل Date: الأصلي بالضرورة. النتيجة: جميع الرسائل تعرض تاريخ يوم الترحيل.

أي الأدوات تُسبب المشكلة؟

تقريباً كل الأدوات المستخدمة لترحيل بين مستأجري Google Workspace متأثرة. لا استثناءات تُذكر:

• GSMMO (Google Workspace Migration for Microsoft Outlook): صُمم أصلاً للترحيل من Exchange، لكنه يُستخدم في بعض سيناريوهات الترحيل من GWS إلى GWS.
• CloudM Migrate: منتشر جداً لدى مزودي الخدمات المُدارة في ترحيلات Google البينية، يضيف رأس Received: للترحيل بشكل منهجي. راجع التحليل التفصيلي لـ CloudM.
• BitTitan MigrationWiz: نفس الأمر، السلوك موثق في هذا المقال حول BitTitan.
• imapsync: الأداة مفتوحة المصدر التي تتيح برمجة عمليات ترحيل IMAP، بما فيها بين مستأجرين على Google.
• التصدير والاستيراد اليدوي عبر Takeout + إعادة الاستيراد بـ IMAP: أقل شيوعاً، لكنه ينتج الأثر ذاته بالضبط.

السبب بسيط: كل هذه الأدوات تعمل كعملاء IMAP عاديين. لا تملك وصولاً إلى مسار "أصلي" من Google يحافظ على البيانات الوصفية. حتى لو كان المستأجران كلاهما على Google، يمر النقل عبر طبقة IMAP، وهذه الطبقة لا "تعرف" أنها تتحدث إلى نفسها.

آلية رؤوس Received بالتفصيل

(بالمناسبة، إن كنت قد حاولت يوماً قراءة الرؤوس الخام لبريد إلكتروني من Gmail أو Outlook، فأنت تعرف أن ذلك ليس بالضبط قراءة مريحة. لكن هناك تكمن الحقيقة كاملة.)

البريد الإلكتروني الذي سلك مساره الطبيعي يحتوي على سلسلة من رؤوس Received: بترتيب عكسي للمسار: آخر خادم لمس الرسالة يظهر في الأعلى. بعد الترحيل، يجد رأس الترحيل نفسه في قمة هذه السلسلة.

هكذا تبدو رسالة مُرحَّلة عبر CloudM من مستأجر GWS إلى آخر:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

حقل Date: يقول 2019. أول Received: يقول أكتوبر 2024. Outlook يقرأ أول Received:. يرى المستخدم أكتوبر 2024 لبريد من عام 2019.

حقل Date: الأصلي سليم تماماً. لم يتحرك. هذه هي البشرى الجيدة: البيانات موجودة، تنتظر فقط أن تُستخدم بشكل صحيح.

Outlook وGmail لا يتصرفان بنفس الطريقة

هذه نقطة تستحق التوضيح. المستخدمون الذين يصلون إلى بريدهم عبر واجهة Gmail على الويب يرون في الغالب التواريخ الصحيحة، لأن Gmail يستخدم حقل Date: وفق RFC 2822 أولاً لعرض الرسائل. المشكلة أقل ظهوراً على جانب الويب.

في المقابل، المستخدمون الذين يهيئون صناديق Google Workspace في Outlook عبر IMAP (أو عبر مزامنة Exchange ActiveSync) يعانون التاريخ الخاطئ بشكل كامل، لأن Outlook يعتمد على INTERNALDATE في IMAP، الذي يعكس تاريخ أول Received: المضاف أثناء الترحيل.

لأكون دقيقاً، سلوك Outlook يختلف بحسب الإصدار وطريقة الاتصال. Outlook 2019 وMicrosoft 365 (الإصدارات الحديثة) يستخدمان INTERNALDATE عند الاتصال بـ IMAP. الإصدارات الأقدم قد تتصرف بشكل مختلف قليلاً. لكن في جميع الحالات التي رُصدت في بيئات الإنتاج، أفرز الترحيل من GWS إلى GWS عبر IMAP تواريخ خاطئة في Outlook.

نتيجة لذلك، في المؤسسات التي رحّلت إلى مستأجر جديد وما زالت تضم مستخدمين هجينين (بعضهم على Gmail على الويب، وآخرون على Outlook)، تكون تذاكر الدعم الواردة غير متسقة. تقضي فرق IT وقتاً في محاولة فهم سبب "تأثر بعضهم دون الآخرين"، بينما الجواب ببساطة: الفارق يصنعه عميل البريد.

الاستحواذات والاندماجات وتغييرات النطاقات: الحالات الأكثر شيوعاً

هذا النوع من الترحيل ليس استثنائياً. إليك السيناريوهات التي تُولّد أكبر عدد من التذاكر:

الاستحواذ على شركة

شركة مستحوذ عليها كانت تمتلك مستأجر Google Workspace خاصاً بها (نطاق @old-company.com). بعد الاستحواذ، يجب ترحيل كل شيء إلى مستأجر الشركة الأم (@group.com). 250 صندوق بريد، الأرشيفات، 8 سنوات من تاريخ المراسلات. يُستدعى BitTitan أو CloudM للعملية. النتيجة: 2.4 مليون بريد إلكتروني يحمل تاريخ عطلة نهاية الأسبوع التي جرى فيها الترحيل.

تغيير النطاق

شركة غيّرت هويتها تنتقل من @old-name.com إلى @new-name.com. نفس بنية Google التحتية، لكن إنشاء مستأجر جديد للبدء بشكل نظيف (خيار شائع لتجنب بقايا الإعدادات القديمة). ترحيل صناديق البريد عبر imapsync أو GSMMO. التواريخ تنكسر بالطريقة ذاتها تماماً.

دمج الفروع

مجموعة تضم 4 فروع، كل منها على مستأجر G Suite قديم خاص به، تقرر دمج الكل في مستأجر موحد. أربع عمليات ترحيل بالتوازي، وأربع دفعات من الرسائل بتواريخ فاسدة تنتظر المعالجة.

في هذه السيناريوهات الثلاثة، المشكلة واحدة والحل واحد. قائمة فحص ترحيل البريد تتيح استباق هذا النوع من المشاكل قبل الشروع في الترحيل.

لماذا سكريبت منزلي الصنع ليس الحل؟

فهم المشكلة شيء. القول لنفسك "سأكتب سكريبت Python ينظف الرؤوس" وتطبيقه على 30,000 رسالة في بيئة إنتاج، شيء آخر تماماً.

الحالات الاستثنائية كثيرة جداً. سكريبت يعمل جيداً على 50 رسالة اختبار في بيئة نظيفة سيواجه حتماً، في صندوق بريد إنتاجي حقيقي:

• رسائل بـ توقيعات S/MIME أو محتوى مشفر بـ PGP، حيث أي تعديل على بنية الرسالة يُبطل التوقيع التشفيري.
• رسائل ببنى MIME متداخلة معقدة (multipart/alternative داخل multipart/mixed مع مرفقات تزيد على عشرات الميغابايتات).
• رؤوس مُرمَّزة وفق RFC 2047 (أحرف غير ASCII)، يلتهمها المُحلل اللغوي المُهيأ بشكل خاطئ صامتاً.
• أخطاء 429 Too Many Requests من واجهة Google البرمجية في الساعتين صباحاً، في منتصف دفعة التصحيح، مما يترك العملية في حالة غير محددة.
• رسائل تكون فيها سلسلة Received: غامضة: أدوات ترحيل متعاقبة أضاف كل منها رأسه الخاص، وليس من السهل تحديد أيها يجب إزالته.

والسؤال الأهم: كيف تتحقق، رسالة بعد رسالة، من أن كل رسالة مُصحَّحة سليمة وأن شيئاً لم يُفقد أو يتلف؟ السكريبت المنزلي عادةً لا يُجري هذا التحقق. Redate.io يُجريه تلقائياً، مع الاحتفاظ بالأصول في مجلد احتياطي مرئي مدة 30 يوماً.

ما الذي يفعله Redate.io في هذا النوع من الترحيل؟

Redate.io يتصل بمستأجر Google Workspace الوجهة (عبر تفويض النطاق، دون تدخل يدوي صندوقاً بصندوق) ويمسح الرسائل لتحديد تلك التي تحمل بيانات تاريخية وصفية غير متسقة مع محتوى الرسالة. مرحلة المسح هذه مجانية وتعطيك صورة دقيقة عن حجم المشكلة قبل أي تصحيح.

يُحلل محرك التصحيح الخاص بـ Redate.io بعد ذلك سلسلة رؤوس كل رسالة، ويُجري مطابقة نماذج على التوقيعات المعروفة لأدوات الترحيل (BitTitan وCloudM وimapsync وGSMMO وغيرها الأقل شيوعاً)، وينفذ تصحيحاً مستهدفاً للبيانات الوصفية دون تغيير محتوى الرسالة. كل رسالة مُصحَّحة يُتحقق منها فردياً. الأصول تُحفظ.

لعمليات الترحيل البيني بين مستأجري Google Workspace تحديداً، يتعامل محرك المعالجة مع الحالات التي جرت فيها عدة جولات ترحيل (مثلاً، صندوق بريد رُحِّل مرة أولى في 2021 ثم مجدداً في 2024)، مما يستلزم فك تشابك طبقات متعددة من الرؤوس الزائدة.

يمكنك الاطلاع على دليل التصحيح المخصص CloudM إلى Google Workspace وBitTitan إلى Google Workspace للاطلاع على خطوات الاتصال لهذا النوع من الإعداد.

اكتشاف المشكلة قبل أن يشكو منها المستخدمون

أفضل وقت للكشف عن التواريخ الفاسدة هو مباشرة بعد الترحيل، قبل الإطلاق الرسمي. فحص سريع على عدد من صناديق البريد التجريبية عبر عميل IMAP كـ Thunderbird يُتيح مقارنة عرض التواريخ بما كان متوقعاً. إن بدت جميع الرسائل المُستوردة تحمل نفس التاريخ الحديث، فهذه العلامة الكاشفة للمشكلة.

لكن في الواقع، يُكتشف الأمر في الغالب بعد أسابيع من الترحيل، حين يبحث مستخدم عن عقد قديم ويدرك أن صندوق Gmail خاصته مرتب بشكل ممتاز... بحسب تاريخ الترحيل. آلاف الرسائل مكدسة بنفس التوقيت. البحث بالتاريخ لا يعمل. سلاسل المحادثات مختلطة. يبدو التاريخ كله قد اختفى.

لمزودي الخدمات المُدارة الذين يُدارون ترحيلات بين مستأجري Google Workspace بانتظام، إدراج مسح Redate.io في قائمة الفحص بعد الترحيل (قبل تسليم العمل للعميل) يُجنّب هذا النوع من المفاجآت.

أنهيت للتو الترحيل بين مستأجرين على Google Workspace وتواريخ رسائلك خاطئة؟ أطلق مسحاً مجانياً على Redate.io لقياس حجم المشكلة قبل أي تصحيح.