تواريخ بريد خاطئة بعد ترحيل Exchange Online

سيناريو الاثنين الصباحي الكلاسيكي

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

صباح الاثنين، تبدأ التذاكر تتوالى. "كل رسائلي مؤرخة بيوم الجمعة." "سجل صندوق الوارد لديّ أصبح عديم الفائدة." "رسائل قديمة اختفت." لم يختفِ شيء في الواقع: الرسائل موجودة، لكن Outlook يعرضها جميعاً بتاريخ الترحيل بدلاً من تاريخ الإرسال الأصلي. رسالة من عام 2019 تظهر بتاريخ الجمعة الماضي. النتيجة: يبدو الصندوق البريدي بأكمله وكأنه لا يحوي سوى رسائل حديثة.

هذه واحدة من أكثر مشكلات ترحيل IMAP إلى Exchange Online إحباطاً، وهي شبه غائبة من توثيق Microsoft.

لماذا يكسر الترحيل عبر مركز الإدارة التواريخ

عندما تستخدم مركز إدارة Exchange (EAC) لإعداد ترحيل IMAP من خادم محلي (Dovecot أو Courier أو Cyrus أو UW-IMAP أو غيرها)، يتصل Exchange Online بخادمك المصدر عبر IMAP، ويسترجع الرسائل، ثم يحقنها في صناديق الوجهة عبر خط الأنابيب الداخلي للنقل.

هنا تحديداً تنشأ المشكلة.

كل رسالة تعبر خط أنابيب النقل في Exchange تتلقى تلقائياً ترويسة Received: مختومة بالتوقيت. هذا سلوك معياري لخوادم SMTP وIMAP منذ عقود: كل خادم يلمس رسالة يضع عليها توقيعه الزمني. المشكلة أن Outlook (وبخاصة إصدارات Windows الحديثة) يستخدم أحدث ترويسة Received: كمرجع للعرض حين تكون البيانات الوصفية الأخرى غامضة.

ترويسة Date: الأصلية (التي تشير إلى وقت إرسال الرسالة فعلياً وفق RFC 2822) لا تزال موجودة في الرسالة. لم تُحذف. لكنها تجد نفسها "محجوبة" بهذه الترويسة Received: الجديدة التي أضافها Exchange أثناء الحقن.

في الوقت ذاته، يُضبط INTERNALDATE الخاص بـ IMAP (البيانات الوصفية التي تستخدمها خوادم IMAP لتأريخ الرسائل داخلياً والتي تتحكم في الترتيب في معظم العملاء) على تاريخ الحقن لا على التاريخ الأصلي للرسالة. لا يملك Exchange Online أي آلية أصيلة للحفاظ على INTERNALDATE من الخادم المصدر أثناء الترحيل بالدفعات عبر مركز الإدارة.

مركز الإدارة مقابل الأدوات الخارجية: فرق جوهري

يجب التمييز بين حالتين. مع أدوات مثل BitTitan MigrationWiz أو CloudM Migrate، المشكلة موجودة أيضاً، لكن هذه الأدوات تمتلك أحياناً خيارات تهيئة (موثقة جزئياً، مخفية في الإعدادات المتقدمة في الغالب) تحاول الحفاظ على بعض بيانات التاريخ الوصفية.

الترحيل الأصيل عبر مركز الإدارة لا يوفر أي خيار من هذا القبيل. Microsoft لا تعرض أي معامل للتحكم في الحفاظ على INTERNALDATE في خط أنابيب الترحيل بالدفعات. إنه صندوق أسود: تُعدّ الدفعة وتُطلقها، ويفعل Exchange ما يشاء داخلياً. وما يفعله دائماً هو تأريخ الرسائل بتاريخ حقنها.

(إن كنت قد جربت قراءة الترويسات الخام لرسالة مُرحَّلة عبر مركز الإدارة، فأنت تعرف أن حقل Received: الذي يضيفه Exchange مميز لا يُخطئ: يحتوي على مراجع لخوادم Microsoft الداخلية مثل *.protection.outlook.com أو *.prod.exchangelabs.com، مع توقيت زمني يتطابق تماماً مع نافذة الترحيل.)

لماذا لا يحل إعادة إنشاء الدفعة المشكلة

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

هذا منطقي. لكنه لا يجدي.

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

بعض المديرين يحاول أيضاً تغيير إعدادات الترتيب في Outlook ("ترتيب حسب تاريخ الإرسال" بدلاً من "تاريخ الاستقبال"). الترتيب حسب تاريخ الإرسال ليس حلاً. إنه ضمادة مؤقتة. ترويسة Date: وقيمة INTERNALDATE تبقيان خاطئتين للعملاء التي لا تتيح هذا الضبط، ولـ OWA، ولـ Outlook Mobile، ولأي تطبيق خارجي يصل إلى الصندوق عبر IMAP أو EWS.

ما يجري فعلياً في الترويسات

إليك مثالاً مبسطاً لما تحتويه رسالة بعد الترحيل عبر مركز الإدارة. الترويسة الأصلية:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@anciendomaine.fr
Subject: Rapport Q1 2019

