eM Client: تواريخ خاطئة بعد استيراد PST أو Thunderbird

العَرَض: جميع رسائلك تحمل نفس التاريخ

انتهيت للتو من استيراد ملف PST إلى eM Client، أو ربما انتقلت من Thunderbird إلى صندوق البريد الجديد. جرى الاستيراد دون أخطاء ظاهرة. لكن حين فتحت صندوق الوارد، لاحظت شيئاً غريباً: مئات بل آلاف الرسائل تحمل كلها نفس التاريخ، تاريخ يوم الاستيراد. رسالة من 2019 تبدو كأنها وصلت أمس. عقد موقَّع قبل ثلاث سنوات يظهر كأنه وصل للتو.

الرد الطبيعي الأول هو إلقاء اللوم على eM Client. إعداد خاطئ، عمود ترتيب خاطئ، خلل في العرض... تبحث في الإعدادات. تتنقل بين "تاريخ الاستلام" و"تاريخ الإرسال". لا شيء يتغير. أو بالأحرى، يتغير شيء ما لكنه لا يحل جوهر المشكلة.

السبب أن المشكلة ليست في eM Client. هي في بيانات التعريف على الخادم.

السبب الحقيقي: INTERNALDATE IMAP مُستبدَل أثناء الاستيراد

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

كل رسالة على خادم IMAP تمتلك نوعين مختلفين من التواريخ:

• رأس الرسالة Date: (المحدد في RFC 2822): هو التاريخ الذي كتبه المُرسِل في الرسالة لحظة إرسالها. مُضمَّن داخل محتوى الرسالة، ولا يُمَس نظرياً.
• INTERNALDATE: بيانات تعريف على مستوى الخادم، خارجة عن الرسالة نفسها، تمثل التاريخ الذي وُضعت فيه الرسالة في صندوق البريد. هذه القيمة هي التي تعتمدها برامج البريد بالدرجة الأولى لترتيب الرسائل وعرضها.

عند استيراد PST أو الترحيل من Thunderbird، تقوم أداة الاستيراد (سواء كانت وحدة eM Client الأصلية أو أداة خارجية أو نسخاً يدوياً عبر IMAP) بإيداع الرسائل على خادم IMAP الوجهة. وإن لم تحافظ الأداة صراحةً على INTERNALDATE الأصلي وقت الإيداع، يُعيِّن الخادم تلقائياً INTERNALDATE الحالي، أي تاريخ ووقت الاستيراد.

النتيجة: 8000 رسالة مؤرشفة منذ 2017، كلها مختومة بـ"استُلمت" في لحظة الترحيل.

(بالمناسبة، إن سبق لك قراءة رؤوس رسالة خام عبر "عرض المصدر" في eM Client، ستلاحظ أن رأس Date: الأصلي لا يزال موجوداً وسليماً. هذا يؤكد أن المشكلة في INTERNALDATE على الخادم، لا في الرسالة ذاتها.)

لماذا تغيير عمود الترتيب لا يجدي نفعاً

مصدر الالتباس هو تمييز لا يعرفه كثيرون. في eM Client كما في Outlook وThunderbird، توجد عادةً عمودان للتاريخ:

• "تاريخ الاستلام" (أو "تاريخ الوصول"): مبني على INTERNALDATE الخادم.
• "التاريخ" أو "تاريخ الإرسال": مبني على رأس Date: داخل الرسالة.

يكتشف كثير من المسؤولين هذا ويظنون أنهم وجدوا الحل: التبديل إلى "تاريخ الإرسال" فيختفي الاضطراب بصرياً في eM Client. لكن هذا ليس دقيقاً تماماً.

في الواقع، حتى لو رتّبت حسب تاريخ الإرسال في eM Client، تبقى المشكلة قائمة لجميع العملاء والواجهات الأخرى التي تصل إلى نفس صندوق البريد. إن كان مستخدموك يطّلعون على رسائلهم من OWA أو Outlook على سطح المكتب أو تطبيق Gmail على الهاتف أو أي عميل مُهيَّأ بـ IMAP، فسيرون تواريخ الاستيراد. إعداد الترتيب في eM Client لا يُطبَّق إلا داخله، ولا يؤثر على البيانات المخزنة على الخادم.

فضلاً عن ذلك، في Microsoft 365 وGoogle Workspace، تُرتِّب الواجهة الويب الأصلية حسب INTERNALDATE. لا يمكنك تغيير هذا السلوك من جانب العميل.

الترتيب حسب تاريخ الإرسال ليس حلاً. هو ضمادة تغطي مشكلة حقيقية دون أن تعالجها.

الحالة الخاصة باستيراد PST

استيراد ملفات PST يستحق فقرة منفصلة. ملف PST (Personal Storage Table) صيغة مملوكة لـ Microsoft تخزِّن الرسائل وجهات الاتصال والتقاويم محلياً. حين تستورد PST في eM Client، ثمة سيناريوان محتملان:

• الاستيراد المحلي إلى حساب IMAP: يقرأ eM Client ملف PST ويدفع الرسائل إلى خادم IMAP الوجهة. إن لم يُحفَظ تاريخ الإيداع، يُستبدَل INTERNALDATE. هذه الحالة الأكثر شيوعاً، وهنا تتلف التواريخ.
• الاستيراد إلى مجلد محلي: تبقى الرسائل على الجهاز بعيداً عن الخادم. لا يوجد INTERNALDATE في هذا السياق، ويستطيع eM Client عرض التاريخ Date: من الرسالة. مشكلة التواريخ أقل هنا، لكن الفائدة العملية أقل أيضاً.

