البريد الإلكتروني: كيف يُرسَل ويصل، وكيف يُحمى من الانتحال

في المقالات السابقة تتبّعتَ مسار طلب الويب: من العنوان، إلى DNS، إلى HTTP فالتشفير ثمّ الكوكيز. لكنّ الويب ليس تطبيق الإنترنت الوحيد، بل أقدمها وأكثرها صمودا تطبيق آخر يعمل على مسار مختلف تمامًا: البريد الإلكتروني. فهو أسبق من الويب، وما زال العمود الفقريّ لهويّتك الرقمية، إذ تسجّل به دخولك إلى كل شيء تقريبًا.

وهذا المقال يفتح البريد من الداخل: لماذا يختلف عن الويب جوهريّا، وما البروتوكولات الثلاثة التي تحرّكه (SMTP وIMAP وPOP3)، وكيف تسافر رسالة من إصبعك إلى صندوق صديقك، ثمّ المشكلة الأكبر فيه (الانتحال والسبام) وكيف تُعالَج، وأخيرًا ما يحميه التشفير فيه وما لا يحميه.

لماذا يختلف البريد عن الويب

الويب «طلب وردّ»: تطلب صفحة فتصلك فورًا حين تريدها. أمّا البريد فـ«تخزين وتمرير» (Store-and-Forward): ترسل رسالة فتنتقل عبر خوادم، وتنتظر في صندوق حتى يأتي صاحبها ليأخذها، كرسالة بريديّة ورقيّة لا كمكالمة هاتفية. فهو غير متزامن: لا يحتاج المرسِل والمستقبِل أن يكونا متّصلين في اللحظة نفسها. ويعمل ببروتوكولات خاصّة به، ليست HTTP.

وله خاصّية يتقاسمها مع الويب وتميّزه عن تطبيقات الدردشة المغلقة: إنه «اتّحاديّ» لامركزيّ. فأيّ شخص يشغّل خادم بريد يستطيع مراسلة أيّ أحد آخر، دون أن يملك الشبكةَ طرف واحد، ودون أن يحتاج الطرفان أن يكونا على المنصّة نفسها. مستخدم بريد جوجل يراسل مستخدم بريد مايكروسوفت بلا حاجز، بينما لا يراسل مستخدم تطبيق دردشة مستخدمَ تطبيق آخر. هذه اللامركزية هي سرّ بقاء البريد نصف قرن.

والبريد أقدم من الويب بعقدين: ففي 1971 أرسل راي توملينسون أوّل رسالة بين حاسوبين، واختار رمز «@» ليفصل اسم المستخدم عن اسم الخادم. ومن يومها بقيت بنية العنوان نفسها: جزء محلّيّ يحدّد المستخدم، ثمّ «@»، ثمّ اسم النطاق الذي يحدّد الخادم المسؤول. فحين تكتب عنوانا، أنت تقول فعلًا: «هذا المستخدم، عند هذا الخادم»، وبساطة صمدت 50 سنة.

البروتوكولات الثلاثة: SMTP وIMAP وPOP3

يقوم البريد على ثلاثة بروتوكولات لكلّ دوره.^[1] أولها «بروتوكول نقل البريد البسيط» (SMTP): وهو محرّك الإرسال، ينقل الرسالة من برنامجك إلى خادمك، ومن خادم إلى خادم، حتى تبلغ خادم المستقبِل.^[2] وهو «الصادر» دائمًا.

أمّا الاستقبال (أخذ الرسائل من خادمك إلى جهازك) فلبروتوكولين. «IMAP» يبقي الرسائل على الخادم ويزامنها عبر أجهزتك كلّها، فما تقرؤه على الهاتف يظهر مقروءا على الحاسوب؛ وهو الخيار الحديث الافتراضيّ. و«POP3» الأقدم ينزّل الرسائل إلى جهاز واحد وغالبًا يحذفها من الخادم، فلا تزامن؛ وقد تراجع استعماله. وفي القلب ثلاثة أدوار تتعاون: برنامجك (سواء تطبيق أو بريد على الويب) هو «عميل البريد»، والخادم الذي ينقل هو «وكيل النقل»، والذي يودع الرسالة في الصندوق هو «وكيل التسليم».

