ترحيل cPanel: تواريخ بريد خاطئة

صباح الاثنين الذي لا يُنسى

لقد أتممت للتو ترحيل استضافة مشتركة على cPanel إلى Google Workspace أو Microsoft 365. سارت العملية بشكل جيد، وأصبحت صناديق البريد متاحة، ويتصل المستخدمون بلا مشكلة. ثم، حوالي 9:15 صباحاً، يصل أول بلاغ: "رسائلي القديمة كلها تحمل نفس التاريخ، تاريخ عطلة نهاية الأسبوع الماضية." ثم يأتي بلاغ ثانٍ. ثم عشرة.

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

cPanel وRoundcube وHorde: سياق IMAP خاص

الاستضافة المشتركة على cPanel عبارة عن خادم Linux يشغّل خادم IMAP (عادةً Dovecot) مع Roundcube أو Horde كواجهة بريد إلكتروني. لا يوجد في هذا أي شيء غريب. لكن هذا السياق له خصائص معينة تجعل عمليات الترحيل إلى المنصات المؤسسية أكثر تعقيداً مما تبدو عليه.

أولاً، صناديق بريد cPanel تتراكم فيها رسائل على مدى سنوات، بل أحياناً عقد كامل. عميل كان يستضيف نطاقه على خادم مشترك منذ عام 2013 قد يمتلك أرشيفاً عميقاً جداً. هذا الحجم، مقروناً بطريقة تنفيذ الترحيل، يُهيئ بيئة خصبة لمشكلة التواريخ.

ثانياً، الأدوات المستخدمة في هذه الترحيلات غالباً ما تكون إما الأداة الأصلية لـ cPanel (قسم "Migrations" في WHM)، أو imapsync الذي يُشغَّل عبر سطر الأوامر من قِبل مزود الاستضافة أو مختص تقنية المعلومات، أو حلول شائعة كـ GSMMO للترحيل إلى Google Workspace.

لماذا تتلف التواريخ بعد ترحيل cPanel

لفهم المشكلة، لا بد من استيعاب مفهومين متمايزين: ترويسة Date: في الرسالة وINTERNALDATE في IMAP.

ترويسة Date: مكتوبة في جسم الرسالة الخام لحظة إرسالها، وفقاً للمعيار RFC 2822. وهي تُشير إلى وقت كتابة الرسالة وإرسالها. هذه الترويسة لا تتغير أبداً إلا في حالة التعديل المتعمد للرسالة.

أما INTERNALDATE فهي بيانات وصفية يربطها خادم IMAP بكل رسالة مُخزَّنة، وهي مستقلة عن محتوى الرسالة. حين تصل رسالة عادياً إلى الخادم، تُحدَّد قيمة INTERNALDATE انطلاقاً من ترويسات Received: الخاصة بالرسالة، أو من تاريخ الإيداع إذا سُلِّمت الرسالة مباشرة. وهذه القيمة هي التي يعتمدها Outlook وThunderbird وأغلب عملاء البريد لترتيب الرسائل.

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

النتيجة: رسالة من عام 2019 تصل إلى Google Workspace بقيمة INTERNALDATE محددة ليوم الترحيل، وترويسة Received: مختومة بالأمس. يعرضها Outlook في صندوق الوارد كأنها وصلت للتو. ويُدمَّر كامل الترتيب الزمني للأرشيف.

أداة الترحيل في WHM / cPanel

الأداة المدمجة في WHM لترحيل حسابات cPanel إلى منصة أخرى تُولِّد هذه المشكلة بشكل شبه منهجي حين تكون الوجهة خادم IMAP خارجي (Google Workspace أو Microsoft 365). فهي تنسخ محتوى Maildir إلى الخادم الجديد عبر IMAP APPEND دون الحفاظ على INTERNALDATE الأصلية، فتحصل كل رسالة على طابع زمني يُطابق لحظة تنفيذ العملية.

imapsync والترحيلات اليدوية من cPanel

