رسائلك القديمة كلها بنفس التاريخ: ماذا حدث؟

الأعراض: رسائلك القديمة كلها مجمّعة تحت نفس التاريخ

تفتح Outlook أو Gmail أو Apple Mail ذات صباح. شيء ما لا يبدو صحيحا. مئات بل آلاف الرسائل القديمة تحمل نفس التاريخ: تاريخ قبل أيام أو أسابيع قليلة. رسائل من عام 2021، من 2019، من 2016، تظهر كأنها وصلت بالأمس. الترتيب الزمني لم يعد يعني شيئا. تبحث عن رسالة مهمة من العام الماضي فتجدها مدفونة وسط آلاف الرسائل التي تبدو كأنها وصلت كلها في يوم واحد.

الرسائل الجديدة تعرض تواريخ صحيحة. الأمر يمس فقط الرسائل القديمة.

ما الذي حدث بالضبط؟

رد الفعل الأول: اتهام البرنامج

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

تُضيع ساعتين في تجربة كل شيء. المشكلة لا تزال قائمة.

في الواقع، SCANPST هي أداة لإصلاح ملفات بيانات Outlook المحلية. قد تُصلح بعض تلف الملفات، لكنها لا تمس البيانات المخزّنة على خادم البريد. بعبارة أخرى، حتى لو أصلحت ملف OST بشكل مثالي، ستبقى التواريخ خاطئة، لأن المشكلة ليست عندك.

المشكلة في الرسائل ذاتها، على الخادم.

ما الذي حدث فعلا: عملية ترحيل

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

ربما لم تُبلَّغ بذلك. أو عرفت لكنك لم تربط الأمر بمشكلة التواريخ. هذا أمر مفهوم تماما.

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

وهنا تكمن جوهر المشكلة.

كيف يقرر تطبيق البريد أي تاريخ يعرضه

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

(إن سبق لك الضغط على "عرض المصدر" أو "عرض الرؤوس الكاملة" لرسالة ما، ربما رأيت تلك الأسطر الغامضة التي تبدو كتلة نص غير مفهومة. هذا هو بالضبط ما نتحدث عنه.)

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

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

النتيجة: 8000 رسالة تبدو كأنها وصلت كلها في نفس ذلك الثلاثاء من نوفمبر.

أي الأدوات تتسبب في هذه المشكلة؟

أدوات الترحيل الأكثر شيوعا تتصرف كلها بنفس هذه الطريقة. BitTitan MigrationWiz وCloudM وimapsync وGSMMO (الأداة المجانية من Google للترحيل من Outlook)، وغيرها الكثير. ليس هذا عيبا حقيقيا فيها: إنه نتيجة طبيعية لآلية عمل بروتوكول البريد الإلكتروني. هذه الأدوات تضيف هذا الرأس لأن البروتوكول يقتضي ذلك حين تنقل رسالة من خادم إلى آخر.

المشكلة أن أحدا لا يُنبّه المستخدمين بأن هذا سيحدث.

إن كانت شركتك قد غيّرت نظام البريد مؤخرا، أو أجرى قسم تقنية المعلومات "ترحيلا إلى السحابة"، فهذا على الأرجح هو مصدر المشكلة. يمكنك التحقق بالنظر في التواريخ المتأثرة: هل تتوافق جميعها مع نفس الفترة الزمنية تقريبا؟ إن كان الأمر كذلك، فتلك الفترة هي وقت الترحيل.

المسارات الخاطئة التي يجب تجنبها

بعض الحلول الشائعة في المنتديات التي لا تجدي نفعا:

إصلاح ملف البيانات باستخدام SCANPST

ذكرنا هذا سابقا: SCANPST تُصلح ملفات Outlook المحلية (ملفات .pst أو .ost المخزّنة على جهازك). لا تُعدّل الرسائل على الخادم. بعد الإصلاح، ستظل رسائلك تحمل نفس التواريخ الخاطئة، لأن هذه التواريخ موجودة في الرسائل ذاتها، ليس في الملف المحلي.

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

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

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

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

إعادة تثبيت تطبيق البريد

لا. الرسائل على الخادم وليس في التطبيق. إعادة تثبيت Outlook أو Gmail أو Apple Mail أو Thunderbird لا تُغيّر شيئا في البيانات المخزّنة عبر الإنترنت.

البشرى السارة: التواريخ الأصلية لا تزال موجودة

هذا أمر مهم يجب فهمه، وهو ما يجعل الإصلاح ممكنا: تاريخ إرسال كل رسالة لم يُحذف. لا يزال موجودا داخل الرسالة، في رأس يُسمى "Date:" يتوافق مع تاريخ الإرسال الذي اختاره المُرسل. هذا معيار بريدي (محدد في مواصفة تقنية تُسمى RFC 2822) تلتزم به جميع أدوات الترحيل، لأن تعديله يُعدّ انتهاكا صريحا للمعايير.

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

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

لماذا لا تحاول الإصلاح بنفسك؟

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

الرسالة الإلكترونية ليست ملف نص بسيط. قد تحتوي على مرفقات، توقيعات رقمية، محتوى مشفّر بصيغ معقدة. تعديل البيانات الوصفية لهذه الرسالة دون تفكيك بنيتها يستلزم معالجة عشرات الحالات الخاصة: الرسائل الموقّعة إلكترونيا (S/MIME)، الرسائل المشفّرة (PGP)، الترميزات غير المعيارية، البنى متعددة الأجزاء... سكريبت منزلي يعمل على 20 رسالة تجريبية لن يعمل بشكل صحيح على صندوق بريد إنتاجي يحتوي 15,000 رسالة. وإن حدث خطأ ما، كيف تتأكد أن لا رسالة تلفت أو ضاعت؟ مع سكريبت منزلي: مستحيل.

بدون آلية نسخ احتياطي والتحقق الفردي من كل رسالة، خطر الأضرار الجانبية حقيقي.

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

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

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

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

التسعير يعتمد على دفعة واحدة، حسب حجم الرسائل المراد إصلاحها. لا اشتراكات شهرية. تدفع مرة واحدة، وتنتهي المشكلة.

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