كيف يعمل البريد الإلكتروني؟ رحلة رسالتك الرقمية من الإرسال إلى الاستقبال

هل تساءلت يوماً عن الكيفية التي تنتقل بها رسائلك الإلكترونية عبر الشبكة العنكبوتية لتصل إلى وجهتها؟ إن البريد الإلكتروني، ذلك الرفيق اليومي في حياتنا الرقمية، يعتمد على بنية تحتية معقدة وبروتوكولات متعددة لضمان وصول رسائلك بأمان وكفاءة. في هذا المقال، سنغوص في أعماق عالم البريد الإلكتروني، مستكشفين مكوناته الأساسية، وآليات عمله، وأهم البروتوكولات التي تحميه من التهديدات السيبرانية، وكيف تطورت هذه الأنظمة لتواكب التحديات الأمنية المتزايدة.

فهم أساسيات عمل البريد الإلكتروني: المكونات الرئيسية

لفهم كيفية عمل البريد الإلكتروني، يجب أن نتعرف أولاً على المكونات الأساسية التي تشكل هذا النظام المتكامل:

وكيل مستخدم البريد (MUA): بوابتك إلى عالم الرسائل

يُعد Mail User Agent (MUA)، أو وكيل مستخدم البريد، هو البرنامج الذي تستخدمه لقراءة وإرسال رسائل البريد الإلكتروني من جهازك. أمثلة على ذلك تشمل تطبيقات مثل Gmail على الويب، أو تطبيق البريد على أجهزة Apple، أو برامج مثل Microsoft Outlook. هذه البرامج تكون نشطة فقط عندما تستخدمها، وهي واجهتك المباشرة للتفاعل مع صندوق بريدك.

وكيل نقل البريد (MTA): العمود الفقري لنظام البريد

يتواصل MUA عادةً مع Mail Transfer Agent (MTA)، أو وكيل نقل البريد، والذي يُعرف أيضاً باسم خادم البريد (Mail Server)، أو مضيف MX (MX Host)، أو مبادل البريد (Mail Exchanger). وظيفته الأساسية هي استقبال وتخزين رسائلك الإلكترونية. يتم تخزين الرسائل عن بعد على خوادم MTA حتى تقوم بفتح MUA الخاص بك للتحقق من بريدك.

وكيل تسليم البريد (MDA): ضمان وصول الرسائل إلى صندوق الوارد

تُسلم الرسائل الإلكترونية بواسطة Mail Delivery Agents (MDA)، أو وكلاء تسليم البريد، والتي غالباً ما تكون مدمجة مع MTA. يضمن MDA وصول الرسالة من خادم البريد إلى صندوق الوارد الصحيح للمستلم.

بروتوكولات البريد الإلكتروني: تطور من البساطة إلى التعقيد

تعتمد عملية نقل وتسليم البريد الإلكتروني على مجموعة من البروتوكولات القياسية التي تطورت مع مرور الوقت:

بروتوكول نقل البريد البسيط (SMTP): معيار الإرسال

في البداية، كان إرسال البريد يتم إلى خادم بريد باستخدام بروتوكول SMTP (Simple Mail Transfer Protocol). يُعد SMTP بروتوكول اتصال قياسي للبريد الإلكتروني. وحتى الآن، بينما تستخدم العديد من الأنظمة الاحتكارية مثل Microsoft Exchange وبرامج البريد عبر الويب مثل Gmail بروتوكولاتها الداخلية الخاصة، فإنها تعتمد على SMTP لنقل الرسائل خارج أنظمتها. على سبيل المثال، إذا أراد مستخدم Gmail إرسال بريد إلكتروني إلى عميل Outlook، فسيتم استخدام SMTP.

بروتوكول مكتب البريد (POP3): تحميل الرسائل دون اتصال

كان يتم تنزيل البريد من الخادم باستخدام بروتوكول POP3 (Post Office Protocol version 3). يُعد POP3 بروتوكولاً لطبقة التطبيقات يوفر الوصول عبر شبكة بروتوكول الإنترنت (IP) لتطبيق المستخدم للاتصال بصندوق بريد على خادم بريد. يمكنه الاتصال، استرداد الرسائل، تخزينها على جهاز العميل، وحذفها أو الاحتفاظ بها على الخادم. صُمم هذا البروتوكول لإدارة اتصالات الإنترنت المؤقتة، مثل الاتصال الهاتفي (dial-up)، حيث كان يقوم بالاتصال واسترداد البريد عند الاتصال فقط، مما يتيح لك عرض الرسائل عندما تكون غير متصل بالإنترنت. كان هذا البروتوكول أكثر شيوعاً عندما كان الوصول الهاتفي منتشراً.