بعد الترحيل، تتلقى الرسالة في مقدمة السلسلة شيئاً مثل:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

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

لنكن دقيقين: يتفاوت هذا السلوك قليلاً بين إصدارات Outlook. الإصدارات الصادرة بعد 2021 (ولا سيما Outlook الجديد لـ Windows المُطرح منذ أواخر 2023) أكثر عرضة لهذه المشكلة، إذ تعتمد بشكل أكبر على بيانات Exchange Graph الوصفية بدلاً من ترويسة Date: الخام. هذا يعني أن عمليات ترحيل لم تكن تسبب مشكلة ظاهرة مع Outlook 2016 قد تسبب مشكلة الآن مع Outlook الجديد.

من يتأثر فعلاً

خوادم IMAP المصدر الأكثر شيوعاً في هذا النوع من الترحيل هي Dovecot (المنتشر على نطاق واسع في بيئات Linux/cPanel) وCourier. كلاهما يكشف قيم INTERNALDATE عبر IMAP لا يحفظها مركز الإدارة. إن كنت تُرحِّل من خادم Exchange محلي إلى Exchange Online (ترحيل هجين أو cutover)، فالسلوك مختلف لأن Microsoft تستخدم بروتوكول نقل داخلي (MAPI/EWS) يحفظ البيانات الوصفية بشكل أفضل. المشكلة خاصة بالترحيل العام عبر IMAP من مركز الإدارة.

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

لماذا يُعدّ السكريبت المنزلي فكرة سيئة هنا

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

أولاً، الحالات الحدية. الرسائل الموقعة بـ S/MIME والرسائل المشفرة بـ PGP ذات بنية لا تتحمل تعديل الترويسات دون إبطال التوقيع. الرسائل متعددة الأجزاء من نوع multipart/alternative ذات حدود MIME مشوهة (شائعة على خوادم Courier القديمة) قد تتعرض للتلف من سكريبت يعدّل الرسالة دون إعادة بناء البنية بشكل صحيح. الترويسات غير ASCII المشفرة وفق RFC 2047 (أسماء المرسلين التي تحتوي على أحرف عربية أو يابانية مثلاً) مصدر كلاسيكي للأخطاء.

ثانياً، الحجم. سكريبت يعمل بسلاسة على 50 رسالة تجريبية في بيئة التطوير لا يُدير حدود معدل API الخاص بـ Exchange Online في الإنتاج. خطأ 429 Too Many Requests الساعة الثانية صباحاً أثناء دفعة من 8000 رسالة، دون آلية استئناف، يعني ليلة بيضاء وربما رسائل مكررة أو ضائعة.

والأهم: كيف تتحقق من أن كل رسالة مُصحَّحة سليمة؟ أن لا مرفق قُطع، وأن لا خيط نقاش كُسر، وأن التسميات والمجلدات محفوظة؟ دون آلية تحقق فردية، الأمر مجرد أمل أن كل شيء سار على ما يرام.

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

ما تفعله Redate.io بشكل مختلف

تتصل Redate.io بـ Exchange Online عبر واجهات برمجة Microsoft 365 (Azure Active Directory، صلاحيات التفويض على مستوى المستأجر) وتمسح الصناديق البريدية المعنية لتحديد الرسائل التي تضررت بيانات تاريخها الوصفية جراء الترحيل. خطوة المسح هذه مجانية وتعطي صورة دقيقة لحجم المشكلة: عدد الرسائل المتأثرة، والصناديق المعنية، ونطاق التواريخ التالفة.

يعالج محرك التصحيح الخاص بـ Redate.io كل رسالة بشكل فردي عبر خط أنابيب تحليل متعدد المراحل، يشمل مطابقة الأنماط على توقيعات أدوات الترحيل المعروفة (بما فيها خط أنابيب نقل Exchange Online)، والتحقق من الامتثال لمعايير RFC، وفحص سلامة البنية قبل التصحيح وبعده. الرسائل الموقعة بـ S/MIME، والهياكل MIME المعقدة، والترميزات غير المعيارية: كلها تعالج عبر مسارات معالجة مخصصة.

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

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

لعمليات الترحيل إلى Exchange Online تحديداً، تدعم Redate.io الاتصال عبر صلاحيات تطبيق Azure AD (دون الحاجة إلى إنشاء بيانات اعتماد فردية لكل صندوق)، مما يجعل معالجة مجموعات كبيرة من الصناديق أسهل بكثير في التنسيق لمدير تقنية المعلومات أو مزود الخدمة المُدارة.

إن كنت تُدير عدة عملاء تعرضوا لهذا النوع من الترحيل، راجع أيضاً الدليل الشامل لتصحيح التواريخ بعد ترحيل Microsoft 365 للاطلاع على نظرة عامة لمختلف السيناريوهات المشمولة.

الرسائل موجودة، والتواريخ الأصلية كذلك. أطلق مسحاً مجانياً على Redate.io لترى بالضبط عدد الرسائل المتأثرة في صناديق Exchange Online لديك، قبل أن تقرر ما ستفعله.