تعديل تاريخ بريد إلكتروني مستلم: حقيقة أم وهم؟

السؤال الذي يطرحه الجميع (ولماذا يختبئ وراءه وضعان مختلفان تماماً)

اكتب "تعديل تاريخ بريد إلكتروني مستلم" في أي محرك بحث. ستجد عشرات الخيوط في منتديات Microsoft Q&A وthreads على Reddit وأسئلة على Quora. الطلب واضح، لكن الأسباب وراءه تختلف اختلافاً جذرياً حسب من يطرح السؤال.

هناك من يبحث عن تزوير تاريخ، بصورة رجعية، لأسباب نفضل عدم تخيلها. وهناك مدراء IT الذين، بعد ترحيل IMAP، يرون جميع رسائلهم تعرض نفس اليوم (يوم الترحيل)، ويريدون ببساطة استعادة التواريخ الحقيقية. هذان الوضعان لا علاقة لأحدهما بالآخر، لكنهما يشتركان في صياغة البحث ذاتها.

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

أولاً: ما هو "تاريخ" البريد الإلكتروني؟

البريد الإلكتروني لا يحتوي على تاريخ واحد. بل يحتوي على عدة تواريخ، مخزنة في أماكن مختلفة، تتحكم فيها جهات مختلفة.

حقل Date: (RFC 2822)

هذا هو التاريخ الذي يكتبه عميل المُرسل في الرسالة لحظة الإرسال. يظهر في الرؤوس الخام على الشكل التالي:

Date: Mon, 14 Oct 2024 09:32:11 +0200

هذا الحقل جزء من محتوى الرسالة. يمكن تعديله تقنياً إذا وصلت إلى الملف الخام. لكن كلمة "تقنياً" هنا هي المفتاح.

حقول Received:

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

INTERNALDATE في IMAP

هذه هي البيانات الوصفية الأهم لفهم لماذا بعض التعديلات لا يكون لها أي أثر مرئي. INTERNALDATE هو وصف مخزن على جانب خادم IMAP، بشكل مستقل عن محتوى الرسالة. معظم عملاء البريد يعتمدون عليه لترتيب الرسائل في المجلدات. Outlook يستخدمه. Gmail أيضاً. Apple Mail كذلك في الغالب.

INTERNALDATE ليس داخل الرسالة. إنه في قاعدة بيانات الخادم. لا يمكنك تعديله بتحرير ملف .eml على قرصك الصلب.

ما الذي يحدث فعلاً عند التعديل المحلي

تحرير ملف .eml

تقنياً، ملف .eml هو ملف نصي. يمكنك فتحه في أي محرر نصوص، تغيير سطر Date:، ثم الحفظ. إذا أعدت استيراد هذا الملف في عميل بريد محلي، فقد يتغير التاريخ المعروض، حسب العميل.

لكن هذا ما لن يتغير:

• INTERNALDATE على خادم IMAP (يبقى سليماً)
• حقول Received: التي أضافتها الخوادم الوسيطة
• سجلات التسليم لدى Google أو Microsoft أو مزود الخدمة
• توقيع DKIM، إن كانت الرسالة تحمل واحداً

النتيجة: على جهازك المحلي قد ترى تاريخاً مختلفاً. أما من Outlook المتصل بـ Exchange Online، أو Gmail في المتصفح، فلا شيء تغير.

تغيير ساعة النظام

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

التلاعب عبر Thunderbird

Thunderbird يوفر مرونة أكبر من معظم العملاء. باستخدام الإضافات أو بالتعديل المباشر على الملف الشخصي (ملفات mbox وملفات .msf)، يحاول البعض تعديل عرض التواريخ. قد ينجح ذلك داخل Thunderbird نفسه، للرسائل المخزنة محلياً في وضع POP3. لكن فور اتصال Thunderbird عبر IMAP، يزامن مع الخادم مجدداً. "التصحيح" يختفي عند أول مزامنة.

DKIM: الحاجز الخفي الذي لا يذكره أحد

معظم الرسائل المرسلة منذ عام 2018 موقعة بـ DKIM (DomainKeys Identified Mail). توقيع DKIM يبدو هكذا في الرؤوس:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

