لضمان أمان المستخدمين وخصوصيتهم، تخضع الرسائل الإلكترونية الديناميكية لقيود ومتطلبات أمان إضافية.
مصادقة المُرسِل
للتأكّد من سلامة مُرسِل الرسالة الإلكترونية بتنسيق 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" من النطاق. على سبيل المثال، النطاق foo.bar.example.com
هو 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
، ما يؤدي إلى ظهور رسالة تحذير بشأن وحدة تحكّم المتصفّح.