استضافة مشتركة إلى Microsoft 365: مشكلة التواريخ الخفية

المشكلة التي لم يخبرك أحد بها

أنهيت للتو ترحيل بريدك الإلكتروني من OVH أو Infomaniak أو Ionos أو o2switch إلى Microsoft 365. عمل مساعد الترحيل في EAC (Exchange Admin Center) طوال الليل، كل شيء يبدو على ما يرام، وصناديق البريد ممتلئة. صباح الاثنين، أول تذكرة دعم: "كل رسائلي القديمة تحمل تاريخ اليوم." ثم تذكرة ثانية. ثم عشر.

هذا ليس خطأ في Microsoft 365، وليس مصادفة. إنه نتيجة حتمية لترحيل IMAP. وفي حالة الاستضافة المشتركة، تكون المشكلة في الغالب أشد وطأة بمرتين مقارنة بالترحيل العادي. إليك السبب.

كيف يتعامل IMAP مع التواريخ (وأين تسوء الأمور)

كل رسالة مخزنة على خادم IMAP تمتلك نوعين مختلفين من بيانات التاريخ. الأول هو رأس Date: (المحدد بموجب RFC 2822)، الموجود داخل جسم الرسالة نفسها، ويشير إلى متى أُرسلت الرسالة أو استُلمت. الثاني هو INTERNALDATE، وهو بيانات وصفية على مستوى الخادم تحدد متى أُودعت الرسالة في صندوق البريد. وهذه القيمة هي التي يستخدمها برامج البريد كـ Outlook بشكل افتراضي لترتيب الرسائل وعرضها.

(بالمناسبة، إن حاولت يوماً قراءة رؤوس رسالة إلكترونية خام في EAC، فأنت تعرف أن الأمر يشبه قراءة وثيقة قانونية على الشاطئ. عشرون إلى ثلاثون سطراً من الرؤوس قبل الوصول إلى المحتوى.)

حين تنقل أداة ترحيل IMAP رسالة من صندوق إلى آخر، يجب عليها إعادة إنشاء هذا INTERNALDATE على الوجهة. بعض الأدوات تفعل ذلك بشكل صحيح. كثير منها لا يفعل، أو يفعل بقيود. وخادم الاستلام من جهته يحتفظ بما يُعطى له: حين تحمل النسخة تاريخها الأصلي، يحتفظ Exchange Online بذلك التاريخ. لذلك حين تخرج التواريخ خاطئة، فالأداة هي من يجب النظر إليها، لا Microsoft 365.

النتيجة: كل رسالة مرحَّلة تبدو كأنها "استُلمت" يوم الترحيل. لا يهم أنها تعود إلى عام 2019.

سيناريو التلف المزدوج: لماذا تزيد الاستضافة المشتركة الأمر سوءاً

هنا تصبح الأمور حقاً صعبة في حالة الترحيل من استضافات مشتركة كـ OVH وInfomaniak وGandi وIonos وo2switch.

تستخدم هذه الاستضافات في الغالب خوادم Postfix أو Dovecot أو cPanel مشتركة بإعدادات IMAP قياسية. كثير من الشركات الصغيرة والمتوسطة راكمت فيها سنوات من الرسائل، أحياناً منذ عام 2010 أو 2012. حين تقرر الانتقال إلى Microsoft 365، يجري الترحيل في الغالب على مرحلتين.

المرحلة الأولى: التلف الأول (قبل Microsoft 365 حتى)

في كثير من الحالات، مرت الرسائل بترحيل أول بالفعل. الشركة غيّرت مزود الاستضافة المشتركة مرة أو مرتين على مر السنين: من Gandi إلى OVH عام 2018، ثم من OVH إلى Infomaniak عام 2022، مثلاً. كل نقل IMAP كان يمكن أن يُعيد ضبط INTERNALDATE الأصلي على يوم النقل (كلما لم تُنقل الأداة التاريخ الأصلي)، وبعض الأدوات تترك أيضاً رؤوس ترحيل خاصة بها، مختومة بذلك التاريخ.

حين تصل الرسائل إلى Microsoft 365، تحمل إذن ندوباً قديمة. رأس Date: الأصلي لا يزال سليماً (إنه جزء من جسم الرسالة ولا أحد يمسه)، لكن بيانات التاريخ الوصفية تعطلت مرة أولى.

المرحلة الثانية: التلف الثاني عند الانتقال إلى Exchange Online

بعدها، تستوعب أداة ترحيل IMAP في EAC، أو أداة خارجية كـ BitTitan MigrationWiz في وضع IMAP، هذه الرسائل المتضررة أصلاً. وإذا كانت هذه الأداة أيضاً لا تنقل تاريخ كل رسالة الأصلي، يُدرج Exchange Online الرسالة تحت يوم النقل، وهذا هو "تاريخ الاستلام" الذي يعرضه Outlook في النهاية.

رسالة أُرسلت في مارس 2017 قد تحمل طبقتين من التواريخ الخاطئة: رؤوس ترحيل تركها النقل عام 2022، وتاريخ استلام من الترحيل إلى Microsoft 365 عام 2024. Outlook يعرض 2024. المستخدم يرى 2024. وهذا خطأ على مستويين.

في الواقع، لكي نكون دقيقين تماماً: Outlook يحدد تاريخ العرض من خلال مزيج بين INTERNALDATE الذي سجّله Exchange Online والرؤوس الموجودة. لكن كلما لم تُنقل أداة الترحيل التواريخ الأصلية، يضيف الانتقال إلى Exchange Online طبقة أخطاء جديدة فوق القديمة.

أدوات الترحيل والاستضافات: التركيبات الخطرة

بعض التركيبات تتكرر كثيراً في عمليات الترحيل من الاستضافة المشتركة:

