read receipts
رسالة بريد إلكتروني وهمية من "دعم PayPal" يمكنها اجتياز كل فحص أمان أُخبرت بالثقة فيه
SPF و DKIM و DMARC تحمي الجزء الوحيد من البريد الإلكتروني الذي لا تراه أبداً — وتترك الاسم الذي تقرأه فعلاً دون حماية.
نعم، يمكن لرسالة بريد إلكترونية مزيفة أن تمر عبر DMARC بينما يظهر في سطر المرسل من "PayPal Support" أو "Chase Fraud Department". البروتوكولات الثلاثة التي يستشهد بها الجميع كدليل على أن رسالة بريد إلكترونية حقيقية — SPF و DKIM و DMARC — تتحقق فقط من نطاق الإرسال والتوقيع التشفيري. اسم العرض، الجزء الذي تقرؤه العين أولاً، لا يتم التحقق منه أبداً. شارة الثقة تحمي الحقل الذي لا ينظر إليه أحد.
هل يمكن فعلاً لرسالة بريد إلكترونية مزيفة أن تجتاز DMARC باسم عرض وهمي؟
يمكنها ذلك، والسبب مدرج في المعيار نفسه. RFC 7489، مواصفة DMARC، صريحة في أنها تتعلق فقط بالنطاق في رأس "RFC5322.From" — الجزء الذي يأتي بعد علامة @. لا تقول شيئاً عن اسم العرض، الملصق النصي الحر الذي يأتي قبل العنوان. لذلك المهاجم الذي يتحكم في نطاق عادي مثل support-team-alerts.com، وينشئ سجلات SPF و DKIM صحيحة، ويرسل من billing@support-team-alerts.com سيحصل على موافقة DMARC نظيفة. يقومون ببساطة بتعيين اسم العرض إلى "PayPal Service". المصادقة صحيحة تقنياً. العرض كاذب تماماً.
ثم معظم عملاء البريد تجعل الأمور أسوأ. الهواتف خاصة تعرض الاسم الودود وتخفي العنوان تماماً حتى تضغط عليه. ترى "PayPal Service"؛ عنوان support-team-alerts.com الفعلي يجلس خلف رمز شيفرون لن تضغط عليه أبداً.
إذاً، ما الذي يتحقق منه DMARC فعلاً؟
يتحقق DMARC من أن النطاق في رأس المرسل من يتماشى مع نطاق لديه المرسل صلاحية لاستخدامه — وليس أكثر من ذلك. SPF يؤكد أن عنوان IP للخادم المرسل موجود في القائمة المعتمدة للنطاق. DKIM يضيف توقيعاً تشفيرياً مرتبطاً بنطاق. مهمة DMARC هي "التوافق": التأكد من أن النطاق الذي تحقق منه SPF أو DKIM يطابق نطاق المرسل من المرئي، بحيث لا يمكنك الحصول على مصادقة على evil.com أثناء ادعائك أنك paypal.com.
هذا مفيد فعلاً. هذا هو السبب في أن انتحال نطاق العلامات التجارية الكبرى أصبح أصعب، وهذا هو السبب في أن Google و Yahoo بدآ بمتطلبات DMARC للمرسلين بالجملة في فبراير 2024. لكن M3AAWG، مجموعة الصناعة التي تكتب إرشادات المصادقة للمرسلين، واضحة في أن هذه البروتوكولات تصادق النطاق، وليس النية أو الصياغة. الغلاف يمكن أن يكون حقيقياً بينما الرسالة كذب.
لماذا يحصل اسم العرض على بطاقة دخول مجانية؟
لأن البريد الإلكتروني تم بناؤه قبل أن يتخيل أحد أنه سيحرك الأموال، وتم تصميم اسم العرض ليكون ودياً، وليس مُتحقق منه. إنها ملصق مجاملة. لا يوجد سجل لمن قد يستدعي أنفسهم "Apple Billing"، لا توجد فحوصات ضد العلامة التجارية، لا شيء. يمكنك تعيين الخاص بك للبابا. معايير البريد تعامله على أنه زخرفة، لذلك تخطو خطوات المصادقة فوقه.
هذا هو أيضاً كيف تعمل فئة متنامية من الخدع: انتحال اسم العرض جنباً إلى جنب مع نطاق يشبه الشرعي. سجل مركز الشكاوى الجنائية بالإنترنت التابع لـ FBI خسائر بريد إلكتروني للشركات تتجاوز $2.9 مليار في 2023 — و BEC تعتمد بشدة على هذه الحيلة بالذات، اسم موثوق يبدو فوق عنوان الهدف لا يفحصه أبداً. جميع البروتوكولات اجتيزت. الأموال غادرت على أي حال.
كيف تقرأ فعلاً سطر المرسال من الآن فصاعداً؟
توقف عن قراءة الاسم واقرأ العنوان. على سطح المكتب، انقر أو اضغط لتوسيع user@domain الكامل واسأل سؤالاً واحداً: هل هذا هو النطاق الذي تستخدمه الشركة الفعلية، حرفاً لحرف؟ يرسل PayPal من paypal.com، وليس من paypal-secure.net أو service-paypal.com. على الهاتف الجوال، اضغط على المرسل لكشف العنوان قبل أن تضغط على أي شيء آخر.
ثم فحص ثانٍ: هل ستخاطبك هذه المنظمة بتحية عامة وتدفعك نحو رابط تسجيل دخول بدلاً من مطالبة لم تتوقعها؟ هذا هو الجزء الذي لا يتحقق منه أي رأس. هذا هو أيضاً حيث يكسب تصفية AI رزقها — أدوات مثل xmail's scam flagging تقارن اسم العرض مقابل النطاق المصرح به وتسلط الضوء على عدم التطابق، بدلاً من الثقة في الملصق الودود الذي تثق به عينك. موافقة DMARC تخبرك أن النطاق هو من يقول أنه. لم تخبرك أبداً أن الاسم كان.
المصادر
- RFC 7489 (DMARC) — IETF specification; defines what DMARC authenticates
- M3AAWG Sender Authentication guidance — industry guidance on SPF/DKIM/DMARC scope
- FBI IC3 2023 Internet Crime Report — $2.9B in BEC losses
- Google bulk sender requirements — DMARC required for bulk senders from Feb 2024