ترحيل iCloud إلى Office 365: تواريخ بريد خاطئة

سيناريو ترحيل يكسر التواريخ بشكل منهجي

لقد أنهيت للتو نقل بريدك من iCloud إلى Office 365. الرسائل موجودة، المجلدات في مكانها، كل شيء يبدو مثاليا. صباح الاثنين، تصلك أولى الشكاوى: "كل رسائلي القديمة تظهر بتاريخ اليوم." ثم شكوى ثانية. ثم عشر.

هذه ليست مشكلة معزولة. ترحيل البريد من iCloud Mail إلى Office 365 هو أحد أكثر السيناريوهات توثيقا من حيث تلف تواريخ الرسائل، لأسباب تقنية دقيقة مرتبطة في آن واحد بسلوك Apple Mail وبروتوكول IMAP وطريقة معالجة Microsoft 365 للرسائل الواردة.

لماذا يكسر الترحيل من iCloud إلى Office 365 التواريخ؟

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

حقل Date: (RFC 2822)

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

قيمة INTERNALDATE في بروتوكول IMAP

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

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

السلوك الخاص بـ Apple Mail

يستخدم Apple Mail أحيانا، عند مزامنة الرسائل من iCloud، تاريخ إنشاء الملف على الخادم كمرجع لقيمة INTERNALDATE. هذا ليس خطأ بالمعنى الصارم، بل تفسير لمواصفات IMAP يختلف عما تفعله برامج بريد أخرى. (بالمناسبة، إن سبق لك تتبع مشكلة في INTERNALDATE بقراءة مواصفات RFC الخام، فأنت تعرف أن المواصفة تترك هامشا واسعا للتفسير في هذه النقطة تحديدا.)

النتيجة: حين تصدّر رسائل من iCloud عبر Apple Mail أو تنقلها، قد تكون قيم INTERNALDATE خاطئة أصلا قبل وصولها إلى Office 365.

الطرق الثلاث لترحيل iCloud ومخاطرها

الترحيل المباشر عبر IMAP

الطريقة الأكثر شيوعا هي ضبط iCloud كمصدر IMAP وOffice 365 كوجهة، ثم استخدام أداة ترحيل (imapsync أو MigrationWiz أو أداة مخصصة). تتصل الأداة بالخادمين وتنسخ الرسائل.

المشكلة هنا مزدوجة. أولا، خوادم IMAP الخاصة بـ Apple لها حدود سرعة تجبر الأدوات على التوقف المؤقت، مما ينشئ نوافذ زمنية تُغلق فيها الاتصالات وتُعاد، وهذا قد يولّد قيم INTERNALDATE طفيلية. ثانيا، كل رسالة منسوخة عبر الإدراج في Exchange Online تحصل افتراضيا على تاريخ إيداع يتوافق مع لحظة الترحيل، إلا إذا مررت الأداة صراحةً قيمة INTERNALDATE الأصلية في أمر الإدراج.

بعض الأدوات تؤدي هذا بشكل صحيح. أخرى، ليس دائما. وعلى صندوق بريد يضم 40000 رسالة، حتى معدل خطأ بنسبة 2% يمثل 800 رسالة بتاريخ خاطئ.

للترحيل عبر imapsync، راجع أيضا: إصلاح تواريخ imapsync في Microsoft 365.

تصدير .mbox أو .eml ثم الاستيراد

يلجأ بعض المستخدمين إلى تصدير رسائلهم من iCloud عبر Apple Mail بصيغة .mbox، ثم محاولة استيرادها في Outlook. هذه طريقة يدوية تعطي نتائج متفاوتة.

صيغة .mbox تشفّر الرسائل كتسلسل من نصوص. التواريخ موجودة في حقول Date: الفردية لكل رسالة، لكن سطر الفصل بين الرسائل ("From ") يتضمن تاريخا قد يُفسَّر كتاريخ إنشاء من قِبل بعض أدوات الاستيراد. Outlook، حين يستورد ملف .mbox محولا إلى .pst، يستخدم أحيانا تاريخ سطر الفصل بدلا من حقل Date: في الرسالة نفسها.

السحب والإفلات عبر Outlook

هذه الطريقة هي الأكثر إلحاقا للضرر. يضبط المستخدم حسابيه في Outlook (iCloud وOffice 365)، ثم يسحب رسائله من مجلد إلى آخر. يبدو الأمر بسيطا. في الواقع، هو كارثة على مستوى التواريخ.

حين ينقل Outlook رسالة بالسحب والإفلات بين حسابين IMAP، يُنشئ فعليا ملف .EML جديدا، يُدرجه في الحساب الهدف، ثم يحذف الأصل. هذا الملف الجديد يرث تاريخ إنشاء ملف Windows، أي اللحظة الدقيقة لعملية السحب والإفلات. حقل Date: الأصلي لا يزال موجودا في نص الرسالة، لكن قيمة INTERNALDATE المسجلة على خادم Exchange Online تتوافق مع تاريخ التلاعب. يعرض Outlook بعد ذلك هذا التاريخ لجميع الرسائل المنقولة.