حقل h= يسرد الرؤوس التي يشملها التوقيع. في المثال أعلاه، Date موقّع. إذا عدّلت حقل Date: في الرسالة، يفشل التحقق من DKIM. أي خادم بريد، وأي أداة تحليل جنائي رقمي، يمكنه اكتشاف التعديل بإعادة حساب التوقيع.

هذه ليست حماية مثالية (مُرسل خبيث يتحكم في مفتاح DKIM الخاص به ويمكنه توقيع ما يشاء وقت الإرسال). لكن بالنسبة لرسالة مستلمة موقّعة مسبقاً، تعديل حقل Date: يترك أثراً قابلاً للاكتشاف.

سجلات الخادم: المرجعية الحقيقية للحقيقة

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

Google Workspace يسجّل كل رسالة في سجلات التدقيق بـ Admin Console. Microsoft 365 يفعل الشيء ذاته في مركز الامتثال (Purview). هذه السجلات تتضمن توقيتات التسليم، بصرف النظر عما يُعرض في العملاء. محامٍ، أو خدمة قانونية، أو فريق أمن معلومات يمكنه استرداد هذه البيانات. التاريخ المرئي في Outlook لا يُعتد به أمام المحاكم أو خلال عمليات التدقيق الأمني.

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

الحالة المشروعة: التصحيح بعد الترحيل

لنقل أنك للتو أنهيت ترحيل 150 صندوق بريد من Exchange on-premise إلى Microsoft 365. يوم الاثنين التالي تبدأ التذاكر تتساقط: "جميع رسائلي القديمة تحمل تاريخ الجمعة الماضي". تاريخ الترحيل بالضبط.

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

في هذه الحالة، "التصحيح" يعني إعادة الانسجام بين ما تقوله الرسالة (حقل Date: الأصلي، الموجود دائماً) وما يعتقده الخادم (INTERNALDATE المضبوط وقت الترحيل). هذا ليس تزويراً. هذا استعادة.

هذا بالضبط ما تشرحه مقالة لماذا تظهر رسائلك الالكترونية بتاريخ خاطئ بعد الترحيل. وهذا ما تحله Redate.io.

لماذا تفشل الحلول اليدوية على نطاق واسع

فهم المشكلة شيء. تصحيح 40,000 رسالة موزعة على 150 صندوق بريد دون فقدان رسالة واحدة شيء آخر تماماً.

السكريبتات المنتشرة على GitHub أو Stack Overflow تعمل على 20 رسالة تجريبية. تصطدم بعقبات في بيئة الإنتاج لأسباب لم يتوقعها كاتب السكريبت:

• الرسائل الموقعة بـ S/MIME أو المشفرة بـ PGP لها بنى لا تُعامل معاملة الرسائل العادية
• الرسائل متعددة الأجزاء ذات حدود MIME غير قياسية تسبب أخطاء في التحليل
• الرؤوس المشفرة وفق RFC 2047 (الأحرف غير ASCII في حقول From: أو Subject:) تُعطل المحللات البسيطة
• واجهات برمجة Google وMicrosoft تفرض قيوداً على معدل الطلبات (rate limiting): الساعة الثالثة صباحاً خلال معالجة 30,000 رسالة، خطأ 429 Too Many Requests لا تتم معالجته، السكريبت يتوقف، ولا أحد يعلم أين توقف بالضبط
• لا آلية للتراجع: إذا تلفت رسالة أثناء المعالجة، لا شيء يُعيدها إلى حالتها الأصلية

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

للاستزادة حسب الأداة المستخدم: BitTitan MigrationWiz: إصلاح تواريخ البريد، أو CloudM Migrate: كيفية إصلاح تواريخ البريد الخاطئة.

ما الذي يتغير وما الذي لا يتغير أبداً

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

إن كنت في الوضع الموصوف في آخر الجدول، بعد ترحيل باستخدام imapsync أو BitTitan أو CloudM أو أداة أخرى، فـ Redate.io صُمم لهذا تحديداً.

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