Outlook الجديد: تواريخ خاطئة بعد الترحيل

تطبيقان مختلفان، سلوكان مختلفان أمام نفس الرسائل

إذا أجريت مؤخرا ترحيل صناديق بريد إلى Microsoft 365 وبدأ المستخدمون يشكون من أن كل رسائلهم القديمة تحمل نفس التاريخ (تاريخ الترحيل)، فربما لاحظت شيئا غريبا: المستخدمون الذين يعملون على Outlook الكلاسيكي يرون أحيانا التاريخ الصحيح في جزء القراءة، بينما أولئك على Outlook الجديد لنظام Windows يرون تاريخ الترحيل بشكل منتظم. نفس صندوق البريد. نفس الرسائل. نتائج مختلفة.

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

INTERNALDATE في IMAP: الجاني الحقيقي

حين تُخزَّن رسالة على خادم IMAP، تحمل نوعين من التواريخ يتعايشان دون أن يختلطا.

الأول هو رأس Date: المُعرَّف بموجب RFC 2822. هذا هو التاريخ المكتوب في الرسالة نفسها، الذي وضعه المُرسل لحظة إرسال البريد. يشكل جزءا من جسم الرسالة ولا يتغير أبدا بصرف النظر عن المسار الذي تسلكه الرسالة لاحقا.

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

(بالمناسبة، إذا سبق لك الاطلاع على سجلات imapsync أو MigrationWiz، ستعرف أن هناك خيارات محددة للمحاولة في الحفاظ على INTERNALDATE. هذه الخيارات لا تنجح دائما، وبعض خوادم الوجهة ترفض تنفيذها.)

Outlook الكلاسيكي: كيف يقرأ التواريخ

Outlook الكلاسيكي، أي الإصدارات المُثبَّتة محليا (Outlook 2016 و2019 و2021 وعميل سطح المكتب Microsoft 365 Apps)، يستخدم آلية أكثر تعقيدا لتحديد التاريخ الذي يعرضه في قائمة الرسائل.

للرسائل في مجلد المُرسَل، يعتمد على رأس Date:. للرسائل المُستلَمة، يُعطي الأولوية لـ INTERNALDATE من الخادم، لكن في سياقات معينة (لا سيما حين يكون التخزين المؤقت OST متورطا، أو عند أول عرض في جزء القراءة)، يمكنه أيضا قراءة سلسلة رؤوس Received: لإعادة بناء تاريخ أصلي تقريبي.

هذا هو السبب في ملاحظة هذا السلوك غير المتسق: Outlook الكلاسيكي قد يعرض أحيانا التاريخ الصحيح في جزء القراءة، لأنه يقرأ رأس Date: الأصلي من الرسالة للمعاينة التفصيلية، حتى لو كانت قائمة الرسائل ذاتها تستخدم INTERNALDATE التالف. لكن احذر، هذا ليس موثوقا، ولا يُصلح شيئا. يبقى الترتيب معطوبا، وتبقى البحوث بالتاريخ مُشوَّهة.

Outlook الجديد: معمارية مختلفة جذريا

Outlook الجديد لنظام Windows، الذي يُنشَر تدريجيا منذ أواخر 2023، لم يعد تطبيقا يعتمد على COM. إنه في جوهره تطبيق ويب تقدمي (PWA) مبني على نفس قاعدة الشيفرة التي يستخدمها Outlook على الويب (OWA). هذا التغيير الجذري له تداعيات بعيدة الأثر.

Outlook الجديد يُفوِّض عرض التواريخ كليا إلى API الخاصة بـ Microsoft 365. لا يقرأ رؤوس Received:، ولا يتعمق في سلسلة الرؤوس للعثور على تاريخ أصلي، ولا يُجري أي محاولة لإعادة البناء من جانب العميل. يعرض ببساطة ما يُرجعه الخادم: INTERNALDATE.

النتيجة: إذا تلف INTERNALDATE أثناء الترحيل، فـ Outlook الجديد لا يتردد. يعرض تاريخ الترحيل لكل رسالة متأثرة، دون استثناء، دون تمييز. هذا سلوك أكثر اتساقا وقابلية للتنبؤ مقارنة بـ Outlook الكلاسيكي، لكنه يجعل مشكلة الترحيل مرئية فورا ومستحيلة التجاهل.

مسؤول النظام الذي يُرحِّل 300 صندوق بريد ليلة الجمعة سيكتشف صباح الاثنين أن كل المستخدمين على Outlook الجديد يرون أرشيفاتهم بأكملها مؤرخة بنهاية الأسبوع الماضي. التذاكر تنهال بسرعة.

لماذا لا تجدي أي حلول جانبية من طرف العميل

كثير من مسؤولي النظام يجربون حلولا من جانب العميل قبل أن يدركوا أن المشكلة في بيانات الخادم. إليك المحاولات الشائعة، ولماذا تفشل.

الترتيب حسب "تاريخ الإرسال" بدلا من "تاريخ الاستقبال"

الترتيب حسب تاريخ الإرسال في Outlook يعتمد على رأس Date: للرسالة، الذي يبقى سليما. إذن، نعم، هذا الترتيب قد ينجح. لكنه لصقة جرح، لا حل. تبقى البحوث بالتاريخ معطوبة. تبقى القواعد المبنية على التاريخ غير قابلة للاستخدام. والأهم، يجب على المستخدم إعادة ضبط كل مجلد وكل صندوق بريد يدويا. على 300 صندوق، هذا غير واقعي. الترتيب حسب تاريخ الإرسال ليس حلا، والمستخدمون النهائيون لا يفهمون لماذا يُطلب منهم تغيير عاداتهم.

تفريغ ذاكرة التخزين المؤقت أو إعادة إنشاء ملف التعريف