لنكن دقيقين: هذا السلوك يتفاوت بحسب إصدار Outlook. منذ تحديث Outlook في خريف 2023، تحسّن الأمر قليلا في بعض السيناريوهات، لكن السحب والإفلات بين الحسابات لا يزال مصدرا موثقا لتلف التواريخ.

ما الذي يعرضه Office 365 وOutlook في نهاية الأمر؟

يخزّن Exchange Online الرسائل مع قيمة INTERNALDATE الخاصة بها. يقرأ Outlook Desktop هذه القيمة لعرض التاريخ في عمود "المستلمة" ولترتيب صندوق الوارد. إذا استُبدلت قيمة INTERNALDATE أثناء الترحيل، يعرض Outlook تاريخ الترحيل، لا أكثر ولا أقل.

Outlook Web App (OWA) يفعل الشيء نفسه. لا توجد "عرض بديل" يظهر التاريخ الأصلي من حقل Date:. ما تراه في عمود التاريخ هو قيمة INTERNALDATE.

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

ما لا يحله دعم Microsoft

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

هذا ليس تقصيرا من Microsoft. ببساطة، لا تملك Microsoft أداة أصلية لتصحيح قيم INTERNALDATE بأثر رجعي على آلاف الرسائل المُدرجة مسبقا في Exchange Online. التصحيح يتطلب الوصول إلى كل رسالة على حدة، وتحليل رؤوسها، وإعادة بناء بيانات التاريخ الوصفية، وهذا خارج نطاق الدعم المعتاد.

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

مشكلة الحجم الكبير

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

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

• رسائل S/MIME الموقّعة أو المشفرة بـ PGP لا يمكن تعديلها دون إبطال التوقيع التشفيري
• الرسائل ذات البنى المعقدة من نوع multipart/alternative (HTML + نص عادي + مرفقات متداخلة) هشّة عند التلاعب بها
• الرؤوس المشفرة بغير ASCII (RFC 2047، لا سيما للأحرف اليابانية أو العربية أو السيريلية) قد تتلف بفعل أدوات لا تعالج هذه الترميزات بشكل صحيح
• حصص Microsoft Graph API وحدود سرعة Exchange Online (خطأ 429 Too Many Requests) توقف السكريبتات غير المصممة للتعامل مع التراجع الأسي
• سكريبت يعمل بشكل صحيح على 500 رسالة تجريبية قد يتوقف في الساعة الثالثة فجرا عند الرسالة رقم 8000 في صندوق بريد حقيقي، دون آلية استئناف

والسؤال الأصعب: كيف تتحقق من أن كل رسالة مُصحَّحة سليمة بعد التصحيح؟ أن المرفق لا يزال موجودا؟ أن خيط المحادثة لم ينكسر؟ السكريبت المنزلي في الغالب لا يجري هذا التحقق.

كيف تعالج Redate.io عمليات ترحيل iCloud إلى Office 365

تتصل Redate.io مباشرة بـ Office 365 عبر صلاحيات Microsoft 365 (Azure AD)، دون الحاجة للوصول إلى خوادم iCloud. الرسائل تكون موجودة بالفعل في Exchange Online حين تتدخل Redate.

يحلل محرك التصحيح في Redate سلسلة رؤوس كل رسالة لتحديد التاريخ الأصلي، مميّزا بين حقول Received: المضافة أثناء الترحيل والبيانات الوصفية الشرعية للتاريخ. يشمل هذا التحليل مطابقة أنماط على توقيعات أدوات الترحيل المعروفة، مما يتيح تحديد الرؤوس الطفيلية حتى حين لا تكون واضحة بشكل مباشر.

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

تدعم Redate أيضا الترحيل من Google Workspace إلى Office 365 والتصحيح بعد ترحيل cPanel. راجع مثلا: إصلاح تواريخ البريد بعد ترحيل Microsoft 365 أو تواريخ خاطئة بعد ترحيل Exchange Online.

الفحص أولا، التصحيح لاحقا

نقطة البداية الموصى بها لأي ترحيل من iCloud إلى Office 365 أسفر عن تواريخ خاطئة: تشغيل الفحص المجاني من Redate.io على صناديق البريد المتأثرة. يحدد الفحص بدقة عدد الرسائل التي تحمل قيمة INTERNALDATE مشبوهة والمجلدات التي توجد فيها.

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

إن كانت تواريخ رسائلك خاطئة بعد الترحيل من iCloud، ابدأ بالفحص المجاني على Redate.io لقياس حجم المشكلة على صناديق Office 365 الخاصة بك.