لا يتمتع أي مطور ، الذي واجه إنشاء رسائل بريد إلكتروني لأول مرة ، بفرصة تقريبًا لكتابة تطبيق ، سيقوم بذلك بشكل صحيح. ينتهك حوالي 40٪ من رسائل البريد الإلكتروني ، التي يتم إنشاؤها بواسطة تطبيقات الشركات ، شكلاً من أشكال المعيار ، ولهذا السبب ، هناك مشاكل في التسليم والعرض. هناك أسباب لذلك: رسائل البريد الإلكتروني أكثر صعوبة من الناحية الفنية على شبكة الإنترنت ، ويتم تنظيم رسائل البريد الإلكتروني العاملة من خلال بضع مئات من المعايير ، بالإضافة إلى عدد لا يحصى من الممارسات المقبولة عمومًا (وليس بنفس القدر) ، في حين أن عملاء البريد الإلكتروني أكثر تنوعًا ولا يمكن التنبؤ بها من المتصفحات. قد يؤدي الاختبار إلى تحسين الموقف إلى حد كبير ، ولكن المواد المخصصة لاختبار نظام البريد الإلكتروني ، غير موجودة من الناحية العملية.
Mail.ru يتفاعل بانتظام مع مستخدميها عن طريق البريد الإلكتروني. في مشاريعنا ، تخضع جميع المكونات المسؤولة عن إنشاء رسائل البريد الإلكتروني وحتى المراسلات الفردية للاختبار الإلزامي. في هذه المقالة ، سوف نشارك تجربتنا (التعلم من أخطائنا).
أي نوع من رسائل البريد الإلكتروني هناك؟
يمكن للتطبيق إنشاء أنواع مختلفة من رسائل البريد الإلكتروني. يمكن تصنيفها إلى عدة فئات. من خلال طريقة اختيار المتلقين - الشخصية / أثار - مجموعة انتقائية. عن طريق التعيين: المعاملات - التسويق - الخدمة. يمكنك تعيين متطلبات مختلفة لأنواع مختلفة من البريد الإلكتروني وتطبيق سيناريوهات اختبار مختلفة.
يتم إنشاء رسائل البريد الإلكتروني التي يتم تشغيلها استجابةً لأية أحداث ، على سبيل المثال ، إجراءات المستخدم أو تغييرات حالة كائنات النظام. يتم إنشاؤها بواسطة التطبيق ، وبالتالي فهي الأكثر إثارة للاهتمام فيما يتعلق الاختبار. يمكن أن تكون رسائل البريد الإلكتروني التي يتم تشغيلها معاملات وتسويق واستخدام الخدمة. يتم إرسال رسائل البريد الإلكتروني الانتقائية إلى مجموعة ديناميكية من المستخدمين ، والتي تلبي بعض أشكال المعايير. يتم إرسال رسائل البريد الإلكتروني الجماعية إلى مجموعة دائمة من المستلمين ، على سبيل المثال ، جميع المستخدمين أو الشركاء. غالبًا ما تكون رسائل البريد الإلكتروني الانتقائية والمجموعات للاستخدام التسويقي ، ويتم إرسال رسائل البريد الإلكتروني هذه يدويًا أو وفقًا لجدول زمني.
يتم إنشاء رسائل البريد الإلكتروني للمعاملات في عملية قيام المستخدم باستكمال شكل من أشكال العمل. تتضمن رسائل البريد الإلكتروني هذه ، على سبيل المثال ، الفواتير أو التذاكر أو إعلامات حالة التسليم. يتم دائمًا تشغيل رسائل البريد الإلكتروني الخاصة بالمعاملات وتهدف إلى حمل معلومات مهمة. يجب أن تكون بسيطة ومتوافقة قدر الإمكان ، ويجب أن يتم اختبارها على عدد كبير من عملاء البريد.
تشجع رسائل البريد الإلكتروني التسويقية المستخدم على اتخاذ إجراء ، على سبيل المثال ، يمكن أن يكون هذا عرضًا لخصم شخصي استنادًا إلى عمليات الشراء السابقة. يمكن استخدام بيانات المعاملات في رسائل البريد الإلكتروني هذه ، ويمكن إطلاقها أو إرسال رسائل جماعية أو دورية أو مرة واحدة. بالنسبة إلى رسائل البريد الإلكتروني هذه ، تكون الكفاءة أكثر أهمية ، وعادة ما تحدد نتائج اختبار الانقسام. يمكن التضحية ببعض جوانب التوافق من أجل الكفاءة.
غالبًا ما يتم إرسال رسائل البريد الإلكتروني التسويقية الجماعية ، على سبيل المثال ، الرسائل المتعلقة بالعروض الموسمية ، والعروض الترويجية ، والمبيعات ، "يدويًا" ، وليست جزءًا من التطبيق الخاص بك ، لكن يمكنك (ويجب عليك) أيضًا تطبيق مبادئ الاختبار العامة عليها.
أيضًا ، قد تكون هناك رسائل بريد إلكتروني للخدمة: الإشعارات التي يتم إنشاؤها للموظفين أو لأنظمة CRM التلقائية أو عمل اليومية أو التدقيق أو DWH. عادةً ما يتم تشغيل رسائل البريد الإلكتروني هذه ، مما يعني أنها جزءًا من التطبيق ، ويجب اختبارها.
من يشارك في عملية الاختبار والتحكم؟
- مهندس ضمان الجودة - يشارك في جميع مراحل العملية.
- مهندس شبكة - مسؤول عن تكوين البنية التحتية للشبكة والبنية التحتية لتسليم الرسائل. يجب أن يشارك مهندس الشبكة في التخطيط واختبار البنية التحتية.
- أخصائي التسليم - هو الشخص الذي يراقب تسليم رسائل البريد الإلكتروني ، والذي يشارك أيضًا في مراقبة المعايير الفنية والإدارية لجميع رسائل البريد الإلكتروني المرسلة ، ويرصد التقدم المحرز في عملية البريد. إنه مسؤول عن ضمان وصول رسائل البريد الإلكتروني المرسلة إلى أعلى نسبة مئوية من المستخدمين ، ولا ينتهي الأمر بالرسائل غير المرغوب فيها. لهذا الغرض ، يجب أن يكون لدى المتخصص معرفة واتصالات محددة. إذا كانت هناك أي مشاكل في تسليم رسائل البريد الإلكتروني ، فهو الشخص الذي يجب عليه فهم السبب المحتمل والقضاء عليه ؛ إما عن طريق إزالة العقبات التقنية ؛ أو تغيير شيء ما في محتوى رسائل البريد الإلكتروني ؛ أو حاول حل المشكلة مع خدمة دعم مزود البريد ، والتي لا تصل إليها رسائل البريد الإلكتروني. يجب أن يشارك هذا الاختصاصي (إن وجد) في وضع قائمة مرجعية واختبار التطبيقات والبريد الإلكتروني لتوليد البنية التحتية. ومع ذلك ، يجب أن تكون عملية الاختبار نفسها تحت سيطرة خدمة ضمان الجودة.
- البريد الإلكتروني المسوق - يحدد فعالية النشرات الإخبارية التسويقية. تحت سيطرته ، يحدث اختبار تقسيم لتوزيع التسويق على الجمهور. يتحكم مسوق البريد الإلكتروني أيضًا في تجزئة قاعدة المستخدمين ، وتكوين وتكرار رسائل البريد الإلكتروني المرسلة ، و "العرض" المرئي للبريد الإلكتروني للمستخدم.
كل هذه الأدوار لا يؤديها بالضرورة موظف متخصص ؛ يمكن تنفيذ دور المسوق بواسطة أحد مديري المنتجات ، ويمكن أن يؤدي دور أخصائي التسليم ، على سبيل المثال ، من قبل موظف دعم أو مهندس شبكة. في الشركات المبتدئة ، من المحتمل جدًا أن يتعامل كل هذا مع شخص واحد ، وقد يتحول الأمر إلى أخصائي جودة.
البريد ونقل البريد
يشبه هيكل البريد الإلكتروني جبل جليدي هائل ، وهناك مستويان فيه. هناك أكثر من مائة معيار مختلف تحكم رسائل البريد الإلكتروني ، ولكن معظمها ينتمي إلى أحد هذين المستويين:
الجزء تحت الماء من خدمة الشبكة
الجليدية ، وبروتوكوله الأساسي هو بروتوكول تطبيق SMTP المحدد بواسطة RFC 5321. وهو مسؤول عن تسليم رسائل البريد الإلكتروني. يتم تشكيل مغلف SMTP يسمى لتسليم البريد الإلكتروني ، والذي يتضمن عناوين المرسل والمستلم لمستوى SMTP. خدمات الشبكة الأخرى ، مثل DNS ، مسؤولة أيضًا عن تسليم البريد الإلكتروني. المكون الرئيسي للبنية التحتية للشبكة هو وكيل نقل البريد (MTA). MTA هي المسؤولة عن تسليم قائمة انتظار تسليم الرسائل وعملية التسليم نفسها إلى خوادم المستلم. تتضمن أمثلة MTA خدمة Postfix و Sendmail و Exim و Microsoft SMTP.
هذا الجزء تحت الماء من جبل الجليد ، والذي يتضمن MTA ، معلمات DNS ، ومعلمات الشبكة الأخرى ، سوف نسمي البنية التحتية للبريد الإلكتروني أو البنية التحتية لتوصيل الرسائل.
غيض من فيض - البريد الإلكتروني نفسه. يتم تعريف البنية الأساسية للبريد الإلكتروني من خلال معيار RFC 5322. يتكون البريد الإلكتروني من رؤوس الخدمات وواحد أو أكثر من أجزاء البيانات. قد تكون البيانات بتنسيق نص عادي و / أو HTML أو حتى AMP ، مع صور مضمنة أو مرفقات من أي نوع تقريبًا.
واجهة البنية التحتية للبريد الإلكتروني وحدود التطبيق الذي تم اختباره
تحتوي البنية الأساسية للبريد الإلكتروني ، كقاعدة عامة ، على واجهة واحدة أو عدة واجهات يتم من خلالها إرسال بريد إلكتروني (عند إدخال قائمة انتظار التسليم MTA). على سبيل المثال ، خدمة إرسال SMTP ، أو وظيفة
mail() في PHP ، أو نقل البيانات إلى تطبيق البريد الإلكتروني أو البريد الإلكتروني الخارجي ، أو واجهة برمجة التطبيقات للخدمة الداخلية أو الخارجية (مثل GetResponse ، أو SendPulse ، أو Amazon SES). سننظر في هذه الواجهات كجزء من البنية التحتية. غالبًا ما يحدث أن يقوم التطبيق "أ" بإعداد البيانات للبريد الإلكتروني وقائمة المستلمين ، ثم يرسله إلى التطبيق "ب" من خلال واجهة برمجة التطبيقات الخاصة به (للبريد الجماعي للتسويق ، ويمكن القيام بذلك يدويًا عبر واجهة المستخدم- واجهة المستخدم) ، ويقوم التطبيق "ب" بإنشاء رسالة بريد في RFC 5322 ، وتسليمها إلى MTA. بالنسبة للتطبيق A (وعند اختباره) ، سيكون التطبيق B جزءًا من البنية التحتية للبريد الإلكتروني. ستكون واجهة برمجة التطبيقات أو واجهة المستخدم الخاصة بالتطبيق B للتطبيق واجهة للبنية الأساسية للبريد. على الرغم من أن التطبيق B ، سيكون الوضع مختلفًا ، والبنية التحتية للبريد ستكون تطبيقات أو بروتوكولات شبكة ذات المستوى الأدنى.
تعريف معلمات الاختبار
عند اختبار كل تطبيق ، من المهم اختيار جميع البنى التحتية للبريد المستخدمة من قبله (قد يكون هناك العديد منها) ، ولكل بنية أساسية أن تفرد الواجهات المستخدمة (قد يكون هناك أيضًا العديد منها لكل بنية تحتية). لكل واجهة ، يتم تحديد تكوين وتنسيق البيانات المرسلة إليها بأكبر قدر ممكن من الدقة ، على سبيل المثال نص البريد الإلكتروني في TEXT / HTML ، نص البريد الإلكتروني في TEXT / PLAIN ، موضوع البريد الإلكتروني ، اسم المستلم ، عنوان المستلم ، اسم المرسل ، عنوان المرسل (RFC5321.From) ، عنوان مرسل مرسل SMTP (RFC5322.mailfrom). بعد ذلك ، تم تطوير مجموعة من المتطلبات لكل معلمة (تمثيلات ، ترميزات ، قيم حدود ، إلخ.) ، يتم تحديد طرق لمراقبة كل معلمة (كيفية مقارنة النتيجة الفعلية بالقيمة المتوقعة).
هيكل نموذجي لتوليد التطبيق
كقاعدة عامة ، فإن نفس المنتج الذي نختبره هو المسؤول عن إنشاء رسائل البريد الإلكتروني والبيانات الموجودة فيه. هذا عادة ما يكون تطبيق خادم (ولكن في بعض الأحيان عميل). إنه يحدد بنية البريد الإلكتروني ، وجزءًا من رؤوس الخدمات ، وتنسيقات تغليف البيانات ، وتمثيلات السلسلة ، وترميز النص. مثال بسيط لهذا التطبيق هو البرنامج النصي الذي يشكل البريد الإلكتروني ويستدعي وظيفة
mail() . العناصر الرئيسية للتطبيق التي يجب التحكم فيها هي:
- الرمز المسؤول عن إنشاء الرؤوس و / أو بنية البريد الإلكتروني ، إذا تم إنشاء بنية البريد الإلكتروني ديناميكيًا ، و / أو قوالب البريد الإلكتروني الثابتة التي تصف هيكلها ؛
- تخطيط HTML للبريد الإلكتروني (من الناحية المثالية ، إنه كيان منفصل أو جزء من قالب / تخطيط البريد الإلكتروني ، ولكن يمكن تضمينه في رمز التطبيق) ؛
- استبدال بيانات التطبيق في بريد إلكتروني (أو في قالب بريد إلكتروني) ؛
- دمج التطبيق مع البنية التحتية لتسليم البريد الإلكتروني ، وصحة المعلمات مرت إلى واجهة البنية التحتية.
ماذا ومتى لاختبار
سواء أحببنا ذلك أم لا ، يجب اختبار جبل الجليد بأكمله. هناك العديد من المكونات الرئيسية التي تتطلب الاختبار:
البنية التحتية للتوصيل
يجب أن يتم التركيز في الاختبار على: تسليم البريد الإلكتروني ؛ سجلات DNS الصحيحة ، بما في ذلك سجلات PTR / FCrDNS و MX و A ؛ معلمات بروتوكول SMTP (HELO ، استخدم TLS) ؛ إذن البريد الإلكتروني (SPF / DKIM / DMARC) ؛ عناوين مغلف SMTP (إذا كان التطبيق لا يديرها) ؛ صحة معالجة معلمات الإدخال لواجهة البنية التحتية ؛ تتبع وتسجيل ومعالجة رسائل البريد الإلكتروني غير المسلمة.
من الضروري اختبار البنية التحتية أثناء التنفيذ الأولي وفي كل مرة يتم إجراء تغييرات على البنية التحتية نفسها (تكوين MTA أو DNS أو تغييرات الشبكة) أو الواجهة لإرسال بريد إلكتروني ؛ باستخدام مجال أو شبكة أو API جديد ؛ يلزم إجراء اختبار إضافي إذا تم تغيير خصائص رسائل البريد الإلكتروني المرسلة ، مثل لغتها أو حجمها أو أرقامها بشكل كبير. وفقًا للتجربة ، تميل البنية التحتية إلى التغيير "بمفردها" ، لذلك يجب إجراء الاختبارات الأساسية بشكل دوري ، حتى إذا لم تكن هناك معلومات حول أي تغييرات.
من الممكن والضروري إشراك مهندس الشبكة ومتخصص التوصيل في وضع الخطة وقوائم المراجعة لاختبار البنية التحتية.
توليد التطبيق
يجب مراقبة عناوين مظروف SMTP (إذا كان التطبيق يسيطر عليها ، أي يتم نقلها إلى الواجهة - مظروف - من - مظروف - إلى) ، وقيم رؤوس خدمة البريد الإلكتروني (التاريخ والرسالة معرف ، إلغاء الاشتراك ، تقديم تلقائي ، وما إلى ذلك). بند) ، تفويض البريد الإلكتروني (DKIM / DMARC) ، تشفير MIME (base64 ، اقتباس قابل للطباعة) ، صحة عامة لتنسيق البريد الإلكتروني ، على سبيل المثال ، عدم وجود أحرف غير ASCII في الرؤوس ، تركيبة البيانات التي يتم حقنها ، والتشغيل الصحيح للمشغلات ، وآليات إلغاء الاشتراك ، وتتبع آليات كتابة وجمع الإحصاءات (رؤوس Postmaster ، على سبيل المثال ، Feedback-ID أو X-Mailru-Msgtype ، وكذلك تتبع البكسل).
من الضروري اختبار أحد التطبيقات أثناء تطويره ، عندما تكون جميع مكوناته ذات الصلة المسؤولة عن إنشاء وتخزين تغيير البيانات ، مع تغييرات كبيرة في قوالب البريد الإلكتروني ، عند تغيير البنية التحتية أو الواجهة المستخدمة له ، وكذلك في إطار الانحدارات العامة.
قوالب البريد الإلكتروني الإنشائية والتنضيدية (يمكن أن تكون جزءًا من تطبيق توليد أو يتم تطويرها بشكل منفصل)
يتم فحص بنية البريد الإلكتروني (نوع المحتوى ، والتخلص من المحتوى ، وتداخل أجزاء متعددة الأجزاء من البريد الإلكتروني ، وترميز النص ، ومعلمات السلسلة) ، وقيمة الهدف والرؤوس المعروضة (من ، إلى ، رد على ، موضوع ) ، طريقة عرض البريد الإلكتروني في قائمة رسائل البريد الإلكتروني وعند القراءة في واجهات مختلفة ، تنسيقات microformat (على سبيل المثال ، يتم التعرف على حدث التقويم كحدث تقويم أو تذكرة طيران كتذكرة جوية) ، والعلامة التجارية.
يجب اختبار قوالب البريد الإلكتروني في كل مرة تقوم فيها بإجراء أقل التغييرات على الأقل ، وكذلك بشكل منفصل ، على سبيل المثال ، في المواقف التي تصل فيها رسائل البريد الإلكتروني إلى التطبيق قبل أن يصبح جزء الخادم جاهزًا.
يوصى بإشراك أخصائي تسويق عبر البريد الإلكتروني ومتخصص في إمكانية التسليم لتجميع قائمة مرجعية لاختبار قالب بريد إلكتروني.
المتطلبات الأساسية لفحص البنية التحتية
يجب أن يكون عنوان IP المحدد لخادم البريد أقرب ما يكون إلى عنوان IP لخادم البريد. يوصى بالتحقق من ذلك باستخدام أداة whois. على وجه الخصوص ، يجب ألا ينتمي عنوان المرسل إلى الشبكة ، والتي يمكن اعتبارها ديناميكية ؛ يجب أن يكون للشبكة المحددة جهات اتصال نشطة يمكن إرسال الشكاوى إليها ؛ يجب استخدام الشبكة (يكون لها الحالة المعينة في RIPE) يجب أن يكون لعنوان IP سجل PTR مهيأ بشكل صحيح. يمكن تهيئته بشكل مستقل من خلال لوحة تحكم الاستضافة ، أو بمساعدة مزود الخدمة. يجب أن يشير سجل PTR إلى اسم مضيف حقيقي وأن يظل ذا معنى ، ويعود إلى عنوان IP نفسه (ما يسمى بفحص FCrDNS) ، ولا يذكر اسم المضيف الحيوي ، ولا يتضمن مجموعة كبيرة من الأرقام أو الأحرف. مثال جيد هو mailserver.example.com.
يجب أن يكون لدى كل مجال يستخدم في عناوين المغلف أو عناوين البريد الإلكتروني سجل MX صالح يشير إلى مضيف A ، والذي ، كحد أدنى ، يمكنه التعامل مع الرسائل غير القابلة للتسليم. لا يُسمح لـ MX بالإشارة مباشرةً إلى عنوان IP.
السيطرة على مرور SPF ، DKIM ، DMARC. يسمح SPF لمالك النطاق بتحديد سجلات الخوادم في TXT قائمة بالخوادم المسموح لها بإرسال رسائل البريد الإلكتروني مع عناوين الإرجاع في هذا المجال. تم تكوينه للعنوان المستخدم في المغلف - من (مغلف SMTP) في قسم إدارة مناطق DNS في المجال. يوفر DKIM التحقق من تأليف رسالة أو منشئها إلى مجال معين باستخدام تقنيات التوقيع الرقمي ، والتي تتم إضافتها إلى البريد الإلكتروني نفسه (في رأسها DKIM- التوقيع). عادة ، يتم تكوين توقيع DKIM على مستوى MTA (البنية التحتية). يحدد DMARC سياسة فحص البريد الوارد في مجال محدد والإجراءات على رسائل البريد الإلكتروني التي لا تتجاوز مصادقة SPF أو DKIM. عند محاولة انتهاك هذه السياسة ، يأتي تقرير منظم مع معلومات حول هذه المحاولة. يتم نشر DMARC ، وكذلك SPF ، كسجل TXT في منطقة المجال.
تحقق من تسليم رسائل البريد الإلكتروني إلى الخدمات البريدية الرئيسية - من أجل روسيا Mail.Ru و Yandex و Gmail و Microsoft (Hotmail / Outlook.com / Office365) ، Rambler ، nic.ru. في رسائل البريد الإلكتروني وصلت ، تحتاج إلى التحقق من صحة HELO. وجود وشيك الشيكات PTR / FCrDNS و SPF و DKIM و DMARC ؛ صحة الرؤوس والبيانات فيها ، وعلى وجه الخصوص ، تزامن الساعة في التواريخ وصحة المناطق الزمنية.
(بريد التسجيل قد قطع المصادقة بسبب استخدام عنوان البريد الإلكتروني)
يتأثر تشكيل بعض المعلمات ، على سبيل المثال ، التخويل ، والتسليم ، والبريد العشوائي بشكل أساسي بجميع المكونات ، ولكن من أجل السيطرة عليها ، هناك عادة أدوات تشغيل منفصلة - تقارير DMARC و FBL ، واجهة برمجة تطبيقات خدمات إدارة البريد ، أدوات تتبع البريد الإلكتروني ، إحصائيات التسليم. يجب أن يأخذ الاختبار في الاعتبار مستوى تنفيذ أدوات المراقبة التشغيلية في الشركة - على سبيل المثال ، في حالة عدم وجود رقابة تشغيلية على تقارير DMARC ، ينبغي اختبار ترخيص رسائل البريد الإلكتروني بانتظام ، بينما في حالة عدم وجود مراقبة تشغيلية للتسليم ، حيث وكيف تذهب رسائل البريد الإلكتروني ، حتى لو لم يكن هناك أي تطور يتعلق بإرسال رسائل البريد الإلكتروني.
لاختبار البنية التحتية ، يمكنك استخدام خدمات متخصصة ، على سبيل المثال ، mail-tester.com ، mxtoolbox.com. يمكن
العثور على متطلبات البنية التحتية التفصيلية
في هذه المقالة .
(مثال على سجل SPF المكسور)
متطلبات المصادقة
عادة ما يكون التحقق من مرور SPF و DKIM و DMARC ممكنًا باستخدام رأس نتائج المصادقة على خادم المستلم.
تحقق من صلاحية سجل SPF لبناء الجملة ، والحد الأقصى لاستعلامات DNS (على سبيل المثال ، باستخدام mxtoolbox.com). عند تشكيل SPF ، ينبغي أن تؤخذ جميع مصادر المراسلات في الاعتبار (لا تنس أنظمة CRM ، وجميع البنى التحتية للتسليم المستخدمة حاليًا ، بما في ذلك تلك التي يتم من خلالها إجراء حملات تسويقية لمرة واحدة). يوصى بتعيين الخوادم المسموح بها للمجال من خلال قائمة الشبكات ('ip4' / 'ip6'). يتم التحقق من SPF لعنوان المرسل من مغلف SMTP. تحقق من أن مجال مغلف SMTP (مغلف من) يطابق المجال من الرأس من. يتم سرد أخطاء SPF الشائعة في هذه المقالة (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).
تحقق من سجل DKIM DNS ، وصحة وتكوين توقيع DKIM. تحقق من أنك تستخدم مفتاح DKIM لا يقل عن 1024 بت. وضع تجزئة الموصى به من توقيع DKIM: استرخاء / استرخاء. تأكد من توقيع جميع الرؤوس المهمة (من ، إلى ، الموضوع ، التاريخ ، معرف الرسالة ، إصدار MIME ، نوع المحتوى) ، وأن رؤوس التتبع (المتلقاة ، التسليم ، العودة ، المسار) غير موقعة ، و DKIM يتم التحقق من صحة لخدمات البريد الأساسية. إعداد إعادة التوجيه إلى إحدى خدمات البريد إلى أخرى ؛ DKIM يجب ألا "تغلب" على رسائل البريد الإلكتروني المعاد توجيهها. تحقق من مطابقة مجال توقيع DKIM لنطاق المرسل من رأس "من".
تحقق من DMARC للحصول على خدمات البريد الإلكتروني الأساسية. تحقق من تقارير DMARC ، وحدد واستكشاف SPF و DKIM لجميع عناوين IP للبنية التحتية الخاصة بك.
تحقق من تسليم الرسائل إلى خوادم خارجية باستخدام التشفير (TLS). يمكنك في بعض الأحيان البحث عن TLS بواسطة الرأس المستلم على خادم المستلم: على سبيل المثال ، تحديد بروتوكول ESMTPS أو وجود معلمات للنموذج (الإصدار = TLS1_2 cipher = ECDHE-RSA-AES128-GCM-SHA256 بت = 128/128) ؛ يشير إلى وجود TLS.
التحقق من تطبيق توليد
متطلبات عنوان البريد الإلكتروني
مغلف عناوين
نبدأ التحقق من إنشاء التطبيق مع العناوين في مغلف SMTP.
عناوين المغلف هي عناوين لمستوى البنية التحتية للبريد الإلكتروني. لا تكون مرئية للمستخدم ، لكنها مهمة للتسليم لأن عنوان المغلف يحدد صندوق البريد الذي يتم إرسال البريد الإلكتروني إليه.
عنوان المستلم في المغلف (
envelope-to ، الملقب
RCPT TO: هو العنوان الذي سيتم تسليم البريد الإلكتروني إليه بالفعل.
- بالنسبة لجميع رسائل البريد الإلكتروني باستثناء التسجيل ، يجب أن يكون العنوان موقَّعًا قانونيًا والتحقق من صحته للبريد وفقًا للمتطلبات الإدارية.
- بالنسبة إلى الرسائل الإخبارية ، يجب أن يكون العنوان "مباشر" ، ويجب أن تكون العناوين التي لا يمكن تسليم البريد الإلكتروني إليها بانتظام غير نشطة ، ويجب عدم إرسال المراسلات إليهم. ولكن قد يلزم أيضًا إرسال بعض فئات رسائل البريد الإلكتروني (على سبيل المثال ، الوصول إلى الاسترداد) إلى عناوين تم تمييزها مسبقًا على أنها غير نشطة.
عنوان المرسل في مغلف SMTP (عادة ما يسمى
envelope-from ،
smtp.mailfrom ،
MAIL FROM: أو
Return-Path ) - سيتم تسليم الرسائل إلى هذا العنوان حول عدم القدرة على تسليم بريد إلكتروني والردود التلقائية. هذا العنوان غير مرئي للمستخدم. يستخدم هذا العنوان أيضًا لترخيص SPF. نحن نتحقق مما يلي:
- العنوان متاح
- ليس عنوان الموظف ولا تتم إعادة توجيهه إليه لاستبعاد الإجابات التلقائية أو الرسائل المتعلقة بعدم إمكانية الوصول ، وما إلى ذلك ؛
- تتم معالجتها بواسطة برنامج نصي يقوم بتمييز عناوين المستخدمين الذين يتعذر الوصول إليهم على أنه غير نشط ؛
- يمكن إنشاء العنوان تلقائيًا ، أي فريد لكل بريد إلكتروني ؛
- يجب ألا يؤدي إرسال بريد إلكتروني إلى هذا العنوان إلى إنشاء أي بريد إلكتروني استجابة ، على سبيل المثال ، رسالة حول تجاوز سعة صندوق البريد.
عناوين رأس البريد الإلكتروني
تكون هذه العناوين مرئية مباشرة للمستخدم أو يتم استخدامها عند الرد على رسالة بريد إلكتروني.
عنوان المرسل (الرأس
From: هو العنوان واسم المرسل المعروض في قائمة رسائل البريد الإلكتروني وعند قراءة بريد إلكتروني. نحن نتحقق مما يلي:
- هذا هو عنوان ودية للقراءة البشرية التي تحدد الشركة.
- لا يحتوي فقط على عنوان بريد إلكتروني ولكن أيضًا اسم المرسل.
- Noreply @ ممكن ، ولكن فقط إذا أردنا التأكيد على أننا لا نتوقع تلقي رد على البريد الإلكتروني ولن تتم قراءته. من الأفضل تكرار هذه الفكرة في نص البريد الإلكتروني.
- في حالة وجود أحرف غير ASCII (على سبيل المثال ، السيريلية) ، يجب ترميز اسم المرسل وفقًا لـ MIME ، يجب ترميز المجال في وجود أحرف غير ASCII في Punycode
- يجب أن تحمل عناوين البريد الإلكتروني من نفس الفئة العنوان نفسه ؛ يجب تجنب استخدام العناوين التي يتم إنشاؤها تلقائيًا. ويرجع ذلك إلى حقيقة أن "من:" يتم استخدامه غالبًا من قبل الأشخاص لفرز رسائل البريد الإلكتروني حسب المجلدات باستخدام المرشحات.
- يجب أن يكون العنوان مختلفًا (يفضل أن يكون ذلك في نطاقات فرعية مختلفة) للمعاملات التسويقية ورسائل البريد الإلكتروني العاجلة (مثل رسائل البريد الإلكتروني من خدمة الدعم). ويرجع ذلك أيضًا إلى حقيقة أنه يمكن للمستخدم تمييز رسائل البريد الإلكتروني التسويقية كرسائل غير مرغوب فيها أو تصفيتها في مجلد غير قابل للقراءة.
- يجب أن يكون العنوان
From: وعنوان مغلف SMTP في نفس المجال أو في نطاقات فرعية لنفس المجال التنظيمي من أجل تمرير SPF داخل DMARC.
- يجب أن يكون العنوان من مجال المنظمة. من غير المقبول استخدام خدمات البريد المجانية ومجالات البريد العام الأخرى في
From: نظرًا لأن هذه الرسائل لن تمر بمصادقة SPF و DKIM ضمن إطار DMARC.
سيتم إرسال الردود "الرد" - "اليدوي" إلى هذا العنوان عندما يجيب المستخدم على رسالة بريد إلكتروني. إنه اختياري. إذا لم يكن موجودًا ، فسيتم استخدام العنوان من "من:" للاستجابة. تحقق من أن "الرد على":
- يمكن أن يتم إنشاؤه تلقائيًا ، أي فريد في البريد الإلكتروني (يسمح لك بمعرفة البريد الإلكتروني الذي جاءت الإجابة عليه).
- لا ينبغي أن يندرج في صندوق بريد الموظف لتجنب الإجابة التلقائية ، ولكن من الأفضل أن يتم "لف" في CRM.
- يمكنه إنشاء إجابة CRM تلقائية قياسية ، لكن لا ينبغي أن يولد أي شيء غير ضروري ، على سبيل المثال ، تجاوز سعة صندوق البريد أو رسائل "في المهنة". عند إنشاء استجابات تلقائية ، يجب اتخاذ تدابير لتجنب التكرار ، فهي مدرجة في RFC 3834.
- يمكن أن يكون من أي مجال لا يتطابق بالضرورة مع "من:" ، لكن هذا يخيف المستخدمين في بعض الأحيان عند الرد.
- قد تكون غائبة ، ثم يؤدي العنوان
From: وظائفه.
- بالإضافة إلى العنوان ، تتم الإشارة إلى اسم المرسل.
العنوان
To:- يجب أن يحتوي على البريد الإلكتروني للمستلم (وإلا فإنه يخيف مستلم الرسالة ويزيد من مكافحة البريد العشوائي).
- من الناحية المثالية ، يجب أن يحتوي على اسم المستلم. ولكن إذا كان الاسم غير معروف أو مشكوك فيه (على سبيل المثال ، لم يتم تأكيد العنوان بعد) ، فمن الأفضل عدم الإشارة إليه (قد يدخل شخص ما عنوان شخص آخر باسم سيء وقد يتعرض المستلم للإساءة).
متطلبات رأس البريد الإلكتروني
يجب أن يتطابق الترميز الفعلي للنص مع ما هو مشار إليه في الرأس. يُنصح باستخدام ترميز واحد في جميع رؤوس وأجزاء البريد الإلكتروني. يوصى باستخدام UTF-8 كواحدة مدعومة على نطاق واسع. يشار إلى الترميز في رؤوس Content-Type وفي علامة جزء HTML.
من: ، معرف الرسالة: والتاريخ: يجب تكوين الرؤوس مباشرةً في البرنامج النصي لإرسال البريد الإلكتروني (وحسب المعايير - جنبًا إلى جنب مع نص البريد الإلكتروني) ودائما بالتنسيق الصحيح. في حالة غيابها أو تشكيلها بشكل غير صحيح ، يمكن لأحد خوادم النقل أن تضيف هذه الرؤوس ، مما يؤدي إلى انتهاك سلامة توقيع DKIM.
يجب أن تكون الأحرف ذات 8 بت في الرؤوس ، بما في ذلك سطر الموضوع (الموضوع) وأسماء الملفات المرفقة (Content-Type و Content-Disposition) ، غائبة ؛ يجب أن يتم تشفير جميع الأحرف غير ASCII ، بما في ذلك السيريلية ، في ونقلت ونقلت أو base64.
(تأكيد التسجيل في الترميز الغريب)
متطلبات هيكل البريد الإلكتروني
بالنسبة إلى جزء HTML من البريد الإلكتروني ، من المستحسن تكوين جزء (نص) بديل. من الضروري أيضًا التحقق من مطابقة وقراءة جزء النص العادي للبريد الإلكتروني (إن وجد) والبنية العامة للبريد الإلكتروني.
وفقًا لـ RFC 5322 ، يجب ألا يتجاوز طول السطر في رسالة بريد إلكتروني 998 حرفًا من 8 بتات. يرجى ملاحظة أنه في UTF-8 ، يمكن أن تشغل الشخصية عدة ثمانيات. فاصل الأسطر في رسالة بريد إلكتروني هو زوج من CRLF (ascii 13 ، ascii 10) ، والذي يأخذ 2 من الثماني. تحتاج إلى التحقق من صحة فاصل السلسلة ، حيث غالبًا ما يتم إرسال رسائل البريد الإلكتروني باستخدام برنامج نصي Unix ، وفي Unix ، فاصل السلسلة هو حرف واحد - وهذا خطأ للبريد الإلكتروني. يجب عليك أيضًا التحقق مما إذا كانت وحدات إنهاء السلسلة تكسر أحرفًا مشفرة UTF-8: لا يمكنك السماح بوجود حرف نهاية سلسلة بين اثنين من الثمانية من نفس الحرف ، على سبيل المثال ، رمز السيريلية. لتجنب مثل هذه الحالات ، من الضروري كسر النص قبل تكوين البريد الإلكتروني أو تشفير النص في base64 ، وعادة ما يكون base64 بطول الخط الثابت.
من الضروري التحقق من العلامات الصحيحة للمرفقات والمضمنة - أي صحة تكوين الرؤوس "Content-Disposition: inline" ، إذا كانت صورة معروضة داخل البريد الإلكتروني ، أو "Content-Disposition: attachment" إذا كان الملف المرفق مخصصًا للتنزيل.
يجب أن تكون بنية البريد الإلكتروني بسيطة قدر الإمكان: على وجه الخصوص ، يجب ألا يكون هناك أكثر من جزء متعدد الأجزاء من كل نوع (مختلط ، بديل ، مرتبط) ، ويتم استخدام متعدد الأجزاء / مختلط فقط إذا كان البريد الإلكتروني يحتوي على مرفقات ملفات ، متعدد الأجزاء / ذات الصلة - إذا كان HTML يأتي مع الصور المضمنة ، متعددة الأجزاء / بديلة - في وجود نص عادي وأجزاء HTML. بشكل عام ، يجب أن تبدو بنية البريد الإلكتروني ، في حالة عدم وجود مرفقات وصور مضمّنة ، كما يلي:
متعددة الأجزاء / بديلة
- نص / عادي
- نص / أتش تي أم أل
ترتيب الأجزاء مهم ، يجب أن يذهب النص / عادي قبل النص / HTML أو متعدد الأجزاء / مرتبط. يعد ذلك ضروريًا حتى يتم عرض جزء HTML افتراضيًا ، وفقط في حالة عدم توفر العرض لسبب ما ، يتم عرض الجزء العادي.
إذا كانت هناك صور مضمّنة في البريد الإلكتروني ، فيجب أن يبدو هيكلها كما يلي:
متعددة الأجزاء / بديلة
- نص / عادي
- متعددة الأجزاء / ذات الصلة
—— نص / html
—— صورة / ... (صورة مضمّنة)
—— صورة / ... (صورة مضمّنة)
يجب أن تحتوي الصور المضمّنة على Content-Disposition: مضمّن وأن يكون داخل الجزء المتعدد الأجزاء / المتصل بصرامة.
في أصعب الحالات ، عندما يكون هناك صور مضمّنة وملفات مرفقة ، يكون للبريد الإلكتروني البنية التالية:
متعددة الأجزاء / مختلطة
- متعدد الأجزاء / البديل
—— نص / عادي
—— متعددة الأجزاء / ذات الصلة
——— نص / html
——— صورة / بابوا نيو غينيا
——— صورة / بابوا نيو غينيا
...
- سلسلة التطبيق / الثمانية (محتوى التصرف: مرفق)
- سلسلة التطبيق / الثمانية (محتوى التصرف: مرفق)
...
يجب إغلاق الأجزاء ذات الصلة بالأجزاء المتعددة والمتعددة الأجزاء / البديلة قبل المرفقات ، وتنتمي المرفقات إلى الجزء الخارجي متعدد الأجزاء / المختلط)
(رسالة التسجيل مع هيكل أجزاء غير صحيحة)
متطلبات URI
يجب أن يحتوي أي URIs (في src ، href ، الأنماط ، إلخ) على البروتوكول واسم المضيف (https://example.com/somepath). تتمثل الأخطاء النموذجية في استخدام الروابط النسبية (/ somepath) وعدم وجود بروتوكول (//example.com/somepath) ، وهو أمر غير مقبول بالنسبة لرسائل البريد الإلكتروني ، لأنه في هذه
file:// قد يكون البروتوكول الافتراضي هو
file:// .
- يجب ترميز أي خدمة أو أحرف غير ASCII (خاصة السيريلية) في URI باستخدام ترميز النسبة المئوية.
- يجب أن يظل الرمز الذي تم إدخاله كنص (أي مرئيًا للمستخدم كعنوان URL وليس كقطعة نصية)
<> بعلامة <> ، وإلا فلن يتمكن المستخدم من النقر عليه. تقوم بعض رسائل الويب بترميز هذه الروابط من تلقاء نفسها ، ولكن هذا ليس سلوكًا قياسيًا. في هذه الحالة ، يجب أن يتطابق عنوان href داخل A مع نص الارتباط ، وإلا فقد يتفاعل مرشح المحتوى مع هذا الارتباط كمحاولة لخداع المستخدم. هذا الأمر يستحق الانتباه بشكل خاص عندما يكون هناك "نقرات" تتعقب انتقالات المستخدم من البريد الإلكتروني.
- من الأفضل قصر النفس على استخدام البروتوكولات
http:// و https:// و mailto:
- مع متطلبات الأمان العالي ، يجب أن تتخلى تمامًا عن استخدام
http:// لصالح https:// .
- لا ينبغي استخدام المنافذ غير القياسية (على سبيل المثال ، example.com : 8080 / somepath) ، لأنها قد لا تكون في متناول المستخدم.
- لا ينبغي أن يؤدي النقر فوق الارتباط الموجود داخل جزء HTML إلى أي تغييرات في حالة التطبيق (الاشتراك ، إلغاء الاشتراك ، إلغاء الطلب ، وما إلى ذلك) دون تأكيد إضافي من قبل المستخدم على الصفحة ، لأن بعض أنظمة فلترة المحتوى يمكنها بشكل مستقل التحقق من أمان هذا الانتقال من خلال طلب صفحة بالرجوع إليها ؛ يمكن لتطبيق البريد أن يعرض معاينة الصفحة من خلال الرابط الموجود بالمرور ، ويمكن للمتصفحات الحديثة تحميل الصفحة قبل أن ينقر المستخدم على الرابط لتقليل وقت التحميل (في تطبيق الويب ، لا ينصح عمومًا بأية إجراءات تعديل على الحصول على طلب ، يجب أن تمر جميع الطلبات المعدلة عبر POST أو PUT).
- على العكس من ذلك ، يجب ألا يتطلب النقر على الرابط في رأس قائمة إلغاء الاشتراك ، أي إجراءات إضافية من المستخدم ، لأن إلغاء الاشتراك بهذا الرابط يتم عادةً عن طريق برنامج البريد الإلكتروني أو البريد الإلكتروني نيابة عن المستخدم. أيضًا ، هناك رأس جديد لإلغاء الاشتراك-قائمة مقدمة من RFC 8058.
- يجب ألا تتوقع من المستخدم قراءة البريد الإلكتروني واتباع الرابط في نفس المتصفح الذي يبدأ فيه الإجراء الذي يؤدي إلى إرسال البريد الإلكتروني (على سبيل المثال ، يسجل حسابًا). يجب أن يعمل الرابط في أي متصفح أو جهاز محمول آخر. على وجه الخصوص ، يمكن للمستخدم فتح الرابط دون الحصول على إذن ، أو التصريح في حساب آخر غير الحساب الذي تم إرسال البريد الإلكتروني إليه.
- لأن طول URI يمكن أن يكون محدودا ؛ يجب ألا تستخدم URIs من نوع "البيانات:" للكائنات الكبيرة. للسبب نفسه ، لا تستخدم URIs طويلة جدًا في الارتباطات التشعبية.
- يجب عدم استخدام اختصارات الارتباط الخارجي ، فهذا يؤثر سلبًا على تسليم رسائل البريد الإلكتروني. من الأفضل أن تشير جميع الروابط إلى نطاقك ، مما يقلل من التأثير السلبي المحتمل لسمعة شخص آخر على تسليم رسائل البريد الإلكتروني.
- لا تضع صورًا خارجية على بعض الخدمات العامة أو الاستضافة المجانية ، ولا تستخدم خدمة استضافة موثوقة أو CDN بأداء وسمعة جيدين.
(صورة غير صالحة ومرساة URI بسبب فقدان بروتوكول المواصفات)
متطلبات تخطيط البريد الإلكتروني
لماذا يكون من الصعب للغاية جعل رسائل البريد الإلكتروني؟
إرسال عملاء بالبريد الإلكتروني بطريقة أو بأخرى محتوى مستخدم عرض داخل واجهاتهم. من المحتمل أن يؤدي ذلك إلى مشاكل أمنية متعددة - البرمجة النصية عبر المواقع (XSS ، البرمجة النصية Crossite) ، خداع الواجهة ، Clobbering DOM ، deanonymization / تسرب المعلومات للمستخدم (على سبيل المثال ، عنوان IP للمستخدم أو ملفات تعريف الارتباط من خلال الطلبات الخارجية) ، إلخ. لذلك ، فإن أي خدمة بريد وتطبيق بريد لديها نوع من الحماية ضد كل فئة من الهجمات. لسوء الحظ ، لا يوجد نهج واحد لتنظيم هذه الحماية. يمكن تنظيمها من خلال:
- إطارات محدودة معزولة ،
- تصفية العلامات و / أو السمات ،
- القيود المفروضة على تحديد المواقع المطلقة ،
- حظر أو تقييد استخدام أنماط الكتل (وهو أمر بالغ الأهمية للتخطيط التكيفي) ،
- حظر العناصر الخارجية افتراضيًا (أي يتطلب تنزيل صور خارجية إذن مستخدم) أو استخدام وكيل للوصول إليها ،
- تحويل رسائل البريد الإلكتروني بتنسيق HTML إلى تنسيق وسيط آخر (على سبيل المثال ، يستخدم Microsoft Exchange / Outlook RTF ، مما يجعل من الصعب للغاية عرض العناصر بشكل صحيح في Outlook باستخدام الطرق التقليدية) ،
- حظر أو تقييد استخدام النماذج أو عناصرها الفردية.
تستخدم رسائل البريد الإلكتروني أيضًا عناصر محددة ، مثل الصور المضمنة و URI
cid:// ، والتي قد يكون دعمها محدودًا. على سبيل المثال ، لا يدعم Mozilla Thunderbird
cid:// لصور الخلفية.
حتى البريد الإلكتروني الذي تم تكوينه بشكل صحيح يمكن عرضه بشكل مختلف في واجهات مختلفة نظرًا لخصائص تنفيذها وتصفية محتويات البريد الإلكتروني.
في حالة وجود أخطاء في تنسيق البريد الإلكتروني ، يصبح السلوك غير متوقع تمامًا. على سبيل المثال ، قد يكون لدى عملاء البريد الإلكتروني سلوك مختلف باستخدام URIs غير صحيحة ، أو أن تنسيق الرأس غير الصحيح يتم معالجته بشكل مختلف. أيضًا ، يعمل تشفير النص التلقائي للاكتشاف بشكل مختلف إذا لم يتم تحديده أو تم تحديده بشكل غير صحيح. لذلك ، يجب أن يتم عرض البريد الإلكتروني في واجهات مختلفة: العرض الصحيح للبريد الإلكتروني في واجهة واحدة لا يعني أنه يتكون بشكل صحيح (في الواقع ، حتى العرض الصحيح للبريد الإلكتروني في جميع الواجهات لا يضمن عدم وجود مشاكل مع العرض في المستقبل).
من الضروري الانتباه إلى النقاط التالية:
- تحقق من نص البريد الإلكتروني لمعرفة المحتوى الدلالي والعرض وغياب الأخطاء المطبعية والأخطاء النحوية والإملائية والمعاجمية.
- تحقق من صحة استبدال بيانات التطبيق في قالب أو تصميم البريد الإلكتروني.
- تحقق من صحة المبالغ والتواريخ والأرقام وعناصر البضائع وغيرها من المعلومات ، مع مراعاة شروط الحدود المسموح بها. يجب أن يكون للتواريخ سنة (بعض المستخدمين يدخلون المربع نادرًا). يجب أن تكون المنطقة الزمنية موجودة في الوقت المناسب. يجب أن يحتوي العنوان على مدينة ، وفي بعض الحالات ، من الضروري الإشارة إلى البلد.
- تحقق من الحالة التشغيلية لجميع الروابط في البريد الإلكتروني ، إن وجدت.
- في رسائل البريد الإلكتروني المرسلة قبل تأكيد العنوان ، بما في ذلك. رسائل البريد الإلكتروني التي تحتوي على رابط تأكيد ، يجب ألا يكون هناك أي نص يتم التحكم فيه من الخارج ، حتى اسم المستخدم ، وإلا ، يمكن استخدامها في البريد العشوائي (في الحقل المعروض في البريد الإلكتروني ، على سبيل المثال ، في الاسم ، يتم إدراج نص البريد العشوائي و العنوان هو العنوان المشار إليه للضحية). على سبيل المثال ، إذا كنت تستطيع إرسال نص فاحش على عنوان المطور نيابة عن خدمتك ، فهناك مشكلة.
- تحقق من عدم وجود صور خارجية على خدمات الجهات الخارجية. يمكن أن يؤثر ذلك على معلومات التسليم والتسرب الخاصة بعملائك.
- تحقق من توفر العدادات للإرسال والتسليم وقراءة البريد الإلكتروني والتحولات. يوجد بعضها في البريد الإلكتروني نفسه (على سبيل المثال ، البيكسل المعاكس لقراءة البريد الإلكتروني) ، ويتم تتبع بعضها من قبل الارسال ، ولكن كقاعدة عامة ، كلها متاحة في لوحة إدارة الارسال.
- تحقق من صحة فئة الاشتراك وإلغاء اشتراك المستخدم لهذه الفئة من خلال الرابط في البريد الإلكتروني.
- تحقق كيف تبدو الرسالة الإلكترونية:
- إصدارات الويب الشائعة من البريد للبلد المستهدف: "الثلاثة الكبار" بالنسبة لروسيا هي Mail.Ru و Yandex و Gmail. يمكنك أيضًا إضافة Rambler و Outlook.com ؛
- تطبيقات الهاتف المحمول لمقدمي البريد الإلكتروني أعلاه ؛
- تطبيقات الجوال القياسية التي تستخدم IMAP ، مع مراعاة المنصات المحمولة الشائعة ، على الأقل لأجهزة iPhone و Pixel (نظام أندرويد المرجعي) ، Samsung (الأكثر شيوعًا لنظام Android) ، MIUI (تأخذ المرتبة الثانية في روسيا لأنظمة Android) ؛
- متصفحات سطح المكتب المختلفة: Chrome و Firefox و Edge و Internet Explorer و Opera وغيرها.
- تطبيقات سطح المكتب (برامج البريد الإلكتروني) ، وخاصة Thunderbird و Outlook و Apple Mail ، اختياريًا The Bat! و Opera Opera
- حلول مشتركة للشركات مع واجهة ويب (Exchange ، وربما Roundcube ، Communigate ، Zimbra ، SquirrelMail) - للحلول B2B ؛
- لا تنس التحقق من التخطيط على شاشات وشاشات شبكية العين بدقة أقل.
- أثناء الفحص في كل حالة ، عليك الانتباه إلى:
- اجتياز رؤوس التراخيص ، SPF / DKIM / DMARC.
- سرعة تنزيل البريد الإلكتروني: يجب أن يتم التحميل بسرعة ، ولا يستغرق وقتًا.
- عرض رسالة بريد إلكتروني في قائمة رسائل البريد الإلكتروني: الصورة الرمزية واسم المرسل والموضوع الذي يندرج في مقتطف الرسالة ، ما إذا كانت فئتها محددة بشكل صحيح (على سبيل المثال ، إذا لم يندرج الترتيب في فئة "الشبكات الاجتماعية").
- تخطيط البريد الإلكتروني ككل: إذا ظل التنسيق ثابتًا ، فهل هناك أي فواصل غير صحيحة للكلمات ، وما إلى ذلك ، بما في ذلك عند تغيير حجم النافذة وتغيير حجمها.
- يجب ألا تكون الخطوط صغيرة أو يصعب قراءتها.
- صور الخلفية وألوان الخلفية.
- مطابقة كتاب العلامة التجارية.
- سهولة تنفيذ الإجراءات المتضمنة في البريد الإلكتروني. على سبيل المثال ، إذا كان البريد الإلكتروني يحتوي على رمز تأكيد أو معلومات أخرى قد تحتاج إلى تخزينها في مكان ما ، فلا ينبغي أن تكون للقراءة فقط فحسب ، بل يجب أن تكون ملائمة أيضًا لتحديدها ونسخها حتى في واجهة الهاتف المحمول.
- تتبع الحجم الكلي للبريد الإلكتروني (بما في ذلك الصور الخارجية) وأنه لا يتجاوز القيم المعقولة. كلما زاد وقت التحميل ، زاد احتمال تعرض الشخص لرد فعل سلبي عليه.
- يجب التحقق حتى من رسائل البريد الإلكتروني التي لم يتم تعديلها بشكل دوري ، حيث يمكن أن تحدث التغييرات على جانب الخدمة البريدية ، وعلى سبيل المثال ، "تكشف" عن مشكلة غير مرئية مسبقًا.
- يجب التحكم في بعض المعلمات في جميع الاختبارات. على سبيل المثال ، يمكن أن تكون المشاكل المتعلقة بتمرير مصادقة DKIM ناتجة عن مشاكل في البنية التحتية (مشاكل في DNS أو تشكيل توقيع DKIM ، أخطاء مزامنة الوقت) ، بسبب أخطاء في برنامج التوليد (عنوان المرسل مكون بشكل غير صحيح ، أحرف غير صحيحة في الرؤوس مفقودة أو إلزامية من ، تم تكرار رؤوس معرف الرسالة أو بسببها (بسبب أخطاء المحتوى (خطوط نهاية السطر غير صحيحة ، الخطوط طويلة جدًا ، عناوين غير صحيحة). في الوقت نفسه ، قد لا "ينجح" البريد الإلكتروني ، وقد لا تظهر المشكلة في أي خدمة.
إجراء اختبارات الانقسام
بحوث التسويق خارج نطاق هذا المقال ، ولكن ينبغي ذكر بعض النقاط الرئيسية التي تؤثر بشكل كبير على جودة رسائل البريد الإلكتروني.
The newsletter has a purpose, so it should entail through its quality, not quantity (which is the opposite for spammers). The newsletter must be segmented. When conducting an advertising campaign, you need to know exactly who gets into the segment sample, why they need the offered product and what they want to convey.
For each mailing list, it is necessary to calculate the CTR of the list of emails — this is the ratio of the number of emails read to the total number that has been sent out. In postmaster.mail.ru, you can see indicators for unique users. If the measurement goes through the counter in the email (pixel), then the absolute number of openings is estimated. CTR <10% is a very low indicator, it is undesirable to carry out such mailing. It should strive for a CTR> 30%. For marketing emails, the clickthrough rate of clickthroughs and the percentage of completed actions («sales») on these links are also of great importance. Be sure to monitor complaints (marking the email as spam). Typically, for one-time mailings, a tenth of a percent is a good indicator, for regular ones, a hundredth of a percent. The critical values, after which the mailing is always interpreted as spam, are indicated here:
https://help.mail.ru/developers/mailing_rules/technical .
It is necessary to conduct split testing of various distribution options to obtain optimal performance. Just changing the name of the sender and the subject of the email can increase the CTR by several times and significantly reduce the number of complaints. The number of emails should be statistically significant for evaluating the results (for large projects, usually a few thousand). The final version of the email is sent in several stages for additional measurement of indicators and «warming up» — starting with about 10,000 recipients, with an increase of about an order of the day.
The main idea: emails are part of your application, perhaps one of the most complex and problematic. At the same time, this is often a «blind spot» in terms of testing. I hope that I was able to draw your attention to this issue.
I would like to thank Vladimir Dubrovin (
z3apa3a ) and Alena Likhacheva (
s4ever ) for helping me with this article. As well as that, the article utilised sources of Eduard Tyantov (
edT ) and Alexander Purtov (
4Alexander ).