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

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

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

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

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

كيف يتعامل MigrationWiz مع رؤوس Received

عندما ينقل MigrationWiz بريدا الكترونيا من المصدر الى الوجهة، يستخدم بروتوكول IMAP (او Exchange Web Services حسب نوع نقطة النهاية). خلال هذه العملية، يختم خادم البريد الوجهة الرسالة براس Received: جديد يحتوي على الطابع الزمني الحالي، تماما كما يختم اي بريد الكتروني وارد.

هكذا تبدو سلسلة رؤوس Received النموذجية بعد ترحيل MigrationWiz:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

راس Received: الاصلي من عام 2019 لا يزال موجودا. وكذلك راس Date: الاصلي. لكن عملاء البريد الالكتروني مثل Outlook لا يستخدمونها. يقرا Outlook احدث راس Received: لتحديد وقت عرض الرسالة، وذلك الراس يشير الان الى 28 مارس 2026.

قيمة INTERNALDATE (الطابع الزمني الذي تستخدمه خوادم IMAP للفرز) يتم استبدالها ايضا اثناء النقل. يحاول MigrationWiz الحفاظ على التواريخ عندما تدعم الوجهة ذلك، لكن النتيجة تعتمد بشكل كبير على سلوك الخادم الوجهة. في الواقع، يقوم خط نقل Microsoft 365 باستبدال INTERNALDATE بطابعه الزمني الخاص للتسليم بغض النظر عما يطلبه MigrationWiz.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتصل Redate.io بصندوق البريد (Google Workspace او Microsoft 365 او IMAP)، ويفحص رسائل البريد الالكتروني المتاثرة بترحيل MigrationWiz، ويصحح البيانات الوصفية للتواريخ من خلال خط تحليل متعدد المراحل خاص. يستهدف التصحيح طبقة البيانات الوصفية تحديدا، مع مطابقة انماط توقيعات MigrationWiz المعروفة في الرؤوس بما في ذلك معرفات mx.migrationwiz.com وbittitan.com المميزة في سلسلة Received.

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

فهم المشكلة شيء. اصلاح 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 وتعانون من تواريخ خاطئة؟ شغلوا فحصا مجانيا لمعرفة عدد رسائل البريد الالكتروني المتاثرة بالضبط قبل الالتزام باي شيء.