Outlook: تاريخ الاستلام IMAP مقابل تاريخ الإرسال

الأعراض التي يعرفها الجميع

انتهيت للتو من ترحيل IMAP إلى Microsoft 365 أو Google Workspace. صباح الاثنين، تبدأ التذاكر تتراكم: "كل رسائلي بنفس التاريخ"، "السجل التاريخي مكسور"، "لا أجد أي شيء في صندوق بريدي". تفتح Outlook، وفعلاً، آلاف الرسائل تعرض تاريخ نهاية الأسبوع الماضي. ليس تاريخ إرسالها الأصلي، بل تاريخ تنفيذ عملية الترحيل.

هذه ليست مشكلة في Outlook. هي نتيجة مباشرة لآلية عمل بروتوكول IMAP وأدوات الترحيل. لكن لفهم السبب، لا بد من فتح غطاء المحرك.

ثلاثة تواريخ في رسالة واحدة

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

رأس Date: وفق RFC 2822

هذا هو التاريخ الذي وضعه المُرسِل في رسالته لحظة الإرسال. محدد بموجب RFC 2822، ويبدو هكذا:

Date: Tue, 14 Mar 2023 09:42:17 +0100

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

رأس Received: (يُضاف عند كل محطة شبكية)

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

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

النتيجة: حين تنقل أداة ترحيل مثل BitTitan MigrationWiz أو CloudM أو imapsync أو GSMMO رسالةً من خادم المصدر إلى خادم الوجهة، فهي تتصرف هي الأخرى كـ"محطة شبكية". تحقن رأس Received: جديداً في قمة السلسلة، يحمل تاريخ ووقت الترحيل.

INTERNALDATE في IMAP

هذا هو التاريخ الثالث، وهو مصدر المشكلة. INTERNALDATE بيانات وصفية مخزنة على جانب خادم IMAP، مستقلة تماماً عن محتوى الرسالة. تمثل التاريخ الذي سُلِّمت فيه الرسالة (أو أُدرجت) في صندوق البريد. حين تُدرج أداة الترحيل رسالةً في الخادم، هي من تحدد قيمة INTERNALDATE. وفي كثير من الحالات، تستخدم الأدوات تاريخ لحظة الترحيل نفسه. ليس التاريخ الأصلي.

هنا يتعطل كل شيء.

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

يستخدم Outlook قيمة INTERNALDATE لعرض عمود "مُستلَم". هذا سلوكه الافتراضي، وهو متسق مع مواصفات IMAP: من المفترض أن تمثل INTERNALDATE تاريخ الاستلام في صندوق البريد. في سير العمل الطبيعي (رسالة حقيقية تصل فعلاً)، تكون INTERNALDATE قريبة من التاريخ في رأس Date:. القيمتان متوافقتان.

بعد ترحيل فاشل، تشير INTERNALDATE لجميع الرسائل المستوردة إلى ليلة 14-15 يونيو 2024 (أو أياً كان تاريخ الترحيل). يقرأ Outlook هذه القيمة، يعرضها في عمود "مُستلَم"، والنتيجة كارثية: 45,000 رسالة تبدو وكأنها وصلت في نفس الليلة.

للدقة، رأس Received: الأول (الأحدث في السلسلة) يؤثر هو الآخر على العرض في بعض الإعدادات. لكن INTERNALDATE تبقى المحدد الرئيسي لعمود "مُستلَم" في Outlook بوضع IMAP المتزامن.

الحل المؤقت: إضافة عمود "المُرسَل" في Outlook

أول ما يفعله معظم مديري تقنية المعلومات حين يكتشفون المشكلة هو البحث عن حل مؤقت على جانب العميل. وفعلاً يوجد حل كهذا.

في Outlook، يمكن تعديل عرض الأعمدة في أي مجلد لاستبدال عمود "مُستلَم" بعمود "التاريخ" أو "المُرسَل" (أو إضافته بجانبه). عمود "التاريخ" يقرأ مباشرة من رأس Date: في الرسالة، لا من INTERNALDATE. وبما أن رأس Date: لم يمسّه الترحيل، تعود التواريخ الأصلية للظهور.

للقيام بذلك في Outlook (سطح المكتب، إصدار Microsoft 365): انقر بالزر الأيمن على رأس العمود في قائمة الرسائل، ثم "إعدادات العرض"، ثم عدّل الأعمدة لإزالة "مُستلَم" وإضافة "التاريخ". يمكن تطبيق ذلك عبر GPO للنشر الجماعي.

حسناً. من الناحية النظرية، هذا يحل المشكلة البصرية. في الواقع، هو ضمادة على جرح عميق.

الحدود الفعلية لهذا الحل المؤقت

عملاء الجوال والويب