imapsync أداة قوية، لكن سلوكها الافتراضي لا يحفظ التواريخ دائماً. فبدون الخيارات الصحيحة (والإصدار المناسب)، يمكنها بكل بساطة أن تنسخ 40,000 رسالة منسوبةً جميعها إلى تاريخ تشغيل السكريبت. (وإن كنت قد تصفحت يوماً سجلات imapsync سطراً بسطر لتشخيص مشكلة تواريخ في صندوق بريد يحتوي 25,000 رسالة، فأنت تعرف أنها تجربة لا يتمنى أحد تكرارها.)

لنكن دقيقين: imapsync تمتلك خيارات للمحاولة في الحفاظ على التاريخ، لكن هذه الخيارات تتفاعل بشكل مختلف تبعاً للخوادم المصدر والوجهة، وفعاليتها غير مضمونة على جميع إعدادات cPanel / Dovecot.

GSMMO وأدوات الترحيل الشائعة

أداة Google Workspace Migration for Microsoft Outlook (GSMMO) مصممة أصلاً للترحيل من Outlook، لا من خادم IMAP مباشر. حين تُستخدم للترحيل من cPanel (عبر حساب IMAP مُهيَّأ في Outlook)، تتعرض التواريخ للمعالجة ذاتها: تُحدَّد قيمة INTERNALDATE على Google Workspace وفق تاريخ الترحيل. مشكلة GSMMO وتواريخ البريد الإلكتروني موثقة بشكل منفصل، نظراً لانتشارها الواسع.

أي عملاء البريد تتأثر؟

تلف التواريخ لا يظهر بنفس الطريقة في جميع عملاء البريد.

Outlook هو الأكثر تضرراً. فهو يعتمد على INTERNALDATE (أو ترويسة Received: الناتجة عن الترحيل) كمعيار أساسي للترتيب في المجلدات. بعد ترحيل cPanel غير المُدار بشكل صحيح، قد يعرض صندوق بريد في Outlook آلاف الرسائل المؤرشفة بتاريخ عطلة نهاية أسبوع الترحيل. إصلاح تواريخ imapsync في Outlook من أكثر الطلبات شيوعاً.

Gmail (Google Workspace) يعرض في الغالب التاريخ المستخرج من ترويسة Date: في قائمة الرسائل، لكن الترتيب قد يتأثر بـ INTERNALDATE في بعض الحالات. يُبلِّغ المستخدمون عن سلوك غير منتظم في البحث والفرز حسب التاريخ.

Apple Mail وThunderbird لديهما سلوك أكثر دقة، لكن لا أحدهما محصَّن ضد المشكلة، خاصةً حين تكون ترويسة Received: الخاصة بالترحيل في مقدمة السلسلة.

خبر جيد: التاريخ الأصلي لا يزال موجوداً

هذه هي التفصيلة التقنية التي تُغيِّر كل شيء. ترويسة Date: الأصلية للرسالة مكتوبة في جسم البريد الإلكتروني الخام. الترحيل لا يمسها. حين تفتح رسالة متأثرة وتستعرض ترويساتها الخام (في Gmail: "عرض النص الأصلي"، وفي Outlook: ملف > خصائص)، ترى Date: الأصلية سليمة، يعقبها ترويسة Received: واحدة أو أكثر تحمل أولاها تاريخ الترحيل.

هذه المعلومة موجودة دائماً، ويمكن توظيفها لإصلاح البيانات الوصفية. وهذا تحديداً ما يقوم به محرك التصحيح الخاص بـ Redate.io.

لماذا "إصلاحها بنفسك" أخطر مما يبدو

الإغراء موجود. تبدو المشكلة بسيطة: اقرأ التاريخ الأصلي، صحِّح البيانات الوصفية، انتقل إلى التالي. لكن بين فهم الآلية وإصلاح 12,000 رسالة في بيئة إنتاج دون خسارة رسالة واحدة، ثمة هوة واسعة.

بعض الحقائق التي لا تستوعبها السكريبتات المنزلية عادةً:

