Takeout mbox مستورد: كل الرسائل بتاريخ اليوم

فتحت أرشيف Google Takeout، واستوردت ملف mbox في Thunderbird عبر ImportExportTools NG (أو في Apple Mail)، ثم سحبت المجلدات إلى حسابك الجديد عبر IMAP. في برنامج البريد كانت الرسائل مرتبة سنة بعد سنة. أما في حساب الوجهة فكلها بتاريخ اليوم. يشرح هذا المقال ما يحدث مع Takeout mbox المستورد، ولماذا يكون التاريخ المعروض هو تاريخ النسخ، وكيف تتأكد من ذلك في دقائق، وكيف تصحح تواريخ الرسائل من جهة الخادم.

أول ما ينبغي معرفته: رسائلك لم تتضرر. تاريخها الأصلي ما زال داخل الرسالة. كل ما في الأمر أنه لم يعد التاريخ الذي يبرزه حساب الوجهة.

السيناريو المعتاد لاستيراد Takeout mbox

أغلقت للتو حساب Gmail شخصيًا فتحته قبل خمس عشرة سنة. طلبت التصدير من takeout.google.com، وانتظرت رسالة Google (يومين لصندوق بريد كبير)، ونزّلت أربعة أرشيفات zip. في كل واحد منها ملف .mbox لكل تصنيف. استوردتها في Thunderbird: امتلأ المجلد المحلي، وبدا الفرز حسب التاريخ سليمًا تمامًا، 2009 في الأسفل وأمس في الأعلى.

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

المشكلة؟ الرسائل البالغ عددها 18,400 كلها مؤرخة بنهاية الأسبوع، ضمن نافذة من ساعات قليلة. عقد من 2014 يجلس بجانب نشرة إخبارية وصلت الأسبوع الماضي، ولم يعد أحد قادرًا على العثور على أي شيء بترتيب زمني.

الحالة قريبة جدًا من حالة الرسائل القديمة التي تحمل كلها التاريخ نفسه، مع فارق كبير: لا توجد هنا أي أداة ترحيل متهمة. السحب والإفلات وحده كافٍ.

ثلاثة تواريخ في رسالة واحدة

لفهم ما جرى، علينا أن نتوقف عن الحديث عن "التاريخ" الواحد للرسالة. الرسالة المستوردة من ملف mbox تحمل ثلاثة تواريخ على الأقل، ولكل منها وظيفة مختلفة.

رأس Date: تاريخ المرسل

هذا هو الرأس Date: الذي عرّفه المعيار RFC 2822 (وأعاد المعيار RFC 5322 تناوله). يكتبه برنامج المرسل لحظة الإرسال، مثل Date: Tue, 14 Mar 2017 09:12:45 +0100. هو جزء من الرسالة ويسافر معها، وTakeout يحتفظ به كما هو. وهو ما يجعل التصحيح ممكنًا، لأنه يبقى سليمًا.

سطر From في ملف mbox: تاريخ شكلي

في ملف mbox، تسبق كل رسالة سطرٌ يبدأ بـ From (متبوعًا بمسافة ودون نقطتين). هذا ليس رأسًا: إنه فاصل خاص بصيغة الملف ولا يشكل جزءًا من الرسالة. لا ينبغي لأي أداة جادة أن تعتمد عليه لتحديد تاريخ رسالة.

INTERNALDATE: تاريخ الإيداع على الخادم

التاريخ الثالث هو الأكثر خفاءً: INTERNALDATE الذي يعرّفه المعيار RFC 3501. إنه سمة يخزنها خادم IMAP بجانب الرسالة (لا داخلها)، وتمثل التاريخ الذي أُودعت فيه الرسالة في صندوق البريد. يعتمد عليها Outlook وواجهات البريد على الويب والهواتف لعرض تاريخ الاستلام وفرز الرسائل. ولمعرفة تفاصيل الآلية، يتعمق مقال INTERNALDATE وأسباب تلف التواريخ في IMAP أكثر.

توضيح بشأن رؤوس Received: التي يُتهم بها خطأً في هذه الحالة. سطور Received في رسالة Gmail مُصدَّرة تروي المسار الحقيقي للرسالة عام 2017: تواريخها قديمة ومشروعة. إذن التاريخ الخاطئ هنا لا يسكن الرسالة، بل البيانات الوصفية التي يمنحها الخادم للنسخة.

لماذا يعرض حساب الوجهة تاريخ النسخ

حين يودع برنامج البريد رسالة على خادم IMAP، فإنه يستخدم الأمر APPEND. يقبل هذا الأمر اختياريًا تاريخًا تُمنحه الرسالة. إن قدّمه البرنامج، احتفظ به الخادم بوصفه INTERNALDATE. وإن لم يقدمه، طبّق الخادم القاعدة التي ينص عليها RFC 3501: تاريخ اللحظة ووقتها. بعبارة أخرى، يتوقف التاريخ المعروض على الطريقة التي كتبت بها الأداة الرسالة. الأداة التي لا تمرر التاريخ الأصلي تحصل على تاريخ النسخ.

والنتيجة: أثناء سحبك للمجلدات، تأخذ كل رسالة تاريخ إيداعها هي. مجلد من 3,000 رسالة نُسخ في 40 دقيقة يقع كله داخل نافذة من 40 دقيقة.

