مصادقة البريد الإلكتروني

الموسوعة الحرة

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

لا يحتوي بروتوكول نقل البريد البسيط (SMTP) الأساسي للبريد الإلكتروني على مثل هذه الميزة، لذلك تم استخدام عناوين المرسل المزيفة في رسائل البريد الإلكتروني (وهي ممارسة تُعرف باسم انتحال البريد الإلكتروني ) على نطاق واسع في التصيد الاحتيالي والبريد الإلكتروني العشوائي وأنواع مختلفة من الاحتيال. لمكافحة هذا، تم تطوير العديد من مقترحات مصادقة البريد الإلكتروني المتنافسة. بحلول عام 2018، تم اعتماد ثلاثة على نطاق واسع - SPF و DKIM و DMARC . [1] [2] يمكن استخدام نتائج هذا التحقق في تصفية البريد الإلكتروني الآلية ، أو يمكن أن تساعد المستلمين عند تحديد الإجراء المناسب.

لا تتناول هذه المقالة مصادقة المستخدم لإرسال البريد الإلكتروني واسترجاعه.

الأساس المنطقي

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

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

الاعتماد على ملكية النطاق هو موقف ظهر في أوائل عام 2000. [3] [4] وهو يعني مصادقة دقيقة، نظرًا لأن النطاقات تظهر في الجزء الأيمن من عناوين البريد الإلكتروني، بعد علامة @ . يمكن تحقيق المصادقة الدقيقة، على مستوى المستخدم، من خلال وسائل أخرى، مثل Pretty Good Privacy و S/MIME . في الوقت الحاضر، يجب إدارة الهوية الرقمية من قبل كل فرد.

إن أحد الأسباب البارزة لمصادقة البريد الإلكتروني هو القدرة على أتمتة تصفية البريد الإلكتروني في الخوادم المستلمة. بهذه الطريقة، يمكن رفض الرسائل المزيفة قبل وصولها إلى صندوق الوارد الخاص بالمستخدم. وبينما تسعى البروتوكولات إلى ابتكار طرق لمنع البريد غير الموثوق به بشكل موثوق، يمكن لمؤشرات الأمان وضع علامات على الرسائل غير المصادق عليها والتي لا تزال تصل إلى صندوق الوارد. تظهر دراسة أجريت عام 2018 أن مؤشرات الأمان يمكن أن تخفض نسبة النقر إلى الظهور بأكثر من عشر نقاط، 48.9% إلى 37.2% من المستخدمين الذين يفتحون الرسائل المزيفة. [5]

طبيعة المشكلة

يحدد بروتوكول SMTP نقل الرسائل ، وليس محتوى الرسالة . وبالتالي، فهو يحدد مغلف البريد ومعامِلاته، مثل مُرسِل المغلف ، ولكن ليس الرأس (باستثناء معلومات التتبع ) ولا نص الرسالة نفسها. يحدد المعيار 10 و RFC  5321 بروتوكول SMTP (المغلف)، بينما يحدد المعيار 11 و RFC  5322 الرسالة (الرأس والنص)، والتي يشار إليها رسميًا باسم تنسيق رسائل الإنترنت .

يقوم بروتوكول SMTP بتعريف معلومات التتبع الخاصة بالرسالة، والتي يتم حفظها في الرأس باستخدام الحقلين التاليين: [6]

  • تم الاستلام : عندما يقبل خادم SMTP رسالة، فإنه يقوم بإدراج سجل التتبع هذا في الجزء العلوي من الرأس (من الأخير إلى الأول).
  • مسار العودة : عندما يقوم خادم SMTP للتسليم بالتسليم النهائي للرسالة، فإنه يقوم بإدراج هذا الحقل في الجزء العلوي من الرأس.

يعرف وكيل مستخدم البريد (MUA) خادم SMTP للبريد الصادر من خلال تكوينه. يحدد وكيل MTA (أو خادم التتابع) عادةً الخادم الذي سيتم الاتصال به من خلال البحث في سجل موارد DNS الخاص بـ MX (Mail eXchange) لاسم المجال الخاص بكل مستلم .

