تعديل تاريخ بريد مستلم: الحدود التقنية

لكل رسالة إلكترونية ثلاثة "تواريخ". ليس تاريخ واحد.

حين يتحدث أحدهم عن "تعديل تاريخ بريد إلكتروني مستلم"، يتخيل معظم الناس تغيير حقل ما في مكان ما، كما تغير تاريخ إنشاء ملف في Windows. الواقع أعقد من ذلك. كل رسالة إلكترونية تحمل في الحقيقة ثلاث طبقات زمنية مستقلة، لكل منها قواعدها الخاصة، وحراسها الخاصون، وعواقبها الخاصة إن مسّها أحد.

فهم هذه الطبقات الثلاث هو المفتاح لفهم لماذا بعض التصحيحات سليمة تقنيا، وبعضها إما مستحيل أو قابل للكشف فورا باعتباره تزويرا.

الطبقة الأولى: INTERNALDATE في بروتوكول IMAP

INTERNALDATE هي بيانات وصفية مخزنة على الخادم، خارج محتوى الرسالة تماما. لا تشكل جزءا من نص البريد الإلكتروني. يضبطها خادم IMAP، وهي التي تعتمد عليها معظم تطبيقات البريد لترتيب الرسائل في القائمة.

Outlook مثلا يعرض الرسائل مرتبة بحسب INTERNALDATE افتراضيا. Gmail كذلك في سياقات معينة. لذا إن كانت INTERNALDATE خاطئة، تبدو جميع رسائلك وكأنها وصلت في نفس التاريخ في الواجهة، بصرف النظر عما تقوله الترويسات الداخلية للرسالة.

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

الطبقة الثانية: ترويسة Date: (وفق RFC 2822)

هذا هو الحقل Date: في الترويسات الخام للرسالة. يضبطه تطبيق البريد لحظة الإرسال، ويسافر مع الرسالة من خادم إلى خادم. هو التاريخ المُعلَن من طرف المرسل.

(بالمناسبة، إن لم تنظر قط في الترويسات الخام لرسالة إلكترونية، فهي قراءة مثيرة للدهشة. كل رسالة تجر معها نحو عشرين سطرا تقنيا لم يرها 99% من المستخدمين قط.)

من الناحية التقنية، لا شيء يمنع إرسال بريد إلكتروني بحقل Date: مؤرخ في الماضي أو المستقبل. خوادم SMTP لا تتحقق من هذا الحقل. لكن خوادم المستلم تسجل وقت الوصول الحقيقي في ترويسات Received:، مما يُنشئ فورا تناقضا مرئيا لأي تطبيق بريد أو أداة تحليل.

الطبقة الثالثة: ترويسات Received: المتراكمة

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

هنا بالضبط تكمن المشكلة التي تصنعها أدوات الترحيل. حين ترحّل BitTitan MigrationWiz أو CloudM أو imapsync أو GSMMO رسالة ما، تعيد حقنها في الخادم الجديد عبر IMAP. هذا الإيداع يولّد إدخالا جديدا في Received: مختوما بتاريخ الترحيل. النتيجة: رسالة قديمة في صندوقك، كانت مرسلة عام 2019، تجد نفسها تحمل Received: مؤرخا في نوفمبر 2024. وبما أن بعض تطبيقات البريد (Outlook في مقدمتها) تستخدم أحدث ترويسة Received: كتاريخ للعرض...

ها هي المشكلة. 15000 رسالة تعرض جميعها نفس تاريخ الترحيل.

هل يمكن فعلا "تعديل" هذه التواريخ؟

تقنيا، نعم بالنسبة لـ INTERNALDATE (مع قيود). تقنيا ممكن لكن عديم الجدوى بالنسبة لـ Date:. أما Received: فيستحق وقفة أطول.

إعادة كتابة ترويسة Received: أمر بسيط. وقابل للكشف فورا.

ترويسة Received: ما هي إلا سطر نص في الرسالة. يمكن تحريرها كأي ملف نصي. الأمر بهذه البساطة تماما.

لكن إليك ما يحدث بعد ذلك.

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

المشكلة الثانية: المعرفات الداخلية. خوادم البريد الحديثة (Google Workspace وMicrosoft 365) تعيّن لكل رسالة معرفا داخليا متزايدا وفريدا. هذه المعرفات مرتبطة بـ INTERNALDATE وترتيب الاستلام. تعديل Received: دون انسجام مع هذه المعرفات يخلق تناقضات تكشفها أدوات التدقيق بلا عناء.

المشكلة الثالثة، وهي الأكثر عملية: حتى لو عدّلت Received: في محتوى الرسالة، لم تلمس INTERNALDATE التي لا تزال مضبوطة على تاريخ الإيداع عبر IMAP. يستمر تطبيق البريد في عرض التاريخ الخاطئ عند الترتيب. عدّلت الرسالة دون طائل.

باختصار: إعادة كتابة Received: بهدف تزوير تاريخ بريد إلكتروني لغرض خبيث - سهل تقنيا، وقابل للكشف في ثوانٍ من قِبَل أي خبير. ليست مسارا جديا.

ترويسة Date:: تغيير الماضي على الورق فقط

المنطق نفسه ينطبق على Date:. يمكن تعديلها في جسم الرسالة. لكن ترويسات Received: الموثقة من الخوادم الوسيطة تبقى سليمة وتروي قصة مختلفة. السلسلة الزمنية غير متسقة. أي محلل أو قاضٍ يقارن هذه الحقول سيرى التناقض فورا.

