من POP إلى IMAP: رسائلك القديمة تحمل تاريخ اليوم

السيناريو الكلاسيكي صباح الاثنين

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

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

POP3 مقابل IMAP: فرق جوهري في التخزين

لفهم سبب المشكلة، لا بد أولاً من فهم كيفية عمل POP3، وما الذي يجعله مختلفاً جذرياً عن IMAP.

مع POP3، لا يعدو الخادم كونه صندوق بريد مؤقتاً. يتصل برنامجك (Outlook أو Thunderbird أو Apple Mail) بالخادم، ويُنزّل الرسائل، ثم يحذفها من الخادم (أو يتركها حسب إعداداتك). بعد ذلك، تعيش الرسائل محلياً فحسب: في ملف .pst لـ Outlook، في الملف الشخصي المحلي لـ Thunderbird، أو في قاعدة بيانات على قرصك الصلب.

مع IMAP، الأمر معكوس: الرسائل موجودة على الخادم، وبرنامجك لا يفعل أكثر من عرض ما هو مخزن عن بُعد. من هنا تأتي المزامنة التلقائية بين كل أجهزتك.

المشكلة تظهر عند الانتقال بين الطريقتين، أي حين ترفع رسائلك المحلية القديمة POP إلى خادم IMAP.

أمر IMAP APPEND: الجذر الحقيقي للمشكلة

حين يرفع برنامج البريد رسالة محلية إلى خادم IMAP، يستخدم الأمر IMAP APPEND. هذا الأمر يقول للخادم ببساطة: "خزّن هذه الرسالة في هذا المجلد".

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

بمعنى آخر: مهما كان تاريخ 2018 مدرجاً في ترويسات الرسالة، إن لم يُبلّغ أحد الخادم بأن "هذا البريد يعود إلى 2018"، يستنتج الخادم أنه وُدع الآن ويُسنّد إليه INTERNALDATE بتاريخ اليوم.

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

لماذا يختلف هذا عن الترحيل بين خوادم IMAP

في الترحيل الاعتيادي من خادم IMAP إلى آخر (باستخدام BitTitan أو CloudM أو imapsync أو غيرها)، المشكلة مختلفة نوعاً ما. تنسخ أداة الترحيل الرسائل من خادم إلى آخر، وفي هذه الحالة يمكنها (نظرياً) نقل INTERNALDATE الأصلية إلى خادم الوجهة عبر أمر APPEND. المشكلة هناك أن بعض الأدوات تُضيف ترويسة Received: بتاريخ الترحيل، مما يُربك العرض في عملاء كـ Outlook.

في حالتك، أنت تنطلق من بيانات محلية بالكامل. لا يوجد INTERNALDATE أصلي لنسخه. ملف .pst أو الملف الشخصي لـ Thunderbird يخزن الرسائل بصيغته الخاصة مع بياناته الوصفية الداخلية. حين يُعيد برنامج البريد قراءة هذه الرسائل لرفعها إلى خادم IMAP، يُعيد بناء أمر APPEND انطلاقاً من محتوى الرسالة. وفي أغلب الأحيان، لا يُرسل تاريخاً صريحاً.

النتيجة: يستقبل خادم IMAP مئات أو آلاف الرسائل خلال دقائق، ويُسنّد إلى جميعها النطاق الزمني ذاته: الآن.

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

أي تاريخ يعرضه كل برنامج، ولماذا

لا تتصرف برامج البريد كلها بالطريقة ذاتها. هذه نقطة يكتشفها كثير من مدراء تقنية المعلومات في وقت متأخر.

Outlook (في إصداراته الحديثة، خاصة منذ تحديثات 2023-2024) يستخدم INTERNALDATE من الخادم لعمود "المستلمة". فيعرض تاريخ الرفع، لا تاريخ الإرسال الأصلي. لمزيد من التفاصيل حول هذا السلوك، يُفيد مقال Outlook: تاريخ الاستلام IMAP مقابل تاريخ الإرسال.

Gmail / Google Workspace وThunderbird لهما سلوك أكثر دقة. Gmail مثلاً قد يستخدم أحياناً حقل Date: في ترويسة الرسالة للعرض، مما يوحي بأن كل شيء على ما يرام... حتى تحاول الترتيب حسب التاريخ وتكتشف أن الترتيب عشوائي تماماً.

Apple Mail يعرض عادةً التاريخ المستخرج من ترويسة Date:، لكن الترتيب والبحث يعتمدان على INTERNALDATE في الخلفية. فقد تبدو رسائلك "مؤرخة بشكل صحيح" بصرياً، لكن وظيفة الترتيب لا تعمل بشكل سليم. لمزيد من التفاصيل حول سلوك Apple Mail، انظر Apple Mail: تواريخ خاطئة بعد الترحيل.

البشرى الجيدة: التاريخ الأصلي لا يزال سليماً