بالنسبة لـ Thunderbird، الوضع مشابه. سواء استخدمت وظيفة الاستيراد المدمجة في eM Client (التي تقرأ ملفات تعريف Thunderbird)، أو نسخت مجلدات mbox عبر IMAP، تُعاد إيداع الرسائل على الخادم دون ضمان لحفظ INTERNALDATE. وأي خادم يستلم رسالة دون تعليمات صريحة بالتاريخ سيختمها تلقائياً بتاريخ الاستلام.

أي منصات تتأثر؟

المشكلة ذاتها بصرف النظر عن منصة الوجهة، لأنها سلوك معياري لبروتوكول IMAP:

• Microsoft 365 / Exchange Online: يُستبدَل INTERNALDATE في أي استيراد لا يستخدم أمر IMAP APPEND مع معامل تاريخ صريح. ينطبق الأمر ذاته على الترحيل من Exchange داخل الشبكة.
• Google Workspace: السلوك مطابق. الرسائل المستوردة عبر eM Client أو أدوات خارجية تُعرض بتاريخ الاستيراد في Gmail وفي واجهة الإدارة.
• مزودو IMAP الكلاسيكيون (OVH، Infomaniak، Ionos، إلخ): لا معالجة خاصة للتاريخ عند استلام رسالة بـ APPEND. سيكون INTERNALDATE هو تاريخ الإيداع.

اتصل بنا أحد العملاء بعد ترحيل ما يقارب المئة صندوق بريد من Exchange 2013 إلى Microsoft 365، مستخدماً eM Client أداةً انتقالية لبعض حسابات VIP. النتيجة: الصناديق المرحَّلة عبر MigrationWiz كانت سليمة، لكن الصناديق التي مرت عبر eM Client حملت كلها تواريخ الاستيراد. لا داعي للقول إن المستخدمين المعنيين لم يُسعَدوا.

لماذا لن يحل سكريبت منزلي المشكلة بسهولة

من الناحية التقنية، قد يخطر لمن يفهم بروتوكول IMAP كتابة سكريبت لإصلاح INTERNALDATE. رأس Date: الأصلي موجود وسليم في كل رسالة. يكفي قراءته وإعادة بناء بيانات التعريف على الخادم وفقاً لذلك، أليس كذلك؟

نظرياً، نعم. عملياً، هذا حقل ألغام.

أولاً، الحالات الحافة تتراكم سريعاً في صندوق بريد إنتاجي. الرسائل الموقَّعة رقمياً بـ S/MIME حساسة بشكل خاص لأي تلاعب في البنية. الرسائل المشفرة بـ PGP كذلك. الرسائل ذات المرفقات الضخمة، أو حدود MIME غير المعيارية، أو ترميزات Content-Transfer-Encoding غير المعتادة، قد تتلف بصمت إن لم تكن المعالجة دقيقة. سكريبت يعمل على 50 رسالة اختبارية لن يعمل بشكل موثوق على صندوق بريد بـ 20,000 رسالة تمتد على 6 سنوات من السجلات.

ثانياً، إدارة حصص API. في Microsoft 365، حدود المعدل على Graph API أو EWS الساعة 3 فجراً أثناء دفعة تصحيح 8000 رسالة أمر يستلزم المتابعة. سكريبت غير مُشرَف عليه يواجه خطأ 429 Too Many Requests عند الرسالة رقم 3741 قد يكمل أو لا يكمل. ولن تعرف بالضرورة أي الرسائل عولجت.

والأهم: كيف تتحقق أن كل رسالة مُصحَّحة سليمة بعد المعالجة؟ السكريبت المنزلي لا يملك عادةً آلية تحقق فردية. Redate.io يفعل ذلك تلقائياً، لكل رسالة على حدة.

إصلاح التواريخ من المصدر مع Redate.io

Redate.io يعالج المشكلة من حيث توجد: على مستوى بيانات التعريف على الخادم، لا على مستوى عميل البريد.

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

يعتمد التصحيح على محرك خاص يُحلِّل سلسلة رؤوس كل رسالة كاملةً، ويُطابق أنماطاً على مئات من بصمات أدوات الاستيراد المعروفة (بما فيها سلوكيات eM Client وThunderbird واستيرادات PST)، ويُعيد بناء بيانات التاريخ بشكل مُستهدَف دون المساس بمحتوى الرسالة أو مرفقاتها أو بنيتها MIME.

كل رسالة مُصحَّحة تُتحقَّق منها فردياً. تُحفَظ النسخ الأصلية في مجلد نسخ احتياطي مرئي لمدة 30 يوماً، وهو ما لن يفعله أي سكريبت منزلي بشكل افتراضي.

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

قبل الترحيل القادم: ما الذي يجب التحقق منه

إن كنت تخطط لترحيل وتريد تفادي هذه المشكلة مسبقاً، نقطة التحقق بسيطة: هل تحافظ الأداة التي تستخدمها صراحةً على INTERNALDATE أثناء إيداع الرسائل على الخادم الوجهة؟

لاستيراد PST إلى Microsoft 365، تُعالج الأدوات المعتمدة من Microsoft (كـ MigrationWiz في أوضاعها الأصلية، أو أداة ترحيل Exchange Online) هذا الحفظ عادةً. أما الاستيراد اليدوي عبر eM Client أو Thunderbird، فنادراً ما يُحافَظ فيه على ذلك. راجع توثيق أداتك قبل الشروع في استيراد صناديق إنتاجية.

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

للمسؤولين الذين يُدارون ترحيلات دورية لعملائهم، مقال كيف تُصلح شركات MSP تواريخ بريد العملاء ومقال IMAP INTERNALDATE: لماذا تتلف التواريخ يُقدِّمان صورة أشمل للمشكلة.

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