استيراد PST في Outlook: لماذا تتغير كل التواريخ إلى اليوم

الأعراض: كل رسائلك تحمل تاريخ اليوم

انتهيت للتو من استيراد ملف PST في Outlook. وصل شريط التقدم إلى 100%، وسارت الأمور بسلاسة ظاهرية. ثم تفتح صندوق الوارد... فتجد كل رسالة مستوردة تحمل تاريخ اليوم. رسالة من 2019، وأخرى من 2021، وأرشيف عمره خمس سنوات - كلها تحمل نفس التاريخ. تاريخ يوم الاستيراد.

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

PST المحلي و IMAP: عالمان مختلفان جذريا

قبل شرح سبب تعطل التواريخ، لا بد من فهم ما يمثله ملف PST من حيث إدارة التواريخ.

ملف PST (Personal Storage Table) هو تنسيق ملكي خاص بـ Microsoft. يخزن الرسائل مع بياناتها الكاملة: تاريخ الإرسال، تاريخ الاستلام، المرفقات، الفئات، ومؤشرات القراءة. هذه البيانات يديرها Outlook مباشرة، بمعزل عن أي بروتوكول بريد. حين تفتح ملف PST في Outlook دون اتصال بخادم، تأتي التواريخ المعروضة مباشرة من الحقول الداخلية لملف PST. حتى الآن، كل شيء طبيعي.

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

IMAP APPEND و INTERNALDATE: جوهر المشكلة

في IMAP، لكل رسالة مخزنة على الخادم نوعان من بيانات التاريخ:

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

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

حين تصل رسالة إلى الخادم بصورة اعتيادية، يحدد خادم البريد INTERNALDATE تلقائيا عند لحظة الاستلام بالضبط. النتيجة: التاريخ المعروض في Outlook يعكس فعلا وقت استلام الرسالة.

حين يستورد Outlook ملف PST إلى صندوق IMAP، يستخدم أمر IMAP APPEND لإرسال كل رسالة إلى الخادم. يتيح معيار IMAP تمرير INTERNALDATE صريح مع APPEND. لكن Outlook لا يفعل ذلك. يرسل الرسائل دون تحديد INTERNALDATE. فيطبق خادم IMAP، في غياب أي تعليمات، قاعدته الافتراضية: يضبط INTERNALDATE على الوقت الحالي، أي لحظة الاستيراد.

النتيجة: 8000 رسالة مستوردة، 8000 رسالة تحمل تاريخ اليوم.

لماذا يتصرف Outlook هكذا

هذا ليس إهمالا من Microsoft. بل هو خيار تصميمي بدا منطقيا في وقته: في حالة الاستخدام الأصلية لاستيراد PST، يقوم المستخدم بأرشفة الرسائل محليا ثم "يستوردها" إلى صندوقه الحالي. التاريخ الأهم للترتيب هو تاريخ الاستلام الأصلي... لكن Microsoft اختارت عدم نقل INTERNALDATE أثناء عملية الاستيراد.

لنكن دقيقين: هذا السلوك خاص باستيراد PST عبر المعالج الأصلي في Outlook (ملف > فتح وتصدير > استيراد/تصدير). طرق استيراد أخرى، كبعض الأدوات الخارجية أو عمليات الترحيل عبر مركز إدارة Exchange، قد تتصرف بشكل مختلف حسب طريقة تطبيقها لـ IMAP APPEND.

هذا السلوك معروف وموثق في منتديات Microsoft منذ سنوات. لم يتغير مع Outlook 2016، ولا مع Outlook 2019، ولا مع إصدارات Microsoft 365 الحالية. مستخدم يستورد ملف PST اليوم سيواجه نفس المشكلة التي واجهها من فعل ذلك عام 2015.

كيف يختلف هذا عن ترحيل IMAP الكلاسيكي

هنا يصبح الأمر مثيرا للاهتمام، لأن استيراد PST ينتج نتيجة مشابهة لـ ترحيل IMAP الكلاسيكي بتواريخ معطوبة، لكن بآلية مختلفة.

في ترحيل IMAP النموذجي، مثلا مع BitTitan MigrationWiz أو imapsync، تنتقل الرسائل من خادم IMAP مصدر إلى خادم IMAP وجهة. تسترجع أداة الترحيل الرسائل وتعيد حقنها عبر IMAP APPEND. بعض الأدوات تحافظ على INTERNALDATE بشكل صحيح، وبعضها لا. في جميع الحالات، تحمل الرسائل بالفعل ترويسة Received: تضم تاريخ الترحيل مضافة أثناء العملية، وهو ما قد يخل بالعرض في Outlook بمعزل عن INTERNALDATE.

مع استيراد PST، الآلية أبسط: لا توجد ترويسة Received: للترحيل مضافة (ملفات PST لا تمر عبر خادم بريد وسيط)، لكن INTERNALDATE ببساطة لا يُضبط على القيمة الصحيحة. النتيجة المرئية متطابقة، أما السبب الجذري فمختلف قليلا.

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

لماذا لا تحل خيارات عرض Outlook المشكلة

الرد المعتاد عند اكتشاف المشكلة هو البحث في إعدادات Outlook. وهناك فعلا خيار يبدو واعدا: إمكانية ترتيب الرسائل حسب "التاريخ" بدلا من "تاريخ الاستلام".

الترتيب حسب تاريخ الإرسال ليس حلا. إنه مسكن مؤقت.

