إعادة إنشاء ملف تعريف Outlook: لماذا تتغير التواريخ

إجراء الاستكشاف الذي يكسر التواريخ

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

حتى صباح اليوم التالي، حين يفتح المستخدم صندوقه البريدي ويكتشف أن 8 سنوات من المراسلات تحمل نفس التاريخ: اليوم.

هذا بالضبط نفس الأعراض التي تنتج عن ترحيل IMAP فاشل. وللأسباب ذاتها.

ما يحدث من الناحية التقنية

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

كل رسالة بريد إلكتروني تحتوي في رؤوسها وفق معيار RFC 2822 على حقل Date: يُشير إلى وقت إرسال الرسالة. هذا الحقل يكتبه عميل البريد الخاص بالمُرسِل لحظة الإرسال، ثم ينتقل كما هو عبر جميع الخوادم حتى يصل إلى صندوقك. لا يتغير أبداً. رسالة أُرسلت في 14 مارس 2019 الساعة 9:32 ستحتفظ دائماً بهذا الحقل سليماً، بصرف النظر عما يحدث لاحقاً.

أما INTERNALDATE في IMAP، فهو شيء مختلف تماماً. هو بيانات وصفية يديرها خادم البريد، مستقلة عن محتوى الرسالة. تُشير إلى متى "أُودعت" الرسالة في الصندوق. في الأحوال الطبيعية، حين تصل رسالة عبر SMTP، يسجّل الخادم وقت الاستلام كـINTERNALDATE. لذا فرسالة مستلمة في 14 مارس 2019 ستكون قيمة INTERNALDATE لها متسقة مع تاريخ إرسالها.

Outlook بشكل افتراضي يُرتّب الرسائل ويعرضها وفق INTERNALDATE الذي يُرسله خادم IMAP، لا وفق حقل Date: في الرسالة ذاتها. (بالمناسبة، إن سبق لك فتح خصائص رسالة في Outlook لرؤية رؤوسها الخام، تعرف أن ذلك ليس قراءة مريحة.)

ما يُطلقه حذف ملف OST

حين يستخدم Outlook حساب IMAP، يحتفظ بقاعدة بيانات محلية: ملف OST (جدول التخزين غير المتصل). هذا الملف هو نسخة محلية مطابقة للرسائل المخزّنة على الخادم، مع بياناتها الوصفية وحالات القراءة والفئات وغيرها.

حذف ملف OST يعني محو هذه النسخة المحلية. يضطر Outlook حينئذٍ لإعادة تنزيل كل شيء من خادم IMAP.

المشكلة؟ حين يُعيد Outlook تنزيل رسالة عبر IMAP، يستخدم أمر FETCH لاسترداد المحتوى. لكنه لا يستخدم دائماً أمر FETCH INTERNALDATE لاسترداد تاريخ IMAP الأصلي والاحتفاظ به. في بعض الإعدادات وإصدارات Outlook، يعيد العميل بناء فهرسه المحلي مستخدماً تاريخ إعادة التنزيل بدلاً من INTERNALDATE المخزّن على الخادم.

وهنا تُصبح جميع رسائل الصندوق مؤرّخة بيوم إعادة التحميل.

ليست جميع إصدارات Outlook تتصرف بالطريقة ذاتها

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

Outlook 2016 و2019 في وضع IMAP توثيق لسلوك إعادة بناء الفهرس بصورة خاطئة بعد حذف ذاكرة التخزين المؤقت. أما Outlook الجديد (المبني على الويب، المُطرح تدريجياً منذ نهاية 2023) فيتعامل مع التخزين المؤقت بطريقة مختلفة وقد يُنتج نتائج متفاوتة. Outlook عبر Exchange أو Microsoft 365 مع حساب مُهيَّأ في وضع Exchange أقل عرضة لهذه المشكلة تحديداً، لأن بروتوكول MAPI/Exchange يُدير المزامنة بطريقة تختلف عن IMAP.

لكن إن كان مستخدمك يعمل على حساب IMAP مُهيَّأ في Outlook الكلاسيكي، وأقدم فني على حذف ملف OST أو إعادة إنشاء ملف التعريف: الخطر حقيقي.

كيف تميّز هذه الحالة عن ترحيل حقيقي

مسؤول IT يتلقى تذاكر "تواريخ رسائلي خاطئة" بعد إعادة إنشاء ملف تعريف قد يعتقد خطأً أنها مشكلة ترحيل. إليك كيف تفرّق بين الحالتين.

حالة ترحيل IMAP

