بوابات الأمان التي تقوم بتعديل البريد الموقع

ابحث عن التعديل قبل إلقاء اللوم على البوابة

يمكن لبوابة الأمان فحص البريد أو تحويله بشكل قانوني مع تعقيد عملية نقل البيانات DKIM تَحَقّق. تعد إعادة كتابة عنوان URL واستبدال المرفقات وتحذيرات النص من الأمثلة المحتملة، ولكن وجود البوابة وحده لا يثبت شيئًا بشأن فشل التوقيع. حدد التمثيل الذي دخل إلى البوابة والذي غادرها وأين تم تقييم المصادقة.

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

جرد تسلسل المعالجة الدقيق

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

يصف RFC 7960 عوامل تصفية الحدود التي تزيل المحتوى الضار أو تضع علامة على البريد العشوائي المشتبه به أو تغير عناوين URL. ويشرح أيضًا السبب وراء إمكانية أن يؤدي تقييم المصادقة بعد تعديلات عامل التصفية إلى نتائج مختلفة. هذه احتمالات معمارية وليست حكمًا على مستأجر معين. يعد تتبع الرسالة والنسخ المحفوظة ضروريين لربط الآلية الموثقة بالحادث. RFC 7960 القسم 3.2.5

تحديد ما يغطيه التوقيع الفاشل

لكل DKIM-Signature، احتفظ بمجال التوقيع d=, محدد s=, تحديد العنوان القانوني c=, header list h= and any l= body-length value. The تجزئة الجسم يتم حسابه على مدخلات النص الأساسية المحددة؛ يغطي التوقيع أيضًا حالات الرأس المحددة. "لقد غيرت البوابة رأسًا" غير مكتملة دون معرفة ما إذا كان هذا المثيل قد تم تحديده وما إذا كان التحديد الأساسي يحافظ على الفرق. RFC 6376 الأقسام 3.4-3.5 و5.4

يتحمل التحديد الأساسي المريح تغييرات معينة في المسافات البيضاء وتنسيق الرأس. ولا يتعامل مع تعديلات HTML التعسفية أو بدائل عناوين URL أو تغييرات المرفقات كمحتوى مكافئ. وعلى العكس من ذلك، لا يحتاج الحقل المضاف خارج التغطية المحددة إلى إبطال التوقيع الموجود. يمكن أن يؤدي تكرار الرأس والتوقيع الزائد إلى تعقيد هذا التقييم، لذا قم بمقارنة الحالات المحددة بدلاً من مجرد قائمة بأسماء الحقول الفريدة. RFC 6376 الأقسام 3.4 و5.4

قارن الرسائل الأولية دون تغيير الأدلة

استخدم ملفات الرسائل الأولية التي لم تتغير من نقاط الالتقاط المعتمدة. يمكن أن تخفي لقطات الشاشة المعروضة حدود MIME وتغييرات التشفير والرؤوس المطوية. يمكن لإعادة حفظ الرسالة من خلال محرر أن يؤدي في حد ذاته إلى تغيير نهايات الأسطر أو التسلسل، لذا احتفظ بالنسخ الأصلية وقم بإجراء التحليل على النسخ. قم بتسجيل وقت الالتقاط وموضع المسار وتجزئة الملف لربط كل عينة بالخطوة المطالب بها.

لا يثبت التوقيع الفاشل لاحقًا أن التوقيع كان صالحًا قبل البوابة. يحذر RFC 6376 من أن أداة التحقق لا يمكنها بشكل عام استنتاج الصلاحية المسبقة من توقيع غير صالح. ولذلك يتضمن الاختبار المقترح التحقق من المدخلات المحفوظة وكذلك المخرجات، مع الاحتفاظ بالمفتاح ذي الصلة وسياق التحقق. وإلا، فقد يتم إسناد خطأ التوقيع الموجود مسبقًا إلى البوابة بشكل خاطئ. RFC 6376 القسم 4.2

العمل من خلال استبدال عنوان URL خيالي

