إصلاح تواريخ imapsync للبريد

وعد --syncinternaldates (وأين يتوقف)

لقد شغّلت أمر imapsync. أضفت --syncinternaldates لأنك قرأت الوثائق وأنت حريص بهذا القدر. ينتهي الترحيل، ويقول السجل أنّ كل شيء انتقل، صفر أخطاء. ثم تفتح صندوق البريد في Outlook وكل رسالة تعرض تاريخ الأمس.

هذا واحد من أكثر مصادر الإحباط شيوعا مع imapsync، وهو يحيّر مسؤولي الأنظمة منذ 2017 على الأقل. من المفترض أن تحافظ علامة --syncinternaldates على INTERNALDATE الخاص بـ IMAP أثناء الترحيل. وهي تفعل ذلك: تعطي كل نسخة التاريخ الداخلي الذي يحتفظ به الخادم المصدر. وهنا يكمن الفخ بالضبط.

imapsync أداة مفتوحة المصدر مكتوبة بلغة Perl بواسطة Gilles Lamiral، وهي جيدة حقا فيما تفعله. تتعامل مع نقل صناديق البريد من IMAP إلى IMAP بمستوى من الموثوقية تحسدها عليه معظم الأدوات التجارية. لكن imapsync لا يمكنه نسخ إلا التواريخ التي يجدها، وهنا تصبح الأمور معقدة.

كيف تعمل تواريخ IMAP فعليا

هناك ثلاثة "تواريخ" مختلفة في كل رسالة بريد إلكتروني، ومعظم الناس (بما في ذلك بعض مسؤولي تقنية المعلومات) يخلطون بينها:

رأس Date: (RFC 2822) - التاريخ الذي وضعه برنامج بريد المرسل على الرسالة عند تحريرها. يعيش هذا داخل نص الرسالة ولا تعدّله خوادم البريد أبدا.
رؤوس Received: - كل خادم بريد يعالج الرسالة يضيف واحدا بطابعه الزمني الخاص. تشكّل هذه سلسلة من المرسل إلى المستلم. أحدث رأس Received (الأعلى) هو ما تستخدمه بعض برامج البريد للعرض.
INTERNALDATE - طابع زمني من جانب خادم IMAP يتحكم في كيفية فرز الرسائل في صندوق البريد. يُعيَّن هذا عند تخزين الرسالة لأول مرة عبر IMAP APPEND.

عندما يرحّل imapsync رسالة، يقرأها من الخادم المصدر (بما في ذلك INTERNALDATE الخاص بها) ويكتبها على خادم الوجهة باستخدام IMAP APPEND. تُخبر علامة --syncinternaldates imapsync بتمرير INTERNALDATE المصدر إلى خادم الوجهة أثناء APPEND.

وهذا هو الخبر الجيد: تحتفظ Microsoft 365 وOutlook.com وGmail بالتاريخ الذي تُعطى إياه. إذا ظهرت التواريخ خاطئة، فالمشكلة في مكان آخر.

لماذا يمكن أن تظل التواريخ خاطئة

تقول مواصفة IMAP (RFC 3501) إنه إذا تم توفير تاريخ-وقت مع أمر APPEND، فينبغي (SHOULD) على الخادم استخدامه. "ينبغي" في لغة RFC تعني "افعل هذا إلا إذا كان لديك سبب وجيه لعدم فعله". تفعل Microsoft 365 وOutlook.com وGmail ذلك: النسخة التي تحمل تاريخها الأصلي تحتفظ به.

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

تُعد Gmail حالة خاصة فقط عندما تمر النسخة عبر واجهة الاستيراد الخاصة بـ Gmail بدل IMAP: تلك الواجهة تضيف سطر Received: مؤرخا بيوم النسخ، ويمكن لـ Outlook أن يعرض ذلك التاريخ. imapsync يتحدث بلغة IMAP، فلا يتأثر بذلك.

يحتفظ Dovecot وCyrus، أشهر خادمي IMAP مفتوحي المصدر، بالتاريخ من APPEND أيضا. فأيا كانت الوجهة، السؤال واحد: أي تاريخ كان يحمله المصدر؟

