لماذا تظهر رسائلك الالكترونية بتاريخ خاطئ بعد الترحيل

المشكلة - جميع الرسائل تعرض نفس التاريخ

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

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

كيف يبدو ذلك في Outlook

في Microsoft Outlook، يعرض عمود "مستلم" تاريخ الترحيل لكل رسالة. سواء أرسلت الرسالة عام 2018 أو 2023، يظهر Outlook نفس التاريخ، وهو يوم معالجة أداة الترحيل لصندوق البريد. صندوق الوارد والعناصر المرسلة وكل مجلد متأثر. المستخدمون الذين يعتمدون على الترتيب بالتاريخ يجدون سير عملهم معطلا تماما.

كيف يبدو ذلك في Apple Mail

Apple Mail على macOS وiOS يتصرف بشكل مشابه. التاريخ المعروض بجوار كل رسالة يعكس طابع الترحيل الزمني بدلا من التاريخ الأصلي. بما أن Apple Mail يستخدم بيانات خادم IMAP الوصفية لتحديد تواريخ العرض، فإن نفس المشكلة الأساسية تنتج نفس النتيجة المرئية. عند تصفح صندوق الوارد، لا يرى المستخدم سوى جدار من التواريخ المتطابقة.

كيف يبدو ذلك في Gmail (واجهة الويب)

واجهة Gmail على الويب تقدم وضعا مختلفا قليلا. عميل Gmail الخاص بالويب يستخدم عادة رأس "Date" من الرسالة نفسها، لذلك قد تظهر الرسائل بالتاريخ الصحيح في Gmail. لكن INTERNALDATE في IMAP تبقى خاطئة، مما يعني أن أي عميل IMAP يتصل بحساب Gmail هذا (Outlook أو Thunderbird أو Apple Mail) سيعرض تاريخ الترحيل. النتيجة؟ نفس صندوق البريد يبدو صحيحا في عميل وخاطئا في آخر.

لماذا يحدث هذا - السبب التقني

السبب الجذري يكمن في طريقة تعامل أدوات ترحيل IMAP مع رؤوس البريد الالكتروني وكيفية تحديد عملاء البريد للتاريخ الذي يعرضونه. فهم ذلك يتطلب نظرة سريعة على بروتوكول IMAP وبنية الرؤوس.

كيف تتعامل أدوات ترحيل IMAP مع الرؤوس

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

رأس "Received" الذي يكسر كل شيء

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

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

INTERNALDATE مقابل رأس Date

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

ببساطة، بعض أدوات الترحيل تحاول الحفاظ على INTERNALDATE الأصلية بتعيينها أثناء أمر APPEND. لكن حتى عندما يتم تعيين INTERNALDATE بشكل صحيح، فإن رأس "Received" المضاف يسبب مشاكل في العملاء التي تعطي الأولوية لتاريخ "Received" على INTERNALDATE.

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

تقريبا جميع أدوات ترحيل IMAP يمكن أن تسبب هذه المشكلة. القضية متأصلة في بروتوكول IMAP وليست خاصة بأداة معينة. لكن بعض الأدوات ترتبط بالمشكلة أكثر نظرا لانتشار استخدامها.

BitTitan MigrationWiz

BitTitan MigrationWiz هي واحدة من أكثر أدوات الترحيل التجارية شيوعا لدى مقدمي الخدمات المدارة (MSP) ومستشاري تقنية المعلومات. تضيف MigrationWiz رأس "Received" يحتوي على "mx.migrationwiz.com" أثناء عملية الترحيل. هذا الرأس يصبح الأحدث في السلسلة، مسببا عرض تاريخ الترحيل في Outlook وعملاء IMAP الأخرى. راجع الأدلة التفصيلية لإصلاح تواريخ BitTitan في Outlook وMicrosoft 365 وGoogle Workspace وExchange Online.

CloudM Migrate

CloudM Migrate (المعروفة سابقا بـ Cloud Migrator) تستخدم على نطاق واسع لترحيل Google Workspace. مثل الأدوات الأخرى، تضيف CloudM رأس "Received" الخاص بها عند الإدراج عبر IMAP. الرسائل المرحلة عبر CloudM تعرض تاريخ الترحيل في العملاء التي تعتمد على رأس "Received". راجع الأدلة لإصلاح تواريخ CloudM في Gmail وOutlook وGoogle Workspace وMicrosoft 365.

imapsync

imapsync أداة مفتوحة المصدر شائعة لدى مسؤولي Linux ومقدمي الاستضافة. رغم أن imapsync تحاول الحفاظ على INTERNALDATE، إلا أن الخادم الوجهة يضيف رأس "Received" أثناء عملية APPEND. الأسئلة الشائعة في imapsync تعترف بهذا القيد لكنها لا تقدم حلا مدمجا لإزالة الرأس المضاف بعد الترحيل. راجع الأدلة لإصلاح تواريخ imapsync في Outlook وGmail وMicrosoft 365 وGoogle Workspace.

GSMMO (ترحيل Google Workspace)

أداة Google Workspace Migration for Microsoft Outlook أي GSMMO هي أداة Google الخاصة للترحيل من Exchange أو ملفات PST في Outlook إلى Google Workspace. يمكن لـ GSMMO إنتاج نفس مشكلة التاريخ، خاصة عندما يتضمن الترحيل مرحلة IMAP وسيطة. راجع الأدلة لإصلاح تواريخ GSMMO في Outlook وGmail وApple Mail.

مركز إدارة Exchange (استيراد IMAP الأصلي)