• OVH / Infomaniak / Ionos + أداة IMAP في EAC: الأداة الأصلية من Microsoft مريحة، لكنها مشهورة بعدم الحفاظ على التواريخ بشكل صحيح في عمليات الترحيل الضخمة عبر IMAP.
• cPanel (o2switch, LWS, إلخ.) + BitTitan MigrationWiz في وضع IMAP: يضيف MigrationWiz في هذا الوضع رؤوس ترحيل خاصة به. النتيجة موثقة، ضمن ما هو موثق، في صفحة إصلاح تواريخ BitTitan في Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync أداة قوية، لكن تعاملها مع INTERNALDATE يعتمد على الإعداد. بدون الخيار المناسب، لا تُحفظ التواريخ. انظر أيضاً imapsync لم يحفظ التواريخ؟ كيفية إصلاحها.
• أي ترحيل يدوي بالسحب والإفلات في Outlook: إن نسخ أحدهم مجلدات كاملة بالسحب والإفلات بين حسابين مفتوحين في Outlook، أُعيد كتابة INTERNALDATE لكل رسالة بتاريخ النسخ. بلا استثناء.

القاسم المشترك: كل هذه الطرق تنتهي بـ Exchange Online ورسائل تاريخها المعروض في Outlook لا يتطابق مع أي واقع.

لماذا يُعد "الإصلاح الذاتي" فكرة خطيرة على نطاق واسع

فهم المشكلة أمر، وإصلاح 8,000 رسالة موزعة على 40 علبة بريد في Exchange Online، بهياكل مجلدات معقدة ورسائل موقعة بـ S/MIME ومرفقات كبيرة وسلاسل محادثات متداخلة، أمر آخر تماماً.

سكريبت PowerShell يبدو أنه يعمل على عشر رسائل تجريبية قد يفشل بصمت عند الرسالة رقم 4,237 بسبب حد MIME تالف أو رأس مشفر بصيغة RFC 2047 (تلك الصيغة =?UTF-8?B?...?= المستخدمة للأحرف غير ASCII في أسماء المرسلين). بدون تحقق من كل رسالة على حدة، لن تعرف. ستكون قد فقدت رسالة، ببساطة.

المخاطر الملموسة للإصلاح الذاتي في هذا النوع من الترحيل:

وفي عمليات ترحيل الاستضافة المشتركة على وجه التحديد، توجد طبقة صعوبة إضافية: تلك الرسائل تحمل عدة رؤوس Received: متراكمة، لا واحداً فقط. سكريبت بسيط يحذف "آخر Received:" لن يكفي. يجب تحليل سلسلة الرؤوس كاملة لتحديد أي رأس يخص أي ترحيل، وأيها يمثل فعلاً تاريخ الاستلام الأصلي.

ما الذي يفعله Redate.io بشكل مختلف

يسجل كل شخص الدخول بحساب Microsoft الخاص به، ويفتح Redate.io علبة البريد تلك بالصلاحية التي يمنحها ذلك الدخول. بلا بوابة، بلا تطبيق يُسجل. الفحص الأولي مجاني: يحدد Redate.io كل رسالة لا يتطابق تاريخها المعروض مع التاريخ الحقيقي، ويعطي عدداً دقيقاً لكل علبة بريد.

يعتمد الإصلاح على محرك خاص يقوم بتحليل سلسلة الرؤوس وإعادة بناء بيانات التاريخ الوصفية لكل رسالة على حدة، أيا كانت أداة الترحيل المستخدمة، حتى عند تراكم طبقات متعددة من التلف فوق بعضها. يُتحقَّق من كل رسالة مُصلحة بشكل فردي. تبقى النسخ الأصلية في مجلد نسخ احتياطي ظاهر داخل علبة بريدك الخاصة إلى أن تحذفها بنفسك.

وفي عمليات ترحيل الاستضافة المشتركة على وجه التحديد، تتعامل خطوط تحليل Redate.io متعددة المراحل بوضوح مع سيناريوهات التلف المضاعف: فهي لا تنظر فقط إلى آخر رأس Received:، بل تتتبع التاريخ الكامل لاستعادة تاريخ الاستلام الحقيقي. انظر أيضاً كيفية إصلاح تواريخ البريد بعد الترحيل إلى Microsoft 365 بشكل عام، والشرح التقني لـ IMAP INTERNALDATE ولماذا تتلف التواريخ.

قبل أو بعد الترحيل: لحظتان للتصرف

حالتان، نهجان.

لم تُرحّل بعد. خبر جيد: يمكن الحد من الضرر. بعض أدوات الترحيل (MigrationWiz في وضع Exchange، CloudM بالإعدادات الصحيحة) تحافظ على التواريخ بشكل أفضل من غيرها. لكن حتى في أفضل الحالات، فإن ترحيلاً من استضافة مشتركة بلا تاريخ نظيف سيترك آثاراً على الأرجح. خطط لفحص من Redate.io بعد الترحيل، قبل إعادة علب البريد إلى المستخدمين.

رحّلت بالفعل والتذاكر تتوالى. يُصلح Redate.io علب البريد الموجودة في Microsoft 365، بصرف النظر عن الوقت الذي مر منذ الترحيل. يعطي الفحص صورة دقيقة عن الحالة الحقيقية لكل علبة بريد قبل أي تدخل. راجع أيضاً قائمة فحص ترحيل البريد الإلكتروني لتجنب المشاكل نفسها في المرة القادمة.

رحّلت من OVH أو Infomaniak أو Ionos أو o2switch إلى Microsoft 365 والتواريخ خاطئة؟ أنشئ حساب Redate.io لفحص علب بريدك مجاناً ومعرفة مدى الضرر بدقة قبل اتخاذ أي قرار.