أفضل ممارسة لمصادقة البريد الإلكتروني - الطرق المُثلى لنشر SPF وDKIM وDMARC
المحتويات
المقدمة
يصف هذا الدليل ثلاث تقنيات أساسية لمصادقة البريد الإلكتروني قيد الاستخدام اليوم - SPF، DKIM، و DMARK، ويناقش الجوانب المختلفة لتنفيذها. تتم مناقشة العديد من حالات بنية البريد الإلكتروني الواقعية، وإرشادات لتنفيذها على مجموعة منتجات أمان البريد الإلكتروني من Cisco. وبما أن هذا دليل عملي لأفضل الممارسات، فإن بعض المواد الأكثر تعقيدا سوف يتم حذفها. وعند الضرورة، يمكن تبسيط مفاهيم معينة أو تكثيفها لتسهيل فهم المسألة المعروضة.
متطلبات معرفة المنتج
هذا الدليل هو وثيقة مستوى متقدم. لمتابعة العملية باستخدام المواد المقدمة، يجب أن يمتلك القارئ معرفة المنتج الخاصة بجهاز أمان البريد الإلكتروني من Cisco إلى مستوى اعتماد مهندس حقل أمان البريد الإلكتروني من Cisco. علاوة على ذلك، يجب أن يكون للقراء قيادة قوية لنظام أسماء النطاقات (DNS) و SMTP وتشغيلهما. إن الاطلاع على أساسيات صندوق الثروة السيادية، ومؤسسة كيم، ومارك يشكل إضافة واضحة.
مصادقة البريد الإلكتروني - نظرة عامة قصيرة
إطار عمل نهج المرسل (SPF)
تم نشر "إطار عمل نهج المرسل" لأول مرة في عام 2006، ك RFC4408. يتم تحديد الإصدار الحالي في RFC7208 ويتم تحديثه في RFC7372. وفي الأساس، يوفر طريقة بسيطة لمالك المجال للإعلان عن مصادر بريدهم الإلكتروني الشرعية للمستلمين باستخدام DNS. على الرغم من أن SPF يقوم بمصادقة عنوان مسار الإرجاع (البريد من) بشكل أساسي، فإن المواصفات توصي (وتوفر الآلية) بمصادقة وسيطة SMTP HELO/EHLO (FQDN لعبارة المرسل كما تم إرسالها أثناء محادثة SMTP).
يستخدم SPF سجلات موارد DNS من نوع TXT لبناء بسيط إلى حد ما:
نص Spirit.com = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com all"
يسمح سجل Spirit Airlines أعلاه بإرسال البريد الإلكتروني من @spirit.com عنوان من شبكة فرعية /24 معينة، وجهازين يحددهما FQDN، وبيئة Microsoft Office365. يرشد المؤهل "~all" في النهاية المتلقي إلى إعتبار أي مصادر أخرى على أنها فشل بسيط - وهو أحد وضعي فشل SPF. لاحظ أن المرسلين لا يحددون ما يجب أن يقوم به المتلقي مع الرسائل الفاشلة، إلى أي درجة سيفشلون.
ومن ناحية أخرى، توظف دلتا خطة مختلفة لصناديق الثروة السيادية:
نص delta.com = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"
لتقليل عدد استعلامات DNS المطلوبة، قامت Delta بإنشاء سجل "A" واحد تسرد جميع بوابات SMTP الخاصة بها. كما أنها توفر سجلا منفصلا لصناديق دعم spf لمورديها في "_spf.vendor.delta.com". كما تتضمن أيضا تعليمات حول الفشل الثابت في أي رسائل غير مصدق عليها من قبل مؤهل "-all" (SPF). يمكننا إجراء مزيد من البحث عن سجل SPF الخاص بالموردين:
_spf.vendor.delta.com text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com:؟all"
لذا، فقد تأتي رسائل البريد الإلكتروني الواردة من المرسلين على موقع delta.com بشكل مشروع، على سبيل المثال، من بوابات البريد الإلكتروني التابعة لشركة Air France.
ومن ناحية أخرى، تستخدم شركة يونايتد خطة أكثر بساطة لبروتوكول معلومات سوق الأوراق المالية:
نص United.com = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"
فهي بخلاف بوابات البريد الخاصة بشركاتها، تتضمن مزودي التسويق عبر البريد الإلكتروني ("USA.Net" و"enviaremails.com.br") وبوابات الخطوط الجوية القارية القديمة، فضلا عن كل شيء مدرج في سجلات MX الخاصة بهم ("آلية MX"). لاحظ أن MX (عبارة بريد واردة لمجال) قد لا تكون هي نفسها الصادرة. وفي حين أن المؤسسات الأصغر حجما تكون هي نفسها عادة، فإن المؤسسات الأكبر حجما سيكون لديها بنية أساسية منفصلة لمعالجة البريد الوارد ومعالجة التسليم الصادر بشكل منفصل.
وتجدر الإشارة أيضا إلى أن جميع الأمثلة المذكورة أعلاه تستخدم على نطاق واسع الإحالات الإضافية إلى نظام أسماء النطاقات (آليات "تشمل"). ومع ذلك، ونظرا لأسباب تتعلق بالأداء، تحدد مواصفات SPF العدد الإجمالي لعمليات بحث DNS اللازمة لاسترداد السجل النهائي إلى عشرة. ستفشل أي عمليات بحث ل SPF ذات أكثر من 10 مستويات من تكرار DNS.
البريد المحدد لمفاتيح المجال (DKIM)
DKIM، المحددة في RFCs 5585، 6376 و 5863 هي دمج لمقترحين تاريخيين: Yahoo's DomainKeys و Cisco’s Defined Internet Mail. يوفر طريقة بسيطة للمرسلين لتوقيع الرسائل الصادرة بشكل مشفر وتضمين التوقيعات (مع بيانات التعريف الأخرى للتحقق) في رأس بريد إلكتروني ("DKIM-Signature"). يقوم المرسلون بنشر المفتاح العام الخاص بهم في DNS، مما يسهل على أي متلقي إسترداد المفتاح والتحقق من التوقيعات. لا يقوم DKIM بمصادقة مصدر الرسائل الفعلية ولكنه يعتمد على حقيقة أنه إذا كان المصدر في حوزة المفتاح الخاص للمنظمة المرسلة، فإنه مخول ضمنيا لإرسال بريد إلكتروني نيابة عنها.
لتنفيذ DKIM، ستقوم المؤسسة المرسلة بإنشاء زوج أو أكثر من أزواج المفاتيح العامة ونشر المفاتيح العامة في DNS كسجلات TXT. تتم الإشارة إلى كل زوج مفاتيح بواسطة "محدد" بحيث يمكن لمدققي DKIM التمييز بين المفاتيح. سيتم توقيع الرسائل الصادرة، وإدخال رأس توقيع DKIM:
DKIM-Signature: v=1؛ a=rsa-sha1؛ c=rsa/relaxed؛ s=unified؛ d=news.united.com؛h=mime-version:content-type:content-transfer-encoding:Date:To:From:Reply-to:Subject:List-unsubscribe:Message-id؛ i=MileagePlus@news.united.com؛ bh=IBSWR4yzI1PSRYtWLx4SRDSWI4=؛
b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt1K WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=
شكل التوقيع واضح إلى حد ما. تحدد علامة "a" الخوارزميات المستخدمة للتوقيع، و"c" تحدد مخطط (خطط) التحويل المستخدمة [1]، و"s" هي المرجع المحدد أو المرجع الأساسي، و"d" هو مجال التوقيع. باقي عنوان DKIM-Signature هذا خاص بالرسالة: "H" يسرد الرؤوس الموقعة، "I" يسرد هوية المستخدم الموقعة، وأخيرا ينتهي الرأس بتجزئتين منفصلتين: "Bh" هي مجموعة من الرؤوس الموقعة، بينما "b" هي قيمة التجزئة لجسم الرسالة.
عند تلقي رسالة موقعة من DKIM، يقوم المستقبل بالبحث عن المفتاح العام عن طريق إنشاء استعلام DNS التالي:
<selector>._domainKey.<توقيع مجال>
كما هو محدد في رأس DKIM-Signature. على سبيل المثال أعلاه، سيكون سؤالنا هو "UNIFIED._DOMAINKEY.news.UNITED.com":
unified._domainKey.news.united.com text = "g=*\؛ k=rsa\؛ n=" "contact" "postmaster@responsys.com" "with" "any" "questions" "concerning" "this" "signature" "\؛ p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX x/Q2KkWgl35H4d4d4d Ty5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qbiz9Kc3Kc2IBwIDAQB\؛
يحتوي سجل DNS الذي تم إرجاعه على المفتاح، بالإضافة إلى المعلمات الاختيارية الأخرى. [2]
المشكلة الرئيسية في DKIM هي أن المواصفات الأولية لم تسمح بالإعلان عن إستخدام المرسل ل DKIM. وبالتالي، إذا كانت الرسالة تأتي بدون توقيع، فلا توجد طريقة سهلة ليعرف المتلقي أنه كان ينبغي أن يوقع وأنه في هذه الحالة، على الأرجح غير صحيح. وبما أن المؤسسة الواحدة يمكنها (وستستخدم في أغلب الأحيان) العديد من المحددين، فليس من البديهي "تخمين" ما إذا كان المجال ممكنا بواسطة DKIM. وتم وضع معيار مستقل، هو "ممارسات التوقيع على مجال المؤلفين"، لتغطية هذا الأمر، ولكن بسبب قلة الاستخدام والمسائل الأخرى، ألغي العمل به في عام 2013 دون وجود خلف له.
مصادقة الرسائل المستندة إلى المجال وإعداد التقارير والمطابقة (DMARK)
ويعد DMARK أحدث التقنيات الثلاث الخاصة بمصادقة البريد الإلكتروني التي تمت تغطيتها، وقد تم تطويره خصيصا لمعالجة أوجه القصور في كل من SPF و DKIM. بخلاف الاثنين الآخرين، فإنه يصادق الرأس من رسالة وروابط إلى التحققات التي أنجزت سابقا من قبل الإثنان الآخرين. يتم تحديد DMARK في RFC7489.
تتكون القيمة المضافة لمعامل إزالة الألغام عبر SPF و DKIM من:
- التأكد من أن جميع الهويات المتوفرة (مجال توقيع HELO و MAIL FROM و/أو DKIM) متوافقة (مطابقة أو تبعية تماما) مع رأس From
- توفير وسيلة لمالك مجال المرسل لتحديد سياسة للمستلمين حول كيفية معالجة الرسائل الفاشلة
- توفير توفير مردود إرتجاعي لمالكي مجال المرسل لإبلاغهم بأي رسائل فاشلة، مما يجعل من السهل التعرف على حملات التصيد الاحتيالي أو الأخطاء في تعيين نهج SPF/DKIM/DMARK
كما يستخدم DMARK آلية توزيع سياسة بسيطة قائمة على نظام أسماء المجالات (DNS):
_dmarc.aa.com نص = "v=DMARK1\؛ p=none\؛ fo=1\؛ ri=3600\؛ rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\؛ ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"
العلامة الإلزامية الوحيدة في مواصفات نهج DMARK هي "p"، وتحدد السياسة التي سيتم إستخدامها على الرسائل الفاشلة. يمكن أن يكون واحدا من الثلاثة لا شيء، الحجر الصحي، رفض.
غالبا ما تكون المعلمات الاختيارية المستخدمة مرتبطة بالتقارير: تحدد "rua" عنوان URL (إما رسالة بريد إلكتروني: أو عنوان URL http:// باستخدام أسلوب POST) لإرسال تقارير تجميع يومية حول كافة الرسائل الفاشلة التي يزعم أنها تأتي من مجال معين. تحدد "ruf" عنوان URL لإرسال تقارير فشل تفصيلية فورية عن كل رسالة فاشلة.
وفقا للمواصفات، يجب أن يلتزم المستقبل بالسياسة المعلن عنها. وفي حالة عدم حدوث ذلك، يجب عليها إعلام مالك مجال المرسل في تقرير التجميع.
إن المفهوم المركزي ل DMARK هو ما يسمى محاذاة المعرف. تحدد محاذاة المعرف كيفية تمرير رسالة التحقق من DMARK. يتم محاذاة معرفات SPF و DKIM بشكل منفصل، ويجب تمرير رسالة أي منها لتمرير DMARK بشكل عام. ومع ذلك، هناك خيار نهج DMARK حيث يمكن للمرسل طلب إنشاء تقرير فشل حتى في حالة تمرير محاذاة، ولكن فشل الآخر. يمكننا رؤية ذلك في المثال أعلاه مع تعيين علامة "fo" على "1".
هناك طريقتان للإلتزام بالرسائل بمحاذاة معرف DKIM أو SPF، صارمة ومرتاحة. يعني الالتزام الصارم أن FQDN من Header يجب أن تطابق تماما توقيع معرف المجال ("d") الخاص بتوقيع DKIM أو FQDN الخاص بالبريد من أمر SMTP ل SPF. ومن ناحية أخرى، يتيح الاسترخاء لرأس FQDN أن يكون مجالا فرعيا للمجالين المذكورين آنفا. ولهذا الأمر تداعيات هامة عند تفويض حركة مرور البريد الإلكتروني إلى جهات خارجية، والتي ستتم مناقشتها لاحقا في المستند.
اعتبارات نشر SPF
SPF لأجهزة الاستقبال
يعد التحقق من SPF تافها للتكوين على أجهزة Cisco Email Security Appliance أو أجهزة أمان البريد الإلكتروني السحابي الظاهرية. أما ما تبقى من هذه الوثيقة، فإن أي إشارة إلى الإيسا ستتضمن أيضا نظام التبادل الشبكي.
يتم تكوين التحقق من SPF في سياسات تدفق البريد - تعتبر أسهل طريقة لتشغيله بشكل عام هي تشغيله في قسم معلمات النهج الافتراضية من المصغي (المصغي) المناسب. إذا كنت تستخدم نفس موزع الرسائل لجمع البريد الوارد والصادر، تأكد من أن نهج تدفق البريد "RELAATED" لديك تم تعيين التحقق من SPF إلى "إيقاف".
بما أن SPF لا يسمح بتحديد إجراءات السياسة التي يجب إتخاذها، فإن التحقق من SPF (بالإضافة إلى DKIM، كما سنرى لاحقا) يتحقق فقط من الرسالة ويدرج مجموعة من الرؤوس لكل فحص SPF يتم تنفيذه:
Receive-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: مجال
united.5765@envfrm.rsys2.com يعين 12.130.136.195 ك
المرسل المسموح به) الهوية=mailfrom؛
client-ip=12.130.136.195؛ المستقبل=mx1.hc4-93.c3s2.smtpi.com؛
envelope-from="united.5765@envfrm.rsys2.com"؛
مرسل x="united.5765@envfrm.rsys2.com"؛
x-conformance=sidf_compatible؛ x-record-type="v=spf1"
Received-SPF: لا يوجد (mx1.hc4-93.c3s2.smtpi.com: لا يوجد مرسل
معلومات أصلية متوفرة من مجال
postmaster@omp.news.united.com) الهوية=helo؛
client-ip=12.130.136.195؛ المستقبل=mx1.hc4-93.c3s2.smtpi.com؛
envelope-from="united.5765@envfrm.rsys2.com"؛
مرسل x="postmaster@omp.news.united.com"؛
x-conce=sidf_compatible
لاحظ أنه بالنسبة لهذه الرسالة، تم التحقق من "هويتين" من قبل SPF: "Mailfrom" حسب التكليف الوارد في المواصفات و"helo" على النحو الذي أوصى به الشخص نفسه. ستمرر الرسالة رسميا الصندوق، لأن الرسالة الأولى فقط هي ذات صلة بالامتثال لصناديق البريد الخاصة، ولكن قد يفرض بعض المتلقين عقوبات على المرسلين الذين لا يشملون سجلات الصندوق الخاص لهوياتهم من أجهزة الهليكوبتر أيضا. لذلك، من الممارسات الجيدة تضمين أسماء بيوت بوابات البريد الصادرة الخاصة بك في سجلات SPF.
وبمجرد أن تتحقق سياسات تدفق البريد من رسالة ما، يصبح الأمر متروكا للمسؤولين المحليين لتكوين إجراء يجب إتخاذه. يتم القيام بذلك باستخدام حالة قاعدة تصفية الرسائل () [3]، أو من خلال إنشاء عامل تصفية محتوى وارد باستخدام نفس النهج وتطبيقه على نهج البريد الوارد المناسبة.
الصورة 1: شرط عامل تصفية محتوى التحقق من SPF
تتمثل إجراءات التصفية الموصى بها في إسقاط الرسائل التي فشلت ("-all" في سجل SPF)، ورسائل العزل التي تم تطبيق Softfail ("~all" في سجل SPF) في إجراء عزل النهج، ومع ذلك، قد يختلف هذا الإجراء وفقا لمتطلبات الأمان الخاصة بك. بعض المستلمين يقومون فقط بوضع علامات على الرسائل الفاشلة أو عدم إتخاذ أي إجراء مرئي، ولكن يتم الإبلاغ عنها للمسؤولين.
حدث مؤخرا إرتفاع ملحوظ في شعبية SPF، ولكن العديد من المجالات تنشر سجلات SPF غير كاملة أو غير صحيحة. لكي تكون على الجانب الآمن، قد ترغب في عزل كافة رسائل فشل SPF، ومراقبة الحجر الصحي لفترة من الوقت، للتأكد من عدم وجود "إيجابيات خاطئة".
إذا قمت بتوفير خدمات البريد الإلكتروني لمجالات أخرى أو أطراف خارجية
إذا قمت بتوفير خدمات تسليم البريد الإلكتروني أو الاستضافة لأطراف ثالثة، فسيتعين عليهم إضافة أسماء المضيف وعناوين IP التي تستخدمها لتسليم رسائلهم إلى سجلات SPF الخاصة بهم. وأبسط طريقة للقيام بذلك هي أن يقوم الموفر بإنشاء سجل "مظلة" لبروتوكول SPF، وجعل العملاء يستخدمون آلية "التضمين" في سجلات بروتوكول SPF.
نص sun country.com = v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20.247.57.ip4:207.17.8.17.17.82.66 ip4:199.66.248.0/22 يتضمن:cust-spf.exacttarget.com ~all
كما نرى، لدى "صن كانتري" بعض رسائلها الإلكترونية تحت سيطرتها، لكن بريدها الإلكتروني التسويقي يتم إسناده لطرف ثالث. يكشف توسيع السجل المشار إليه قائمة بعناوين IP الحالية المستخدمة من قبل موفر خدمة التسويق البريدية:
cust-spf.exactlyTtarget.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 ip4:13.-all"
وتتيح هذه المرونة لمزودي خدمة البريد الإلكتروني إمكانية التطوير دون الاضطرار إلى التواصل مع كل عميل لتعديل سجلات DNS الخاصة به.
إذا كنت تستخدم خدمات بريد إلكتروني من جهة خارجية
على نحو مماثل للفقرة السابقة، إذا كنت تستخدم أي خدمات بريد إلكتروني من قبل جهة خارجية، وترغب في إنشاء تدفق بريد تم التحقق منه بالكامل بواسطة SPF، فيجب عليك تضمين سجلات SPF الخاصة بك.
jetblue.com نص وصفي "v=spf1 include:_spf.qualtrics.com؟all"
تستخدم JetBlue خدمة Qualtrics analytics، والشيء الوحيد الذي يحتاجون إلى القيام به هو تضمين سجل SPF صحيح من Qualtrics. وعلى نحو مماثل، توفر أغلب مزودي خدمة الإنترنت الآخرين سجلات عامل الأداء الخاص (SPF) لتضمينها في سجلات عملائهم.
إذا لم يوفر موفر خدمة الإنترنت (ESP) أو مسوق البريد الإلكتروني لديك سجلات SPF، فسيتعين عليك إدراج بوابات البريد الصادرة مباشرة في سجلاتك. ومع ذلك، تكون من مسؤوليتك حينئذ الحفاظ على دقة هذه السجلات، وإذا قام الموفر بإضافة بوابات إضافية أو تغيير عناوين IP أو أسماء المضيف، فقد يتعرض تدفق البريد للخطر.
ينشأ الخطر الإضافي من جهات خارجية غير واعية ل SPF من مشاركة الموارد: إذا كان مزود خدمة الإنترنت (ESP) يستخدم عنوان IP نفسه لتسليم بريد إلكتروني للعديد من العملاء، فمن الممكن تقنيا أن يقوم أحد العملاء بإنشاء رسالة صالحة ل SPF يدعي فيها أنه عميل آخر يقدم عبر الواجهة نفسها. لهذا السبب، قبل وضع أي قيود SPF، يجب عليك التحقيق في سياسات أمان MSP الخاصة بك والتوعية بمصادقة البريد الإلكتروني. إذا لم يكن لديهم إجابات على أسئلتك، بالنظر إلى كون SPF إحدى الآليات الأساسية للثقة على الإنترنت، ينصح بشدة بإعادة النظر في إختيارك MSP. الأمر لا يتعلق فقط بالأمن - SPF و DKIM و DMARK والمرسلون الآخرون أفضل الممارسات [4] التي تستخدمها MSPs هي ضمان للتسليم. وإذا لم يتبعهم مزودو الخدمات المدارة (MSP) أو يتبعوهم بشكل غير صحيح، فإن ذلك يقلل من جدواهم للثقة مع أنظمة الاستلام الكبيرة وربما يؤخر أو حتى يحجب رسائلك.
(فرعي)مجالات بدون حركة مرور للبريد الإلكتروني
تمتلك معظم المؤسسات اليوم العديد من المجالات لأغراض التسويق ولكنها لا تستخدم سوى واحدة بشكل نشط لحركة مرور البريد الإلكتروني للشركات. حتى إذا تم نشر SPF بشكل صحيح على مجال الإنتاج، ما يزال يمكن للجهات الفاعلة السيئة إستخدام مجالات أخرى لا يتم إستخدامها بشكل نشط للبريد الإلكتروني لتهتك هوية المؤسسة. يمكن أن يمنع SPF هذا من الحدوث من خلال سجل "رفض الكل" الخاص ب SPF - لأي من المجالات (والمجالات الفرعية!) التي لا تقوم بإنشاء حركة مرور البريد الإلكتروني، قم بنشر "v=spf1 -all" في DNS. ومن الأمثلة الممتازة هذا الموقع openspf.org الموقع الشبكي لمجلس الصندوق الخاص.
بما أن تفويض SPF صالح فقط لمجال واحد، فمن المهم أيضا نشر سجلات "رفض جميع" SPF لأي مجالات فرعية قد تستخدمها والتي قد لا تقوم بإنشاء بريد إلكتروني. حتى إذا كان مجال الإنتاج لديك يحتوي على سجل SPF "منتظم"، فقم بجهد إضافي لإضافة سجلات "رفض الكل" إلى مجالاتك الفرعية بدون حركة مرور. مرة أخرى - لا تنسى أن الاستلام لا يعادل الإرسال: قد يكون المجال يتلقى بريد إلكتروني بالفعل، ولكنه لن يكون مصدرا أبدا. وهذا صحيح تماما لمجالات التسويق قصيرة الأجل (على سبيل المثال الأحداث والعروض المحدودة للوقت وطرح المنتجات...)، حيث يتم تسليم رسائل البريد الإلكتروني الواردة إلى هذه المجالات إلى مجال الإنتاج الخاص بك، وسيتم إرسال أي ردود على رسائل البريد الإلكتروني هذه من مجال الإنتاج. سيكون لهذه المجالات القصيرة الأجل سجل MX صالح ولكن يجب أن يكون لها سجل SPF الذي يحدد هذه المجالات على أنها لا مصدر للبريد الإلكتروني أيضا.
اعتبارات نشر DKIM
DKIM لأجهزة الاستقبال
تكوين التحقق من DKIM على ESA مشابه للتحقق من SPF. في معلمات النهج الافتراضية لنهج تدفق البريد، قم ببساطة بتحويل التحقق من DKIM إلى "تشغيل". مرة أخرى، حيث أن DKIM لا يسمح بأي مواصفات نهج، فإن هذا سيتحقق من التوقيع ويدخل رأس "Authentication-Results":
نتائج المصادقة: mx1.hc4-93.c3s2.smtpi.com؛ dkim=pass (تم التحقق من صحة التوقيع) header.i=MileagePlus@news.united.com
يجب تنفيذ أي إجراءات تستند إلى نتائج التحقق من DKIM بواسطة عوامل تصفية المحتوى:
الصورة 2: شرط عامل تصفية محتوى التحقق من DKIM
وخلافا ل SPF، وهو واضح، فإن DKIM تتلاعب بنص الرسالة الفعلي، لذا فإن بعض المعلمات قد تكون محدودة. إختياريا، يمكنك إنشاء ملفات تعريف تحقق DKIM، وتعيين ملفات تعريف تحقق مختلفة لسياسات تدفق بريد مختلفة. إنها تسمح لك بتقييد أحجام المفاتيح للتوقيعات التي ستقبلها، وتعيين إجراءات فشل الاسترداد الأساسية وتكوين عمق التحقق من DKIM.
بينما تمر الرسالة بعدة بوابات، يمكن توقيعها عدة مرات وبالتالي تحمل توقيعات متعددة. لتمرير رسالة تحقق DKIM، يجب التحقق من أي توقيع. وبشكل افتراضي، ستقوم الإيسا بالتحقق من صحة ما يصل إلى خمسة توقيعات.
نظرا للانفتاح التاريخي لبروتوكول SMTP والبريد الإلكتروني وتردد الإنترنت بشكل عام في التكيف مع التغييرات (الإيجابية)، لا يزال هناك العديد من الحالات التي يمكن فيها فشل توقيعات DKIM بشكل مشروع مثل عندما يقوم مديرو قائمة المراسلات البريدية بترحيل الرسائل مباشرة ولكن بتعديل الرسائل، أو عندما يتم إعادة توجيه الرسائل مباشرة بدلا من إرسالها كمرفقات لرسائل جديدة. وهذا هو السبب في أن أفضل الممارسات للرسائل التي تفشل DKIM تظل بشكل عام هي الحجر الصحي أو وضع العلامات بدلا من إسقاطها.
التحضير للتوقيع مع DKIM
قبل أن تتمكن من تشغيل توقيع DKIM في نهج تدفق البريد ذي الصلة، تحتاج إلى إنشاء/إستيراد المفاتيح وإنشاء ملف (ملفات) تعريف توقيع DKIM ونشر المفتاح (المفاتيح) العام في DNS.
إذا كنت تقوم بالتوقيع على مجال واحد، فإن العملية تكون مباشرة. قم بإنشاء زوج المفاتيح، وإنشاء ملف تعريف التوقيع الفردي الخاص بك في قسم مفاتيح المجال من نهج البريد، وانقر فوق الخيار "إنشاء" ضمن "سجل DNS النصي" بمجرد أن يكون ملف التعريف الخاص بك جاهزا. قم بنشر المفتاح كما تم إنشاؤه في DNS. أخيرا، قم بتشغيل توقيع DKIM في نهج تدفق البريد.
الأمر يصبح أكثر تعقيدا إذا كنت تقوم بالتوقيع لمجالات مختلفة متعددة. في هذه الحالة، لديك خيارين:
- أستخدم ملف تعريف توقيع مفرد للتوقيع على كل المجالات. سوف تقوم بتخزين المفتاح العام (الواحد) في منطقة DNS الخاصة بالمجال "الأساسي"، وستشير توقيعات DKIM الخاصة بك إلى هذا المفتاح. وغالبا ما كانت هذه التقنية تستخدم من قبل مزودي خدمة الإنترنت (ESPs) في الماضي - حيث كانت تسمح لهم بالتوقيع على نطاق واسع، في حين لم يكونوا مضطرين للتفاعل مع مساحة DNS الخاصة بالعملاء الأفراد [5].
- قم بإنشاء ملف تعريف توقيع منفصل لكل مجال تقوم بالتوقيع عليه. يؤدي ذلك إلى إجراء عملية تهيئة أولية أكثر تعقيدا، ولكنه يوفر المزيد من المرونة للتحرك إلى الأمام. قم بإنشاء زوج مفاتيح لكل مجال، وإنشاء ملف تعريف يحدد مجال واحد فقط (ومجالاته الفرعية) في القسم "مستخدمو ملف التعريف"، ونشر المفتاح العام المناسب في منطقة DNS الخاصة بالمجال.
على الرغم من سهولة البدء بالخيار رقم 1، تذكر أنه في نهاية المطاف سوف يكسر DMARK. بما أن DMARK يتطلب أن يتم محاذاة معرف مجال التوقيع مع "الرأس من"، ستفشل محاذاة المعرف مع DKIM. قد تكون قادرا على الابتعاد عنه إذا قمت بتكوين SPF بشكل صحيح، واعتمدت على محاذاة معرف SPF لتمرير التحقق من DMARK.
ومع ذلك، بتنفيذ الخيار رقم 2 من البداية، لا تحتاج إلى القلق بشأن DMARK ومن السهل للغاية إبطال خدمة إعادة التكوين أو إعادة تكوينها لمجال واحد فقط. أيضا، إذا قمت بتوفير بعض خدمات البريد الإلكتروني لمجال تابع لجهة خارجية، فستحتاج على الأرجح إلى الحصول على المفتاح المراد إستخدامه منها (واستيراده إلى ESA الخاص بك). سيكون هذا المفتاح خاص بالمجال، لذلك ستحتاج إلى إنشاء ملف تعريف منفصل.
إذا كنت تستخدم خدمات بريد إلكتروني من جهة خارجية
بشكل عام، إذا كنت تستخدم توقيع DKIM وإلغاء تحميل بعض من معالجة بريدك الإلكتروني (مثل رسائل البريد الإلكتروني التسويقية) إلى جهة خارجية، فأنت لا تريد منهم إستخدام نفس المفاتيح التي تستخدمها في الإنتاج. وهذا هو أحد الأسباب الرئيسية لوجود المحددين في DKIM. بدلا من ذلك، يجب إنشاء زوج مفاتيح جديد ونشر الجزء العام في منطقة DNS وتسليم المفتاح السري إلى الطرف الآخر. كما سيتيح لك هذا إمكانية إبطال هذا المفتاح بشكل سريع في حالة حدوث مشكلة مع الحفاظ على البنية الأساسية ل DKIM الخاصة بالإنتاج دون المساس بها.
على الرغم من أنه ليس من الضروري ل DKIM (يمكن توقيع الرسائل الخاصة بنفس المجال باستخدام مفاتيح متعددة مختلفة)، فمن الممارسات الجيدة توفير مجال فرعي منفصل لأي بريد إلكتروني تتم معالجته بواسطة طرف ثالث. وسيجعل هذا الأمر من تعقب الرسائل أكثر سهولة، وسيسمح بتنفيذ أكثر نظافة لمقر DMARK في وقت لاحق. على سبيل المثال، ضع في اعتبارك تلك الرؤوس الخمسة الخاصة بتوقيع DKIM من رسائل متعددة من Lufthansa:
توقيع DKIM: v=1؛ a=rsa-sha1؛ c=relaxed/relaxed؛ s=lufthansa؛ d=newsletter.milesandmore.com؛
توقيع DKIM: v=1؛ a=rsa-sha1؛ c=relaxed/relaxed؛ s=lufthansa2؛ d=newsletter.lufthansa.com؛
توقيع DKIM: v=1؛ a=rsa-sha1؛ c=relaxed/relaxed؛ s=lufthansa3؛ d=lh.lufthansa.com؛
توقيع DKIM: v=1؛ a=rsa-sha1؛ c=relaxed/relaxed؛ s=lufthansa4؛ d=e.milesandmore.com
توقيع DKIM: v=1؛ a=rsa-sha1؛ c=relaxed/relaxed؛ s=lufthansa5؛ d=fly-lh.lufthansa.com؛
يمكننا أن نرى أن Lufthansa يستخدم خمسة مفاتيح مختلفة (محددين) تقسيم على خمسة مجالات فرعية منفصلة من مجالين للإنتاج الأساسي (lufthansa.com و milesandmore.com). وهذا يعني أنه يمكن التحكم في كل واحد من هذه العناصر بشكل مستقل، ويمكن الاستعانة بمصادر خارجية في كل منها إلى موفر خدمة مراسلة مختلف.
اعتبارات نشر خدمة DMARK
DMARK لأجهزة الاستقبال
يعتمد التحقق من DMARK في ESA على ملف التعريف، ولكن على عكس DKIM، يجب تحرير ملف التعريف الافتراضي ليكون متوافقا مع المواصفات. والسلوك الافتراضي ل ESA هو عدم إسقاط أي رسائل ما لم يتم توجيهها بشكل صريح من قبل العميل، لذلك سيتم تعيين جميع الإجراءات على "عدم إتخاذ أي إجراء" في ملف تعريف التحقق من DMARK الافتراضي. بالإضافة إلى ذلك، لتمكين إنشاء التقرير الصحيح، ستحتاج إلى تحرير "الإعدادات العمومية" لقسم DMARK في "نهج البريد".
بمجرد إعداد ملف تعريف، يتم تعيين التحقق من DMARK، مثل الاثنين الآخرين، في قسم إعدادات النهج الافتراضية في نهج تدفق البريد. تأكد من تحديد المربع لإرسال تقارير ملاحظات مجمعة - يمكن القول أن هذه هي الميزة الأكثر أهمية في DMARK للمرسل. وفي وقت كتابة هذا التقرير، لم تكن الإيسا تدعم إعداد تقارير فشل لكل رسالة ("RUF" Tag of DMARK Policy).
وكما ينصح المرسل بإجراءات سياسة DMARK، على عكس SPF أو DKIM، لا توجد إجراءات محددة قابلة للتكوين خارج تكوين ملف التعريف. ليس من الضروري إنشاء أي عوامل تصفية محتوى.
سيقوم التحقق من DMARK بإضافة حقول إضافية إلى رأس نتائج المصادقة:
المصادقة-النتائج: mx1.hc4-93.c3s2.smtpi.com؛ dkim=pass (تم التحقق من التوقيع) header.i=MileagePlus@news.united.com؛ dmark=pass (p=none dis=none) d=news.united.com
وفي المثال المذكور أعلاه، نرى أنه تم التحقق من DMARK استنادا إلى محاذاة معرف DKIM، وطلب المرسل سياسة "لا شيء". وهذا يشير إلى أنهم حاليا في مرحلة "المراقبة" لنشر DMARK.
إذا قمت بتوفير خدمات البريد الإلكتروني لمجالات أخرى أو أطراف خارجية
يتمثل أكبر قلق مزودي خدمة الإنترنت (ESPs) فيما يتعلق بالتوافق مع معيار DMARK في تحقيق محاذاة مناسبة لمعرف الهوية. عند التخطيط ل DMARK، تأكد من إعداد SPF الخاص بك بشكل صحيح، وأن كل المجالات الأخرى ذات الصلة بها بوابات صادرة في سجلات SPF الخاصة بك وأنها لا ترسل رسائل تفشل في المحاذاة، بشكل أساسي باستخدام مجالات مختلفة للبريد من الهوية والرأس منها. غالبا ما يتم تنفيذ هذا الخطأ من قبل التطبيقات التي ترسل إعلامات البريد الإلكتروني أو التحذيرات لأن واضعي التطبيق غير مدركين في الغالب لعواقب عدم تناسق هويات البريد الإلكتروني الخاصة بهم.
كما هو موضح مسبقا، تأكد من إستخدام ملف تخصيص توقيع DKIM مستقل لكل مجال، وأن ملف تخصيص التوقيع الخاص بك يشير بشكل صحيح إلى المجال الذي تقوم بالتوقيع عليه كما هو مستخدم في Header From. إذا كنت تستخدم المجالات الفرعية الخاصة بك، يمكنك التوقيع باستخدام مفتاح واحد، ولكن تأكد من تعيين التزامك ب DKIM على التخفيف في سياسة DMARK ("adkim=").
بشكل عام، إذا كنت تقدم خدمات بريد إلكتروني لعدد أكبر من الأطراف الثالثة التي ليس لديك سيطرة مباشرة عليها، فإنه من الممارسات الجيدة أن تكتب وثيقة توجيه حول كيفية إرسال بريد إلكتروني والذي من المرجح أن يقوم بتسليم. ونظرا لأن البريد الإلكتروني من مستخدم إلى مستخدم يتم التصرف فيه بشكل جيد بشكل عام، فإن هذا سيكون في الغالب بمثابة مستند سياسة لواضعي التطبيق في الأمثلة المذكورة أعلاه.
إذا كنت تستخدم خدمات بريد إلكتروني من جهة خارجية
إذا كنت تستخدم جهات خارجية لتسليم بعض حركة مرور البريد الإلكتروني الخاصة بك، فإن الطريقة المثلى هي تفويض مجال فرعي منفصل (أو مجال مختلف تماما) إلى موفر جهة خارجية. بهذه الطريقة يمكنهم إدارة سجلات SPF حسب الحاجة، ولديهم بنية أساسية منفصلة لتوقيع DKIM، ولا يتدخلون في حركة مرور الإنتاج. بعد ذلك، يمكن أن تكون سياسة DMARK للبريد الإلكتروني الصادر عن جهات خارجية مختلفة عن تلك الخاصة بجهات داخلية. وكما ذكرنا مسبقا، عند النظر في البريد الإلكتروني الذي تم تسليمه من قبل جهة خارجية، تأكد دائما من محاذاة معرفات الهوية الخاصة بك، ويتم تعيين التزامك ب DKIM و SPF بشكل مناسب في سياسة DMARK الخاصة بك.
(فرعي)مجالات بدون حركة مرور للبريد الإلكتروني
تتمثل إحدى التحسينات الأخرى التي تم إدخالها على DMARK مقارنة بتقنيات مصادقة البريد الإلكتروني السابقة في كيفية معالجتها للمجالات الفرعية. بشكل افتراضي، تنطبق سياسة DMARK الخاصة بالمجال على جميع المجالات الفرعية الخاصة به. عند إسترداد سجلات نهج DMARK، في حالة عدم العثور على أي سجل في Header من مستوى FQDN، يلزم المستلمون بتحديد المجال التنظيمي [6] الخاص بالمرسل والبحث عن سجل نهج هناك.
ومع ذلك، يمكن لسياسة DMARK الخاصة بمجال تنظيمي أيضا تحديد علامة سياسة مجال فرعي ("sp" لسجل DMARK) منفصلة تنطبق على أي مجالات فرعية ليس لها سياسة DMARK صريحة منشورة.
في السيناريو الذي تمت مناقشته سابقا في فصل SPF، يمكنك:
- قم بنشر سجل DMARK صريح لأي مجالات فرعية تمثل مصادر مشروعة للبريد الإلكتروني.
- نشر سياسة مجال فرعي ل "رفض" في سجل نهج المجال التنظيمي الخاص بك لرفض أي رسائل بريد إلكتروني تنسب إلى مجالات غير مرسلة تلقائيا
يوفر هذا النوع من هيكلة مصادقة البريد الإلكتروني أفضل حماية ممكنة للبنية الأساسية والعلامة التجارية.
القضايا الخاصة ب DMARK
هناك العديد من القضايا المحتملة مع DMARK، وكلها تأتي من طبيعة وأوجه القصور في تكنولوجيات التوثيق الأخرى التي تعتمد عليها. المشكلة هي أن DMARK أخرج هذه المشاكل إلى السطح من خلال الضغط بنشاط على سياسة لرفض البريد الإلكتروني، ومن خلال ربط كافة معرفات المرسل المختلفة في رسالة.
تحدث معظم المشكلات مع القوائم البريدية وبرامج إدارة القوائم البريدية. عندما يتم إرسال بريد إلكتروني إلى قائمة بريدية، فإنه يتم إعادة توزيعه على كافة المستلمين. ومع ذلك، سيتم تسليم البريد الإلكتروني الناتج، الذي يحتوي على عنوان مرسل للمرسل الأصلي، بواسطة البنية الأساسية المضيفة لمدير القائمة البريدية، وبالتالي فشل فحوصات SPF الخاصة ب "الرأس من" (يستخدم معظم مديري القائمة البريدية عنوان القائمة كمظروف من (البريد من) وعنوان المرسل الأصلي كرأس من).
وبما أن DMARK سيفشل بالنسبة ل SPF، فقد نعتمد على DKIM، ومع ذلك، فإن معظم مديري القوائم البريدية يضيفون أيضا رسائلهم إلى الرسائل، أو يضعون علامة على أشخاص ذوي اسم القائمة، مما يؤدي إلى مخالفة التحقق من توقيع DKIM.
يقترح مؤلفو DKIM عدة حلول للمشكلة، تنحصر كلها في ضرورة إستخدام مديري القائمة البريدية لعنوان القائمة في جميع عناوين "من"، مع الإشارة إلى عنوان المرسل الأصلي بوسائل أخرى.
تنشأ مشاكل مماثلة من الرسائل التي يتم إعادة توجيهها عن طريق نسخ الرسالة الأصلية عبر SMTP إلى المستلم الجديد. ومع ذلك، فإن معظم "وكلاء مستخدم البريد" المستخدمة اليوم سوف تشكل بشكل صحيح رسالة جديدة وتتضمن الرسالة المعاد توجيهها إما في السطر أو كمرفق بالرسالة الجديدة. ستمرر الرسائل التي تمت إعادة توجيهها بهذه الطريقة DMARK إذا مر مستخدم إعادة التوجيه (بالطبع، لا يمكن التحقق من صحة الرسالة الأصلية).
نموذج خطة العمل لتنفيذ مصادقة البريد الإلكتروني
على الرغم من أن التقنيات نفسها بسيطة، إلا أن الطريق إلى تنفيذ بنية أساسية كاملة لمصادقة البريد الإلكتروني يمكن أن يكون طويلا وملتفا. أما بالنسبة للمؤسسات الأصغر حجما وتلك التي لديها تدفقات بريدية خاضعة للسيطرة، فإن هذا الأمر سوف يكون واضحا إلى حد كبير، في حين قد تجد البيئات الأكبر حجما صعوبة بالغة في تحقيقه. وليس من غير الشائع أن تستعين المؤسسات الكبرى بمساعدات إستشارية لإدارة مشروع التنفيذ.،
الخطوة 1: DKIM
DKIM غير تطفلي نسبيا لأن الرسائل غير الموقعة لن تؤدي إلى أي رفض. وقبل التنفيذ الفعلي، يؤخذ في الاعتبار جميع النقاط المذكورة آنفا. اتصل بأي طرف ثالث يمكنك تفويض التوقيع إليه، وتأكد من أن الأطراف الثالثة تدعم توقيع DKIM، وتضع إستراتيجية إدارة التحديد الخاصة بك في الاعتبار. تحتفظ بعض المؤسسات بمفاتيح منفصلة (محددين) للوحدات التنظيمية المختلفة. قد تضع في الاعتبار التدوير الدوري للمفاتيح للحصول على أمان إضافي - ولكن تأكد من عدم حذف مفاتيحك القديمة حتى يتم تسليم جميع الرسائل أثناء النقل.
وينبغي إيلاء إعتبار خاص للأحجام الرئيسية. على الرغم من أن "المزيد هو الأفضل" بشكل عام، إلا أنه يجب الأخذ في الاعتبار أن إنشاء توقيعين رقميين لكل رسالة (بما في ذلك تحويل البيانات إلى شبكات وما إلى ذلك) يعد مهمة باهظة التكلفة لوحدة المعالجة المركزية (CPU) ويمكن أن يؤثر على أداء بوابات البريد الصادرة. نظرا لارتفاع تكاليف الحوسبة، تعد 2048 بت أكبر حجم مفتاح عملي يمكن إستخدامه، ولكن بالنسبة لمعظم عمليات النشر، توفر المفاتيح من فئة 1024 بت تسوية جيدة بين الأداء والأمان.
لتنفيذ DMARK بنجاح في وقت لاحق، يجب عليك:
- التعرف على جميع المجالات التي تقوم بإرسالها باسم، بما في ذلك المجالات الفرعية
- إنشاء مفاتيح DKIM وإنشاء ملفات تعريف توقيع لكل مجال
- تسليم المفاتيح الخاصة ذات الصلة إلى أي أطراف ثالثة
- نشر كافة المفاتيح العامة في مناطق DNS ذات الصلة
- التأكد من أن الأطراف الثالثة مستعدة لبدء التوقيع
- تشغيل توقيع DKIM في نهج تدفق البريد المتصل على كل ESA
- إشعار الأطراف الثالثة ببدء التوقيع
الخطوة 2: SPF
من المحتمل أن يكون تنفيذ SPF بشكل صحيح هو الجزء الأكثر استهلاكا للوقت والأكثر إرهاقا في تنفيذ البنية الأساسية لمصادقة البريد الإلكتروني. نظرا لأن البريد الإلكتروني كان بسيطا للغاية للاستخدام والإدارة ومفتوحا تماما من وجهة نظر الأمان والوصول، فإن المؤسسات لم تقم تاريخيا بفرض سياسات صارمة حول من وكيف يمكن إستخدامه. وقد أدى ذلك إلى عدم امتلاك معظم المؤسسات اليوم نظرة كاملة على جميع المصادر المختلفة للبريد الإلكتروني، من الداخل والخارج على حد سواء. إن المشكلة الأكبر الوحيدة التي تواجه تنفيذ بروتوكول SPF تتلخص في اكتشاف من يرسل رسائل البريد الإلكتروني بالنيابة عنك بشكل مشروع حاليا.
أشياء يجب البحث عنها:
- أهداف واضحة - خوادم Exchange أو برامج مجمعة أخرى أو بوابات البريد الصادر
- أي حلول DLP أو أنظمة معالجة بريد إلكتروني أخرى قد تقوم بإنشاء إعلامات خارجية
- أنظمة CRM التي ترسل معلومات تتفاعل مع العملاء
- تطبيقات جهات خارجية متنوعة يمكنها إرسال بريد إلكتروني
- الخادمات المعملية أو المختبرة أو غيرها التي قد ترسل بريد إلكتروني
- أجهزة كمبيوتر وأجهزة شخصية تم تكوينها لإرسال بريد إلكتروني خارجي مباشرة
والقائمة المذكورة أعلاه غير كاملة، لأن المنظمات لها بيئات مختلفة، ولكن ينبغي النظر إليها كمبدأ توجيهي عام فيما يتعلق بما ينبغي البحث عنه. بمجرد (معظم) مصادر بريدك الإلكتروني، قد ترغب في الرجوع خطوة إلى الوراء، وبدلا من السماح لكل مصدر موجود، قم بتنظيف القائمة. من الناحية المثالية، يجب تسليم جميع رسائل البريد الإلكتروني الصادرة عبر بوابات البريد الصادرة مع بعض الاستثناءات المبررة. إذا كنت تملك حل بريد تسويقي خاص بك أو تستخدم حل بريد خارجي، فيجب عليك إستخدام بنية أساسية منفصلة بدلا من عبارات بريد إلكتروني للإنتاج. إذا كانت شبكة تسليم البريد لديك معقدة بشكل إستثنائي، فقد تستمر في توثيق الحالة الحالية في SPF الخاص بك، ولكن لا تستغرق وقتا لتنظيف الحالة في المستقبل.
إذا كنت تقوم بخدمة مجالات متعددة عبر البنية الأساسية نفسها، فقد ترغب في إنشاء سجل SPF عالمي واحد وترجمته في مجالات فردية باستخدام آلية "التضمين". تأكد من أن سجلات SPF ليست واسعة جدا، على سبيل المثال، إذا قامت خمسة أجهزة فقط في شبكة /24 بإرسال SMTP، فقم بإضافة عناوين IP الفردية هذه إلى SPF الخاص بك، بدلا من الشبكة بالكامل. حاول أن تكون سجلاتك محددة قدر الإمكان لتقليل أي فرص لظهور بريد إلكتروني ضار يخل بهويتك.
ابدأ بخيار Softfail للمرسلين غير المتطابقين ("~الكل"). قم بتغييره إلى فشل تام (الكل) فقط بمجرد التأكد 100٪ من أنك قمت بتعريف جميع مصادر البريد الإلكتروني لديك، وإلا فإنك تجازف بفقدان بريد الإنتاج الإلكتروني. بعد ذلك، وبعد تنفيذ برنامج DMARK وتشغيله في وضع المراقبة لفترة من الوقت، ستتمكن من تحديد أي أنظمة فاتتك وتحديث سجلات برنامج دعم المنتج الخاصة بك حتى تكتمل. وآنذاك فقط يصبح من الآمن تعيين SPF الخاص بك على فشل تام.
الخطوة الثالثة: مارك
بمجرد إعداد كل من DKIM و SPF قدر المستطاع، فقد حان الوقت لإنشاء سياسات DMARK الخاصة بك. خذ بعين الإعتبار جميع المواقف المختلفة المذكورة في الفصول السابقة، واستعد لنشر أكثر من سجل DMARK واحد إذا كانت لديك بنية أساسية معقدة للبريد الإلكتروني.
قم بإنشاء أسماء مستعارة للبريد الإلكتروني تتلقى التقارير، أو قم بإنشاء تطبيق ويب يمكنه إستلامها. لا توجد عناوين بريد إلكتروني محددة بدقة ليتم إستخدامها لهذا الغرض، ولكن من المفيد أن تكون هذه العناوين وصفية، على سبيل المثال rua@domain.com و dmarc.rua@domain.com و mailauth-rua@domain.com وما إلى ذلك. تأكد من وجود عملية لدى المشغل لمراقبة هذه العناوين وتعديل تكوين SPF و DKIM و DMARK بشكل مناسب، أو تنبيه فريق الأمان في حالة حدوث حملة انتحال. في البداية، سيكون عبء العمل كبيرا أثناء تعديل السجلات لتغطية أي شيء قد فاتك أثناء تهيئة SPF و DKIM. وبعد فترة من الوقت، قد تشير التقارير إلى محاولات انتحال فقط.
في البداية، قم بتعيين سياسة DMARK على "لا شيء" وخيار الطب الشرعي الخاص بك لإرسال تقارير حول أي عمليات تحقق تحقق من الفشل ("fo=1") - وسيكتشف هذا الأمر بسرعة أي أخطاء في SPF و DKIM مع عدم التأثير على حركة المرور. بمجرد أن تكون سعيدا بمحتويات التقارير المقدمة، قم بتغيير النهج إلى "عزل" أو "رفض"، وفقا لسياسة الأمان والتفضيل. مرة أخرى، تأكد من وجود مشغلين يحللون تقارير DMARK التي تم تلقيها باستمرار لأي نتائج إيجابية خاطئة.
تنفيذ DMARK بشكل كامل وصحيح ليس مهمة صغيرة أو قصيرة. وفي حين يمكن الحصول على بعض النتائج (و"التنفيذ" الرسمي ل DMARK) بنشر مجموعة غير كاملة من السجلات وسياسة "لا شيء"، فإن من مصلحة كل من المنظمة المرسلة والإنترنت ككل أن ينفذها الجميع إلى أقصى حد من قدراتها.
وفيما يتعلق بالخطوط الزمنية، يرد فيما يلي مخطط تفصيلي تقريبي جدا للخطوات الفردية لمشروع نموذجي. ومرة أخرى، بما أن كل منظمة مختلفة، فإن هذه ليست دقيقة على الإطلاق:
| 1 - التخطيط والإعداد لآلية التنمية النظيفة |
من أسبوعين إلى أربعة أسابيع |
| 2. تشغيل إختبار DKIM |
أسبوعان |
| 3- SPF - تعريف المرسل المشروع |
من أسبوعين إلى أربعة أسابيع |
| 4 - إعداد سياسة مركز إدارة بريد المؤسسة |
أسبوعان |
| 5. تشغيل إختبار سجلات SPF و DMARK |
من 4 إلى 8 أسابيع |
| 6. تشغيل إختبار SPF مع Hardfail |
أسبوعان |
| 7. تشغيل إختبار DMARK مع الحجر الصحي/الرفض |
4 أسابيع |
| 8 - رصد تقارير مكتب مراقبة المخدرات ومنع الجريمة وتكييفها وفقا لذلك |
مستمر |
ومن المرجح أن تشهد المنظمات الأصغر حجما فترة أقصر لمعظم الخطوات، وخاصة الخطوة 3 والخطوة 4. بغض النظر عن مدى بساطة البنية الأساسية للبريد الإلكتروني الذي تعتقد أنه قد يكون، قم دائما بتخصيص وقت كاف أثناء تشغيل الاختبار ومراقبة تقارير الملاحظات عن كثب لأي شيء قد تكون فاتتك.
وقد تشهد المنظمات الأكبر حجما فترة أطول من نفس الخطوات، مع متطلبات إختبار أكثر صرامة. ليس من غير الشائع أن تقوم الشركات ذات البنية التحتية المعقدة للبريد الإلكتروني بتوظيف مساعدة خارجية، ليس فقط للجانب التقني لتطبيق مصادقة البريد الإلكتروني بل أيضا لإدارة المشروع بأكمله والتنسيق عبر الفرق والأقسام.
مراجع إضافية
- الموقع المرجعي ل SPF: http://www.openspf.org
- مجلس الإدارة: http://www.dkim.org
- موقع DMARK الرئيسي، الذي يتم تشغيله بواسطة مشروع المجال الموثوق به: http://www.dmarc.org
- دمارسيان موقع المساعدة والموارد الذي يديره تيم درايجن، أحد واضعي DMARK. تأكد من زيارة قسم "الأدوات": http://www.dmarcian.com
- أداة التحقق من صحة سجل Online Trust Alliance: https://otalliance.org/resources/spf-dmarc-record-validator
- مساعد تسجيلات DMARK - أداة مفيدة أخرى تساعدك على إنشاء سجلات DMARK: http://www.kitterman.com/dmarc/assistant.html
- أدوات إختبار سجلات SPF: http://www.kitterman.com/spf/validate.html
- "لا تكن عبقريا: تعمق في تقنيات مصادقة البريد الإلكتروني"، عرض Cisco Live 2014 التقديمي BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627
[1] تتجاوز Canonicalization نطاق هذا المستند. ارجع إلى المواد الواردة في قسم "المراجع الإضافية" للحصول على مزيد من المعلومات حول تحويل DKIM إلى DKIM.
[2] معلمات سجل DKIM DNS خارج نطاق هذا المستند أيضا.
[3] يتجاوز إنشاء عوامل تصفية الرسائل نطاق هذا المستند. الرجاء الرجوع إلى AsyncOS للحصول على أدلة مستخدم البريد الإلكتروني للحصول على المساعدة.
[4] تعرف M3AAWG على مجموعة ممتازة من أفضل الممارسات التي تطبقها وتحترمها معظم هذه الصناعة. يتوفر مستند أفضل الممارسات الشائعة لمرسليها على موقع الويب https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf
[5] يستغل هذا السلوك حقيقة أن DKIM لا تتحقق في الأصل من مصدر الرسالة كما هو موضح في "البريد من" أو "العنوان من" على الإطلاق. وهو يتحقق فقط من أن المعلمة ("d") الخاصة بتوقيع DKIM والمعلمة "اسم المجال" في ملف تعريف التوقيع الخاص بك) تستضيف بالفعل المفتاح العام للزوج المستخدم لتوقيع الرسالة. تمت الإشارة إلى أصالة المرسل من خلال توقيع الرأس "من". فقط تأكد من سرد أي وكل المجالات (والمجالات الفرعية) التي تقوم بالتوقيع عليها في قسم "مستخدمو ملف التعريف".
[6] عادة، يكون أحد المجالات أقل من مستوى TLD أو بادئة TLD ذات الصلة (.ac.uk، .com.sg...)
التعليقات