تحديد ما هو المسؤول عن إعادة الإرسال
تتلقى خدمة إعادة البريد المعتمدة رسالة وترسل معاملة SMTP أخرى فصاعدًا. يغطي هذا الوصف خدمات مختلفة: معيد توجيه العناوين، أو قائمة المناقشة، أو بوابة الأمان، أو أحد التطبيقات التي تعيد توزيع البريد. "المصادقة" غير مكتملة ما لم تذكر الهوية والآلية وقفزة الاستقبال. يمكن للخدمة مصادقة الاتصال الصادر الخاص بها دون الحفاظ على مصادقة المؤلف الأصلي. ولذلك يجب أن تتبع حدود المسؤولية الرسالة عبر المسار، بدلاً من اتباع ملصق المنتج.
ابدأ بعقد خدمة مكتوب لتدفق البريد. حدد من يقبل الرسالة الأصلية، ويغير المغلف، ويعدل المحتوى الموقع، ويتعامل مع حالات فشل التسليم ويقدم الأدلة إلى المستلم النهائي. إن خريطة المسؤولية المقترحة أدناه هي أداة مساعدة للتخطيط، وليست مراقبة لخدمة منتشرة. يجب أن يكون كل مشغل قادرًا على شرح التغييرات الخاصة به دون المطالبة بالتحكم في قرار التصفية الخاص بمشغل آخر.
افصل بين أسئلة الهوية الثلاثة
ربط IP و SMTP مرسل المغلف يهم ل SPF. مجال التوقيع ومواد الرسالة المحمية يهم DKIM. DMARC يسألك عما إذا كان المعرف المعتمد المؤهل يتوافق مع مجال المؤلف من الحقل من الرسالة. لا تعد نتيجة نظام التعرف على هوية المرسل SPF الناجحة لمرسل البريد الإلكتروني لنطاق المغلف الخاص به تلقائيًا نتيجة محاذية لمؤلف أصلي غير ذي صلة. هذه أسئلة منفصلة حتى عندما تعرض واجهة المستخدم علامة "مصادق عليها" مطمئنة. RFC 7208 ، القسم 2.4 و RFC 9989 ، القسم 4.4 تحديد الحدود ذات الصلة.
يمكن أن تؤدي إعادة كتابة المغلف إلى جعل معيد التوجيه مسؤولاً عن مسار إرجاع جديد والسماح لنظام التعرف على هوية SPF بوصف بنيته الأساسية الصادرة. لا يقوم في حد ذاته بإصلاح المؤلف الأصلي تنسيق. وكذلك طازجة توقيع DKIM من مُعيد الإرسال يثبت شيئًا ما حول مجال التوقيع هذا، وليس بالضرورة المؤلف الأصلي. قم بتسجيل الهويات القديمة والجديدة حتى يتمكن المحلل اللاحق من معرفة العلاقة التي تم الحفاظ عليها أو استبدالها أو فقدانها.
التعديلات الخاصة التي يمكن أن تكسر التوقيع
تحتاج الخدمة التي تقوم بإلحاق تذييل أو تغيير حقل موضوع موقّع أو إعادة ترميز المحتوى المحمي إلى فهم توقيع DKIM ذي الصلة و تحديد العنوان القانوني. تنجو بعض التحولات من التحديد الأساسي المحدد؛ البعض الآخر لا. لا تفترض أن كل تغيير في الرأس يعطل DKIM ، أو أن التحديد الأساسي "المريح" يسمح بتحريرات عشوائية. احتفظ بنسخة أصلية وقارن بين الرؤوس والنص الفعلي الموقع عند تشخيص الفشل. RFC 6376 ، القسمان 3.4 و5.4 توفير الآلية، وليس وعدا بشأن إعادة الإرسال معين.
توصي إرشادات إعادة التوجيه من Google بحماية المحتوى المغطى بـ DKIM وتنص على أن يقوم Gmail بتقييم الرسائل المُعاد توجيهها بنفسه. هذه نصيحة تشغيلية خاصة بـ Gmail، وليست اتفاقية قبول عالمية. يظل مُعيد الإرسال مسؤولاً عن التغييرات التي يجريها، بما في ذلك إعادة الكتابة المتعمدة المستخدمة في بعض تصميمات القائمة. تؤدي عملية إعادة الكتابة هذه إلى تغيير الهوية المقدمة للمستلمين وتحتاج إلى قرار واضح بشأن المنتج بشأن الردود والإسناد. جوجل توجيه التوجيه.
تعامل مع ARC كدليل بحدود الثقة
ARC يمكن أن يحمل تقييم مصادقة الوسيط وسلسلة معالجة يمكن التحقق منها. التحقق من صحته لا يؤكد المحتوى الحميد أو يثبت أن كل مجال ختم جدير بالثقة. يجب على المتلقي النهائي أن يقرر كيفية استخدام تلك المعلومات، إن وجدت. الحفاظ على السلسلة ومجالات الختم وتقييم المتلقي والتصرف المحلي بشكل منفصل. لا يعد تمرير ARC إدخالاً بديلاً لتمرير DKIM الذي تمت محاذاته. RFC 8617 ، الأقسام 7 و 9.
تحتاج حالة المعايير أيضًا إلى تاريخ. في 8 نوفمبر 2026، يظل RFC 8617 تجريبيًا. تقترح draft-ietf-dmarc-arc-to-historic-01 إنهاء التجربة ونقل RFC إلى Historic؛ إنه عمل مستمر، وليس إعادة تصنيف. يجب أن يكشف تقييم الخدمة عن هذا الاقتراح دون تقديم نشر ARC الشامل أو التقاعد الكامل كحقيقة. حالة المسودة الحالية.
اتبع رسالة خيالية من خلال الحدود
لنأخذ على سبيل المثال رسالة خيالية من notices@sender.example ، يتم توجيهها عبر معيد توجيه الخريجين إلى صندوق بريد نهائي. افترض أن الدفق الأصلي يحتوي على توقيع DKIM محاذٍ. يقوم معيد التوجيه بتغيير مرسل المغلف إلى المجال الخاص به ولكنه يترك الرسالة المحمية دون تغيير. السؤال المتوقع لدى المتلقي النهائي هو ما إذا كان هذا التوقيع الأصلي لا يزال يتم التحقق منه ومحاذاته. تجيب نتيجة SPF للمغلف الجديد على سؤال هوية مختلف. هذا المثال هو تمرين تفكيري؛ لم يتم جمع أي رسالة أو استجابة DNS أو نتيجة جهاز الاستقبال.
لنفترض الآن أن نفس الخدمة تضيف إخلاء المسؤولية عن النص. يجب على المحلل مقارنة المحتوى المغطى بالتوقيع قبل تلك الخطوة وبعدها. التوقيع الخاص بالخدمة أو ختم ARC قد تقدم أدلة إضافية، ولكن لا ينبغي وصف أي منها بصمت بأنها استعادة للتوقيع الأصلي. ينتمي العمل التصحيحي أولاً إلى الممثل الذي قدم التحويل ذي الصلة، في حين لا يزال المرسل الأصلي يمتلك تكوين التوقيع الخاص به ويمتلك المتلقي سياسة القبول الخاصة به.
قبول المسؤولية دون الوعد بالتسليم
يتم نقل مسؤولية SMTP عندما يعطي الخادم المتلقي استجابة إكمال إيجابية بعد بيانات الرسالة. ثم يمتلك هذا الخادم التسليم أو معالجة الفشل اللاحقة المناسبة. تختلف مسؤولية النقل هذه عن الوعد بوضع البريد الوارد أو المصادقة المستمرة في كل خطوة لاحقة. يجب أن يحتفظ مُعيد الإرسال بمعرفات قائمة الانتظار، والطوابع الزمنية، وسجلات التشخيص المحددة بما يكفي لشرح هذا النقل. RFC 5321 ، القسم 4.2.5.
RFC 9989 يناقش بشكل صريح إمكانية التشغيل البيني للتدفق غير المباشر ويحذر من التعامل مع سياسة المجال باعتبارها مدخلات التصرف الوحيدة للمتلقي. قم بمراجعة المشاركة في القائمة وإعادة التوجيه المشروعة عند التخطيط لسياسة المرسل، بدلاً من مطالبة شركة إعادة الإرسال بضمان سلوك كل مستلم. RFC 9989 ، القسم 7.4.
الأدلة لا تزال مطلوبة
مقارنة عينات التسليم المباشر وغير المباشر مع المسار والمغلف والتوقيعات والنتائج الموثوقة. ويظل هذا المطلب مفتوحا. قم بتجميع العينات المطابقة المعتمدة، ووضع علامة على النتائج المضافة بواسطة المستلم الموثوق به، ومقارنة هويات القفزات وتعديلاتها. لا تحدد أبحاث المعايير الوثائقية والمسار الخيالي سلوك خدمة إعادة البريد الفعلية.