لنكن دقيقين، هذا لا يمنع بعض تطبيقات البريد من عرض Date: المعدّلة إن قُدّم إليها ملف .eml مباشرة. لكن في سياق خادم بريد حي مع مصادقة وسجلات، يكون التعديل شفافا تماما.

ترحيل IMAP: السياق الوحيد الذي يكون فيه تصحيح التواريخ مشروعا

ثمة حالة واحدة فقط يكون فيها تعديل تاريخ استلام بريد إلكتروني مبررا تقنيا بل ومطلوبا: تصحيح الأضرار التي خلّفها ترحيل IMAP غير محكم.

إليك السيناريو الواقعي. لقد انتهيت للتو من ترحيل 80 صندوق بريد من Exchange إلى Microsoft 365. اكتمل الترحيل مساء الجمعة. صباح الاثنين تبدأ التذاكر تتراكم: "كل رسائلي تحمل نفس التاريخ"، "لا أستطيع إيجاد رسالة من العام الماضي"، "سجل المراسلات مع هذا العميل تهشّم كليا". لديك 80 مستخدما متوقفا ومديرك ينتظر إجابة.

في هذا السياق، المشكلة موثقة وقابلة للتحديد وسببها واضح: أداة الترحيل أضافت ترويسة Received: مؤرخة بيوم الترحيل، وبعض تطبيقات البريد تستخدم هذه الترويسة الجديدة كتاريخ للعرض. أما ترويسة Date: الأصلية فلا تزال سليمة في كل رسالة، لم تُمَس قط، وتحتوي على تاريخ الإرسال الأصلي الصحيح.

التصحيح إذن ليس تزويرا، بل استعادة. نعود إلى البيانات الحقيقية (الـ Date: الأصلية) لإعادة بناء بيانات وصفية متسقة. هذا مختلف جوهريا عن محاولة تمرير رسالة من 2024 على أنها من 2019.

للتعمق في الآليات الخاصة بكل أداة، توفر هذه الأدلة التفصيلية حالات محددة: إصلاح تواريخ BitTitan في Microsoft 365، إصلاح تواريخ CloudM في Outlook، أو إصلاح تواريخ imapsync في Google Workspace.

لماذا لا تكتب سكريبتا بنفسك

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

المشكلة هي الهوة بين سكريبت يعمل على 50 رسالة اختبار وسكريبت يعالج 40000 رسالة في الإنتاج دون أن يضيع بريدا واحدا، أو يفسد مرفقا واحدا، أو يكسر محادثة واحدة.

بعض الحالات الواقعية التي لا تعالجها السكريبتات المنزلية في الغالب:

• رسائل S/MIME موقعة: التوقيع يغطي المحتوى والترويسات معا. أي تعديل في بنية الرسالة يُبطل التوقيع. رسالة موقعة صُحِّحت بطريقة غير سليمة تصل بعلامة "توقيع غير صالح" لدى المستلمين.
• رسائل مشفرة بـ PGP: المشكلة نفسها، مع عواقب محتملة أسوأ حسب طريقة التطبيق.
• ترميزات غير ASCII في الترويسات: RFC 2047 يصف ترميز الأحرف الخاصة في الترويسات. سكريبت يتعامل مع الترويسات دون معالجة هذه الحالات سيُفسد صامتا عناوين الرسائل التي تحوي أحرفا مُعلَّمة أو أحرفا يابانية أو أسماء عربية.
• حدود معدل طلبات API: Google Workspace وMicrosoft 365 يطبقان تقييدا صارما للطلبات. في الساعة الثالثة فجرا، دفعة من 10000 رسالة تصطدم بخطأ 429 Too Many Requests دون معالجة للتراجع الأسي تترك نصف الصناديق مُصلَحة جزئيا فقط.
• حدود MIME الفاسدة: الرسائل المتعددة الأجزاء مع مرفقات تعتمد على حدود MIME دقيقة. إعادة توليدها بشكل خاطئ يجعل المرفقات غير قابلة للقراءة.

والسؤال الذي لا تحله أي سكريبت منزلية: كيف تتحقق من أن كل رسالة مُصلَحة سليمة؟ سكريبت يعدّل 40000 رسالة دون تحقق فردي هو مجازفة. مجازفة ببيانات يعتبرها مستخدموك في الغالب لا تعوّض.

مقال هل يمكن إصلاح تواريخ الرسائل بعد الترحيل؟ يستعرض الخيارات المتاحة بما فيها حدود كل منها.

ما يفعله Redate.io في هذا السياق

Redate.io مصمم تحديدا لهذه الحالة: تصحيح التواريخ التي أفسدها ترحيل IMAP، على نطاق واسع، دون أي مخاطرة بسلامة الرسائل.

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

مطابقة الأنماط تغطي مئات بصمات أدوات الترحيل المعروفة: BitTitan MigrationWiz وCloudM وimapsync وGSMMO وتنويعاتها. الكشف دقيق: Redate.io لا يمس الرسائل التي تواريخها صحيحة.

نموذج التسعير بسيط: دفعة واحدة لكل صندوق بريد، بدون اشتراك. الفحص التشخيصي مجاني، مما يتيح قياس حجم المشكلة قبل اتخاذ أي قرار.

إن كنت تدير صناديق بريد متأثرة بهذه المشكلة، هذا المقال عن التواريخ الخاطئة في Outlook بعد الترحيل يفصّل الأعراض الأكثر شيوعا وكيفية تمييزها عن أسباب أخرى.

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