يمكن إعادة إنشاء المسار الموضح أدناه على أساس حقول رأس التتبع التي يضيفها كل مضيف إلى الجزء العلوي من الرأس عندما يتلقى الرسالة: [6]

قد يكون مصادقة البريد الإلكتروني معقدة بسبب وجود مرحل وسيط. من الواضح أن A و B ينتميان إلى مجال الإدارة الإدارية للمؤلف، بينما D و E جزء من شبكة المستلمين. ما الدور الذي يلعبه C ؟
مسار العودة: <author@example.com> تم الاستلام: من D.example.org بواسطة E.example.org باستخدام SMTP ؛ الثلاثاء، 05 فبراير 2013 11:45:02 -0500 تم الاستلام: من C.example.net بواسطة D.example.org باستخدام SMTP ؛ الثلاثاء، 05 فبراير 2013 11:45:02 -0500 تم الاستلام: من B.example.com ( b.example.com [ 192.0.2.1 ])
 بواسطة C.example.net ( وأنا ) باستخدام معرف ESMTP 936ADB8838C
 لـ <different-recipient@example.net> ؛ الثلاثاء، 05 فبراير 2013 08:44:50 -0800 (PST)
 تم الاستلام: من A.example.com بواسطة B.example.com باستخدام SMTP ؛ الثلاثاء، 05 فبراير 2013 17:44:47 +0100 تم الاستلام: من [ 192.0.2.27 ] بواسطة A.example.com باستخدام SMTP ؛ الثلاثاء، 05 فبراير 2013 17:44:42 +0100

عادةً ما يثق المستلم في الأسطر القليلة الأولى في الجزء العلوي من الرأس. تتم كتابة هذه الأسطر بواسطة آلات في مجال الإدارة الإدارية للمستلم ( ADMD )، والتي تعمل بناءً على تفويضها الصريح. وعلى النقيض من ذلك، فإن الأسطر التي تثبت تورط A و B ، بالإضافة إلى MUA للمؤلف المزعوم، يمكن أن تكون مزيفة أنشأها C. الحقل Received:الموضح أعلاه هو جزء من الرأس. Return-Path:يتم كتابته بواسطة E ، وكيل تسليم البريد (MDA)، بناءً على مغلف الرسالة . يمكن لحقول التتبع الإضافية، المصممة لمصادقة البريد الإلكتروني، أن تملأ الجزء العلوي من الرأس.

في العادة، تنتقل الرسائل المرسلة بواسطة ADMD الخاص بالمؤلف مباشرة إلى MX الخاص بالوجهة (أي B → D في الأشكال). ولا يمكن لـ ADMD الخاص بالمرسل إضافة رموز المصادقة إلا إذا مرت الرسالة عبر صناديقها. ويمكن توضيح الحالات الأكثر شيوعًا على النحو التالي:

تمثيل تخطيطي لأكثر الطرق شيوعًا لنقل رسالة البريد الإلكتروني من مؤلفها إلى متلقيها.

الإرسال من داخل شبكة ADMD (MUA 1)

  • يقوم MSA الخاص بـ ADMD بمصادقة المستخدم، إما بناءً على عنوان IP الخاص به أو بعض وسائل مصادقة SMTP الأخرى. بناءً على عنوان المستلم، يمكن أن تتبع الرسالة المسار الطبيعي أو تمر عبر قائمة بريدية أو خدمة إعادة توجيه. [ملاحظة 1] يمكن أن يكون B وكيل SMTP خارجيًا أو مضيفًا ذكيًا . [ملاحظة 2]
  • إذا لم تقم الشبكة المحلية بحظر اتصالات المنفذ 25 الصادرة، [ملاحظة 3] يمكن للمستخدم نشر بعض برامج "الاتصال المباشر بـ MX". [ملاحظة 4] عادةً ما يتصرف الزومبي والمضيفون الضارون الآخرون بهذه الطريقة.
  • إذا تم تكوين MUA بشكل سيئ، فيمكنه أيضًا استخدام مرحل مختلف، مثل مرحل مفتوح قديم الطراز ، والذي غالبًا لا يقوم بمصادقة المستخدم.