بروتوكول الوصول إلى رسائل الإنترنت (IMAP): مزامنة بريدك عبر الأجهزة

الآن، حل بروتوكول IMAP (Internet Message Access Protocol) محل POP3 إلى حد كبير. يتيح IMAP لعدة عملاء إدارة نفس صندوق البريد، مما يعني أنه يمكنك قراءة بريدك الإلكتروني من جهاز الكمبيوتر المكتبي، والكمبيوتر المحمول، والهاتف، وما إلى ذلك، وستكون جميع رسائلك موجودة ومنظمة بنفس الطريقة عبر جميع الأجهزة.

البريد الإلكتروني عبر الويب (Webmail): الوصول الشامل في كل مكان

في نهاية المطاف، حل البريد الإلكتروني عبر الويب (Webmail) محل كل من POP3 و IMAP. يتيح لك البريد الإلكتروني عبر الويب تسجيل الدخول إلى موقع ويب واستلام الرسائل من أي مكان أو أي جهاز (وهذا أمر رائع!). ومع ذلك، تحتاج إلى أن تكون متصلاً بالإنترنت أثناء استخدامه. إذا كان موقع الويب (مثل Gmail) هو MUA الخاص بك، فلن تحتاج إلى معرفة إعدادات خادم SMTP أو IMAP.

تأمين البريد الإلكتروني: حماية رسائلك في عالم رقمي

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

تحديات الأمان الأولية في بروتوكولات البريد

لم يكن مفاجئاً أن أصبح هذا الأمر مشكلة عندما توسع الإنترنت من مجرد مجموعات قليلة من الحكومات ومجموعات البحث إلى شيء يستخدمه معظم العالم للقيام بكل شيء تقريباً. سرعان ما أصبح البريد العشوائي (spam) ورسائل التصيد الاحتيالي (phishing emails) مشكلة ضخمة للجميع، ولا تزال كذلك.

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

بروتوكول أمان طبقة النقل (TLS): تشفير البيانات أثناء النقل

تستخدم معظم الأماكن TLS (Transport Layer Security)، وهو بديل لـ SSL (Secure Sockets Layer). TLS هو بروتوكول تشفير يوفر التشفير أثناء النقل. يوفر هذا حماية عندما يتم إرسال الرسالة، ولكن ليس عندما تكون البيانات في حالة سكون (على سبيل المثال، عند تخزينها على جهاز الكمبيوتر الخاص بك). يضمن هذا أن الرسالة لا يتم تغييرها أو التجسس عليها أثناء انتقالها من MTA إلى MTA.

ومع ذلك، لا يتحقق هذا من أن الرسالة لم يتم تعديلها أثناء الرحلة. على سبيل المثال، إذا مرت الرسالة الإلكترونية عبر عدة خوادم بريد قبل أن تصل إلى وجهتها النهائية، فإن استخدام TLS سيضمن تشفيرها بين الخوادم، ولكن كل خادم يمكن أن يغير محتوى الرسالة. لمعالجة ذلك، قمنا بإنشاء SPF و DKIM و DMARC.

بروتوكولات مصادقة البريد الإلكتروني: مكافحة الاحتيال والبريد العشوائي

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

إطار سياسة المرسل (SPF): التحقق من هوية الخادم المرسل

يتيح SPF (Sender Policy Framework) لمالك النطاق (مثل google.com) تعيين سجل TXT في نظام أسماء النطاقات (DNS) الخاص به يحدد الخوادم المسموح لها بإرسال البريد من هذا النطاق.

كيف يعمل SPF؟

يسرد هذا السجل الأجهزة (عادةً عن طريق عنوان IP) المسموح لها بالإرسال، ويمكن أن ينتهي بأحد الخيارات التالية:

