لضمان سلامة المستخدم وخصوصيته، تخضع الرسائل الإلكترونية الديناميكية لمتطلبات وقيود أمان إضافية.
مصادقة المُرسِل
للتأكّد من صحّة مُرسِل الرسائل الإلكترونية لصفحات AMP، تخضع الرسائل الإلكترونية التي تحتوي على تنسيق AMP لعمليات الفحص التالية:
- يجب أن تجتاز الرسالة الإلكترونية مصادقة البريد المعرَّف بمفاتيح النطاق (DKIM).
- يجب أن يتوافق نطاق التوقيع الذي تمت مصادقته عبر DKIM مع نطاق الرسالة الإلكترونية في الحقل
From. راجع محاذاة DKIM أدناه. - يجب أن تجتاز الرسالة الإلكترونية مصادقة نظام التعرّف على هوية المُرسِل (SPF).
بالإضافة إلى ذلك، ننصح مرسِلي الرسائل الإلكترونية باستخدام سياسة مصادقة الرسائل وإعداد تقاريرها وتوافقها استنادًا إلى النطاق (DMARC)
مع ضبط التصرف على quarantine أو reject. قد يتم فرض هذا
في المستقبل.
يظهر كل من DKIM وSPF وDMARC كسطور منفصلة ضمن خيار قائمة "عرض الأصل" في Gmail على الويب. راجِع التحقُّق مما إذا تمت مصادقة رسالة Gmail للحصول على مزيد من المعلومات.
محاذاة DKIM
يتم اعتبار مصادقة DKIM "متوافقة"، يجب أن يكون النطاق التنظيمي
لنطاق توقيع واحد على الأقل تمت المصادقة عليه عبر DKIM
هو نفسه
النطاق التنظيمي لعنوان البريد الإلكتروني في رأس From. يعادل ذلك عملية محاذاة معرّف DKIM بسهولة كما هو موضَّح في مواصفات DMARC، الفقرة 3.1.1 من RFC7489.
يتم تعريف النطاق التنظيمي في الفقرة 3.2 من RFC7489
ويُشار إليه أيضًا باسم جزء "eTLD+1" من النطاق. على سبيل المثال، يتم تحديد example.com للنطاق foo.bar.example.com
باعتباره النطاق التنظيمي الخاص به.
يشير نطاق التوقيع الذي تمت المصادقة عليه من خلال DKIM إلى قيمة علامة d= لتوقيع DKIM.
على سبيل المثال، إذا تم بنجاح التأكد من صحة توقيع DKIM الذي تم التحقق منه مع
d=foo.example.com، سيتم اعتبار أنّ الترميزَين bar@foo.example.com وfoo@example.com
وfoo@bar.example.com متوافقان إذا كانا متوفّرَين في العنوان From، بينما لا يتطابق "user@gmail.com" لأنّ السمة gmail.com لا تتطابق مع
"example.com".
تشفير TLS
لضمان تشفير محتوى رسائل البريد الإلكتروني بتنسيق AMP أثناء نقلها، يجب تشفير بروتوكول أمان طبقة النقل (TLS) مع الرسائل الإلكترونية التي تحتوي على تنسيق AMP.
يشير الرمز في Gmail إلى ما إذا كانت رسالة إلكترونية قد تم إرسالها باستخدام تشفير TLS. يمكنك مراجعة التحقّق مما إذا كانت الرسالة التي استلمتها مشفَّرة للحصول على مزيد من المعلومات.
وكيل HTTP
يتم إنشاء خادم وكيل لجميع طلبات XMLHttpRequest (XHR) التي تنشأ من رسالة إلكترونية بتنسيق AMP. ويتم ذلك لحماية خصوصية المستخدم.
رؤوس CORS
إنّ كل نقاط نهاية الخادم التي يستخدمها amp-list وamp-form يجب أن تنفّذ
CORS في AMP للبريد الإلكتروني
وضبط عنوان HTTP الذي يتضمّن AMP-Email-Allow-Sender بشكل صحيح.
القيود
يوضِّح ما يلي القيود الإضافية على عناوين URL.
عمليات إعادة التوجيه
يجب ألا تستخدم عناوين URL XHR إعادة التوجيه HTTP. يتعذّر تنفيذ الطلبات التي تعرض رمز حالة من فئة إعادة التوجيه (نطاق 3XX) مثل 302 Found أو 308 Permanent Redirect، ما يؤدي إلى ظهور رسالة تحذير في وحدة تحكّم المتصفّح.