تغيير تاريخ البريد الإلكتروني: ممكن ولكن قابل للكشف

تغيير تاريخ البريد الإلكتروني: عمّ نتحدث بالضبط؟

يتكرر هذا السؤال باستمرار في منتديات إدارة الأنظمة ومجموعات Slack الخاصة بمزودي خدمات الإدارة: هل يمكن تعديل تاريخ رسالة إلكترونية بعد إرسالها؟ الجواب المختصر: نعم، من الناحية التقنية. لكن الجواب الكامل أقل إرضاء بكثير لمن يريد فعل ذلك بنوايا مشبوهة.

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

ثلاث طبقات للتأريخ تتعايش في كل رسالة إلكترونية:

• ترويسة Date: (RFC 2822)، تكتبها تطبيقات البريد لحظة الإرسال
• ترويسات Received:، يضيفها كل خادم يُرحّل الرسالة
• قيمة INTERNALDATE في IMAP، وهي بيانات وصفية مخزنة على الخادم، مستقلة عن محتوى الرسالة

كل طبقة من هذه الطبقات قابلة للتعديل. ولا واحدة منها يمكن تعديلها دون ترك أثر.

تعديل ترويسة Date:: التلاعب الأكثر وضوحا

ترويسة Date: مجرد نص خام داخل ملف .eml. من الناحية التقنية، أي محرر سداسي عشري أو سكريبت Python يستطيع إعادة كتابتها في ثوانٍ. إذا سبق لك فتح الترويسات الخام لرسالة في Gmail (من القائمة الصغيرة "عرض الأصل")، فأنت تعرف أن أي شخص يستطيع قراءتها.

المشكلة؟ منذ عام 2004، تقوم الغالبية العظمى من خوادم البريد بتوقيع الرسائل الصادرة باستخدام DKIM (DomainKeys Identified Mail). هذا التوقيع التشفيري يغطي صراحةً عدة ترويسات، منها Date: وFrom: وSubject: وجسم الرسالة. يُخزَّن التوقيع في ترويسة DKIM-Signature:.

تعديل Date: بعد التوقيع يُبطل التحقق من DKIM ميكانيكيا. أي خادم استقبال يمكنه التحقق من التوقيع عبر استرداد المفتاح العام من سجل DNS الخاص بنطاق المرسل. إذا لم يتطابق التوقيع، تُصنَّف الرسالة على أنها مُعدَّلة. Gmail وOutlook.com وجميع المزودين الكبار يجرون هذا التحقق تلقائيا.

(بالمناسبة، إذا أردت رؤية توقيع DKIM بشكل ملموس، افتح الترويسات الخام لأي رسالة وصلتك من Gmail أو Office 365: ستجد سطرا من نوع DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... يبدو وكأنه ضجيج عشوائي، لكنه في الواقع قيمة هاش تشفيرية لكامل الرسالة.)

النتيجة: تعديل Date: في رسالة موقَّعة بـDKIM يعني كسر الختم. التعديل مرئي لأي مدير نظام يعرف أين يبحث.

إعادة كتابة ترويسات Received:: سلسلة يصعب تزويرها

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

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

اتساق السلسلة قابل للتحقق. إذا كانت الطوابع الزمنية في ترويسات Received: المتتالية متناقضة (كأن يكون مرحّل وسيط قد استقبل الرسالة قبل أن يرسلها المرسل)، فهذا مثير للريبة فورا. أدوات التحليل الجنائي للبريد مثل MXToolbox وأدوات فرق الأمن الداخلية تتحقق من ذلك تحديدا.

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

INTERNALDATE في IMAP: الحالة الأكثر تقنية

INTERNALDATE بيانات وصفية لـIMAP مخزنة على الخادم. ليست ترويسة داخل الرسالة نفسها: إنها قيمة يربطها الخادم بالرسالة في قاعدة بياناته الداخلية. هذه القيمة هي ما تستخدمه معظم تطبيقات البريد لترتيب الرسائل في صندوق الوارد.

أمر IMAP APPEND يتيح إيداع رسالة على خادم مع تحديد INTERNALDATE صراحةً. هذه ميزة مشروعة في البروتوكول، موثقة في RFC 3501. أدوات الترحيل تستخدمها باستمرار: imapsync وBitTitan MigrationWiz وCloudM وGSMMO... كلها تودع رسائل على خادم الوجهة مع تحديد INTERNALDATE.

نظريا، شخص لديه وصول IMAP إلى صندوق بريده الخاص يستطيع إيداع رسالة بأي INTERNALDATE يريد. لكن هذا التلاعب لا يعدّل ترويسات الرسالة. ترويسة Date: الأصلية تبقى سليمة، وترويسات Received: تبقى سليمة، وتوقيع DKIM يبقى سليما. فقط البيانات الوصفية للترتيب على جانب الخادم تتغير.

بالنسبة لخبير يفحص الرسالة الخام، التناقض بين INTERNALDATE وترويسة Date: مرئي فورا. وإذا كانت الرسالة موقَّعة بـDKIM، فالتاريخ الأصلي مصادَق عليه تشفيريا.

Message-ID: بصمة يصعب تزويرها

كل رسالة إلكترونية تولّد معرّفا فريدا، هو ترويسة Message-ID:. يبنيه خادم SMTP المرسل لحظة الإرسال، مدمجا في الغالب طابعا زمنيا ومعرّفا عشوائيا واسم نطاق الخادم.