المستخدم المتجول (MUA 2)

  • في أغلب الأحيان، لا يزال من الممكن استخدام ADMD MSA الخاص بك. [ملاحظة 5]
  • يمكن اعتراض الاتصالات الصادرة إلى المنفذ 25 وتوجيهها إلى وكيل شفاف. [ملاحظة 4]
  • يمكن تكوين MUA لاستخدام إعادة توجيه SMTP التي يقدمها مزود الشبكة المحلية كمكافأة. [ملاحظة 4]

مستخدم غير متصل

  • يمكن للبطاقة الإلكترونية إرسال بريد نيابة عن العميل الذي كتب عناوين البريد الإلكتروني على لوحة المفاتيح المحلية؛ ويمكن اعتبار بعض نماذج الويب تعمل بشكل مشابه. [ملاحظة 4]

ملاحظات القسم

  1. ^ على سبيل المثال، يمكن للمستلم أن يطلب من Gmail إعادة توجيه الرسائل إلى عنوان بريد إلكتروني مختلف. ولا يدرك المرسل ذلك بالضرورة.
  2. ^ تظهر الوكلاء الذين تم تكوينهم بشكل صحيح كجزء من ADMD للمؤلف.
  3. ^ تقوم بعض أجهزة ADMD بحظر الاتصال الصادر إلى المنفذ 25 (SMTP) لتجنب هذا. تم وصف هذه التقنية الاستباقية في RFC 5068. بالإضافة إلى ذلك، تقوم بعض أجهزة ADMD بحظر اتصالات SMTP الواردة من عناوين IP المدرجة على أنها اتصال هاتفي /DSL/كابل.
  4. ^ abcd في هذه الحالة لا يشارك ADMD الخاص بالمؤلف على الإطلاق.
  5. ^ بعض موفري خدمة الإنترنت يحظرون المنفذ 587، على الرغم من أن RFC 5068 ينص بوضوح على:

    لا يجوز لموفري الوصول منع المستخدمين من الوصول إلى الإنترنت الخارجي باستخدام منفذ الإرسال 587.

طرق المصادقة المستخدمة على نطاق واسع

عامل الحماية من الشمس

يقوم SPF بالتحقق من عنوان IP الخاص بالمرسل.

يتيح SPF للمستقبل التحقق من أن البريد الإلكتروني الذي يزعم أنه قادم من نطاق معين يأتي من عنوان IP معتمد من قبل مسؤولي هذا النطاق. عادةً، يقوم مسؤول النطاق بتفويض عناوين IP المستخدمة بواسطة وكلاء نقل البريد الصادرين الخاصين بهم، بما في ذلك أي وكيل أو مضيف ذكي. [7] [8]

يضمن بروتوكول التحكم في الإرسال صحة عنوان IP الخاص بـ MTA المرسل ، حيث يقوم بإنشاء الاتصال من خلال التحقق من إمكانية الوصول إلى المضيف البعيد. [9] يتلقى خادم البريد المستقبل أمر HELO SMTP بعد إعداد الاتصال مباشرةً، وفي Mail from:بداية كل رسالة. يمكن أن يحتوي كلاهما على اسم مجال. يستفسر محقق SPF عن نظام اسم المجال (DNS) عن سجل SPF مطابق، والذي إذا كان موجودًا سيحدد عناوين IP المصرح بها من قبل مسؤول هذا المجال. يمكن أن تكون النتيجة "نجاح" أو "فشل" أو بعض النتائج الوسيطة - وستأخذ الأنظمة هذا في الاعتبار بشكل عام في تصفية البريد العشوائي. [10]

دي كيه آي إم

يقوم DKIM بالمصادقة على أجزاء من محتوى الرسالة.

