BitTitan MigrationWiz: اصلاح تواريخ البريد

ما الذي يفعله BitTitan MigrationWiz بتواريخ البريد الالكتروني

انتهت عملية الترحيل يوم الجمعة. تم نقل 47 صندوق بريد من خادم Exchange المحلي الى Microsoft 365، وكل شيء اخضر في لوحة تحكم MigrationWiz. ثم يحل صباح الاثنين ويصل اول تذكرة دعم: "جميع رسائلي الالكترونية تعرض 28 مارس 2026."

كل رسالة على حدة. سنوات من المراسلات، عروض العملاء من 2019، فواتير من 2021، جميعها مختومة بتاريخ الترحيل. سجل MigrationWiz يقول ان كل شيء تم نقله بنجاح (وهذا صحيح تقنيا). لكن التواريخ اختفت.

يعد BitTitan MigrationWiz واحدا من اكثر الادوات استخداما لترحيل البريد الالكتروني بين المنصات السحابية. يتعامل مع Exchange الى Microsoft 365، وGoogle Workspace الى Exchange، والنقل بين المستاجرين والكثير غير ذلك. الاداة نفسها تعمل جيدا فيما صممت من اجله. مشكلة التواريخ ليست خطا برمجيا في MigrationWiz. الأمر يعود إلى شيء واحد: التاريخ الذي تحمله كل نسخة عند كتابتها في صندوق البريد الجديد.

أين يقع التاريخ الخاطئ فعليا

عندما ينقل MigrationWiz بريدا الكترونيا من المصدر الى الوجهة، يستخدم بروتوكول IMAP (او Exchange Web Services حسب نوع نقطة النهاية). يحتفظ الطرف الوجهة بالتاريخ الذي يُعطى له: يحتفظ Microsoft 365 وOutlook.com وGmail بالتاريخ الأصلي عندما تحمله النسخة. لذا إذا ظهرت كل الرسائل بتاريخ الترحيل، فالسؤال هو عن التاريخ الذي ارسله MigrationWiz، أو لم يرسله.

هكذا تبدو رؤوس أحد تلك الرسائل بعد ترحيل MigrationWiz:

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

راس Received: الاصلي من عام 2019 لا يزال موجودا. وكذلك راس Date: الاصلي. وفي Microsoft 365، التاريخ الذي يعرضه Outlook كتاريخ استلام هو سجل صندوق البريد الخاص بوقت وصول كل رسالة: إذا لم يرسل MigrationWiz التاريخ الأصلي، فذلك السجل يشير الان إلى 28 مارس 2026.

قيمة INTERNALDATE (الطابع الزمني الذي تستخدمه خوادم IMAP للفرز) هو التاريخ الذي تستلمه النسخة. يحاول MigrationWiz الحفاظ على التواريخ، ويحتفظ Microsoft 365 بالتاريخ الذي يُعطى له: فاذا خرجت التواريخ خاطئة، فالتاريخ الذي تم ارساله لكل رسالة لم يكن التاريخ الأصلي.

لماذا لا يعمل تعيين التواريخ في MigrationWiz

يقدم BitTitan ميزة "Date Mapping" في الخيارات المتقدمة لـ MigrationWiz. على الورق تبدو كحل. في التطبيق العملي؟ تتحكم في نطاق تواريخ الرسائل التي سيتم ترحيلها، وليس في كيفية الحفاظ على التواريخ في الوجهة.

الالتباس مفهوم. الاعداد يحمل كلمة "تاريخ" في اسمه مباشرة. لكن ما يفعله فعليا هو تصفية رسائل المصدر حسب نطاق التاريخ قبل الترحيل. رسالة من عام 2018 تصل الى الوجهة بالطابع الزمني للترحيل على اي حال.

هناك ايضا مسالة IMAP مقابل نقاط نهاية Exchange. عندما يقوم MigrationWiz بالترحيل بين خادمي Exchange باستخدام EWS (Exchange Web Services)، يعمل الحفاظ على التواريخ بشكل افضل لان EWS يملك سيطرة اكبر على البيانات الوصفية للرسائل. وعبر IMAP ايضا، يحتفظ الطرف الوجهة بالتاريخ الذي يُعطى له: المهم هو هل تم إرسال التاريخ الأصلي ام لا.

حاول بعض المسؤولين اعادة تشغيل الترحيل بتكوينات مختلفة لنقاط النهاية، على امل ان التحول من IMAP الى EWS سيصلح التواريخ بأثر رجعي. لا يصلحها. الرسائل موجودة بالفعل في الوجهة بتواريخ خاطئة. اعادة تشغيل MigrationWiz ستنشئ نسخا مكررة فقط.

سيناريوهات MigrationWiz المحددة التي تفسد التواريخ

ليس كل ترحيل بواسطة MigrationWiz يسبب مشاكل في التواريخ. تعتمد المشكلة على تركيبة نقاط النهاية:

• Exchange (محلي) الى Microsoft 365 عبر IMAP: التواريخ تتلف. تحصل كل رسالة على تاريخ النسخة.
• Google Workspace الى Microsoft 365: التواريخ تتلف. يستخدم MigrationWiz بروتوكول IMAP للقراءة من Google ويكتب إلى M365 دون التاريخ الأصلي.
• Exchange الى Exchange (عبر EWS): التواريخ تُحفظ عادة. ينتقل التاريخ الأصلي مع الرسالة عبر EWS.
• اي مصدر الى Google Workspace عبر IMAP: عبر IMAP، يحتفظ Gmail بالتاريخ الذي ترسله الأداة ولا يضيف شيئا. تتلف التواريخ فقط إذا لم يكن ذلك التاريخ هو الأصلي، أو إذا مرت النسخة عبر واجهة استيراد Gmail التي تضيف سطر Received بتاريخ يوم النسخ.
• ترحيل بين مستاجري Microsoft 365: يعتمد الأمر كليا على التاريخ الذي ترسله الطريقة المستخدمة.

لا تشير لوحة تحكم MigrationWiz الى مشاكل التواريخ. كل شيء يظهر كـ "Completed" لان الرسائل تم نقلها بنجاح فعلا. المحتوى سليم، المرفقات بخير، هيكل المجلدات محفوظ. التواريخ فقط هي التي تغيرت، ولا يتتبع MigrationWiz ذلك كخطا في الترحيل.

التكلفة الحقيقية للتواريخ الخاطئة بعد MigrationWiz

التواريخ الخاطئة للبريد الالكتروني ليست مجرد ازعاج. بالنسبة للمؤسسات التي رحلت باستخدام BitTitan، تتجاوز العواقب صندوق البريد الفوضوي.

لا تستطيع الفرق القانونية استخدام رسائل البريد الالكتروني كادلة عندما تعرض كل رسالة تاريخ الترحيل بدلا من تاريخ الارسال الفعلي. تتطلب عمليات التدقيق الضريبي اثباتا زمنيا للاتصالات. تفرض اطر الامتثال مثل SOX وHIPAA وGDPR حفظ سجلات دقيقة، ورسائل البريد الالكتروني ذات الطوابع الزمنية المزورة لا تفي بهذا المتطلب.

ثم هناك الجانب العملي. حاول ان تجد مناقشة عقد من نوفمبر 2022 عندما يعرض صندوق بريدك بالكامل مارس 2026. الفرز حسب التاريخ؟ بلا فائدة. البحث حسب نطاق التاريخ؟ يعيد كل شيء او لا شيء.

بالنسبة لمزودي الخدمات المدارة (MSP) الذين استخدموا MigrationWiz في بيئات العملاء، يخلق هذا مشكلة مسؤولية. دفع العميل مقابل الترحيل. حصل عليه، لكن ارشيف بريده الالكتروني اصبح غير صالح فعليا لسير العمل القائم على التواريخ.

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

اصلاح تواريخ BitTitan MigrationWiz

راس Date: الاصلي لا يزال داخل كل بريد الكتروني. لا يمس MigrationWiz نص الرسالة او الرؤوس الاصلية. التاريخ الذي سجله صندوق البريد لكل نسخة هو ما يسبب مشكلة العرض.

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

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

فهم المشكلة شيء. اصلاح 15,000 بريد الكتروني دون فقدان مرفق واحد او كسر توقيعات S/MIME او افساد حدود MIME متعددة الاجزاء شيء اخر تماما. سكريبت يعمل على 10 رسائل اختبارية في المختبر لن يتعامل مع الحالات الحدية لصندوق بريد انتاجي يحتوي على 7 سنوات من المراسلات ورسائل مشفرة بـ PGP ورؤوس RFC 2047 غير ASCII.

كيف تتحقق من ان كل رسالة مصححة سليمة؟ ان سلاسل المحادثات لا تزال تعمل، وان دعوات التقويم لا تزال تتم معالجتها، وان المرفق بحجم 47 ميغابايت في ذلك البريد الالكتروني من عام 2020 لم يتلف؟ يقوم Redate.io بذلك تلقائيا لكل رسالة. واذا بدا شيء غير صحيح، فالاصل موجود في مجلد النسخ الاحتياطي.

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

ادلة الاصلاح حسب المنصة لمستخدمي BitTitan

تختلف عملية الاصلاح حسب المكان الذي نقل اليه MigrationWiz رسائلكم. يتعامل Redate.io مع خصائص كل منصة تلقائيا، لكن اذا اردتم تفاصيل حول اعدادكم المحدد:

• اصلاح تواريخ BitTitan في Outlook
• اصلاح تواريخ BitTitan في Microsoft 365
• اصلاح تواريخ BitTitan في Google Workspace
• اصلاح تواريخ BitTitan في Exchange Online

يعمل Redate.io ايضا مع عمليات الترحيل المكتملة قبل اشهر او سنوات. راس Date الاصلي لا تنتهي صلاحيته.

هل رحلتم باستخدام BitTitan MigrationWiz وتعانون من تواريخ خاطئة؟ شغلوا فحصا مجانيا لمعرفة عدد رسائل البريد الالكتروني المتاثرة بالضبط قبل الالتزام باي شيء.