أخطاء شائعة في سطر أوامر imapsync تُفسد التواريخ

بعيدا عن تواريخ المصدر، كثيرا ما يتعثر المسؤولون في خيارات سطر أوامر imapsync، أو يلومون الخيارات الخاطئة. هذه هي الأخطاء التي أراها أكثر من غيرها:

النسخ من مصدر كانت تواريخه خاطئة أصلا

--syncinternaldates مفعّلة افتراضيا: يعطي imapsync كل نسخة التاريخ الداخلي الذي يحتفظ به الخادم المصدر (بحسب وثائقه: "يضبط التواريخ الداخلية على host2 لتكون مطابقة لـ host1"). إذا كان صندوق البريد المصدر نفسه نتيجة ترحيل سابق أو استعادة، فقد تكون تواريخه الداخلية أصلا تواريخ تلك العملية، فينسخ imapsync بأمانة التاريخ الخاطئ. هذا هو السبب الأكثر شيوعا، والأسهل تفويتا، لأن السجل يعرض تاريخين متطابقين.

استخدام --syncinternaldates مع --addheader

توصي بعض الأدلة باستخدام --addheader لحقن رأس مخصص أثناء الترحيل. إضافة رأس تعدّل الرسالة (سطر واحد إضافي في الأعلى) لكنها لا تغير التاريخ الذي يمرره imapsync، فهذا لا يفسر التواريخ الخاطئة. النسخة فقط لا تعود مطابقة تماما للأصل، وهذا مهم إذا قارنت بين الاثنين.

الخلط بين --minage و --maxage والحفاظ على التاريخ

تُصفّي علامتا --minage و --maxage الرسائل المراد ترحيلها بناء على عمرها. لا تؤثران على كيفية معالجة التواريخ في الوجهة. رأيت مسؤولين يقضون ساعات في تعديل هاتين العلامتين ظنا أنهما سيحلان مشكلة التاريخ. لن يفعلا ذلك.

إلقاء اللوم على TLS في انحراف التواريخ

عبر TLS (--ssl1، --ssl2)، يضيف إعداد الاتصالات تأخيرا زمنيا، وفي ترحيل كبير (أكثر من 50,000 رسالة) يتراكم هذا التأخير حتى يصل إلى ساعات. لكنه لا يمس التواريخ: تحمل كل نسخة التاريخ الذي يمرره imapsync، بصرف النظر عن الوقت الذي تصل فيه فعلا.

قراءة سجلات imapsync: ما الذي يقوله المخرج فعليا

يُنتج imapsync سجلات مفصّلة، وهذا رائع. لكن مخرج السجل قد يكون مضللا فيما يخص التواريخ.

هكذا يبدو سطر نقل ناجح نموذجي:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

كلا التاريخين متطابقان. وهذا يعني أن imapsync أرسل INTERNALDATE الصحيح إلى الوجهة. وتحتفظ Microsoft 365 وOutlook.com وGmail جميعا بالتاريخ الذي تُعطى إياه. لكن تطابق التاريخين لا يثبت إلا أن النسخة أمينة للمصدر: إذا كان تاريخ المصدر خاطئا أصلا، يعرض العمودان نفس التاريخ الخاطئ.

تريد التحقق مما حدث فعلا؟ بعد الترحيل، اتصل بالوجهة باستخدام برنامج IMAP وتحقق من INTERNALDATE مباشرة:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

إذا كان التاريخ المُعاد ليس تاريخ إرسال الرسالة، انظر إلى نفس الرسالة في المصدر: ستجد نفس التاريخ الخاطئ هناك. لم يكذب السجل، بل نسخ ما أُعطي له.

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

عمليات ترحيل imapsync واسعة النطاق: حيث تتضاعف مشاكل التواريخ

ترحيل صندوق بريد واحد باستخدام imapsync مزعج عندما تتلف التواريخ. لكن مزودي الخدمات المدارة وأقسام تقنية المعلومات التي تشغّل imapsync عبر مئات صناديق البريد يواجهون مشكلة بمقياس مختلف كليا.

