[ أمن النقل ]
وجهات الإبلاغ TLS-RPT وتسليم التقرير
حدد مسارات مجموعة mailto أو HTTPS المعتمدة، وتكامل التقرير، والتوقيت، ومسؤوليات المعالجة دون افتراض التسليم المكرر المضمون.
بواسطة فريق البحث EmailAuth · 8 دقائق قراءة
[النقاط الرئيسية]
- تعد مجموعة TLS-RPT وإنفاذ النقل تبعيات منفصلة.
- لا تضمن وجهات rua المتعددة الحصول على نسخة عند كل نقطة نهاية.
- التحقق من الاستلام والنزاهة والتحليل والإسناد كمراحل متميزة.
[ الوجبات الجاهزة ]
تعامل مع وجهة إعداد التقارير كعقد خدمة مملوك مع مشاركة البيانات المعتمدة ومراحل التسليم إلى المعالجة التي يمكن ملاحظتها.
[ حسب الدور ]
ماذا يعني هذا بالنسبة لك
اختر دورك للخطوات العملية التالية.
تكنولوجيا المعلومات / مدير البريد
تتبع التقرير من خلال الجمع
قبول نقطة النهاية ليس مثل التحليل الناجح.
الخطوات التالية
- تحقق من سجل التقارير الدقيق وعناوين URI المدعومة.
- الحفاظ على معرفات التقرير من خلال الاستيعاب.
- تحقق من الضغط والنزاهة والإسناد بشكل منفصل.
كبير مسؤولي أمن المعلومات / SecOps
الموافقة على قناة الإبلاغ وحمايتها
تحمل التقارير بيانات تعريف تشغيلية ومحتوى غير موثوق به.
الخطوات التالية
- الموافقة على المستلمين الخارجيين والاحتفاظ بهم.
- الحفاظ على عمليات التحقق من توقيع تقرير SMTP المطلوبة.
- تجنب افتراض أن نقل التقرير مشفر دائمًا.
المؤسس / غير التقنية
تعيين المساءلة جمع
إن نشر الوجهة لا يجعل الشخص مسؤولاً عن التعامل مع حالات الفشل.
الخطوات التالية
- اسم جامع وصاحب الحادث.
- تحديد العلاقة بين الأرشيف ولوحة المعلومات.
- ضع توقعات واقعية للمشاركة والتوقيت.
[ الأسئلة الشائعة ]
الأسئلة المتداولة
أين يتم نشر سجل TLS-RPT ؟
في _smtp._tls ضمن مجال السياسة، باستخدام TXT مع الإصدار TLSRPTv1 ووجهات rua. وهذا منفصل عن ملف سياسة MTA-STS .
ما هي أنظمة الوجهة التي يدعمها RFC 8460 ؟
المخططات المدعومة هي mailto وhttps. تستخدم تقارير HTTPS POST؛ تستخدم تقارير mailto مسار تسليم صندوق البريد المحدد.
هل تتطلب الوجهة الخارجية سجل تفويض بنمط DMARC؟
لا يحدد RFC 8460 مصافحة DNS بنمط DMARC. تأكيد الموافقة التنظيمية وأي عملية تأهيل خاصة بهواة الجمع بشكل منفصل؛ لا تخترع سجل البروتوكول.
هل سيتلقى كل من معرفي URI الخاصين بـ rua كل تقرير؟
ليس بالضرورة. يمكن للمراسل تجربة عدة وجهات مدعومة أو اختيار واحدة. القبول الناجح عند نقطة نهاية واحدة يمكن أن يرضي التسليم.
ما هو فحص التكامل الذي ينطبق على تقارير SMTP ؟
وهي تتطلب توقيع DKIM صالحًا لمجال إعداد التقارير بدون l=. يجب أن يعلن المفتاح s=tlsrpt; قد يتجاهل المتلقي التقارير التي تفتقر إلى إعلان الخدمة هذا.
هل يثبت إقرار HTTPS نجاح المعالجة؟
لا، فالاستجابة الناجحة تشير إلى التسليم، وقد يقوم المُجمع بالمعالجة لاحقًا. تتبع نتائج قائمة الانتظار والمحلل والإسناد بشكل منفصل.
هل التقارير اليومية مضمونة؟
لا. يوصى بفترة زمنية كاملة بالتوقيت العالمي المنسق (UTC) وتأخير التسليم، ولكن التقارير اختيارية ولا يتبع ذلك أي وعد بالاستلام اليومي الشامل.
ماذا يحدث إذا تم نشر سجلين صالحين لسياسة TLS-RPT ؟
بعد تجاهل سجلات موارد TXT التي لا تبدأ بالبادئة الحرفية " v=TLSRPTv1; "، يجب على المرسل العثور على سجل واحد متبقٍ بالضبط. إذا وجد صفرًا أو أكثر من واحد، RFC 8460 يتطلب منه افتراض عدم تنفيذ TLS-RPT . حدود السجلات مهمة: السلاسل المتعددة ضمن سجل TXT واحد لا تعني في حد ذاتها سجلات سياسة متعددة.
[ مصادر ]
مصادر
- RFC 8460
الأقسام §3. سياسة إعداد التقارير · §4.1 الإطار الزمني للتقرير · §4.3 أنواع النتائج · §5.2 الضغط · §5.3 نقل البريد الإلكتروني · §5.4 نقل HTTPS · §5.5 إعادة محاولة التسليم · §5.6 تباينات البيانات الوصفية · §7. الاعتبارات الأمنية
[ مسرد ]
مسرد
- معرف التقرير
- البيانات التعريفية المستخدمة لتحديد التقرير والمساعدة في اكتشاف عمليات الإرسال المكررة.
- عقد جامع
- تغطي الاتفاقية المقترحة ملكية الوجهة ومعالجة البيانات ومعالجة الأدلة.
مصدر المؤسسة
لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.
تبيع لك منصات مصادقة البريد الإلكتروني التقليدية لوحة تحكم وتطلب من مهندسيك القيام بهذا العمل. في البيئات عالية المخاطر، تعني المراقبة اليدوية تأخير التنفيذ، والانحراف في التكوين، ونطاقات الظل غير الخاضعة للمراقبة.
EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.
SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK