التواريخ الثلاثة داخل كل رسالة
كل رسالة مخزنة على خادم IMAP تحمل على الأقل ثلاث قيم تاريخ مميزة. فهم كيف تعمل هذه التواريخ، وكيف تختار عملاء البريد أيها يعرض، هو المفتاح لفهم لماذا يكسر الترحيل التواريخ. هذه المقالة تحليل تقني معمق لنظام تواريخ IMAP، موجهة لمسؤولي تقنية المعلومات ولكل من يريد فهم السبب الجذري لمشاكل التواريخ بعد الترحيل.
1. رأس "Date" وفق RFC 2822
رأس "Date" معرف في RFC 2822 (صيغة رسائل الانترنت). يحدده عميل البريد للمرسل لحظة انشاء الرسالة وارسالها. هذا الرأس جزء من جسم الرسالة نفسه، يسافر مع الرسالة ولا تعدله خوادم البريد في مسار التسليم. رأس Date نموذجي يبدو:
Date: Mon, 15 Jan 2024 09:32:17 +0100
رأس Date يمثل "تاريخ الارسال" للرسالة. هو التاريخ الأكثر موثوقية لأنه يحدد مرة واحدة ولا يعدل أبدا. لكنه يعكس ساعة المرسل، التي قد تكون غير مضبوطة. في حالات نادرة، قد يكون رأس Date مفقودا تماما (خاصة في اشعارات النظام الآلية أو الرسائل المشوهة).
2. IMAP INTERNALDATE
INTERNALDATE معرفة في RFC 3501 (بروتوكول IMAP4rev1). قيمة بيانات وصفية من جانب الخادم تمثل تاريخ ووقت تسليم الرسالة للخادم. على عكس رأس Date، INTERNALDATE ليست جزءا من رسالة البريد نفسها. تخزن بشكل منفصل بواسطة خادم IMAP كبيانات وصفية.
عندما تصل رسالة جديدة عبر SMTP، يحدد خادم IMAP الـ INTERNALDATE للحظة الاستلام. عندما تدرج رسالة عبر IMAP APPEND (كما يحدث أثناء الترحيل)، يمكن تحديد INTERNALDATE صراحة في أمر APPEND. إذا لم تحدد، يستخدم الخادم الوقت الحالي.
3. رؤوس "Received"
رؤوس "Received" تضاف بواسطة كل خادم بريد (MTA) يتعامل مع الرسالة في مسار تسليمها. كل رأس "Received" يسجل من أين جاءت الرسالة ومتى وعبر أي خادم. الرسالة النموذجية تحمل 3 إلى 8 رؤوس "Received" مرتبة زمنيا عكسيا (الأحدث في الأعلى).
هذا مهم لأن عملاء البريد مثل Outlook تقرأ رأس "Received" الأعلى (الأحدث) لتحديد متى "استلمت" الرسالة.
كيف يكسر الترحيل سلسلة التواريخ
مشكلة IMAP APPEND
عندما تدرج أداة ترحيل رسالة في الخادم الوجهة عبر IMAP APPEND، يمكن أن يحدث أمران يؤثران على التاريخ: الخادم الوجهة يضيف رأس "Received" جديدا بالطابع الزمني الحالي (هذا سلوك إلزامي في كثير من خوادم IMAP)، وINTERNALDATE قد تتغير إذا لم تنقلها أداة الترحيل بشكل صحيح.
أي تاريخ يستخدمه كل عميل
هنا مصدر الارتباك. كل عميل بريد يستخدم مصدر تاريخ مختلف:
Outlook Desktop: يستخدم بشكل أساسي رأس "Received" الأحدث لعمود "مستلم". واجهة Gmail على الويب: تستخدم رأس "Date" عادة. Apple Mail: يستخدم INTERNALDATE ورؤوس "Received". Thunderbird: يعرض كلا من "Date" و"Received" في أعمدة منفصلة. OWA: يستخدم رؤوس "Received" وINTERNALDATE.
هذا التباين يعني أن نفس صندوق البريد بعد الترحيل يمكن أن يبدو صحيحا في عميل وخاطئا في آخر.
لماذا لا يكفي الحفاظ على INTERNALDATE
بعض أدوات الترحيل (مثل imapsync مع --syncinternaldates) تحافظ على INTERNALDATE الأصلية. هذا يساعد العملاء التي تعتمد على INTERNALDATE لكنه لا يمنع مشكلة رأس "Received" الجديد. العملاء التي تقرأ رأس "Received" الأحدث (وهذا يشمل Outlook، العميل الأكثر استخداما في المؤسسات) ستعرض تاريخ الترحيل بصرف النظر عن قيمة INTERNALDATE.
الإصلاح التقني
الإصلاح الحقيقي يتطلب تصحيح البيانات على مستوى الخادم بحيث تعمل جميع مصادر التاريخ بشكل متسق. Redate.io يحقق ذلك عبر محرك تصحيح خاص يعالج كل رسالة عبر خط أنابيب تحليل متعدد المراحل. المحرك يتعامل مع هياكل MIME المعقدة ورسائل S/MIME الموقعة ورسائل PGP المشفرة وعشرات الحالات الخاصة. كل تصحيح يتحقق منه قبل الانتهاء.
لكن القيام بذلك يدويا بنص برمجي؟ فهم المشكلة شيء، لكن معالجة 15,000 رسالة دون إتلاف واحدة شيء مختلف تماما. نص يعمل على 10 رسائل اختبارية لن يتعامل مع حالات مثل حدود MIME التالفة أو ترميز Content-Transfer-Encoding الخاص أو رؤوس RFC 2047 غير ASCII. والأسوأ: بدون تحقق آلي، لن تعرف أن شيئا فشل حتى فوات الأوان، بدون وسيلة لمعرفة ما حدث خطأ.
هل تريد معرفة عدد الرسائل بتواريخ خاطئة في صندوق بريدك؟ ابدأ تحليلا مجانيا مع Redate.io للحصول على عدد فوري للرسائل المتأثرة، بدون دفع مطلوب.