قد يرى المرضى نفس الشعار في رسالة التذكير بالموعد ورسالة التسجيل والبريد الإلكتروني للوصول إلى البوابة حتى عندما ترسلهم ثلاثة تطبيقات مختلفة. تحديد الخدمة خلف كل رسالة. ثم اختبر هوية البريد الإلكتروني وسلوك التطبيق الذي يجعل الإشعار مفيدًا وآمنًا.
تحديد الزناد والوجهة
بالنسبة للمواعيد، قم بتسجيل حدث الجدولة الذي يؤدي إلى تشغيل رسالة وكيفية تأثير إعادة الجدولة أو الإلغاء على التذكيرات الموجودة في قائمة الانتظار. للتسجيل قم بتسجيل التطبيق المسؤول عن مطابقة الرسالة للشخص المقصود. للوصول إلى البوابة، حدد خدمة الحساب والارتباط المعتمد أو دورة حياة الكود. احتفظ بموفر البريد الإلكتروني والمستأجر الفعلي بجانب كل تطبيق، وليس فقط عنوان موقع البوابة على الويب.
سجل المجال من وهوية المغلف، DKIM المجال و محدد لكل طريق. افحص وجهة الرد ومضيف البوابة الإلكترونية المعتمد كحقول منفصلة. التوقيع الصالح ضمن مجال الخدمة لا يثبت أن الرابط آمن أو حديث أو مخصص للمستلم. وعلى العكس من ذلك، لا يثبت عنوان URL المألوف للبوابة الإلكترونية أن البريد الإلكتروني مرخص.
اختبار تغييرات دورة الحياة باستخدام السجلات الخيالية
إنشاء حالات التعيين والتسجيل الاصطناعية المعتمدة. ممارسة موعد جديد، وإعادة الجدولة، والإلغاء، ومحاولة التسجيل المكررة وطلب الوصول إلى البوابة حيث تسمح بيئة الاختبار بذلك. تأكد من الرسائل التي تظهر بالفعل، وما إذا كان التطبيق قد قام بمنع التذكيرات القديمة وما إذا كانت الروابط تؤدي إلى بوابة الاختبار المتوقعة.
بالنسبة لرسائل الوصول إلى الحساب، استخدم قيم العرض التوضيحي غير الوظيفية أو حساب اختبار معتمد منفصل. لا تحتفظ بروابط أو أكواد وصول المريض القابلة للاستخدام في أدلة المصادقة العامة. قد يمر البريد الإلكتروني المؤجل الوصول DKIM أثناء انتهاء صلاحية الرمز المميز الخاص به؛ وهذه نتيجة لدورة حياة التطبيق، وليست دليلاً على وجود خلل في المصادقة.
فصل ثلاثة أنواع من الفشل
في حالة فشل DKIM أو عدم وجود مسار محاذٍ، يجب على فرق البريد والخدمة التحقق من تغييرات التوقيع والهوية والرسائل. إذا كان التذكير يتضمن وقتًا خاطئًا، فيجب على مالك الجدولة التحقق من إصدارات الأحداث ومعالجة المنطقة الزمنية. إذا وصلت الرسالة إلى عنوان قديم، فيجب على فرق التسجيل والهوية اتباع عملية تصحيح المستلم المعتمدة. لا تحل المسألتين الأخيرتين بالاسترخاء DMARC سياسة.
احتفظ بسجل اختبار قصير يحتوي على معرف الحالة الاصطناعية ووقت الحدث وهوية المرسل والمصادقة الملحوظة ونتائج الطلب والمالك. استخدم الحد الأدنى من الأدلة المنقحة. رؤوس البريد الإلكتروني لا يزال من الممكن أن تحتوي على عناوين شخصية ومعلومات توجيه، لذا تعامل معها وفقًا لقواعد الوصول والاحتفاظ الخاصة بالمؤسسة بدلاً من افتراض أن الرؤوس عامة.
تحديد قرار القبول
يتطلب هوية إرسال صحيحة بالإضافة إلى سلوك التطبيق المتوقع لكل مجموعة رسائل. لا يمكن لتمرير التوقيع وحده الموافقة على رحلة البوابة الإلكترونية. قم بتأكيد مسار الاسترداد المعتمد مع مالك الخدمة عند فشل التذكيرات أو إشعارات الوصول، دون إنشاء قناة اتصال بديلة غير معتمدة.
تترك الخريطة الخيالية أدناه نموذج الوصول إلى البوابة عن عمد مع توقيع مجال الموفر الذي لا يتوافق تمامًا. توضح صلاحية التشفير المنصوص عليها سبب عدم كفاية البحث عن DKIM =pass فقط. جاهزية الإنتاج تحتاج إلى أدلة الخدمة الفعلية والمطبقة SPF أو DKIM تنسيق، وليس الفرضية المكتوبة.
أعد التحقق بعد استبدال المجدول وتغييرات التسجيل وترحيل موفر الهوية ومضيفي البوابة الجديدة وتغييرات مجال المرسل. قم بتضمين الاستثناءات ذات الحجم المنخفض مثل المواعيد الملغاة والحسابات المستردة. هذه طريقة للتحقق التشغيلي، وليست ادعاءً بأن أي نظام أساسي للرعاية الصحية أو منتج EmailAuth ينفذ بالفعل عناصر التحكم هذه.
فحص دفتر أستاذ الطريق المكتوب
تستخدم جميع الصفوف النطاقات الخيالية المحجوزة والمالكين المقترحين ونتائج DKIM المنصوص عليها. المحدد التجريبي 1 هو تسمية توضيحية، وليس مفتاحًا مثبتًا. نتائج نظام التعرف على SPF ، والتوقيعات الأخرى، واكتشاف سياسة DNS ، والاستلام الفعلي، ونجاح التطبيق غير معروفة. لا يتم توفير أي مفاتيح أو رسائل موقعة أو تنفيذ اختبار أو أدلة تسليم.
- التعيين: من appointments.care.example ؛ البريد من مجهول؛ DKIM d=appointments.care.example, المحدد التجريبي 1، النجاح المفترض؛ المالك المقترح مالك الجدولة. الإجراء التالي: التحقق من مسار التوقيع المدعوم لهذا المستأجر ومعايير قبول الطلب المنفصلة الخاصة به.
- التسجيل: من registration.care.example ؛ بريد من مجهول؛ DKIM d=registration.care.example, المحدد التجريبي 1، النجاح المفترض؛ المالك المقترح مالك التسجيل. الإجراء التالي: التحقق من مسار التوقيع المدعوم لهذا المستأجر ومعايير قبول الطلب المنفصلة الخاصة به.
- الوصول إلى البوابة: من access.care.example ؛ بريد من مجهول؛ DKIM d=provider.example.net, المحدد التجريبي 1، المرور المفترض؛ مالك خدمة هوية المالك المقترح. الإجراء التالي: التحقق من مسار التوقيع المدعوم لهذا المستأجر ومعايير قبول الطلب المنفصلة الخاصة به.
يوفر توقيع التمرير المفترض الذي يتطابق d= تمامًا من مسارًا محاذيًا تمامًا لتلك الرسالة الافتراضية. لا يوفر d= غير المرتبط أي مسار محاذي من هذا التوقيع. يمنع SPF غير المعروف أو التوقيعات الأخرى صدور حكم الفشل الشامل للحالة الأخيرة. لا تحدد هذه المباني المكتوبة أي تكوين مباشر أو وضع للبريد الوارد.
قارن بين ثلاثة قرارات تتعلق بدورة الحياة
استخدم حالة البوابة الخيالية P-02 في مستأجر اختبار مقترح. تم إلغاء إصدار الموعد 1 الساعة 09:00 بتوقيت الخليج قبل إصدار التذكير الموجود في قائمة الانتظار: حتى تمرير DKIM المنصوص عليه يترك عيبًا في الجدولة. تعتبر رسالة التسجيل الموجهة إلى الحساب الاصطناعي الخاطئ بمثابة عيب في تعيين المستلم. يجب تقييم رابط الوصول مع انتهاء صلاحية مفترض عند 09:10 وفقًا لضريبة السلع والخدمات (GST) عند 09:12 وفقًا لقواعد انتهاء صلاحية التطبيق؛ المصادقة لا تمتد الصلاحية. يسجل كل من أصحاب الجدولة والتسجيل والهوية نتائجهم المتوقعة وملاحظة منفصلة. لم يتم توفير هذه الملاحظات هنا، لذلك لا يعتبر أي منها اختبارًا ناجحًا. لا تقم بنسخ الرموز الحية أو روابط المرضى أو الرموز القابلة للاستخدام في حزمة الأدلة.
أبقِ حدود الأدلة واضحة
RFC 9989 يميز القسمان 4.4 و5.3.5 بين المصادقة والمحاذاة؛ القسم 5.4 يترك معالجة الرسائل لسياسة المتلقي. يتطلب القسم 7.4 DKIM صالحًا بدلاً من نظام التعرف على SPF وحده لنشر النطاقات p=reject ويحذر من رفض المجالات التي يقوم مستخدموها بالنشر في قوائم بريد الإنترنت. تحدد البايتات الأساسية المغطاة سلامة DKIM بموجب أقسام RFC 6376 3.4-3.7 و6.1. ولا تؤكد أي من الآليتين السلطة السريرية أو التعليمية أو القانونية. جمع الأدلة الحالية المعتمدة للنشر الفعلي؛ قوائم المراجعة التشغيلية هنا هي توصيات، وليست تقييم امتثال خاص بالولاية القضائية.