• -all: إذا فشل التحقق (مصدر البريد الإلكتروني ليس أحد الأجهزة المدرجة)، تكون النتيجة فشلاً صارماً (HardFail). ستقوم معظم أنظمة البريد بوضع علامة على هذه الرسائل كبريد عشوائي (spam).
• ?all: إذا فشل التحقق، تكون النتيجة محايدة (neutral). يُستخدم هذا عادةً للاختبار، وليس لنطاقات الإنتاج.
• ~all: إذا فشل التحقق، تكون النتيجة فشلاً ليناً (SoftFail). هذا يعني أن الرسالة مشبوهة، ولكنها ليست بالضرورة سيئة معروفة. ستقوم بعض أنظمة البريد بوضع علامة على هذه الرسائل كبريد عشوائي، لكن معظمها لن يفعل ذلك.

يمكن أن تكون رؤوس SPF مفيدة للخوادم نفسها أثناء معالجة الرسائل. على سبيل المثال، إذا كان الخادم على حافة الشبكة، فإنه يعرف أن الرسائل التي يتلقاها يجب أن تأتي من خوادم في سجل SPF الخاص بالمرسل. وهذا يساعد الخوادم على التخلص من البريد العشوائي بشكل أسرع.

تحديات وقيود SPF:

على الرغم من فوائده، يعاني SPF من بعض المشاكل الرئيسية:

• لا يخبر SPF خادم البريد بما يجب فعله بالرسالة — مما يعني أن الرسالة يمكن أن تفشل في فحص SPF ومع ذلك يتم تسليمها.
• لا ينظر سجل SPF إلى عنوان “من” (From) الذي يراه المستخدم، بل ينظر إلى “مسار الإرجاع” (Return-Path). هذا يعادل تقريباً عنوان المرسل الذي تكتبه على رسالة ورقية. يخبر خوادم البريد التي تتعامل مع الرسالة إلى أين تعيد الرسالة (ويتم تخزينه في رؤوس البريد الإلكتروني — وهي معلومات تقنية تستخدمها الخوادم لمعالجة البريد الإلكتروني). هذا يعني أنه يمكنني وضع ما أريد في عنوان From: ولن يؤثر ذلك على فحص SPF. في الواقع، يمكن للمخترق تزوير كلا عنواني البريد الإلكتروني هذين.
• نظراً لعدم وجود تشفير، لا يمكن الوثوق برؤوس SPF بشكل كامل.
• تحتاج سجلات SPF إلى التحديث باستمرار، مما قد يكون صعباً في المؤسسات الكبيرة والمتغيرة باستمرار.
• إعادة التوجيه (Forwarding) يكسر SPF. يحدث هذا لأنه إذا تم إعادة توجيه بريد إلكتروني من، على سبيل المثال، google.com بواسطة bob@bobsburgers.com، يظل مرسل المظروف (envelope sender) دون تغيير (لا يزال عنوان “من” يشير إلى google.com). يعتقد خادم البريد المستلم أنه يدعي أنه من google.com، ولكنه يأتي من bobsburgers.com، لذلك يفشل في فحص SPF (على الرغم من أن البريد يأتي بالفعل من google.com).

يمكنك التحقق مما إذا كان نطاق معين يحتوي على سجلات SPF و DMARC هنا.

بريد المجال المعرف بالمفاتيح (DKIM): ضمان سلامة الرسالة

DKIM (DomainKeys Identified Mail) يشبه SPF. يستخدم أيضاً سجلات TXT في DNS الخاص بالنطاق المرسل، ويوفر بعض المصادقة للرسالة نفسها. يحاول توفير التحقق من أن الرسائل لم يتم تغييرها أثناء النقل.

كيف يعمل DKIM؟

يقوم النطاق المرسل بإنشاء زوج مفاتيح عام/خاص (public/private key pair) ويضع المفتاح العام في سجل DNS TXT الخاص بالنطاق. ثم تستخدم خوادم البريد الخاصة بالنطاق (على الحدود الخارجية — الخوادم التي ترسل البريد خارج النطاق، على سبيل المثال من gmail.com إلى outlook.com) المفتاح الخاص لإنشاء توقيع (signature) لجسم الرسالة بالكامل، بما في ذلك الرؤوس. يتطلب إنشاء التوقيع عادةً تجزئة النص وتشفيره.

تستخدم خوادم البريد المستلمة المفتاح العام في سجل DNS TXT لفك تشفير التوقيع، ثم تقوم بتجزئة الرسالة والرؤوس ذات الصلة (أي رؤوس تم إنشاؤها أثناء وجود البريد داخل البنية التحتية للمرسل — على سبيل المثال، إذا قامت عدة خوادم Gmail بمعالجة البريد الإلكتروني قبل إرساله خارجياً إلى outlook.com). سيتحقق الخادم بعد ذلك للتأكد من تطابق التجزئتين (hashes). إذا تطابقتا، فمن المحتمل أن تكون الرسالة سليمة ولم يتم تغييرها (ما لم يتم اختراق المفتاح الخاص للمرسل) وأنها بالفعل من المرسل المزعوم. إذا لم تتطابق التجزئتان، فإما أن الرسالة لم تكن من المرسل المزعوم، أو تم تغييرها بواسطة خادم آخر أثناء النقل، أو كلاهما.

قيود DKIM:

يقوم DKIM بعمل جيد جداً في مهمة محددة للغاية — الإجابة على السؤال “هل تم تغيير هذا البريد الإلكتروني أثناء النقل أم أنه ليس من المرسل المزعوم؟”. ومع ذلك، هذا كل ما يفعله. لا يخبرك بكيفية التعامل مع رسائل البريد الإلكتروني التي تفشل في هذا الاختبار، أو أي خادم قد يكون قد غير الرسالة، أو ما هي التعديلات التي تم إجراؤها. يستخدم DKIM أيضاً من قبل بعض مزودي خدمة الإنترنت (ISPs) لتحديد سمعة نطاقك (هل ترسل الكثير من البريد العشوائي؟ هل لديك تفاعل منخفض؟ كم مرة ترتد رسائلك الإلكترونية؟).

يمكنك التحقق من سجل DKIM هنا.

مصادقة الرسائل المستندة إلى المجال والإبلاغ والتوافق (DMARC): توجيه سياسات الأمان

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) هو في الأساس تعليمات لخوادم البريد حول كيفية التعامل مع سجلات SPF و DKIM. لا يقوم بأي اختبارات خاصة به، ولكنه يخبر خوادم البريد بكيفية التعامل مع عمليات التحقق التي يقوم بها SPF و DKIM. ستبحث شركات تزويد خدمة الإنترنت المشاركة في سجلات DMARC المنشورة وتستخدمها لتحديد كيفية التعامل مع حالات فشل DKIM أو SPF.

كيف يعمل DMARC؟

على سبيل المثال، قد تقوم علامة تجارية يتم تزويرها بشكل شائع بنشر سجل DMARC ينص على أنه إذا فشل DKIM أو SPF، فيجب إسقاط الرسالة. غالباً ما ترسل شركات تزويد خدمة الإنترنت أيضاً تقارير عن نشاط نطاقك إليك مع مصدر البريد الإلكتروني وما إذا كان قد اجتاز/فشل DKIM/SPF. هذا يعني أنك سترى متى يقوم الأشخاص بتزوير (ادعاء الإرسال من) نطاقك أو تغيير رسائلك.

لتطبيق DMARC، تحتاج إلى إنشاء سجل DMARC، بناءً على احتياجاتك (من مراقبة حركة مرور بريدك الإلكتروني لمعرفة جميع مصادر بريدك الإلكتروني إلى طلب اتخاذ إجراءات، مثل رفض أي رسائل بريد إلكتروني تفشل في DKIM أو SPF).

يمكنك التحقق مما إذا كان نطاق معين يحتوي على سجلات SPF و DMARC هنا.

الخلاصة التقنية

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

ومع ذلك، فإن معظم البروتوكولات التي يعتمد عليها الإنترنت الحالي صُممت للإنترنت المبكر — لمجموعة صغيرة من المتحمسين والعلماء والمسؤولين الحكوميين — وليس لشبكة عالمية نعتمد عليها في إدارة المباني والأجهزة الذكية ووسائل النقل العام والمحطات النووية (!) وما إلى ذلك. وبالتالي، مع استمرار توسع الإنترنت، نحتاج إلى مواصلة التكيف وتطوير طرق جديدة لتأمين الأنظمة التي نعتمد عليها.