يتحقق DKIM من محتوى الرسالة ، وينشر التوقيعات الرقمية . وبدلاً من استخدام الشهادات الرقمية، يتم توزيع مفاتيح التحقق من التوقيع عبر DNS. وبهذه الطريقة، يتم ربط الرسالة باسم المجال. [11]

يقوم مسؤول المجال المتوافق مع DKIM بإنشاء زوج أو أكثر من المفاتيح غير المتماثلة ، ثم يسلم المفاتيح الخاصة إلى MTA التوقيع، وينشر المفاتيح العامة على DNS. يتم تنظيم تسميات DNS على النحو التالي selector._domainkey.example.com، حيث يحدد selector زوج المفاتيح، و _domainkeyهي كلمة أساسية ثابتة، متبوعة باسم مجال التوقيع بحيث يحدث النشر تحت سلطة ADMD لهذا المجال. قبل حقن رسالة في نظام نقل SMTP، يقوم MTA التوقيع بإنشاء توقيع رقمي يغطي حقولًا محددة من الرأس والجسم (أو بدايته فقط). يجب أن يغطي التوقيع حقول الرأس الأساسية مثل From:، To:، Date:، و Subject:، ثم يضاف إلى رأس الرسالة نفسها، كحقل تتبع. يمكن لأي عدد من المرحلات استقبال الرسالة وإعادة توجيهها وفي كل قفزة، يمكن التحقق من التوقيع عن طريق استرداد المفتاح العام من DNS. [12] طالما أن المرحلات الوسيطة لا تعدل الأجزاء الموقعة من الرسالة، تظل توقيعات DKIM الخاصة بها صالحة.

ديمارك

يتيح DMARC تحديد سياسة للرسائل المعتمدة. وهو مبني على آليتين موجودتين، إطار سياسة المرسل (SPF) والبريد المحدد بمفاتيح المجال (DKIM).

إنه يسمح للمالك الإداري للنطاق بنشر سياسة في سجلات DNS الخاصة به لتحديد الآلية (DKIM أو SPF أو كليهما) المستخدمة عند إرسال بريد إلكتروني من هذا النطاق؛ وكيفية التحقق من From:الحقل المقدم للمستخدمين النهائيين؛ وكيف ينبغي للمستقبل التعامل مع حالات الفشل - وآلية إعداد التقارير للإجراءات التي يتم تنفيذها بموجب هذه السياسات.

طرق أخرى

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

اي دي اس بي

سمح ADSP بتحديد سياسة للرسائل التي تم توقيعها بواسطة نطاق المؤلف. كان لابد من اجتياز الرسالة لمصادقة DKIM أولاً، ثم يمكن لـ ADSP المطالبة بمعاملة عقابية إذا لم يتم توقيع الرسالة بواسطة نطاق المؤلف (نطاقات المؤلف) - وفقًا From:لحقل الرأس. [13]

تم تخفيض رتبة ADSP إلى مستوى تاريخي في نوفمبر 2013. [14]

في بي آر

تضيف تقنية VBR ضمانًا للهوية التي تم التحقق من صحتها بالفعل. تتطلب هذه الطريقة بعض السلطات المعترف بها عالميًا والتي تصادق على سمعة المجالات.

يمكن للمرسل أن يتقدم بطلب للحصول على مرجع لدى سلطة التصديق. وإذا تم قبول المرجع، يتم نشره على فرع DNS الذي تديره تلك السلطة. ويجب على المرسل الذي حصل على التصديق أن يضيف VBR-Info:حقل رأس إلى الرسائل التي يرسلها. كما يجب عليه أن يضيف توقيع DKIM، أو أن يستخدم بعض طرق المصادقة الأخرى، مثل SPF. ويمكن للمستقبل، بعد التحقق من هوية المرسل، التحقق من التصديق الذي تم المطالبة به من VBR-Info:خلال البحث عن المرجع. [15]

إيبريف

يجب على التطبيقات تجنب استخدام هذه الطريقة كوسيلة للمصادقة. [16] ومع ذلك، غالبًا ما يتم تنفيذها وكتابة نتائجها، إن وجدت، في Received:حقل الرأس إلى جانب معلومات TCP المطلوبة بواسطة مواصفات SMTP.