هذا لا يمس INTERNALDATE على جانب الخادم. بعد إعادة إنشاء ملف التعريف، يُزامن Outlook الرسائل من الخادم من جديد ويسترجع بالضبط نفس البيانات الوصفية التالفة. التخزين المؤقت ليس المشكلة.

استخدام OWA بديلا

OWA وOutlook الجديد يشتركان في نفس قاعدة البيانات. إذا تلف INTERNALDATE على خادم Exchange Online، تعرض OWA بالضبط نفس التاريخ الخاطئ. تغيير العميل لا يغير البيانات.

المشكلة في الخادم، في البيانات الوصفية لكل رسالة. لا يمكن لأي إجراء من جانب العميل تصحيح بيانات مخزنة على جانب الخادم.

فخ رؤوس Received: لماذا تُعقِّد الأمور

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

تتراكم هذه الرؤوس بترتيب عكسي لمسار الرسالة. الأحدث في الأعلى. بعض عملاء البريد يقرؤون أول Received: لتقدير تاريخ الاستقبال، مما يعطي تاريخ الترحيل بدلا من التاريخ الأصلي.

في الواقع، هذا السلوك ليس حكرا على أداة بعينها. BitTitan MigrationWiz وCloudM وimapsync وGSMMO، وحتى نسخ IMAP يدوية بين عميلَي Thunderbird، كلها تُفضي إلى هذه النتيجة. رأس Date: الأصلي يبقى سليما في الرسالة. هذا بالضبط ما يجعل التصحيح ممكنا تقنيا. أما INTERNALDATE، فهي بيانات وصفية مستقلة يديرها الخادم ولا يمكن تصحيحها بمجرد التلاعب برؤوس الرسالة من جانب العميل.

للتعمق في هذه الآلية، تتناول مقالة IMAP INTERNALDATE والتواريخ التالفة بالتفصيل كيفية إدارة هذه البيانات الوصفية حسب الخوادم المختلفة.

أي أدوات الترحيل تسبب هذه المشكلة على Microsoft 365

السؤال يتكرر دائما: هل كل أدوات الترحيل تُحدث هذه المشكلة؟

الجواب المختصر: يعتمد على الإعداد وعلى منصة الوجهة. على Exchange Online / Microsoft 365، الخادم صارم بشكل خاص في إدارة INTERNALDATE. حتى الأدوات التي تحاول الحفاظ عليه تفشل أحيانا، لأن Graph API وEWS (Exchange Web Services) يتصرفان بشكل مختلف حسب مسار الإدراج المُستخدَم.

BitTitan MigrationWiz هو من أكثر الأدوات انتشارا للترحيل نحو Microsoft 365، وهو أيضا من أكثرها توثيقا لمشكلات التواريخ. صفحة إصلاح تواريخ BitTitan في Microsoft 365 تغطي الإعدادات المحددة الواجب مراقبتها. لـ CloudM وimapsync خصوصياتهما الموثقة على التوالي في صفحتَي إصلاح تواريخ CloudM في Microsoft 365 وإصلاح تواريخ imapsync في Microsoft 365.

ما هو مشترك بين كل هذه الأدوات: رأس Date: الأصلي ينجو من الترحيل. هذا هو الأساس الذي يجعل التصحيح ممكنا.

لماذا السكريبت محلي الصنع فكرة سيئة هنا

فهم المشكلة قد يوحي أحيانا بأن الحل بسيط. عمليا، ليس كذلك، لا على نطاق الإنتاج الفعلي.

تعديل البيانات الوصفية لرسائل مخزنة على Exchange Online أمر ليس بالهيّن. تفرض Microsoft Graph API حدودا صارمة على معدل الطلبات (خطأ 429 Too Many Requests في دفعة ليلية يأتي بسرعة). التعامل مع رسائل موقعة بـ S/MIME أو مُشفَّرة بـ PGP يتطلب عناية خاصة لعدم إبطال التوقيعات. الهياكل متعددة الأجزاء مع مرفقات ضخمة تُضيف قيودا على مهل الشبكة. والأهم: كيف تتحقق، رسالة بعد رسالة، أن التصحيح نجح دون المساس بالمحتوى أو المرفقات؟

سكريبت يعمل بشكل جيد على 50 رسالة تجريبية لن يتصرف بالطريقة ذاتها على صندوق بريد يحتوي 40000 رسالة بسجل 8 سنوات. احتمال أن حالة طرفية تكسر شيئا ما يرتفع مع كل ألف رسالة إضافية. وبدون آلية تراجع، خطأ في منتصف الطريق يترك صندوق البريد في حالة غير متسقة.

انظر أيضا: إصلاح تواريخ رسائل البريد بعد ترحيل Microsoft 365 للاطلاع على نظرة شاملة للخيارات المتاحة.

ما تفعله Redate.io بالتحديد

يسجّل كل مستخدم دخوله بحساب Microsoft الخاص به، فتفتح Redate.io علبة بريده بصلاحيات ذلك الدخول، دون بوابة إدارية ودون تطبيق يُسجَّل، تفحص الرسائل ذات التواريخ الخاطئة مجانا، ثم تُطبِّق محرك تصحيح خاص على الرسائل المُحدَّدة. يُنجز خط أنابيب التحليل متعدد المراحل مطابقة عبر مئات التوقيعات المعروفة لأدوات الترحيل، مع التحقق من الامتثال لـ RFC، وتحليل سلسلة الرؤوس لإعادة بناء البيانات الوصفية للتاريخ الصحيح.

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

يعرض Outlook الجديد عندها التواريخ الصحيحة، لأن بيانات الخادم مُصحَّحة، لا مُخفاة.

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