Message-ID نموذجي يبدو هكذا: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. الطابع الزمني مرمَّز في الغالب مباشرةً داخل المعرّف. تعديل تاريخ الرسالة مع ترك Message-ID يحمل طابعا زمنيا غير متوافق يخلق تناقضا يمكن رصده فورا.

علاوة على ذلك، Message-IDs مفهرسة في أنظمة المراسلة الكبرى. Google وMicrosoft وجهات أخرى تحتفظ بسجلات تتيح تتبع متى تداولت رسالة ما فعليا عبر بنيتها التحتية. في السياقات القانونية أو الجنائية، هذه السجلات متاحة عبر الإجراءات القضائية.

عمليا: من يستطيع كشف محاولة التلاعب؟

لنطرح السؤال بشكل ملموس. وصلتك رسالة تشك في أن تاريخها عُدِّل. ماذا يستطيع مدير تقنية المعلومات أو محامٍ ذو خلفية تقنية بسيطة أن يفعل؟

• التحقق من DKIM: في Gmail، تعرض قائمة "عرض الأصل" نتيجة التحقق من DKIM مباشرةً في أعلى الصفحة. "PASS" يؤكد سلامة الرسالة منذ الإرسال. "FAIL" أو "SOFTFAIL" يشير إلى تعديل.
• تحليل الترويسات: أدوات مثل MXToolbox Header Analyzer أو Google Admin Toolbox تحلّل سلسلة Received: تلقائيا وتشير إلى التناقضات الزمنية.
• تناسق Message-ID مع Date: محلل يستطيع مقارنة الطابع الزمني المرمَّز في Message-ID مع قيمة Date: المُعلَن عنها.
• سجلات الخادم: إذا عبرت الرسالة خادما أنت مديره، فسجلات SMTP تحتوي على التاريخ والوقت الحقيقيَّين لاستقبال الرسالة، بصرف النظر عن أي ترويسة.

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

الحالة المشروعة الوحيدة للتعديل الجماعي للتواريخ: ترحيل IMAP

ثمة سيناريو تجد فيه مئات الآلاف من الرسائل نفسها بتواريخ خاطئة دون أي نية خبيثة: ترحيل IMAP.

تخيّل أنك أنهيت للتو ترحيل 150 صندوق Exchange إلى Google Workspace. صباح الاثنين، تبدأ التذاكر بالتدفق. المستخدمون يبلغون أن جميع رسائلهم القديمة تظهر بنفس التاريخ، تاريخ عطلة نهاية الأسبوع التي جرى فيها الترحيل. صناديق وارد غير قابلة للاستخدام.

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

ترويسة Date: الأصلية سليمة في كل رسالة. توقيعات DKIM سليمة. المحتوى لم يتغير. القيمة الوحيدة الخاطئة هي INTERNALDATE على جانب الخادم.

هذه المشكلة تطال BitTitan MigrationWiz وCloudM Migrate وimapsync وGSMMO وكل الأدوات التي تستخدم IMAP APPEND دون الحفاظ الصحيح على INTERNALDATE. المقال المخصص لـBitTitan MigrationWiz يغطي خصوصيات هذه الأداة. قائمة فحص ترحيل البريد تُدرج النقاط الواجب التحقق منها قبل الترحيل وبعده لتجنب هذا النوع من المشاكل.

الفرق بين التصحيح والتزوير

التصحيح الذي تجريه Redate.io هو النقيض التام لأي محاولة تزوير. محرك التصحيح الاحتكاري يحلل سلسلة ترويسات كل رسالة، ويحدد التاريخ الأصلي المرمَّز في ترويسة Date: (RFC 2822) التي لم تتغير قط، ويصحح البيانات الوصفية للتاريخ لمواءمتها مع هذه المعلومات الأصيلة الموجودة أصلا في الرسالة.

ترويسة Date: هي مصدر الحقيقة. كتبها تطبيق البريد الخاص بالمرسل لحظة الإرسال. وهي مشمولة بتوقيع DKIM. Redate.io لا تُعدِّلها. ما يُصحَّح هو التناقض الذي أدخلته أداة الترحيل، لا التاريخ الأصلي.

تصحيح 47000 رسالة بعد ترحيل فاشل دون فقدان رسالة واحدة، دون كسر خيوط النقاش، دون إتلاف المرفقات، دون إثارة خطأ 429 الساعة 3 صباحا على واجهة برمجة Google: هذا يتطلب خط أنابيب تحليل متعدد المراحل مع معالجة الحالات الحدية (S/MIME، وPGP، والترميزات غير ASCII وفق RFC 2047، وهياكل multipart المعقدة). سكريبت Python من خمسة أسطر لن يصمد أمام أول صندوق بريد إنتاجي. هل يمكن إصلاح تواريخ الرسائل بعد الترحيل؟ يوضح لماذا الحلول اليدوية محفوفة بالمخاطر عند التعامل مع أحجام حقيقية.

Redate.io تفحص صناديق البريد مجانا، وتحدد الرسائل ذات التواريخ الخاطئة، وتصحح عبر خط أنابيب تحقق يفحص كل رسالة على حدة. الرسائل الأصلية محفوظة في مجلد نسخ احتياطي مرئي لمدة 30 يوما. إذا حدث أي خطأ، التراجع ممكن.

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