إن عكس عنوان IP، والذي تم تأكيده من خلال البحث عن عنوان IP للاسم الذي تم العثور عليه للتو، هو مجرد إشارة إلى أن عنوان IP تم إعداده بشكل صحيح في DNS. يمكن تفويض الحل العكسي لمجموعة من عناوين IP إلى ADMD الذي يستخدمها، [17] أو يمكن أن يظل تحت إدارة مزود الشبكة. في الحالة الأخيرة، لا يمكن الحصول على هوية مفيدة مرتبطة بالرسالة.

DNSWL

قد يوفر البحث في DNSWL (القائمة البيضاء القائمة على DNS) تقييمًا للمرسل، بما في ذلك تحديده ربما.

نتائج المصادقة

يحدد RFC 8601 حقل رأس تتبع Authentication-Results:حيث يمكن للمستقبل تسجيل نتائج عمليات التحقق من مصادقة البريد الإلكتروني التي قام بها. [16] يمكن الإبلاغ عن نتائج متعددة لطرق متعددة في نفس الحقل، مفصولة بفاصلات منقوطة ومغلفة حسب الاقتضاء.

على سبيل المثال، من المفترض أن الحقل التالي مكتوب بواسطة receiver.example.orgويقدم نتائج SPF و DKIM : 

نتائج المصادقة: receiver.example.org ؛
 spf=pass smtp.mailfrom = example.com ؛
 dkim=pass header.i=@example.com

الرمز الأول بعد اسم الحقل، receiver.example.orgهو معرف خادم المصادقة، وهو الرمز المعروف باسم authserv-id . يكون المستقبل الذي يدعم RFC 8601 مسؤولاً عن إزالة (أو إعادة تسمية) أي رأس زائف يدعي أنه ينتمي إلى نطاقه حتى لا يتم الخلط بين المرشحات اللاحقة. ومع ذلك، لا تزال هذه المرشحات بحاجة إلى التكوين، حيث يتعين عليها معرفة الهويات التي قد يستخدمها النطاق.

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

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

انظر أيضا