في ترحيل IMAP (BitTitan أو CloudM أو imapsync وغيرها)، تقوم الأداة بنسخ الرسائل من خادم إلى آخر. لكل رسالة مُنسوخة، تُنشئ إدخالاً جديداً على خادم الوجهة. إن لم تُحدّد الأداة صراحةً قيمة INTERNALDATE الأصلية، يُسجّل الخادم الوقت الحالي كـINTERNALDATE. علاوة على ذلك، تُضيف بعض الأدوات رأساً Received: بتاريخ الترحيل، مما يُفاقم المشكلة في بعض العملاء. يمكنك قراءة تفاصيل هذه الآلية في مقال IMAP INTERNALDATE: لماذا تتلف التواريخ.

حالة إعادة إنشاء ملف التعريف

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

للتأكد: سجّل دخولك إلى الصندوق عبر واجهة الويب (Gmail أو Outlook.com أو واجهة الاستضافة). إن كانت التواريخ المعروضة عبر الويب صحيحة، فالمشكلة محلية في Outlook فقط. وإن كانت التواريخ خاطئة أيضاً عبر الويب، فالمشكلة على مستوى الخادم (ترحيل أو تعديل لقيم INTERNALDATE على الخادم نفسه).

لماذا تبقى التواريخ الأصلية قابلة للاسترداد

الخبر الجيد: في كلتا الحالتين (ترحيل أو إعادة إنشاء ملف تعريف)، التواريخ الأصلية لم تُفقد.

حقل Date: وفق RFC 2822 جزء لا يتجزأ من الرسالة. هو ثابت كثبات نص الرسالة ومرفقاتها. رسالة أُرسلت عام 2017 تحتوي في نصّها الخام على شيء كهذا:

Date: Mon, 12 Jun 2017 14:23:41 +0200

هذا السطر موجود في الرسالة المخزّنة على الخادم. لم يُعدَّل. ما يعرضه Outlook بصورة خاطئة هو بيانات وصفية خارجة عن محتوى الرسالة.

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

فخّ إعادة الإنشاء "النظيفة"

لقد حللت للتو مشكلة مزامنة لدى مستخدم. Outlook يعمل، الرسائل الجديدة تصل. تغلق التذكرة.

بعد ثلاثة أيام، يتصل المستخدم مجدداً: يبحث عن رسالة من مورّد تعود للعام الماضي، لكن في Outlook تظهر جميع رسائل 2023 وكأنها مستلمة "أمس". لا يجد شيئاً. ربما أرشفت الأرشفة التلقائية رسائل حديثة بعد معاملتها كرسائل قديمة. ومديره يطلب منه محادثة بريدية من سبتمبر 2022 لتسوية نزاع.

هذا السيناريو يتكرر بانتظام. ليس لأن الفني أخطأ في عمله، بل لأن هذا السلوك في Outlook غير موثّق بشكل واضح في أدلة الاستكشاف المعتادة.

الحلول الوهمية التي لا تُجدي نفعاً

الترتيب حسب "تاريخ الإرسال" بدلاً من "تاريخ الاستلام" في Outlook هو أول ما يُجرّبه المستخدمون. ويبدو أنه ينجح... حتى يكتشفوا أن هذا الترتيب غير متاح في جميع المجلدات، ويختفي عند تغيير طريقة العرض، وأن التطبيقات الأخرى (الهاتف المحمول وواجهة الويب وقواعد الترتيب التلقائي) تواصل استخدام INTERNALDATE الخاطئ.

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

إعادة إنشاء ملف التعريف مرة ثانية؟ لن يتغير شيء إن كان Outlook يُعيد بناء ذاكرته بالتاريخ الحالي.

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

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

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

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

تُعالج العملية الحالات الحدّية التي تُخفق فيها السكريبتات المنزلية باستمرار: الرسائل الموقّعة بـS/MIME، والرسائل ذات ترميزات غير ASCII في الرؤوس (RFC 2047)، والهياكل متعددة الأجزاء المعقدة، ورؤوس Date: ذات المناطق الزمنية غير القياسية أو المشوّهة. سكريبت يعمل بشكل صحيح على 50 رسالة تجريبية في صندوق تطوير قد يُتلف 2000 رسالة بشكل لا رجعة فيه في بيئة إنتاج. لا توجد آلية تراجع أصلية في IMAP بمجرد استبدال رسالة دون نسخة احتياطية مسبقة.

للحالات المتعلقة بـOutlook تحديداً، صفحة التصحيح إصلاح تواريخ النسخ اليدوي عبر IMAP في Outlook تُفصّل خطوات توصيل صندوقك وإطلاق التحليل.

الوقاية من المشكلة في التدخلات القادمة

إن كنت فنياً أو مسؤول IT وتتدخل بانتظام على ملفات تعريف Outlook، بعض العادات تُجنّب هذا الموقف.

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

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

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