كيفية التحقق من صحة EOP للعنوان "من" لمنع التصيد الاحتيالي
ملاحظة
هل تريد تجربة Microsoft 365 Defender؟ تعرف على المزيد حول كيفية تقييم Microsoft 365 Defender وتجربتها.
ينطبق على
تعد هجمات التصيد الاحتيالي تهديدا مستمرا لأي مؤسسة بريد إلكتروني. بالإضافة إلى استخدام عناوين البريد الإلكتروني المخادعة (المخادعة)، غالبا ما يستخدم المهاجمون قيما في العنوان "من" تنتهك معايير الإنترنت. للمساعدة في منع هذا النوع من التصيد الاحتيالي، يتطلب Exchange Online Protection (EOP) و Outlook.com الآن رسائل واردة لتضمين عنوان "من" متوافق مع RFC كما هو موضح في هذه المقالة. تم تمكين هذا الإنفاذ في نوفمبر 2017.
الملاحظات:
إذا كنت تتلقى البريد الإلكتروني بانتظام من المؤسسات التي تحتوي على عناوين تم تكوينها بشكل غير صحيح كما هو موضح في هذه المقالة، فشجع هذه المؤسسات على تحديث خوادم البريد الإلكتروني الخاصة بها للامتثال لمعايير الأمان الحديثة.
لا يتأثر حقل المرسل ذي الصلة (المستخدم بواسطة "إرسال نيابة عن" والقوائم البريدية) بهذه المتطلبات. لمزيد من المعلومات، راجع منشور المدونة التالي: ماذا نعني عندما نشير إلى "مرسل" رسالة بريد إلكتروني؟.
نظرة عامة على معايير رسائل البريد الإلكتروني
تتكون رسالة البريد الإلكتروني SMTP القياسية من مغلف رسالة ومحتوى رسالة. يحتوي مغلف الرسالة على معلومات مطلوبة لنقل الرسالة وتسليمها بين خوادم SMTP. يحتوي محتوى الرسالة على حقول رأس الرسالة (تسمى بشكل جماعي رأس الرسالة) والنص الأساسي للرسالة. يتم وصف مغلف الرسالة في RFC 5321، ويتم وصف رأس الرسالة في RFC 5322. لا يرى المستلمون مغلف الرسالة الفعلي لأنه تم إنشاؤه بواسطة عملية إرسال الرسالة، وهو في الواقع ليس جزءا من الرسالة.
5321.MailFromالعنوان (المعروف أيضا بعنوان MAIL FROM أو مرسل P1 أو مرسل المغلف) هو عنوان البريد الإلكتروني المستخدم في إرسال SMTP للرسالة. يتم عادة تسجيل عنوان البريد الإلكتروني هذا في حقل رأس مسار الإرجاع في رأس الرسالة (على الرغم من أنه من الممكن للمرسل تعيين عنوان بريد إلكتروني مختلف لمسار الإرجاع ).5322.From(المعروف أيضا باسم عنوان "من" أو "مرسل P2") هو عنوان البريد الإلكتروني في حقل رأس "من"، وهو عنوان البريد الإلكتروني للمرسل الذي يتم عرضه في عملاء البريد الإلكتروني. عنوان From هو محور المتطلبات الواردة في هذه المقالة.
يتم تعريف عنوان "من" بالتفصيل عبر عدة RFCs (على سبيل المثال، RFC 5322 sections 3.2.3 و3.4 و3.4.1 وRFC 3696). هناك العديد من التباينات حول المعالجة وما يعتبر صالحا أو غير صالح. لجعله بسيطا، نوصي بالتنسيق والتعريظات التالية:
From: "Display Name" <EmailAddress>
اسم العرض: عبارة اختيارية تصف مالك عنوان البريد الإلكتروني.
- نوصي دائما بإحاطة اسم العرض بعلامات اقتباس مزدوجة (") كما هو موضح. إذا احتوى اسم العرض على فاصلة، فيجب إحاطة السلسلة بعلامات اقتباس مزدوجة لكل RFC 5322.
- إذا كان العنوان "من" يتضمن اسم عرض، فيجب إحاطة قيمة EmailAddress بأقواس زاوية (< >) كما هو موضح.
- توصي Microsoft بشدة بإدراج مسافة بين اسم العرض وعنوان البريد الإلكتروني.
عنوان البريد الإلكتروني: يستخدم عنوان البريد الإلكتروني التنسيق
local-part@domain:- الجزء المحلي: سلسلة تعرف علبة البريد المقترنة بالعنوان. هذه القيمة فريدة داخل المجال. غالبا ما يتم استخدام اسم مستخدم مالك علبة البريد أو GUID.
- المجال: اسم المجال المؤهل بالكامل (FQDN) لخادم البريد الإلكتروني الذي يستضيف علبة البريد المحددة بواسطة الجزء المحلي من عنوان البريد الإلكتروني.
هذه بعض الاعتبارات الإضافية لقيمة EmailAddress:
- عنوان بريد إلكتروني واحد فقط.
- نوصي بعدم فصل الأقواس الزاوية بمسافات.
- لا تقم بتضمين نص إضافي بعد عنوان البريد الإلكتروني.
أمثلة على عناوين "من" صالحة وغير صالحة
عناوين البريد الإلكتروني التالية صحيحة:
From: sender@contoso.comFrom: <sender@contoso.com>From: < sender@contoso.com >(غير مستحسن بسبب وجود مسافات بين الأقواس الزاوية وعنوان البريد الإلكتروني.)From: "Sender, Example" <sender.example@contoso.com>From: "Microsoft 365" <sender@contoso.com>From: Microsoft 365 <sender@contoso.com>(غير مستحسن لأن اسم العرض غير محاط بعلامات اقتباس مزدوجة.)
عناوين البريد الإلكتروني التالية من غير صالحة:
عنوان "لا من": لا تتضمن بعض الرسائل التلقائية عنوان "من". في الماضي، عندما تلقيت Microsoft 365 أو Outlook.com رسالة بدون عنوان "من"، أضافت الخدمة الافتراضي التالي من: عنوان لجعل الرسالة قابلة للتسليم:
From: <>الآن، لم تعد الرسائل التي تحتوي على عنوان "من" فارغ مقبولة.
From: Microsoft 365 sender@contoso.com(اسم العرض موجود، ولكن عنوان البريد الإلكتروني غير محاط بأقواس زاوية.)From: "Microsoft 365" <sender@contoso.com> (Sent by a process)(نص بعد عنوان البريد الإلكتروني.)From: Sender, Example <sender.example@contoso.com>(يحتوي اسم العرض على فاصلة، ولكنه غير محاط بعلامات اقتباس مزدوجة.)From: "Microsoft 365 <sender@contoso.com>"(القيمة بأكملها محاطة بشكل غير صحيح بعلامات اقتباس مزدوجة.)From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com(اسم العرض موجود، ولكن عنوان البريد الإلكتروني غير محاط بأقواس زاوية.)From: Microsoft 365<sender@contoso.com>(لا توجد مسافة بين اسم العرض وقوس الزاوية اليمنى.)From: "Microsoft 365"<sender@contoso.com>(لا توجد مسافة بين علامة الاقتباس المزدوجة للإغلاق وقوس الزاوية اليمنى.)
منع الردود التلقائية على مجالك المخصص
لا يمكنك استخدام القيمة From: <> لمنع الردود التلقائية. بدلا من ذلك، تحتاج إلى إعداد سجل MX فارغ لمجالك المخصص. يتم منع الردود التلقائية (وكافة الردود) بشكل طبيعي لأنه لا يوجد عنوان منشور يمكن للخادم المستجيب إرسال الرسائل إليه.
اختر مجال بريد إلكتروني لا يمكنه تلقي البريد الإلكتروني. على سبيل المثال، إذا كان مجالك الأساسي contoso.com، فقد تختار noreply.contoso.com.
يتكون سجل MX الفارغ لهذا المجال من فترة واحدة.
على سبيل المثال:
noreply.contoso.com IN MX .
لمزيد من المعلومات حول إعداد سجلات MX، راجع إنشاء سجلات DNS لدى أي موفر استضافة DNS Microsoft 365.
لمزيد من المعلومات حول نشر MX فارغ، راجع RFC 7505.
تجاوز فرض العنوان
لتجاوز متطلبات عنوان From للبريد الإلكتروني الوارد، يمكنك استخدام قائمة السماح ب IP (تصفية الاتصال) أو قواعد تدفق البريد (المعروفة أيضا بقواعد النقل) كما هو موضح في إنشاء قوائم المرسلين الآمنة في Microsoft 365.
لا يمكنك تجاوز متطلبات عنوان "من" للبريد الإلكتروني الصادر الذي ترسله من Microsoft 365. بالإضافة إلى ذلك، لن يسمح Outlook.com بتجاوزات من أي نوع، حتى من خلال الدعم.
طرق أخرى لمنع الجرائم الإلكترونية وحمايتها في Microsoft 365
لمزيد من المعلومات حول كيفية تعزيز مؤسستك ضد التصيد الاحتيالي والبريد العشوائي وخروقات البيانات والتهديدات الأخرى، راجع أفضل الممارسات لتأمين Microsoft 365 لخطط الأعمال.
الملاحظات
إرسال الملاحظات وعرضها المتعلقة بـ