لنفترض أن توقيع مجال المؤلف الخيالي يتحقق من رسالة الإدخال الأولية ويغطي جسمها بالكامل. تقوم البوابة بعد ذلك باستبدال عنوان URL في جزء HTML MIME بعنوان URL للحماية من التهديدات. يحتوي الإخراج المقابل على بايتات نص أساسية مختلفة، وتبلغ محاولة التحقق عن عدم تطابق تجزئة النص. تشكل هذه الافتراضات نتيجة اختبار توضيحية؛ لم يتم إجراء مثل هذا الاختبار هنا.

تدعم هذه المقارنة الاستنتاج الضيق بأن الاستبدال الملحوظ أثر على الجسم المغطى لهذا التوقيع. وهذا لا يعني أن كل إجراء بوابة يكسر كل توقيع أو أنه يجب إيقاف تشغيل الحماية. يمكن للتوقيع الإضافي من gateway.example مصادقة معالجة هذا المجال للرسالة المعدلة، لكنه لا يعيد بناء توقيع المؤلف الأصلي أو يتماشى تلقائيًا مع مجال مؤلف غير ذي صلة. RFC 6376 الأقسام 3.4 و5.1 RFC 9989 القسم 5.3

حافظ على تميز نتائج الدخول والتحقق من المصب

قد تعتمد المؤسسة على المصادقة التي يتم إجراؤها عند مدخلها الموثوق به قبل تحويلات السلامة الداخلية. الحفاظ على هوية المقيم وحدود الثقة وراء تلك النتيجة. قد يحصل جهاز الاستقبال المتلقي للمعلومات الذي يقوم بتقييم البايتات المعدلة بشكل صحيح على نتيجة DKIM مختلفة. نسخ ان Authentication-Results الحقل إلى رسالة لا يجعل هذا المجال في حد ذاته جديرًا بالثقة خارج الحدود التي أنتجته. RFC 8601 الأقسام 5 و 7

ARC يمكن إجراء تقييمات مسبقة من خلال المعالجين المشاركين، ولكن التحقق من صحة السلسلة والثقة في هؤلاء المعالجين يظلان سؤالين مختلفين. لا يجعل RFC 8617 ARC آلية لاستعادة توقيع DKIM القديم. فئتها المنشورة تجريبية. يظل الاقتراح الذي تمت مراجعته لنقل ARC إلى التاريخي مسودة نشطة. لا تعد بأن تمكين ARC يجعل كل جهاز استقبال يتلقى البريد يقبل البريد المعدل بواسطة البوابة. RFC 8617 الأقسام 5.2 و9.3 حالة مقترح IETF

ضع التوقيع الشرعي بعد التغييرات المقصودة

بالنسبة للبريد الصادر الذي تم تأليفه ضمن نطاق تتحكم فيه المؤسسة، فإن التصميم المدعوم قد يضع المُوقع المعتمد بعد التغييرات الشرعية النهائية للمحتوى. تأكد من أن الخطوات اللاحقة لا تؤدي إلى تعديل المحتوى المغطى مرة أخرى. لا يمكن للبوابة التوقيع بشكل قانوني كمجال مؤلف خارجي لمجرد أنها تنقل رسالة ذلك المؤلف؛ يجب أن يكون ترخيص المجال ذي الصلة وحضانة المفاتيح موجودين. RFC 6376 القسم 5.1

يجب أن توضح حزمة المراجعة عنصر التحكم الذي يظل نشطًا، وأمر المعالجة المقترح، وكيف سيتم تكرار التحقق قبل وبعد. لا تستخدم تغطية منخفضة للجسم أو تجاوزات المصادقة الشاملة فقط لإنتاج مؤشر أخضر. إن الاختبار المعتمد الناجح سيدعم فقط المسارات التي تم أخذ عينات منها ونماذج الرسائل. لا تزال الأزواج الأولية الأصلية والموضع الفعلي للموقع ونتائج التحقق الخاضعة للرقابة غائبة عن هذه المسودة.