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

وعد --syncinternaldates (ولماذا لا يعمل)

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

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

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.

المشكلة هي: خادم الوجهة ليس ملزما باحترام ذلك التاريخ.

لماذا تتجاهل خوادم الوجهة INTERNALDATE

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

Microsoft 365 هو المذنب الأكبر. عندما تصل رسالة عبر IMAP APPEND، يختم خط أنابيب نقل Exchange رأس Received جديدا بالتاريخ الحالي، ثم يعين INTERNALDATE بناء على طابع التسليم الزمني ذاك. لا يهم أي تاريخ طلبه imapsync. خادم M365 يتجاوزه.

Google Workspace (Gmail) يتصرف بشكل مختلف لكن لا يزال يمكن أن يسبب مشاكل. تطبيق Gmail لـ IMAP يحترم INTERNALDATE من APPEND في معظم الحالات، لكنه يضيف رأس Received خاصا به. إذا كان برنامج البريد الذي يقرأ الصندوق يعطي أولوية لرؤوس Received على INTERNALDATE للعرض (و Outlook يفعل ذلك بالضبط)، فإن التواريخ لا تزال تبدو خاطئة.

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

نسيان --syncinternaldates تماما

العلامة ليست مفعلة افتراضيا. إذا شغلت الأمر الأساسي imapsync --host1 المصدر --host2 الوجهة --user1 مستخدم --user2 مستخدم بدونها، لا يحاول imapsync الحفاظ على التواريخ إطلاقا.

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

بعض الأدلة توصي باستخدام --addheader لحقن رأس مخصص أثناء الترحيل. إذا أضفت رؤوسا فأنت تعدل الرسالة، مما قد يدفع خادم الوجهة لمعاملتها كرسالة "جديدة".

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

علامتا --minage و --maxage تصفيان الرسائل المراد ترحيلها بناء على العمر. لا تؤثران على كيفية معالجة التواريخ في الوجهة.

تفاوض SSL يسبب انحراف الطوابع الزمنية

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

قراءة سجلات 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 الصحيح للوجهة. لكن هذا لا يعني أن خادم الوجهة خزن ذلك التاريخ فعلا. imapsync يبلغ عما طلبه، ليس عما قبله الخادم.

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

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

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

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

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

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

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

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

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

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

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

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

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