مسار رسالة

لنتبع رسالة من «[email protected]» إلى «[email protected]». تكتبها في برنامجك، فيسلّمها عبر SMTP إلى خادم جوجل الصادر. الآن يحتاج خادم جوجل أن يعرف أين خادم بريد outlook.com، فيسأل DNS عن «سجلّ تبادل البريد» (MX) لذلك النطاق (وهذا أحد أنواع سجلّات DNS التي مرّ ذكرها)، فيردّ DNS بعنوان خادم بريد مايكروسوفت.

يتّصل خادم جوجل بخادم مايكروسوفت عبر SMTP ويسلّمه الرسالة، فيودعها «وكيل التسليم» في صندوق صديقك. وتبقى هناك حتى يفتح صديقك بريده، فيجلبها جهازه عبر IMAP. وإن كان خادم المستقبِل معطّلا لحظتها، لا تضيع الرسالة، بل تنتظر في طابور ويُعاد محاولة تسليمها لاحقًا، وهذا جوهر «التخزين والتمرير». تمرّ الرسالة بعدّة خوادمَ في ثوان غالبًا، أو تنتظر إن لزم. وإن تعذّر التسليم نهائيّا (عنوان خاطئ، صندوق ممتلئ)، يعود إليك «إشعار عدم تسليم» من «حارس البريد»، وهو ما تراه حين ترتدّ رسالة خاطئة. وتجري هذه الحركة على منافذ معروفة: الإرسال على المنفذ 587، والاستقبال بـIMAP على 993، كلّها مشفّرة اليوم.

ولكلّ رسالة «ترويسة» تحمل قصّتها: من، وإلى، والموضوع، والتاريخ، وسطورُ «Received» التي يختم بها كلّ خادم مرّت به الرسالةُ مروره، فتُشكّل سجلّ مسارها من المصدر إلى الوجهة. وقراءة هذه الترويسة مهارة مفيدة: بها تتعقّب من أين جاءت رسالة فعلًا، وتكشف ما إذا كان «المرسِل» الظاهر هو الحقيقيّ. وهنا تحديدًا يبدأ سؤال الانتحال.

المشكلة الكبرى: الانتحال والسبام

صُمِّم SMTP في زمن كان الإنترنت فيه صغيرا موثوقا، فلم يُبنَ فيه تحقّق من هويّة المرسِل. والنتيجة خطيرة: يستطيع أيّ أحد أن يدّعي أنه أيّ أحد. يمكن أن تصلك رسالة تقول إنها من بنكك وهي ليست منه («انتحال»). هذا الخلل الأصليّ هو منبع السبام والتصيّد اللذين يبتليان البريد. ولأن إصلاح SMTP نفسه متعذّر (يستعمله العالم كلّه)، بُنيت فوقه طبقة تحقّق من ثلاثة أركان، تعتمد كلّها على DNS:

• SPF: سجلّ في DNS يحدّد الخوادم المسموح لها بإرسال بريد باسم نطاقك. فيتحقّق المستقبِل: هل جاء هذا من خادم مأذون له؟
• DKIM: توقيع تشفيريّ يُضاف إلى الرسالة يثبت أنها من النطاق فعلًا وأنها لم تُعدَّل في الطريق (تطبيق لفكرة التوقيع التي مرّت في مقال TLS).
• DMARC: سياسة تربط الاثنين، وتخبر المستقبِل ماذا يفعل بالرسالة التي تفشل في التحقّق (يقبلها أم يضعها في السبام أم يرفضها)، وترسل تقاريرَ لصاحب النطاق.^[3]

وقد صار هذا التحقّق إلزاميّا لا اختياريّا. فمنذ مطلع 2024، اشترط مزوّدون كبار مثل جوجل وياهو على من يرسل بريدا بالجملة أن يضبط الأركان الثلاثة، وأن يوفّر إلغاء اشتراك بنقرة واحدة، وأن يبقي نسبة شكاوى السبام دون حدّ منخفض.^[4] فمن لا يصادق بريده اليوم، يُرجَّح أن يسقط في مجلّد السبام أو يُرفَض أصلًا. هذا تحوّل كبير نحو بريد موثوق الهوية، ثمّ لحقت مايكروسوفت بهما. فمن الخامس من مايو 2025، صار على من يرسل أكثر من 5,000 رسالة في اليوم إلى عناوين outlook.com وhotmail.com وlive.com أن يضبط الأركان الثلاثة، وأن تكون سياسة DMARC عند p=none على أقلّ تقدير، وأن يوافق نطاقُ المرسِل الظاهر في «من» النطاقَ الذي أثبته SPF أو DKIM.^[6] والعقوبة اليوم هي الفرز إلى السبام، أمّا الرفض الصريح فمُعلَن قادما في موعد لم يُحدَّد.^[6] وانتبه هنا: أكثر ما يُكتب عن هذا الشرط يقول إنّ الرفض نافذ منذ مايو، وهو سبق للواقع، فنصّ مايكروسوفت يفرّق بين الفرز اليوم والرفض لاحقًا.

وإلى جانب المصادقة، يستعمل المستقبِلون أدوات أخرى لفرز السبام: مرشّحات تحلّل المحتوى وتتعلّم من بلاغات المستخدمين، و«قوائم حجب» لعناوين الخوادم السيّئة السمعة، و«التأخير المؤقّت» الذي يردّ الرسالة أوّل مرّة فيعيدها الخادم الشرعيّ ويتخلّى عنها المرسِل العشوائيّ. ومن هنا تأتي «سمعة المرسِل»: تاريخ نطاقك وعنوانك يقرّر إن كان بريدك يصل أو يُحجَب، ولهذا يهتمّ المرسِلون الجادّون ببناء سمعة نظيفة والحفاظ عليها.

وللتحقّق وجه آخر يصطدم به الناس كثيرًا: أنّه يفشل في بريد شرعيّ تمامًا. فحين تُحوَّل رسالة من عنوان إلى آخر، أو تمرّ بقائمة بريديّة، يتغيّر الخادم المُرسِل فيسقط SPF لأنّ الخادم الجديد غير مأذون له في سجلّ النطاق الأصليّ، وتضيف القائمةُ تذييلا أو تعقّم الروابط فينكسر توقيع DKIM لأنّ الرسالة لم تبقَ كما وُقّعت.^[7] فتصل رسالة سليمة وقد فشلت في التحقّق، ويظنّ صاحبها أنّ عيبا في إعداداته.

وعلاج هذا «سلسلة الاستلام الموثَّقة» (ARC): يسجّل كلّ وسيط في الطريق نتيجةَ التحقّق التي رآها قبل أن يعدّل شيئا، ويختم تسجيله تشفيريّا، فتبلغ الخادمَ الأخيرَ سلسلة يقرأ منها أنّ الرسالة كانت سليمة عند أوّل استلام، ثمّ عدّلها وسيط يثق به.^[7] وهو لا يرمّم التوقيع المكسور، وإنّما يحفظ شهادة بأنّه كان سليما قبل أن ينكسر.

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

ولنرَ المثال الأشهر: تصلك رسالة تبدو من بنكك، تحذّرك من «نشاط مريب» وتطلب أن تؤكّد حسابك عبر رابط. الرابط يقودك إلى صفحة تشبه موقع البنك تمامًا لكنها على نطاق مزوّر، فإن أدخلت بياناتك سرقها المحتال. لاحظ أن البنك الحقيقيّ لا يُرسِل مثل هذا، وأن العنوان الظاهر قد يخفي عنوانا غريبا، وأن الرابط عند تمرير الفأرة فوقه يكشف وجهته الحقيقية. هذه يقظة تتعلّمها، ولا يكفيك فيها أن «المصادقة موجودة».

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

جرّبه بنفسك: افتح ترويسة رسالة واقرأ سِجلّها

كلّ ما سبق مكتوب في رسائلك، وتراه في دقيقة. افتح في جيميل أيّ رسالة، ثمّ من قائمة النقاط الثلاث اختر «إظهار الأصل» (Show original). وفي أوتلوك على الويب: قائمة الرسالة، ثمّ «عرض تفاصيل الرسالة».

ابحث في الصفحة عن سطر Authentication-Results. فيه ثلاث كلمات تعرفها الآن، spf وdkim وdmarc، وأمام كلّ منها pass أو fail. جرّبها على رسالة من بنك أو منصّة كبيرة، فستجد الثلاثة pass. ثمّ افتح رسالة من مجلّد السبام واقرأ سطرها: كثيرًا ما تجد fail واحدة على الأقلّ، وقد تجد نطاق header.from مخالفا للنطاق الذي وقّع الرسالة، وذلك عين ما تمنعه الموافقة في DMARC.

ثمّ اقرأ سطور Received، وابدأ من أسفل الصفحة صاعدا: كلّ خادم يضيف سطره في الأعلى، فالأسفل أقدم والأعلى آخر خادم استلم. بهذا ترى بعينك رحلة «التخزين والتمرير» التي مرّ وصفها، وتعرف من أين جاءت الرسالة فعلًا، لا من أين تقول إنها جاءت.

التشفير: ما يحميه وما لا يحميه

هل بريدك مشفّر؟ جزئيًّا. تستعمل الخوادم اليوم تشفير الاتصال بينها (STARTTLS/TLS)، فلا يستطيع متطفّل بين خادمين قراءة ما يمرّ. لكنّ هذا تشفير «قفزة بقفزة» لا «طرف إلى طرف»: الرسالة تُفكّ عند كل خادم تمرّ به، ما يعني أن مزوّدي البريد أنفسهم (جوجل، أو خادم شركتك) يستطيعون قراءة محتواها.^[5] فبريدك أكثر خصوصيّة من بطاقة بريديّة مكشوفة، لكنه أقلّ من محادثة مشفّرة طرفا إلى طرف.

وفي هذا التشفير ثغرة أدقّ من مسألة قراءة المزوّد: STARTTLS اختياريّ بطبعه. فالخادم المُرسِل يسأل المستقبِل هل يدعم التشفير، فإن أجاب بنعم رفع الاتصال إلى TLS. والمهاجم القادر على حذف جزء من هذا الحوار، مثل سطر الجواب «250 STARTTLS»، يجعل كلَّ خادم يظنّ أنّ الآخر لا يدعم التشفير، فتمضي الرسالة نصّا مكشوفا وكلاهما راض.^[8] وهذه هي الثغرة التي مرّت بك في مقال SSL/TLS: ترقية اختياريّة يستطيع من في الوسط أن يمنعها.

وسدَّها معيار اسمه MTA-STS: يعلن صاحب النطاق مقدّما، في سجلّ في DNS وملفّ على موقعه، أنّ بريده لا يُستقبَل إلّا عبر TLS موثَّق، وأيّ الخوادم مأذون لها باستقباله. فإن كانت السياسة في وضع الإلزام، امتنع الخادم المُرسِل عن التسليم حين يتعذّر التشفير الموثَّق، ولم يقبل النزول إلى النصّ المكشوف.^[8] فالفرق بين «شفّر إن استطعت» و«لا تسلّم إن لم تشفّر» هو الفرق بين رجاء وشرط.

شكل 1

وإن أردت تشفيرا حقيقيّا من طرف إلى طرف لا يقرؤه حتى مزوّدك، فتحتاج أدوات إضافيّة تشفّر الرسالة قبل إرسالها ولا يفكّها إلا المستقبِل (مثل PGP أو S/MIME). لكنها معقّدة ولا يستعملها أكثر الناس. وهذه قصّة في ذاتها: تشفير البريد طرفا إلى طرف موجود منذ مطلع التسعينيّات، لكنه لم ينتشر قطّ لصعوبة إدارة المفاتيح على عامّة الناس، فهجر الناسُ فكرة البريد المشفّر إلى تطبيقات الدردشة المشفّرة طرفا إلى طرف افتراضيّا. فيبقى البريد في الغالب مقروءا لمزوّديه. وعيُ هذا الفرق مهمّ: لا تضع في بريد عاديّ سرّا تفترض أن لا أحد سواك وسوى المستقبِل يراه.

وللبريد وجه خفيّ يمسّ خصوصيّتك: «بكسل التتبّع». كثير من رسائل التسويق تحوي صورة شفّافة بحجم نقطة واحدة، فحين يفتح برنامجُك الرسالةَ يحمّلها من خادم المرسِل، فيعرف المرسِل أنك فتحتها ومتى ومن أيّ عنوان. لهذا تحجب برامج البريد الحديثة الصور تلقائيّا أو تمرّرها عبر وسيط يخفي عنك. فحتى مجرّد «فتح» رسالة قد يخبر مرسِلها بأكثر ممّا تظنّ.

المرفقات والويبميل: كيف تحمل الرسالة ملفّا، وكيف تقرؤها

وُلد البريد نصّا صرفا، فكيف يحمل صورة أو ملفّا؟ بمعيار «MIME» الذي يرمّز المرفقات والمحتوى الغنيّ (HTML، صور) إلى نصّ يَعبر قنوات البريد القديمة ثمّ يُفكّ عند الوصول. وأمّا كيف تقرأ بريدك، فبطريقتين: «بريد على الويب» (كفتح جيميل في المتصفّح) يخفي البروتوكولات خلف صفحة ويب، أو «تطبيق بريد» (مثل أوتلوك) يتّصل بخادمك عبر IMAP وSMTP مباشرةً. كلاهما يصل إلى الصندوق نفسه بطرق مختلفة. ولأن IMAP يُبقي كلّ شيء على الخادم، تتزامن مجلّداتك وبحثك ووسومك عبر أجهزتك جميعا، فتبدأ رسالة على الحاسوب وتكملها على الهاتف بلا انقطاع.

البريد بالجملة: صناعة كاملة وراء النشرة الواحدة

وأمّا البريد بالجملة (النشرات والإشعارات) فله عالم خاصّ: تعتمد المؤسّسات على «مزوّدي خدمة بريد» متخصّصين يديرون الإرسال الضخم والسمعة والمصادقة، ويضيفون ترويسة «إلغاء اشتراك بنقرة» التي صارت إلزاميّة. فالفرق بين رسالة شخصيّة واحدة وحملة إلى مليون صندوق ليس في الحجم فقط، بل في بنية كاملة تضمن الوصول دون أن تُحسَب سباما.

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

عنوانك صار مفتاحك الرئيس

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

مفارقة اللامركزية: مفتوح في تصميمه، مركَّز في واقعه

ورغم ظهور تطبيقات الدردشة، بقي البريد لأنه مفتوح لامركزيّ لا يملكه أحد، ولأنه صار «هويّتك» التي تسجّل بها الدخول إلى كل خدمة. لكنّ له هموما حديثة: تركّز متزايد بيد حفنة مزوّدين كبار صاروا يحدّدون قواعد اللعبة (كما مرّ بك في اشتراطات 2024)، و«سمعة المرسِل» التي تقرّر إن كان بريدك يصل أو يسقط في السبام بناء على تاريخ نطاقك وسلوكه. فالبريد بسيط في ظاهره، معقّد في اقتصاده وأمنه.

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

ولهذا التركّز ثمن على الخصوصية أيضًا: حين يُخزَّن بريدك على خوادم مزوّد مجّانيّ، فهو يعالج محتواه ليقدّم ميزاته (وقد كان بعضهم يحلّله للإعلانات سابقا). تذكّر القاعدة نفسها: ما تحصل عليه مجّانًا، تدفع ثمنه غالبًا ببياناتك. وهذا اعتبار في اختيار مزوّد بريدك، خاصّة لمن يهمّه أمر خصوصيّته.

لماذا يصمد البريد في زمن الدردشة

ومع ذلك، لِمَ يصمد البريد في زمن الدردشة الفوريّة؟ لأن طبيعته غير المتزامنة ميزة لا عيب: لا يفرض على المستقبِل الردّ فورًا، ويصلح للرسائل الطويلة والرسميّة، ويترك سجلّا موثّقا يصلح مرجعا وإثباتا. هو وسيط العمل الرسميّ والتعاقد والإشعارات، حيث لا تكفي رسالة دردشة عابرة. ولهذا، مهما كثرت التطبيقات، يبقى البريد العمود الذي يُبنى عليه. وقد دخلته أدوات الذكاء الاصطناعي حديثًا، تقترح ردودا وتلخّص الرسائل وتصطاد السبام بدقّة أعلى، فتطوّره دون أن تزيحه.

عادات تقيك أكثر التهديدات شيوعا

وخلاصة عمليّة لاستعمال آمن: احمِ حساب بريدك بكلمة مرور فريدة قويّة ومصادقة ثنائية، فهو مفتاح حساباتك كلّها. وتشكّك في كل رسالة تطلب بيانات أو نقرة عاجلة، وتحقّق من عنوان المرسِل الحقيقيّ لا اسمه الظاهر، ومرّر فأرتك فوق الروابط قبل نقرها. ولا تفترض السرّية في بريد عاديّ. هذه عادات بسيطة تقيك أكثر التهديدات شيوعا.

حيلة عمليّة: العناوين الإضافية

وحيلة صغيرة يتيحها كثير من مزوّدي البريد (كجيميل) تفيدك عمليًّا: «العنونة بالإضافة». تستطيع أن تضيف إلى اسمك علامة زائد وكلمة، فتصير [email protected]، وتصل كل الرسائل إلى صندوقك [email protected] نفسه. فائدتها أنك تعطي كل خدمة عنوانا مميّزا (+shop لمتجر، +news لنشرة)، فترتّب رسائلك تلقائيّا، والأهمّ أنك تكشف من باع عنوانك: إن وصلتك رسالة دعاية إلى +shop عرفت أن المتجر سرّب عنوانك. عنوان واحد يصير عناوين لا تُحصى، كلّها تحت سيطرتك. وإذا أغرقتك خدمة برسائل دعاية، صفّيت عنوانها الإضافيّ إلى المهملات بقاعدة واحدة، دون أن تمسّ بريدك الأصليّ.

تطبيق فوق المحرّك نفسه

هذا هو البريد الإلكتروني: تطبيق «تخزين وتمرير» اتّحاديّ، يرسل بـSMTP ويستقبل بـIMAP أو POP3، ويجد وجهته بسجلّات MX في DNS، ويحمي هويّته بـSPF وDKIM وDMARC، ويشفّر قناته لا محتواه بالكامل. هو والويب تطبيقان مختلفان، لكنّهما يجريان فوق المحرّك نفسه: العناوين والحزم والطبقات التي تنقل كل بياناتك. وبساطته الظاهرة تخفي نظاما بُنِي على الثقة في زمن غابر، ثمّ رُمِّم بطبقات تحقّق لمواجهة زمن لم يَعُد يثق.

ولفهم ذلك المحرّك المشترك (كيف تتحرّك بيانات أيّ تطبيق فعلًا، من البريد إلى الويب إلى غيرهما)، يأتي النموذج الذي ينظّم هذا كلّه: «بروتوكولات الإنترنت ونموذج الطبقات».

المصادر

1. Cloudflare: بروتوكولات البريد (IMAP وSMTP وPOP3). أدوار الإرسال والاستقبال.
2. IETF: RFC 5321: بروتوكول نقل البريد البسيط (SMTP). نقل الرسائل بين الخوادم.
3. Cloudflare: ما SPF وDKIM وDMARC؟ أركان مصادقة البريد الثلاثة.
4. AWS: اشتراطات المرسِلين بالجملة (جوجل وياهو 2024). المصادقة الإلزامية وإلغاء الاشتراك وحدّ السبام.
5. EFF: STARTTLS: تشفير البريد قفزة بقفزة. حدود التشفير في البريد.
6. Microsoft: Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders. حدّ خمسة آلاف رسالة يوميًّا من الخامس من مايو 2025، وإلزام SPF وDKIM وDMARC عند p=none موافِقة، والفرز إلى السبام قبل الرفض المُعلَن.
7. IETF: RFC 8617: The Authenticated Received Chain (ARC) Protocol. كيف يكسر الوسطاء SPF بتغيير الخادم وDKIM بتعديل الرسالة، وكيف تحفظ السلسلة نتيجة التحقّق الأصليّة.
8. IETF: RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). أنّ STARTTLS ترقية اختياريّة تُسقَط بحذف جواب «250 STARTTLS»، وأنّ وضع الإلزام يمنع التسليم دون تشفير موثَّق.