مراجع

  1. ^ هانج هو؛ بينج بينج؛ جانج وانج (2017). "نحو اعتماد بروتوكولات مكافحة التزييف". arXiv : 1711.06654 [cs.CR].
  2. ^ kerner, Sean Michael (2 January 2018). "DMARC Email Security Adoption Grows in US Government". eWeek . تم الاسترجاع في 24 نوفمبر 2018 .
  3. ^ "قمة مصادقة البريد الإلكتروني". ورشة عمل . لجنة التجارة الفيدرالية . 9-10 نوفمبر 2004. مؤرشف من الأصل في 3 يونيو 2012. تم الاسترجاع في 4 فبراير 2013. ومع ذلك، حدد التقرير المصادقة على مستوى المجال كتطور تكنولوجي واعد{{cite web}}:CS1 maint: عنوان URL غير مناسب ( الرابط )
  4. ^ مايكل هامر (14 أغسطس 2020). "تفويض الطرف الثالث". dmarc-ietf (قائمة بريدية) . تم الاسترجاع في 14 أغسطس 2020 .
  5. ^ هانج هو؛ جانج وانج (15 أغسطس 2018). قياس شامل لهجمات انتحال البريد الإلكتروني. ص 1095-1112. رقم ISBN 9781939133045. {{cite book}}: |work=تم تجاهله ( مساعدة )
  6. ^ من تأليف جون كلينسين (أكتوبر 2008). "معلومات التتبع". بروتوكول نقل البريد البسيط. IETF . القسم 4.4. doi : 10.17487/RFC5321 . RFC 5321. تم الاسترجاع في 1 فبراير 2013. عندما يقبل خادم SMTP رسالة إما لإعادة التوجيه أو للتسليم النهائي، فإنه يقوم بإدراج سجل تتبع (يُشار إليه أيضًا بالتبادل باسم "سطر الطابع الزمني" أو سطر "المستلم") في الجزء العلوي من بيانات البريد. يشير سجل التتبع هذا إلى هوية المضيف الذي أرسل الرسالة، وهوية المضيف الذي تلقى الرسالة (ويقوم بإدراج هذا الطابع الزمني)، وتاريخ ووقت استلام الرسالة. ستحتوي الرسائل التي تم إعادة توجيهها على أسطر طابع زمني متعددة.
  7. ^ Scott Kitterman (أبريل 2014). إطار عمل سياسة المرسل (SPF) لترخيص استخدام النطاقات في البريد الإلكتروني، الإصدار 1. IETF . doi : 10.17487/RFC7208 . RFC 7208. تم الاسترجاع في 26 أبريل 2014. هناك ثلاثة أماكن يمكن فيها استخدام التقنيات لتحسين حالات فشل SPF غير المقصودة باستخدام الوسطاء .
  8. ^ J. Klensin (أكتوبر 2008). "Alias". Simple Mail Transfer Protocol. IETF . sec. 3.9.1. doi : 10.17487/RFC5321 . RFC 5321 . تم الاسترجاع في 15 فبراير 2013 .
  9. ^ من الممكن تزوير عنوان IP، لكنه يتضمن عمومًا مستوى أقل من السلوك الإجرامي (الاقتحام، التنصت، إلخ)، وهو أمر محفوف بالمخاطر بالنسبة للمتسللين أو مرسلي البريد العشوائي النموذجيين، أو الخوادم غير الآمنة التي لا تنفذ RFC 1948، انظر أيضًا بروتوكول التحكم في الإرسال#اختطاف الاتصال .
  10. ^ Scott Kitterman (21 نوفمبر 2009). "ما مدى موثوقية الحظر/الرفض عند فشل SPF؟". spf-help . gossamer-threads.com. أعتقد أنه جيد بشكل عام طالما أنك تقدم آلية لإدراج المرسلين غير SRS في القائمة البيضاء.
  11. ^ D. Crocker; T. Hansen; M. Kucherawy, eds. (سبتمبر 2011). DomainKeys Identified Mail (DKIM) Signatures. IETF . doi : 10.17487/RFC6376 . RFC 6376 . تم الاسترجاع في 18 فبراير 2013 . يسمح DomainKeys Identified Mail (DKIM) للشخص أو الدور أو المنظمة بالمطالبة ببعض المسؤولية عن رسالة من خلال ربط اسم المجال بالرسالة، والتي يُسمح لهم باستخدامها.
  12. ^ ديف كروكر (16 أكتوبر 2007). "الأسئلة الشائعة حول DKIM". DKIM.org . تم الاسترجاع في 17 فبراير 2013 .
  13. ^ E. Allman; J. Fenton; M. Delany; J. Levine (أغسطس 2009). DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). IETF . doi : 10.17487/RFC5616 . RFC 5616 . تم الاسترجاع في 18 فبراير 2013 .
  14. ^ Barry Leiba (25 نوفمبر 2013). "تغيير حالة ADSP (RFC 5617) إلى تاريخي". IETF .
  15. ^ P. Hoffman; J. Levine; A. Hathcock (أبريل 2009). Vouch By Reference. IETF . doi : 10.17487/RFC5518 . RFC 5518 . تم الاسترجاع في 18 فبراير 2013 .
  16. ^ ab Murray Kucherawy (مايو 2019). حقل رأس الرسالة للإشارة إلى حالة مصادقة الرسالة. IETF . doi : 10.17487/RFC8601 . RFC 8601 . تم الاسترجاع في 12 يونيو 2023 .
  17. ^ H. Eidnes; G. de Groot; P. Vixie (مارس 1998). Classless IN-ADDR.ARPA delegate. IETF . doi : 10.17487/RFC2317 . RFC 2317 . تم الاسترجاع في 18 فبراير 2013 .
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=مصادقة_البريد_الإلكتروني&oldid=1234513640"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate