English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
التواريخ الثلاثة داخل كل رسالة
كل رسالة مخزنة على خادم 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 كبيانات وصفية.
عندما تُسلَّم رسالة بشكل عادي (دون ترحيل)، يحدد خادم IMAP قيمة INTERNALDATE عند لحظة الاستلام، وهي قيمة قريبة جدا من رأس Date، غالبا في حدود ثوان أو دقائق. تستخدم عملاء البريد الإلكتروني INTERNALDATE غالبا كـ "تاريخ الاستلام" لأنها تعكس اللحظة التي استقبل فيها الخادم الرسالة فعليا.
الأمر يصبح أكثر تعقيدا هنا: عندما تُدرَج رسالة عبر أمر IMAP APPEND (وهو ما تستخدمه أدوات الترحيل)، يسمح أمر APPEND للعميل بتحديد INTERNALDATE بشكل صريح. أدوات الترحيل المصممة جيدا تستخدم هذه الخاصية للحفاظ على INTERNALDATE الأصلية من الخادم المصدر. لكن حتى عندما تُضبط INTERNALDATE بشكل صحيح، فإن مشكلة رأس "Received" (المشروحة أدناه) يمكن أن تظل تتجاوز التاريخ المعروض في كثير من عملاء البريد.
3. سلسلة رؤوس "Received"
في كل مرة تعبر فيها رسالة خادم بريد، يضيف ذلك الخادم رأس "Received" جديدا في مقدمة الرسالة. يُنشئ ذلك سلسلة من رؤوس Received تسجّل المسار الذي سلكته الرسالة من المرسل إلى المستلم. يُظهر أحدث رأس Received (الموجود في الأعلى) آخر خادم تعامل مع الرسالة، بينما يُظهر أقدمها (في الأسفل) أول خادم.
قد تحتوي رسالة عادية على 3 إلى 6 رؤوس Received، توثّق الرحلة من خادم المرسل الصادر، عبر أي خوادم ترحيل، وصولا إلى خادم المستلم الوارد. يتضمن كل رأس Received طابعا زمنيا. إليك مثال مبسط:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
كيف تختار عملاء البريد التاريخ الذي تعرضه
Outlook (سطح المكتب، الويب، الجوال)
يستخدم Microsoft Outlook مزيجا من INTERNALDATE ورأس "Received" الأعلى لتحديد تاريخ "الاستلام" المعروض في صندوق الوارد. عمليا، يميل Outlook إلى إعطاء الأولوية للطابع الزمني من أحدث رأس Received لعمود "استلم". أما عمود "أُرسل" فيستخدم رأس Date. وبما أن Outlook يفرز افتراضيا بحسب عمود "استلم"، فإن الطابع الزمني لرأس Received هو ما يراه المستخدمون أولا.
Apple Mail
يستخدم Apple Mail على macOS و iOS بشكل أساسي INTERNALDATE من IMAP لعرض التاريخ. إذا حُفظت INTERNALDATE بشكل صحيح أثناء الترحيل، فقد يعرض Apple Mail التاريخ الصحيح، ولكن فقط إذا حُددت INTERNALDATE صريحا خلال عملية APPEND. إذا لم تحدد أداة الترحيل INTERNALDATE، يستخدم الخادم افتراضيا وقت الإدراج (تاريخ الترحيل). لمزيد من التفاصيل حول تأثير ذلك على مستخدمي Apple Mail، راجع تاريخ خاطئ في Apple Mail بعد الترحيل.
Thunderbird
يوفر Mozilla Thunderbird أكبر قدر من المرونة. يمكنه عرض كل من "Date" (من رأس Date) و"Received" (من رؤوس Received). بشكل افتراضي، يعرض Thunderbird قيمة رأس Date، بمعنى أن التواريخ قد تبدو صحيحة في Thunderbird حتى عندما تكون خاطئة في Outlook. مع ذلك، لا يزال عمود "Received" في Thunderbird يعرض تاريخ الترحيل. راجع تاريخ خاطئ في Thunderbird بعد الترحيل لمزيد من التفاصيل.
واجهة Gmail على الويب
يستخدم عميل Gmail على الويب رأس Date لعرض التاريخ الأساسي. لهذا غالبا يُظهر Gmail على الويب تواريخ صحيحة حتى بعد الترحيل. لكن قيمة IMAP INTERNALDATE على خادم Gmail تظل خاطئة، وهذا يؤثر على كل عميل IMAP يتصل بذلك الحساب. التباين بين Gmail على الويب و Outlook أو Apple Mail مصدر شائع للالتباس، ويستهلك وقتا كبيرا من عمل المسؤولين في استكشاف الأعطال.
لماذا يكسر IMAP APPEND التواريخ
ماذا يحدث أثناء الترحيل
عندما تنقل أداة ترحيل رسالة من الخادم أ إلى الخادم ب، تتصل الأداة بالخادم أ عبر IMAP وتنزّل الرسالة الخام، ثم تتصل بالخادم ب وتستخدم أمر APPEND لإدراجها. خلال عملية الإدراج هذه، يعالج الخادم ب الرسالة الواردة ويضيف رأس "Received" جديدا بالطابع الزمني الحالي، أي تاريخ الترحيل. هذا سلوك شائع في العديد من تطبيقات IMAP. يعامل الخادم كل عملية APPEND كتسليم جديد للرسالة.
النتيجة: سلسلة رؤوس ملوّثة
بعد الترحيل، تبدو رؤوس Received في الرسالة كما يلي:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
رأس Received الخاص بأداة الترحيل يصبح الآن أعلى إدخال. أي عميل بريد يستخدم رأس Received الأعلى لتحديد تاريخ العرض (Outlook بشكل خاص) سيعرض "11 أبريل 2025" عوضا عن "15 يناير 2024". رأس Date الأصلي ورؤوس Received الأصلية تظل سليمة تحتها، لكنها لم تعد في الموضع الذي تعطيه عملاء البريد الأولوية.
حتى المعالجة الجيدة لـ INTERNALDATE لا تمنع هذه المشكلة
بعض أدوات الترحيل تحدد INTERNALDATE بشكل صحيح خلال APPEND. على سبيل المثال، يحافظ imapsync صريحا على INTERNALDATE الخاصة بالخادم المصدر. لكن رأس Received يُضاف من قبل الخادم الوجهة، لا من قبل أداة الترحيل. أداة الترحيل لا سيطرة لها على هذا السلوك. حتى مع الحفاظ المثالي على INTERNALDATE، يظل رأس Received الأعلى يحمل تاريخ الترحيل، وتستمر عملاء مثل Outlook في عرض التاريخ الخاطئ.
فما الذي يمكن فعله فعليا حيال ذلك؟
أي أدوات ترحيل تضيف رؤوس Received
كل أداة ترحيل IMAP تتسبب في هذه المشكلة لأن رأس Received يُضاف من قبل الخادم الوجهة، لا من قبل أداة الترحيل نفسها. محتوى الرأس المُضاف يختلف بحسب الأداة والخادم رغم ذلك.
BitTitan MigrationWiz يضيف رأس Received يحتوي على "mx.migrationwiz.com". CloudM Migrate يضيف رؤوسا تشير إلى "cloudm.io". imapsync يتسبب في رأس Received عام من الخادم الوجهة. GSMMO يضيف رؤوسا تحتوي على إشارات إلى "gmailapi.google.com".
الحل: استرجاع التواريخ الصحيحة
الخبر الجيد هو أن معلومات التاريخ الصحيحة لا تزال موجودة داخل كل رسالة. رأس Date الأصلي سليم. رؤوس Received الأصلية سليمة أيضا. المشكلة أن رأسا ملوّثا يجلس فوقها.
يحلل محرك التصحيح الخاص بـ Redate.io سلسلة الرؤوس الكاملة لكل رسالة متأثرة، معتمدا على اكتشاف الشذوذ في التواريخ عبر سلسلة الرؤوس بأكملها، بشكل يعمل بصرف النظر عن أداة الترحيل المستخدمة، لتحديد الرؤوس التي تحتاج إلى تصحيح بدقة. خط أنابيب التحليل المتعدد المراحل يتعامل مع حالات خاصة تعثر الأساليب الأبسط: الرسائل الموقعة بـ S/MIME، المحتوى المشفر بـ PGP، بنى multipart/alternative، مشاكل Content-Transfer-Encoding، الرؤوس غير ASCII (RFC 2047)، المرفقات الكبيرة الحجم، وحدود MIME التالفة.
بعد التصحيح، تمر كل رسالة بعملية تحقق من السلامة للتأكد من أن بنية الرسالة والمحتوى والمرفقات محفوظة تماما كما هي. النسخ الأصلية لا تُحذف تلقائيا؛ بل تُنقل إلى مجلد نسخ احتياطي مرئي داخل صندوق البريد وتبقى فيه إلى أن يزيلها العميل.
هل يمكن كتابة نص برمجي لمحاولة القيام بذلك بنفسك؟ من الناحية التقنية، نعم. لكن الفرق بين نص يعمل على معظم الرسائل ونظام يعمل على كل الرسائل دون إتلاف رسالة واحدة هو ما تتطلبه أشهر من العمل الهندسي. وحين يتعلق الأمر بصندوق بريد كامل يحتوي مثلا على 15,000 رسالة، فإن نسبة فشل صغيرة تعني مئات الرسائل التالفة بصمت دون أي وسيلة للتحقق من ما حدث خطأ.
هل تريد معرفة عدد الرسائل بتواريخ خاطئة في صندوق بريدك؟ ابدأ تحليلا مجانيا مع Redate.io للحصول على عدد فوري للرسائل المتأثرة، دون حاجة إلى الدفع.