مركز إدارة Exchange من Microsoft يتضمن ميزة استيراد IMAP أصلية للترحيل إلى Exchange Online أي Microsoft 365. أداة الترحيل المدمجة هذه تضيف رؤوس "Received" أثناء الاستيراد، مسببة نفس مشكلة عرض التاريخ. راجع الأدلة لإصلاح تواريخ ترحيل Exchange IMAP في Outlook وOWA.

النسخ اليدوي عبر IMAP

حتى النسخ اليدوي للرسائل بين خوادم IMAP عبر عميل مثل Thunderbird يمكن أن ينتج مشكلة التاريخ هذه. عندما ينسخ عميل بريد رسالة عبر IMAP، يعاملها الخادم الوجهة كإدراج جديد ويضيف رأس "Received" خاصا به بالطابع الزمني الحالي. راجع الأدلة لإصلاح تواريخ النسخ اليدوي عبر IMAP في Outlook وGmail وThunderbird وApple Mail.

لماذا لا تنجح الحلول البديلة المعتادة

في مواجهة هذه المشكلة، يحاول المستخدمون والمسؤولون عادة عدة مقاربات قبل أن يدركوا أن أيا منها لا يحل المشكلة فعلا.

"رتب حسب تاريخ الارسال" - لماذا لا يكفي

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

إعادة الترحيل - مكلفة ومحفوفة بالمخاطر

بعض المسؤولين يفكرون في إعادة الترحيل، أملا في تجنب مشكلة التاريخ في المحاولة الثانية. هذا النهج مكلف (500 إلى 5,000 يورو حسب عدد صناديق البريد)، يستهلك وقتا كبيرا ومحفوف بالمخاطر. ترحيل ثان يقدم نفس مشكلة رأس "Received"، ويضاعف خطر فقدان البيانات ويتطلب وقت توقف كبير. إعادة الترحيل لا تحل مشكلة التاريخ ما لم يتم تعديل أداة الترحيل جذريا.

تعديل الرؤوس يدويا - يتطلب وصولا للخادم

تقنيا، الإصلاح يتضمن إزالة رأس "Received" الخاص بالترحيل من كل رسالة. لكن القيام بذلك يدويا يتطلب وصولا مباشرا للخادم ومعرفة ببنية رؤوس البريد الالكتروني وبرمجة نصوص مخصصة. لصندوق بريد يحتوي 10,000 رسالة، التعديل اليدوي غير عملي وخطير بشكل كبير. رسائل موقعة بـ S/MIME، رسائل مشفرة بـ PGP، هياكل multipart بحدود MIME متداخلة، مشاكل Content-Transfer-Encoding، رؤوس غير ASCII وفق RFC 2047، مرفقات كبيرة الحجم: كل حالة من هذه يمكن أن تؤدي إلى إتلاف البيانات بشكل لا يمكن عكسه بواسطة نص برمجي بسيط. كيف تتأكد أن 10,000 رسالة مصححة كلها سليمة؟ لا يمكنك ذلك إلا بنظام تحقق مصمم خصيصا لهذا الغرض.

الحل الحقيقي - استعادة التواريخ الأصلية

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

كيف يصلح Redate.io هذه المشكلة

Redate.io يتصل بصندوق البريد (Google Workspace أو Microsoft 365 أو أي خادم IMAP) ويحلل كل رسالة لتحديد الرسائل المتأثرة برؤوس الترحيل. التحليل مجاني ويوضح بالضبط عدد الرسائل المتأثرة قبل أي دفع.

لكل رسالة متأثرة، يمرر محرك التصحيح الخاص بـ Redate.io الرسالة عبر خط أنابيب تحليل متعدد المراحل. المحرك يطبق مطابقة التوقيعات على مئات ملفات تعريف أدوات الترحيل المعروفة، المبنية من معالجة أحجام كبيرة من بيانات البريد الفعلية. يتعامل مع مشاكل الترميز وهياكل multipart والمرفقات المضمنة وعشرات الحالات الخاصة التي قد تتسبب في إتلاف البيانات بنص برمجي منزلي (ليس الاكتشاف الذي تريد أن تبدأ به صباح يوم الاثنين). كل رسالة مصححة تمر بفحص سلامة قبل الانتهاء. الرسالة الأصلية تنقل إلى مجلد مرئي باسم "Redate.io - Originals" (لا تحذف) وتحفظ لمدة 30 يوما.

النتيجة؟ الرسائل تعرض تواريخها الأصلية الصحيحة في جميع العملاء. الترتيب يعمل مجددا. التاريخ الزمني لصندوق البريد يستعاد.

أسئلة شائعة

هل يمكن إصلاح التواريخ بعد أشهر من الترحيل؟

نعم. رأس "Date" الأصلي محفوظ داخل رسالة البريد بصرف النظر عن وقت الترحيل. Redate.io يستطيع إصلاح تواريخ الرسائل بعد أسابيع أو أشهر أو حتى سنوات من الترحيل. الإصلاح يعمل طالما أن الرؤوس الأصلية للرسالة سليمة.

هل سيحذف إصلاح التواريخ رسائلي؟

لا. Redate.io لا يحذف أي رسائل أبدا. الرسائل الأصلية تنقل إلى مجلد مرئي باسم "Redate.io - Originals" داخل صندوق البريد، حيث تبقى متاحة لمدة 30 يوما. كل رسالة مصححة يتم التحقق منها مقارنة بالأصل قبل إتمام العملية. إذا فشل التحقق لأي رسالة، تبقى الرسالة الأصلية سليمة.

هل يعمل هذا مع صناديق البريد المشتركة؟

نعم. Redate.io يعمل مع صناديق البريد المشتركة في Google Workspace وMicrosoft 365. لصناديق البريد المشتركة، يلزم وصول بمستوى المسؤول لتفويض الاتصال. العملية مطابقة لصناديق البريد الفردية: تحليل، تصحيح، تحقق.

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