Outlook على iOS و Android و Outlook Web App (OWA) لا تملك نفس خيارات التخصيص. تعديل العرض الذي نشرته على أجهزة Windows لا ينتقل إليها. مستخدموك الذين يتحققون من بريدهم على هواتفهم لا يزالون يرون تاريخ الترحيل. وفي شركة متوسطة الحجم، هؤلاء على الأرجح نصف المستخدمين.

البحث

بحث Outlook يستخدم فهرس Windows Search (أو فهرس Exchange/Microsoft 365 على جانب الخادم). هذا الفهرس مبني على أساس INTERNALDATE، لا رأس Date:. إن بحث مستخدم عن "رسائل يناير 2022"، يُرجع البحث الرسائل التي تكون INTERNALDATE فيها في يناير 2022. ليس تلك التي يكون رأس Date: فيها في يناير 2022. النتيجة: الرسائل القديمة لا تظهر في مرشحات التاريخ. تغيير عمود العرض لا يغير شيئاً في هذا.

قواعد البريد الإلكتروني

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

الامتثال والـ eDiscovery

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

الأدوات الخارجية

أنظمة CRM، وأدوات تذاكر الدعم، والأرشيفات... كل ما يتصل بخادم البريد عبر IMAP أو واجهات API لـ Microsoft 365/Google Workspace يقرأ INTERNALDATE. تغيير عرض Outlook لا يصحح شيئاً لهذه الأنظمة.

الحل الحقيقي الوحيد: التصحيح على مستوى الخادم

الترتيب حسب تاريخ الإرسال في Outlook ليس حلاً. هو ضمادة. التصحيح الفعلي يجب أن يتم على مستوى البيانات الوصفية في الخادم، لا على مستوى العرض في العميل.

عملياً، هذا يعني تصحيح INTERNALDATE لكل رسالة بحيث تطابق التاريخ الأصلي في رأس Date:. رأس Date: الأصلي موجود دائماً في الرسالة (لم يمحُه الترحيل)، وهذا ما يجعل التصحيح ممكناً. فيه تكمن معلومات التاريخ الحقيقي.

على Google Workspace، تكشف Gmail API معامل internalDate الذي يتيح التعامل المباشر مع هذه البيانات الوصفية. على Microsoft 365، الآلية مختلفة لكن النتيجة المطلوبة واحدة. وعلى خادم IMAP قياسي، تتيح المعيار تحديد التاريخ عند إدراج رسالة.

في الواقع، تنفيذ هذه العملية على عشرات الآلاف من الرسائل في بيئة إنتاج، دون فقدان بيانات، ودون تكرار، ودون كسر سلاسل المحادثات أو التصنيفات، مع معالجة الحالات الحدية (الرسائل الموقعة بـ S/MIME، وهياكل MIME المعقدة، والترميزات غير ASCII وفق RFC 2047، والمرفقات الضخمة)... هذا شأن مختلف تماماً. سكريبت يعمل على 50 رسالة اختبارية لن يصمد أمام صندوق بريد فيه 40,000 رسالة. معالجة أخطاء 429 (تجاوز حصة API)، والمهلات الشبكية في الثانية صباحاً، والرسائل التي تلفت بنيتها MIME جزئياً أثناء الترحيل... كل ذلك يتطلب هندسة متخصصة جدية.

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

تحديد أداة الترحيل المسؤولة

المشكلة تظهر بنفس الأعراض بصرف النظر عن مصدر الترحيل، لكن التفاصيل تختلف بحسب الأداة المستخدمة. BitTitan MigrationWiz وCloudM وimapsync وGSMMO لكل منها بصمتها الخاصة في رؤوس Received: التي تحقنها. خط تحليل Redate.io يحتفظ بقاعدة مطابقة لمئات من بصمات أدوات الترحيل المعروفة، للتمييز بين رأس الترحيل وبقية سلسلة العبور الشرعية.

إن كنت لا تعرف أي أداة استُخدمت في الترحيل (يحدث هذا، خاصة حين تتسلم بنية تحتية من مزود MSP آخر)، يحدد الفحص المجاني في Redate.io صناديق البريد المتأثرة ويقدم تقديراً لحجم الرسائل التي تحتاج تصحيحاً قبل أي التزام.

لسياقات محددة، راجع الأدلة التفصيلية: إصلاح تواريخ imapsync في Outlook، أو إصلاح تواريخ BitTitan في Outlook، أو إصلاح تواريخ CloudM في Outlook.

ماذا تفعل الآن

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

يمكنك أيضاً قراءة مقال IMAP INTERNALDATE: لماذا تتلف التواريخ للتعمق في آلية المشكلة، أو الدليل الشامل حول التواريخ الخاطئة في Outlook بعد الترحيل للحصول على نظرة شاملة على مختلف الحالات.

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