وماذا عن المجلد المحلي في Thunderbird؟ بدا مثاليًا لأن Thunderbird يفرز فيه حسب الرأس Date، لا حسب تاريخ خادم، إذ لا خادم للمجلد المحلي. وسلوك Apple Mail مع الصناديق المستوردة مشابه: كل شيء على ما يرام ما دامت الرسائل باقية على جهاز Mac. وتظهر الحقيقة في اللحظة التي يقرأ فيها برنامج آخر، مثل Outlook، صندوق IMAP.

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

السحب والإفلات ليس ترحيلًا. إنه نسخ، والنسخة تحمل تاريخ صنعها.

كيف تتعرف على هذه الحالة في خمس دقائق

قبل البحث عن حل، تأكد أنك في هذا السيناريو وليس في سيناريو آخر. أربعة فحوصات تكفي.

• قارن بين المكانين. المجلد المحلي في Thunderbird (أو الصندوق المستورد في Apple Mail) يعرض تواريخ صحيحة، وحساب IMAP يعرض تواريخ حديثة للرسائل نفسها.
• انظر إلى النطاق. في مجلد من حساب IMAP، تقع تواريخ الاستلام ضمن ساعات قليلة، أو حتى دقائق، حول لحظة نقلك للمجلدات.
• افتح مصدر رسالة. في Thunderbird: عرض ثم مصدر الرسالة؛ وفي Outlook، خصائص الرسالة تعرض الرؤوس. ينبغي أن تجد فيها سطر Date: قديمًا بينما يشير العرض إلى تاريخ حديث.
• تحقق من الترتيب. تظهر الرسائل بالترتيب الذي نسخها به البرنامج، لا بالترتيب الزمني.

هذا ما تعطيه المقارنة على رسالة حقيقية:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (داخل الرسالة، سليم)
التاريخ الذي يعرضه حساب IMAP: يوم النسخ   (بيانات وصفية على الخادم)

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

(بالمناسبة، إن لم تقرأ يومًا الرؤوس الخام لرسالة بريد، فأعدّ فنجان قهوة: ليست بالضبط قراءة للاسترخاء على الشاطئ.)

الفرز حسب تاريخ الإرسال: مسكّن مؤقت

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

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

التصحيح من جهة الخادم

الخبر الجيد أن التاريخ الأصلي ما زال موجودًا. ويقوم التصحيح على جعل حساب الوجهة يعرضه، دون المساس بمحتوى رسائلك.

وهذا ما تفعله Redate. تتصل الخدمة بصندوق البريد (Google Workspace عبر التفويض على مستوى النطاق، وMicrosoft 365، وOutlook.com وHotmail بحساب Microsoft الخاص بكل شخص، أو IMAP مباشرة بالعنوان وكلمة المرور). لا تحتاج Redate إلى معرفة الأداة التي تسببت بالمشكلة: فهي تعثر على الرسائل التي لا يطابق تاريخها المعروض تاريخها الأصلي، سواء كان السبب سحبًا وإفلاتًا من Takeout mbox أو شيئًا آخر. الفحص مجاني ويريك حجم الضرر قبل أي قرار.

أما التصحيح نفسه، فتعتمد فيه Redate على محرك تصحيح خاص بها، وعلى خط تحليل متعدد المراحل يفحص سلسلة رؤوس كل رسالة ويعيد إلى كل رسالة تاريخها الأصلي. ثم يُتحقق من كل رسالة مصححة على حدة، مع التأكد من الامتثال لمعايير RFC والحفاظ على بنية الرسالة. لا تُحذف الرسائل الأصلية أبدًا: تبقى في مجلد ظاهر داخل صندوق بريدك إلى أن تحذفها بنفسك.

لماذا تنطوي المحاولة اليدوية على مخاطرة

فهم المشكلة شيء. وتصحيحها على 15,000 رسالة دون فقدان رسالة واحدة شيء آخر.

السكربت الذي يعمل على عشر رسائل تجريبية لا يصمد أمام صندوق بريد إنتاجي فيه 30,000 رسالة. سيصادف رسائل S/MIME موقّعة، وأي تعديل بسيط فيها يكسر التوقيع. ورسائل PGP مشفرة. وبُنى multipart/alternative متداخلة، وحدود MIME غير متسقة، وقيم Content-Transfer-Encoding غير متوقعة، ورؤوسًا غير ASCII مرمّزة بحسب RFC 2047، ومرفقات بحجم 40 ميغابايت. ثم تأتي حصص واجهات API، وخطأ 429 Too Many Requests في الثالثة فجرًا في منتصف دفعة العمل، وانقطاعات الشبكة التي توقف العملية عند الرسالة 11,874.

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

نصيحة أخيرة مجانية: احتفظ بأرشيفات Takeout الأصلية ما دام صندوق البريد لم يُعتمد بعد. يبقى ملف mbox هو النسخة المرجعية، حتى حين يبدو حساب الوجهة سليمًا.

أدلة مرتبطة ببرنامج البريد الذي استخدمته

بحسب البرنامج الذي استخدمته في النسخ، تصف الأدلة التالية الحالة بدقة: إصلاح تواريخ النسخ اليدوي عبر IMAP في Thunderbird والحالة نفسها في Apple Mail.

هل نُسخ Takeout إلى حساب IMAP وصارت التواريخ خاطئة؟ ابدأ الفحص المجاني من Redate لترى كم رسالة متأثرة، ثم صحح تواريخها بدفعة واحدة، دون حد لحجم صندوق البريد.