مشكلة نهاية السطر هي مشكلة على مستوى البايت. إن نسخ رسالة إلى محرر، ورؤية نفس السطور والاستنتاج بأنه لم يتغير شيء هو أمر غير موثوق به DKIM تحقيق. الحفاظ على التمثيل الأصلي وتحديد ما إذا كان التحويل قد حدث قبل التوقيع أو أثناء النقل أو فقط أثناء جمع الأدلة.
إنشاء النموذج المتوقع
يستخدم بريد إنترنت فواصل الأسطر CRLF. RFC 6376 §5.3 يتطلب من الموقّع تحويل اصطلاحات CR أو LF العارية المحلية إلى تسلسل CRLF القياسي SMTP قبل التوقيع. يجب أن ينطبق التحويل على الرسالة المرسلة، وليس فقط على نسخة خاصة تم تمريرها إلى خوارزمية التوقيع. التوقيع على تقرير واحد ونقل آخر يدعو إلى الخلاف عند التحقق.
تحديد العنوان القانوني لديه قواعد أضيق من تطبيع النص العام. تعريف بسيط للجسم يتجاهل الأسطر الفارغة الزائدة ويوفر CRLF النهائي المطلوب. استرخاء الجسم الأساسي يزيل أيضًا المسافات البيضاء في نهاية السطر ويضغط المسافات أو علامات التبويب داخل السطر. ولا يؤدي بشكل عام إلى مسح فواصل الأسطر ذات المعنى أو ضم النص الملتف. يمكن أن تختلف خوارزميات الرأس والنص، لذا اقرأ كلا الجزأين من لغة C بدلاً من افتراض وضع واحد.
حماية الأدلة أولا
اجمع ملفات الرسائل الأولية من الموقع والمتلقي باستخدام الطرق التي تفهم تحويلاتها. احتفظ بالنسخ الأصلية والتجزئة لهذه الملفات للقراءة فقط. في نسخة عمل، قم بفحص أعداد CRLF وLF وCR العارية باستخدام أداة تدرك البايت. عرض عارض النص ليس كافيًا: يقوم العديد من المشاهدين بعرض كل نموذج على شكل فاصل أسطر.
اسأل كيف تم الحصول على العينة. قد يعمل الأرشيف أو خط أنابيب الصدفة أو إعداد التحكم بالمصدر على تطبيع النهايات بعد التسليم. لا يؤدي الاختلاف في الملفات المصدرة إلى تغيير رسالة SMTP نفسها. حيثما أمكن، قارن بين المضبوطات المستقلة على نفس الحدود واحتفظ بإجراءات التصدير مع الأدلة.
استخدم حالة صغيرة يمكن التحكم فيها
مدخل توضيحي : جسم يتكون من ألفا، سي آر إل إف، بيتا، وCRLF النهائي. تتم تسوية إضافة سطر CRLF فارغ فقط في النهاية بواسطة خوارزميات النص القياسية. يؤدي استبدال فاصل الأسطر بين ألفا وبيتا بمسافة إلى تغيير المحتوى وليس نفس العملية. تختلف إضافة مسافات في نهاية سطر ألفا في ظل التحديد البسيط للجسم، ولكن يتم تطبيعها من خلال التحديد الأساسي للجسم المريح.
تشرح هذه الأمثلة القواعد؛ فهي ليست بديلاً للتحقق من التوقيع الكامل. صالحة تجزئة الجسم ما هو إلا جزء واحد من التحقق DKIM . يجب أيضًا أن ينجح اختيار الرأس واسترجاع المفتاح العام وتوقيع التشفير.
البحث عن المرحلة المسؤولة وتصحيحها
إذا تلقى الموقع بيانات محلية LF فقط، فافحص مرحلة التسلسل قبل التوقيع. إذا كان إخراج المُوقع صحيحًا ولكن الالتقاط الأولي اللاحق يختلف، فتحقق من تحويل تلك القفزة أو سلوك إعادة البناء. إذا كان الدليل الذي قمت بتصديره يختلف فقط، فقم بإصلاح طريقة الالتقاط بدلاً من تعديل DNS أو مفاتيح الإنتاج.
قم بإجراء تغيير على نطاق ضيق يضمن أن يستخدم الموقّع والرسالة المرسلة نفس التمثيل المقيس. لا تخترع أداة تحقق مخصصة تقبل تحويلات الأسطر التعسفية لتمرير العينة. لن يقوم هذا المدقق بعد الآن باختبار قواعد DKIM المنشورة.
التحقق من رسالة واحدة
بعد التغيير، أرسل مجموعة صغيرة تغطي نصًا عاديًا وسطورًا زائدة فارغة وHTML والمرفقات. قم بتسجيل التحديد الأساسي المحدد وتجزئة الملف الأولي المجمع ونتيجة التحقق من المتلقي الموثوق به. احتفظ بتمثيل الإخراج المتوقع باعتباره أداة انحدار. يحدد الحل المفيد التحويل المسؤول ويوضح أن الرسائل الجديدة تصل إلى المتلقي بالشكل المقصود.
أبقِ أعداد البايتات منفصلة عن الاستنتاجات
للجسم الاصطناعي ألفا<CRLF>بيتا<CRLF>، يتكون نص شكل الشبكة من 13 ثمانيًا: خمسة أحرف وثمانيتان فاصلتان وأربعة أحرف وثمانيتان فاصلتان نهائيتان. تصدير LF فقط لنفس الخطوط المرئية هو 11 ثماني بتات. يعد هذا الاختلاف في العدد سببًا للتحقيق في التجميع أو التسلسل، وليس دليلاً على تلف البريد المرسل. احتفظ بالملفات الأصلية وطرق التجميع، ثم قارنها بالملفات الموثوقة عند الحدود ذات الصلة. تمثل تسمية CRLF الموجودة بين قوسين وحدات البايت، وليس النص الحرفي.