رسائل S/MIME موقعة أو PGP مشفرة: أي تعديل على بنية الرسالة يُبطل التوقيع التشفيري. رسالة كانت تجتاز التحقق من التوقيع قبل التصحيح قد تفشل فيه بعده. المستخدمون في البيئات ذات الامتثال التنظيمي (مكاتب المحاماة، القطاع المالي، قطاع الصحة) يكتشفون هذه المشكلة في أسوأ لحظة ممكنة.
ترويسات غير ASCII والترميز وفق RFC 2047: صناديق بريد cPanel تتراكم فيها سنوات من الرسائل القادمة من عملاء بريد متنوعة جداً. بعض الترويسات تحتوي أحرفاً مرمَّزة وفق RFC 2047. سكريبت مكتوب بشكل خاطئ يُعيد بناء الترويسات قد يُفسد هذه الترميزات بشكل غير مرئي.
هياكل MIME المتداخلة: رسالة تحتوي ثلاثة مرفقات وجسماً بصيغة HTML بديلة لها هيكل multipart معقد. أي خطأ بسيط في حدود MIME يجعل الرسالة غير قابلة للقراءة، أو الأسوأ: تختفي المرفقات دون أي رسالة خطأ.
حصص API وتحديد معدل الطلبات: Google Workspace وMicrosoft 365 تفرضان قيوداً صارمة على عدد عمليات IMAP في الدقيقة. سكريبت لا يُنفِّذ Exponential Backoff بشكل صحيح يُفجِّر أخطاء 429 في الساعة 3 صباحاً، وتستيقظ لتجد ترحيلاً ناقصاً لا تعرف بالضبط أين توقف.
استحالة التراجع: إذا حدث خطأ في منتصف الطريق، إلى أي حالة ستعود؟ هل لا تزال الرسائل الأصلية موجودة؟ هل لديك نسخ مكررة؟ Redate.io يحتفظ بالرسائل الأصلية في مجلد نسخ احتياطي مرئي لمدة 30 يوماً، تحديداً لتجنب هذا الوضع.

سكريبت يعمل على 50 رسالة اختبار في بيئة تطوير لن يعمل بالضرورة على 18,000 رسالة في صندوق بريد إنتاج موروث من استضافة cPanel منذ عام 2011.

كيف يُصحح Redate.io التواريخ بعد ترحيل cPanel

Redate.io يتصل مباشرة بصندوق البريد الوجهة (Google Workspace عبر تفويض النطاق، أو Microsoft 365 عبر Azure AD، أو خادم IMAP مباشر) ويبدأ بفحص مجاني لتحديد الرسائل التي تكون فيها البيانات الوصفية للتاريخ غير متسقة مع ترويسة Date: الأصلية.

يُطبِّق خط أنابيب التحليل متعدد المراحل بعد ذلك مطابقة الأنماط على توقيعات ترويسات Received: لتحديد تلك التي أدخلتها أدوات الترحيل (وتمييزها عن الترويسات المشروعة). يجري التصحيح المستهدف للبيانات الوصفية دون أي تعديل على محتوى الرسالة: النص والمرفقات والترويسات الأصلية، كل شيء يبقى سليماً. كل رسالة مُصحَّحة تخضع للتحقق منها بشكل فردي قبل التحقق من صحة العملية.

بالنسبة لترحيلات cPanel تحديداً، يتعرف المحرك على التوقيعات النموذجية لترحيلات Dovecot-to-IMAP وسكريبتات imapsync، بما فيها التكوينات الشائعة لدى مزودي الاستضافة المشتركة.

أدلة مخصصة حسب وجهة الترحيل

بحسب منصة الوجهة لترحيل cPanel الخاص بك، تصف الأدلة التالية الخطوات التفصيلية:

هل أجريت ترحيلاً من cPanel ويرى المستخدمون تواريخ غير صحيحة؟ ابدأ فحصاً مجانياً على Redate.io لتحديد عدد الرسائل المتأثرة بالضبط، دون أي تعديل قبل موافقتك.

رسائل بتواريخ خاطئة بعد ترحيل cPanel / Roundcube