إليك السبب: حتى لو غيرت الترتيب لعرض عمود "التاريخ" (الذي يقابل ترويسة Date: للرسالة، أي التاريخ الأصلي)، تبقى عدة مشاكل قائمة:

• بحث Outlook يُفهرس على أساس INTERNALDATE. البحث عن "رسائل يناير 2020" لن يُعيد رسائلك المستوردة من يناير 2020، لأن INTERNALDATE الخاصة بها يقول إنها ترجع إلى يوم الاستيراد.
• مجلدات "اليوم" و"هذا الأسبوع" و"هذا الشهر" في واجهة Outlook تعتمد على INTERNALDATE، لا على ترويسة Date:.
• في واجهات الويب (Outlook Web App، Gmail) وعلى العملاء المحمولين، يعتمد التاريخ المعروض وسلوك الترتيب في الغالب على INTERNALDATE الخادم.
• القواعد والفلاتر التلقائية المطبقة على تاريخ الاستلام لن تعمل بشكل صحيح.

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

إعادة المزامنة عبر OST لا تجدي هي الأخرى

محاولة كلاسيكية أخرى: حذف ذاكرة التخزين المؤقت OST وإجبار إعادة مزامنة كاملة من الخادم. الفكرة أن المشكلة ربما تأتي من الذاكرة المحلية لـ Outlook، لا من الخادم.

هذا مسار خاطئ. ملف OST هو ذاكرة تخزين مؤقت محلية تعكس حالة خادم IMAP. إذا كان INTERNALDATE مغلوطا على الخادم، سيكون مغلوطا في OST بعد إعادة المزامنة. حذف OST لا يغير البيانات المخزنة على خادم Exchange Online أو Google Workspace. الخادم هو مرجع الحقيقة.

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

مشكلة الحجم: رسالة واحدة بسيطة. 15000 رسالة قصة مختلفة تماما

من الناحية التقنية، إذا فهمت المشكلة، يمكنك تخيل كتابة سكريبت يتصفح صندوق البريد، يقرأ ترويسة Date: لكل رسالة، ويصحح INTERNALDATE وفقا لذلك. فهم المشكلة شيء. تصحيحها على 15000 رسالة دون أن تفقد رسالة واحدة شيء آخر تماما.

بعض حقائق الميدان:

• تفرض كل من Microsoft Graph API وGmail حدودا للطلبات (rate limits). سكريبت ساذج سيؤدي إلى أخطاء 429 Too Many Requests، ويتوقف في منتصف عملية التصحيح، ويتركك بصندوق بريد مصحح جزئيا دون أن تعرف أي الرسائل عولجت وأيها لم يُعالج.
• قد تحتوي بعض رسائل PST على ترويسات Date: مشوهة أو مفقودة. سكريبت لا يتعامل مع هذه الحالات الحدية قد يُفسد هذه الرسائل أو يتجاوزها صامتا.
• الرسائل الموقعة (S/MIME) أو المشفرة (PGP) لها قيود نزاهة إضافية. تعديل بياناتها الوصفية دون حذر قد يبطل التوقيع التشفيري.
• الهياكل متعددة الأجزاء (multipart/alternative) ذات حدود MIME المعقدة تتصرف أحيانا بشكل غير متوقع مع عمليات التعديل.
• لا توجد آلية للتراجع. إذا ساءت الأمور في منتصف المعالجة، كيف تعود إلى الحالة الأولى؟

سكريبت يعمل على 10 رسائل اختبارية لن يعمل على صندوق إنتاج يحتوي 50000 رسالة. العام الماضي، حاول أحد العملاء الذي لديه أرشيف PST بحجم 40 غيغابايت تصحيح ذلك بسكريبت Python وجده على Stack Overflow. النتيجة: 3000 رسالة مكررة، 200 رسالة بمرفقات تعذر الوصول إليها، وأسبوعان من التنظيف اليدوي.

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

Redate.io تحلل البيانات الوصفية لكل رسالة في صندوق البريد المستهدف، وتُحدد الرسائل ذات التواريخ الخاطئة (بما فيها تلك الناتجة عن استيراد PST)، وتطبق التصحيح عبر محركها الخاص. يقارن pipeline التحليل متعدد المراحل سلسلة الترويسات لكل رسالة، ويستخرج التاريخ الأصلي مع التحقق من توافقه مع RFC، ويجري تصحيحا موجها للبيانات الوصفية دون المساس بمحتوى الرسالة.

كل رسالة مصححة تخضع للتحقق بشكل فردي. تُحفظ الأصول في مجلد احتياطي مرئي لمدة 30 يوما قبل أي تعديل نهائي. التصحيح يعمل على المنصات الثلاث الرئيسية: Microsoft 365 (عبر Azure AD)، Google Workspace (عبر تفويض النطاق)، وIMAP مباشر لمزودي الاستضافة الكلاسيكيين.

الفحص الأولي مجاني. يتيح رؤية العدد الدقيق للرسائل المتأثرة وتوزيع التواريخ الخاطئة، قبل اتخاذ أي قرار.

اقرأ أيضا:

• إصلاح تواريخ الرسائل بعد ترحيل Microsoft 365
• Outlook: تاريخ الاستلام IMAP مقابل تاريخ الإرسال
• هل يمكن إصلاح تواريخ الرسائل بعد الترحيل؟

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