ترويسة Date: في كل رسالة، التي تحتوي تاريخ الإرسال (أو الاستقبال) الحقيقي، لم يمسّها أحد. لا تزال موجودة في جسم الرسالة. وهي ما تراه حين تفتح بريداً وتُطالع تفاصيله.

ما "أفسده" خادم IMAP هو INTERNALDATE فحسب، تلك البيانات الوصفية الخارجية عن الرسالة. الرسالة نفسها سليمة تماماً.

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

مشكلة الحجم: 3000 رسالة تختلف عن 3

ربما تقول لنفسك: "أحذف وأُعيد الاستيراد، هذه المرة بشكل صحيح". على 5 أو 10 رسائل تجريبية، نعم يصلح ذلك. على صندوق يضم 8000 رسالة مع مجلدات متداخلة ومرفقات ضخمة ورسائل موقعة بـ S/MIME وسلاسل محادثات تعود إلى 2015... القصة مختلفة تماماً.

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

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

المشكلة معروفة جيداً لدى مدراء النظم الذين يتعاملون مع عمليات ترحيل ضخمة. فهم سبب تلف التواريخ شيء، وإصلاح 15000 رسالة بشكل نظيف مع الحفاظ على بنية كل رسالة شيء آخر تماماً. للتعمق أكثر في هذا الموضوع، يُفصّل مقال هل يمكن إصلاح تواريخ الرسائل بعد الترحيل؟ مختلف المقاربات وحدودها.

كيف تتعامل Redate.io مع هذه الحالة تحديداً

Redate.io صُممت بالضبط لهذا النوع من المواقف. يحدد محرك التحليل الخاص بها الرسائل التي لا يتطابق فيها INTERNALDATE مع التاريخ الوارد في ترويسات الرسالة، سواء تعلق الأمر بترحيل POP إلى IMAP، أو ترحيل بين خوادم IMAP، أو رفعاً يدوياً للأرشيفات المحلية.

يفحص خط أنابيب التحليل متعدد المراحل سلسلة ترويسات كل رسالة، يُتحقق من مطابقتها لمعيار RFC، ويُعيد بناء بيانات التاريخ الوصفية دون المساس بمحتوى الرسالة: لا النص، ولا المرفقات، ولا بنية MIME، ولا التوقيعات الرقمية إن وُجدت. كل رسالة مُصحَّحة تخضع للتحقق الفردي قبل اعتمادها.

تُحفظ الرسائل الأصلية في مجلد نسخ احتياطي مرئي لمدة 30 يوماً. إن لم يعجبك شيء، تستطيع الاسترداد.

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

تتصل Redate.io مباشرة بصناديقك عبر Google Workspace (تفويض نطاق)، أو Microsoft 365 (Azure AD)، أو IMAP مباشر. لا تثبيت محلي. لا تصدير لملفات .pst تتعامل معها يدوياً.

لمدراء النظم الذين يديرون صناديق بريد متعددة ويريدون تجارب عملية في هذا النوع من الحالات، مقال كيف تصلح شركات MSP تواريخ بريد العملاء بعد الترحيل قراءة مُكمِّلة مفيدة. وللتفاصيل الخاصة بـ Thunderbird، الذي له سلوكه المميز عند الانتقال من POP إلى IMAP، انظر Thunderbird يعرض تاريخاً خاطئاً بعد الترحيل.

إن كان الأمر لا يزال أمامك: كيف تتفادى المشكلة

إن لم تكن قد رفعت أرشيفاتك المحلية إلى خادم IMAP بعد، أو كنت تخطط لترحيل حسابات POP أخرى في مؤسستك، إليك ما يجب أن تضعه في اعتبارك.

• تحقق مما إذا كان برنامج بريدك يدعم تمرير التاريخ صراحةً في أمر APPEND. Thunderbird مثلاً عرف سلوكيات متفاوتة حسب الإصدار في هذه النقطة بالذات.
• أجرِ أولاً اختباراً على حساب تحقق يضم 50-100 رسالة تمثيلية: رسائل قديمة، مع مرفقات، رسائل موقعة. تحقق من التواريخ المعروضة في برامج بريد مختلفة.
• خطط للتصحيح قبل أن يبدأ المستخدمون النهائيون العمل على الصندوق المُرحَّل. تصحيح التواريخ في صندوق نشط أعقد من صندوق فارغ ما بعد الترحيل.
• وثّق عدد الرسائل قبل الترحيل وبعده. هذه الطريقة الوحيدة للكشف عن الفقدان الصامت للرسائل.

للحصول على قائمة فحص شاملة لكل ما يجب التحقق منه قبل الترحيل وبعده، يُغطي مقال قائمة فحص ترحيل البريد: منع مشاكل التواريخ جميع الحالات.

رسائلك القديمة تحمل تاريخ اليوم بعد الانتقال من POP إلى IMAP؟ ابدأ فحصاً مجانياً على Redate.io لقياس حجم المشكلة وتصحيح بيانات التاريخ الوصفية دون المساس بمحتوى رسائلك.