تخيل سيناريو ترحيل نموذجيا لمؤسسة كبيرة. أنت تنقل 200 صندوق بريد من خادم Zimbra إلى Microsoft 365. تكتب نصا برمجيا يمر على قائمة CSV من المستخدمين، ويستدعي imapsync لكل واحد منهم. يعمل الترحيل خلال عطلة نهاية الأسبوع. صباح الإثنين، لديك 200 صندوق بريد بتواريخ خاطئة، وحوالي 1.2 مليون رسالة إجمالا تعرض طابع وقت الترحيل.

هل يمكنك إعادة تشغيل imapsync لإصلاح ذلك؟ من الناحية التقنية نعم، لكن imapsync سيتجاهل الرسائل الموجودة أصلا في الوجهة (فهو مصمم ليكون idempotent). ستحتاج إلى --delete2 لحذف رسائل الوجهة وإعادة نقلها، وهذا أمر خطير على صندوق بريد في بيئة الإنتاج. وإذا كانت تواريخ المصدر هي المشكلة، فإن التشغيل الثاني ينسخ نفس التواريخ الخاطئة مرة أخرى.

يجرب بعض المسؤولين نهجا مختلطا: تشغيل imapsync مع --dry أولا للاختبار، ثم الترحيل الفعلي. لكن --dry يحاكي النقل فقط: يُظهر التواريخ التي سيمررها imapsync، لا ما إذا كانت تواريخ إرسال الرسائل الفعلية. لا شيء يحذّرك من أن تواريخ المصدر خاطئة أصلا.

الإصلاحات الذاتية وحدودها

إذا بحثت في المنتديات وقوائم البريد (لا تزال قائمة imapsync-devel على SourceForge نشطة حتى أوائل 2026)، ستجد اقتراحات تتراوح من الإبداعية إلى الخطرة.

يقترح بعضهم استخدام سطر Perl واحد لتعديل INTERNALDATE على خادم الوجهة مباشرة. ويوصي آخرون بتصدير جميع الرسائل إلى تنسيق mbox، والتلاعب بالتواريخ، وإعادة الاستيراد. كتب بعضهم نصوص Python تستخدم imaplib لجلب الرسائل وتعديلها وإعادة إدراجها.

تشترك كل هذه الأساليب في نفس المشاكل الجوهرية. كيف تتعامل مع رسائل S/MIME الموقعة دون كسر التوقيع؟ ماذا عن هياكل MIME متعددة الأجزاء بحدود متداخلة؟ الرؤوس غير ASCII المشفرة بـ RFC 2047؟ الرسائل المشفرة بـ PGP التي لا يمكنك حتى فحص محتواها؟ نص برمجي يتعامل مع 50 رسالة اختبار في بيئة تطوير سيتعطل عند الحالات الحدية في صندوق بريد إنتاجي يحتوي على 30,000 رسالة.

والسؤال الأكبر الذي لا يسأله أحد حتى يصبح الوقت متأخرا: كيف تتحقق من أن كل رسالة معدلة لا تزال سليمة؟ من أن المرفقات لم تتلف، ومن أن السلاسل لا تزال تعمل، ومن أن جدول البيانات الذي بحجم 85 ميجابايت الذي أرسله أحدهم عام 2020 نجا من التلاعب؟

(إذا حاولت من قبل تحليل رؤوس البريد الخام في Perl، فأنت تعلم أن الأمر ليس بالضبط نشاطا مريحا لبعد ظهر هادئ.)

كيف يصلح Redate.io مشاكل تواريخ imapsync

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

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

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

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

يعمل Redate.io أيضا على عمليات ترحيل حدثت قبل أشهر أو سنوات. رأس Date: لا تنتهي صلاحيته، ولا تنتهي كذلك القدرة على تصحيح ما حدث خطأ.

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

imapsync لم يحفظ التواريخ؟ كيفية إصلاحها