⛷️ 🤸🏻 🚝 كيفية القيام برسائل البريد الإلكتروني وعدم العبث: نصائح عملية 👊🏻 😋 🐅

المطور ، الذي واجه الجيل الأول من رسائل البريد الإلكتروني ، ليس لديه أي فرصة تقريبًا لكتابة تطبيق يقوم بذلك بشكل صحيح. حوالي 40 ٪ من رسائل البريد الإلكتروني التي تم إنشاؤها بواسطة تطبيقات الشركات لديها نوع من انتهاك المعايير ، ونتيجة لذلك ، مشاكل التسليم والعرض. هناك أسباب لذلك: البريد الإلكتروني أكثر تعقيدًا من الناحية التقنية من الويب ، ويتم تنظيم البريد من خلال عدة مئات من المعايير وعدد لا يحصى من الممارسات المقبولة بشكل عام (وليس كذلك) ، وعملاء البريد الإلكتروني متنوعون ولا يمكن التنبؤ بهم. يمكن أن يؤدي الاختبار إلى تحسين الموقف بشكل كبير ، ولكن لا توجد أي مواد مخصصة لاختبار البريد.

يتفاعل Mail.Ru بانتظام مع مستخدميه من خلال رسائل البريد الإلكتروني. في مشروعنا ، تخضع جميع المكونات المسؤولة عن إنشاء رسائل البريد الإلكتروني ، وحتى الرسائل الفردية ، للاختبار الإلزامي. في هذه المقالة سنشارك تجربتنا (ومليئة بالنتوءات).

ما هي رسائل البريد الإلكتروني

يمكن للتطبيق توليد أنواع مختلفة من الحروف. يمكن تصنيفها إلى عدة فئات. بطريقة اختيار المستلمين: الزناد - الانتقائي - المجموعة. عن طريق التعيين: المعاملات - التسويق - الخدمة. يمكن أن يكون للأنواع المختلفة من الأحرف متطلبات مختلفة وتطبيق نصوص اختبار مختلفة.

يتم إنشاء رسائل البريد الإلكتروني المشغلة استجابة لأية أحداث ، على سبيل المثال ، إجراءات المستخدم أو التغييرات في حالة أي كائنات النظام. يتم إنشاؤها بواسطة التطبيق ، وبالتالي الأكثر إثارة للاهتمام من حيث الاختبار. يمكن أن تكون رسائل البريد الإلكتروني المشغلة على حد سواء المعاملات والتسويق.

يتم إرسال رسائل مخصصة إلى مجموعة ديناميكية من المستخدمين المطابقين لأي معايير.

يتم إرسال رسائل المجموعة إلى مجموعة معروفة من المستلمين ، على سبيل المثال ، إلى جميع المستخدمين أو الشركاء. غالبًا ما يتم تسويق الرسائل الانتقائية والمجموعات ، ويتم إرسال هذه الرسائل يدويًا أو وفقًا لجدول زمني.

يتم إنشاء رسائل المعاملات عندما يقوم المستخدم بإجراء. تتضمن هذه الرسائل ، على سبيل المثال ، الفواتير أو التذاكر أو إشعارات حالة التسليم ، والرسائل التي تحتوي على رمز استرداد الوصول ، إلخ. يتم دائمًا تشغيل رسائل البريد الإلكتروني للمعاملات. التوافق الأقصى مهم بالنسبة لهم ، مما يعني أنه يجب أن يكون بسيطًا قدر الإمكان ، ويجب اختباره على عدد كبير من العملاء.

تشجع رسائل التسويق المستخدم على اتخاذ أي إجراء ، على سبيل المثال ، قد يكون عرضًا من الخصومات الفردية بناءً على عمليات الشراء السابقة. في هذه الحروف يمكن استخدام بيانات المعاملات ، ويمكن أن تكون على حد سواء الزناد والكتلة - دورية أو لمرة واحدة. بالنسبة لهذه الحروف ، تكون الكفاءة أكثر أهمية ، وعادة ما يتم تحديدها من خلال نتائج الاختبار المقسم. يمكن التضحية ببعض جوانب التوافق من أجل الكفاءة.

غالبًا ما يتم إرسال الرسائل التسويقية الجماعية ، على سبيل المثال ، الرسائل المتعلقة بالعروض الموسمية والعروض الترويجية والمبيعات "يدويًا" وليست جزءًا من تطبيقك ، ولكن يمكنك (ويجب) تطبيق مبادئ الاختبار العامة عليها.

بالإضافة إلى ذلك ، قد يكون هناك خطابات خدمة من إنشاء الموظفين لأنظمة إدارة علاقات العملاء أو الأنظمة الآلية أو اليومية أو التدقيق أو DWH. يتم تشغيل هذه الرسائل ، مما يعني أنها أيضًا جزء من التطبيق ويجب اختبارها.

من يشارك في عملية الاختبار والتحكم

مهندس ضمان الجودة - يشارك في جميع مراحل العملية.
مهندس شبكات - مسؤول عن تكوين البنية التحتية للشبكة والمراسلة. يجب أن يشارك مهندس الشبكة في تخطيط اختبار البنية التحتية.
أخصائي التسليم هو شخص يراقب تسليم الرسائل ، ويشارك أيضًا في مراقبة المعلمات الفنية والإدارية لجميع الرسائل المرسلة ويراقب تقدم عملية البريد. وهو مسؤول عن التأكد من أن الرسائل المرسلة تصل إلى أقصى نسبة ممكنة من المستخدمين ولا تقع في البريد العشوائي ، ولهذا يجب أن يكون لدى المتخصص معرفة ومعارف معينة. إذا نشأت مشاكل في إيصال الرسائل ، فمن يجب أن يفهم السبب المحتمل ويزيلها: إما عن طريق إزالة العقبات التقنية ؛ أو تغيير شيء ما في محتويات الحروف ؛ أو حل المشكلة مع خدمة دعم مزود البريد ، والتي لا تصل إليها الرسائل. يجب أن يشارك مثل هذا المتخصص (إن وجد) أيضًا في إعداد قائمة مراجعة واختبار البنية التحتية التي تولد التطبيقات والخطابات. ومع ذلك ، يجب أن تكون عملية الاختبار نفسها تحت سيطرة خدمة ضمان الجودة.
تسويق البريد الإلكتروني - يحدد فعالية الحملات التسويقية. تحت سيطرته ، يتم إجراء اختبار الانقسام للجمهور الضروري للمراسلات التسويقية. يتحكم مسوق البريد الإلكتروني أيضًا في تقسيم قاعدة المستخدمين وتكوين وتكرار رسائل البريد الإلكتروني المرسلة و "العرض" المرئي للبريد الإلكتروني إلى المستخدم.

لا يتم تنفيذ جميع هذه الأدوار بالضرورة من قبل موظف منفصل: يمكن أن يلعب دور المسوق من قبل أحد مديري المنتجات ، ويمكن أن يؤدي دور أخصائي التسليم ، على سبيل المثال ، موظف دعم أو مهندس شبكة. وفي الشركات الناشئة ذات الاحتمال العالي ، يجب أن يقوم شخص واحد بكل هذا ، وقد يتبين أنهم متخصصون في الجودة.

البريد والنقل البريدي

هيكل البريد يشبه جبل جليدي ضخم ، وله مستويين. هناك أكثر من مائة معيار مختلف ينظم البريد ، ولكن جميعها تقريبًا تنتمي إلى أحد هذين المستويين:

الجزء تحت الماء من الجبل الجليدي هو خدمة شبكة يكون بروتوكولها الأساسي هو بروتوكول تطبيق SMTP ، المحدد بواسطة RFC 5321. وهو مسؤول عن تسليم الحروف. لتسليم الرسالة ، يتم تشكيل ما يسمى مغلف SMTP ، والذي يتضمن عناوين المرسل والمستلم لمستوى SMTP. خدمات الشبكة الأخرى مثل DNS مسؤولة أيضًا عن تسليم الرسالة. المكون الرئيسي للبنية التحتية للشبكة هو وكيل نقل البريد ، أو يتم استخدام اختصار MTA في كثير من الأحيان. MTA مسؤولة عن معالجة قائمة انتظار تسليم الرسائل وعملية التسليم إلى خوادم المستلمين. ومن أمثلة MTA خدمة Postfix و Sendmail و Exim و Microsoft SMTP.

هذا الجزء تحت الماء من جبل الجليد ، والذي يتضمن MTA ، ومعلمات DNS ومعلمات الشبكة الأخرى ، سوف نتصل بالبنية التحتية للبريد ، أو البنية التحتية لتسليم الرسائل.

سطح جبل الجليد هو الحرف نفسه. يتم تعريف البنية الأساسية للحرف في RFC 5322. تتكون الرسالة من رؤوس الخدمة وجزء واحد أو أكثر مع البيانات. قد تحتوي البيانات على نص في نص عادي و / أو HTML ، أو صور مضمنة أو مرفقات من أي نوع تقريبًا.

واجهة البنية التحتية للبريد وحدود التطبيق قيد الاختبار

تحتوي البنية التحتية للبريد ، كقاعدة عامة ، على واحدة أو أكثر من الواجهات التي يتم إرسال رسالة بها (تدخل إلى قائمة انتظار التسليم MTA). على سبيل المثال ، خدمة إرسال SMTP ، وظيفة mail() في PHP ، نقل البيانات إلى بريد خارجي أو تطبيق إرسال بريد ، واجهة برمجة التطبيقات للخدمات الداخلية أو الخارجية (على سبيل المثال ، GetResponse أو SendPulse أو Amazon SES). سننظر في هذه الواجهات كجزء من البنية التحتية. غالبًا ما يكون هناك موقف حيث يقوم التطبيق A بإعداد البيانات لرسالة وقائمة بالمستلمين ، ثم ينقلها إلى التطبيق B من خلال API (للتسويق عبر البريد الجماعي ، يمكن القيام بذلك يدويًا من خلال واجهة المستخدم - UI) ، ويقوم التطبيق B بالفعل بإنشاء رسالة بريد في تنسيق RFC 5322 وقوائم الانتظار بطريقة أو بأخرى لتسليم MTA. من وجهة نظر التطبيق أ (وعند اختباره) ، سيكون التطبيق ب جزءًا من البنية التحتية للبريد. ستكون واجهة برمجة التطبيقات B أو واجهة المستخدم هي واجهة البنية التحتية للبريد للتطبيق A. على الرغم من وجهة نظر التطبيق B ، إلا أن الوضع سيكون مختلفًا ، وستكون البنية الأساسية للبريد الخاص بها عبارة عن تطبيقات أو بروتوكولات شبكة ذات مستوى أقل.

تعريف المعلمات المختبرة

عند اختبار كل تطبيق ، من المهم تسليط الضوء على جميع البنى التحتية للبريد المستخدمة من قبله (قد يكون هناك العديد) ، ولكل بنية أساسية ، حدد الواجهات المستخدمة (قد يكون هناك أيضًا العديد من كل بنية تحتية). لكل واجهة ، يتم تحديد تكوين وتنسيق البيانات المنقولة إليها بأكبر قدر ممكن من الدقة ، على سبيل المثال: نص الرسالة في TEXT / HTML ، نص الرسالة في TEXT / PLAIN ، موضوع الرسالة ، اسم المستلم ، عنوان المستلم ، اسم المرسل ، عنوان مرسل الرسالة (RFC5321. From ) ، عنوان مرسل موصل SMTP (RFC5322.mailfrom). بعد ذلك ، يتم تطوير مجموعة من المتطلبات لكل معلمة (تمثيلات ، ترميزات ، قيم حدودية ، وما إلى ذلك) ، يتم تحديد طرق التحكم لكل معلمة (بأي طريقة يمكن مقارنة النتيجة الفعلية بالمعلمة المتوقعة).

هيكل نموذجي لتوليد التطبيق

كقاعدة عامة ، يكون المنتج الذي نختبره مسؤولاً عن إنشاء الرسالة والبيانات الموجودة فيه. هذا عادة ما يكون تطبيق خادم (ولكن في بعض الأحيان عميل). وهي تحدد بنية الحرف ، وجزء من رؤوس الخدمات ، وتنسيقات تغليف البيانات ، وعرض السلاسل وترميز النص. مثال بسيط على مثل هذا التطبيق هو برنامج نصي يشكل حرفًا ويستدعي وظيفة mail() .

العناصر الرئيسية للتطبيق التي يجب التحكم فيها:

الشفرة المسؤولة عن توليد الرؤوس و / أو بنية الحروف إذا تم إنشاء بنية الرسالة ديناميكيًا و / أو قالب خطاب ثابت يصف هيكلها ؛
تخطيط جزء HTML من الحرف (من الناحية المثالية ، هذا كيان منفصل أو جزء من قالب / تخطيط الحرف ، ولكن يمكن خياطته في رمز التطبيق) ؛
استبدال بيانات التطبيق في خطاب (أو في قالب خطاب) ؛
تكامل التطبيق مع البنية التحتية لتسليم الرسالة ، وصحة المعلمات المحولة إلى واجهة البنية التحتية.

ماذا ومتى لاختبار

سواء أحببنا ذلك أم لا ، فإن جبل الجليد بأكمله يحتاج إلى اختبار. هناك العديد من المكونات الرئيسية التي تتطلب الاختبار:

1. البنية التحتية للتسليم

يجب التركيز في الاختبار على ما يلي: صحة سجلات DNS ، بما في ذلك سجلات PTR / FCrDNS و MX و A ؛ إعدادات بروتوكول SMTP (HELO ، باستخدام TLS) ؛ إذن خطاب (SPF / DKIM / DMARC) ؛ عناوين مغلفات SMTP (إذا لم يديرها التطبيق) ؛ المعالجة الصحيحة لمعلمات الإدخال لواجهة البنية التحتية ؛ تتبع ومحاسبة ومعالجة الرسائل التي لم يتم تسليمها.

من الضروري اختبار البنية التحتية أثناء التنفيذ الأولي وفي كل مرة يتم فيها إجراء تغييرات على البنية التحتية نفسها (تكوين MTA أو DNS أو تغييرات الشبكة) أو الواجهة لإرسال الرسائل ؛ استخدام مجال أو شبكة أو واجهة برمجة تطبيقات جديدة تغيير خصائص رسائل البريد الإلكتروني المرسلة بشكل كبير ، مثل لغتها أو حجمها أو كميتها. وفقًا للتجربة ، تميل البنية التحتية إلى التغيير دون إعلان الحرب ، لذلك يجب إجراء الاختبارات الأساسية بشكل دوري ، حتى إذا لم تكن هناك معلومات حول أي تغييرات.

يمكن ويجب أن يشارك مهندس الشبكة وأخصائي التوصيل في إعداد الخطة والتحقق من قوائم اختبار البنية التحتية.

2. تطبيق توليد

يجب عليك التحكم في عناوين مغلف SMTP (إذا كان يتم التحكم فيها بواسطة التطبيق ، أي يتم نقلها إلى الواجهة - المغلف من ، المغلف إلى) ، قيم رؤوس رسائل الخدمة (التاريخ ، معرف الرسالة ، إلغاء الاشتراك ، الإرسال التلقائي ، إلخ.) ص.) ، تخويل الحروف (DKIM / DMARC) ، ترميزات MIME (base64 ، اقتباس قابل للطباعة) ، صحة التنسيق العام للحرف ، على سبيل المثال ، عدم وجود أحرف غير ASCII في الرؤوس ، تكوين البيانات المستبدلة ، التشغيل الصحيح للمشغلات ، آليات إلغاء الاشتراك ، آليات التتبع مجموعة الحروف والإحصائيات (رؤوس Postmaster ، على سبيل المثال ، Feedback-ID أو X-Mailru-Msgtype ، بالإضافة إلى وحدات بكسل التتبع) .

تحتاج إلى اختبار التطبيق أثناء تطويره ، عند تغيير جميع مكوناته ذات الصلة المسؤولة عن إنشاء البيانات وتخزينها ، مع تغييرات كبيرة في قوالب الحروف ، عند تغيير البنية التحتية المستخدمة أو واجهته ، وكذلك في إطار الانحدارات العامة.

3. قوالب الحروف الهيكلية والتخطيطية (يمكن أن تكون جزءًا من تطبيق توليد أو يتم تطويرها بشكل منفصل)

يتم فحص بنية الرسالة (نوع المحتوى ، المحتوى ، الترتيب ، تداخل الأجزاء المتعددة الأجزاء للحرف ، ترميز النص ، معلمات السلسلة) ، قيمة الهدف والعناوين المعروضة (من ، إلى ، الرد على الموضوع) ، يتم عرض الرسالة في قائمة الحروف وعند القراءة في واجهات مختلفة ، تنسيقات microformats (على سبيل المثال ، يتم التعرف على حدث التقويم كحدث تقويم ، أو تذكرة طيران كتذكرة طيران) ، والعلامة التجارية.

يجب اختبار قوالب البريد الإلكتروني في كل مرة تقوم فيها بإجراء تغييرات طفيفة على الأقل ، وكذلك بشكل منفصل ، على سبيل المثال ، في الحالة التي تدخل فيها الرسائل إلى التطبيق قبل أن يصبح جزء الخادم جاهزًا.

من المستحسن استخدام مسوق البريد الإلكتروني ومتخصص التسليم لكتابة قائمة مرجعية لاختبار قالب خطاب.

المتطلبات الأساسية لفحص البنية التحتية

يجب أن يكون عنوان 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 ، واجهات برمجة تطبيقات خدمة postmaster ، وأدوات تتبع البريد الإلكتروني ، وإحصاءات التسليم. يجب أن يأخذ الاختبار في الاعتبار مستوى تنفيذ أدوات المراقبة التشغيلية في الشركة - على سبيل المثال ، في حالة عدم وجود مراقبة تشغيلية لتقارير DMARC ، يجب عليك اختبار تفويض البريد بانتظام ، في حالة عدم وجود مراقبة تشغيلية للتسليم - تحقق بانتظام من كيفية ومكان وصول الرسائل ، حتى إذا لم يكن هناك تطور يتعلق بإرسال الرسائل لم تجر.

للتحقق من البنية التحتية ، يمكنك استخدام الخدمات المتخصصة ، على سبيل المثال ، mail-tester.com ، mxtoolbox.com . يمكن العثور على متطلبات البنية التحتية المفصلة في هذه المقالة .

متطلبات التفويض

عادةً ما يكون التحقق من مرور SPF و DKIM و DMARC ممكنًا باستخدام عنوان نتائج المصادقة على خادم المستلم.

تحقق من صلاحية سجل نظام التعرف على هوية المرسل (SPF) لبناء الجملة ، والحد الأقصى لاستعلامات DNS (على سبيل المثال ، باستخدام mxtoolbox.com). عند تشكيل نظام التعرف على هوية المرسل (SPF) ، يجب أن تؤخذ جميع مصادر البريد في الاعتبار (لا تنسَ أنظمة CRM ، وجميع البنى التحتية المستخدمة للتسليم ، بما في ذلك تلك التي يتم من خلالها إجراء حملات تسويق لمرة واحدة). يوصى بتعيين الخوادم المسموح بها للمجال من خلال قائمة الشبكات ('ip4' / 'ip6'). يتم فحص نظام التعرف على هوية المرسل (SPF) بحثًا عن عنوان المرسل من مغلف SMTP. تحقق من أن مجال مغلف SMTP (مغلف من) يطابق المجال من الرأس من. يتم سرد أخطاء SPF الشائعة في هذه المقالة .

تحقق من سجل 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.

عناوين المغلفات هي عناوين مستوى البنية التحتية للبريد. وهي غير مرئية للمستخدم ، ولكنها مهمة للتسليم ، لأنه في أي صندوق بريد تحصل عليه الرسالة ، يتم تحديده بدقة من خلال عنوان المغلف.

عنوان المستلم في مظروف (مغلف إلى الملقب RCPT TO :) هو العنوان الذي سيتم تسليم الرسالة إليه بالفعل.

بالنسبة لجميع الرسائل باستثناء التسجيل ، يجب أن يكون العنوان موقعًا بشكل قانوني ويتم التحقق منه لإرساله وفقًا للمتطلبات الإدارية.
بالنسبة للرسائل الإخبارية ، يجب أن يكون العنوان "مباشرًا" ، ويجب وضع علامة على العناوين التي لا يمكن تسليم الرسائل إليها بشكل منتظم على أنها غير نشطة ، ولا يجب إرسال الرسائل البريدية إليها. ولكن قد يلزم أيضًا إرسال بعض فئات الرسائل (على سبيل المثال ، استعادة الوصول) إلى عناوين تم وضع علامة عليها سابقًا على أنها غير نشطة.

عنوان المرسل في مغلف SMTP (يسمى عادةً envelope-from أو smtp.mailfrom أو مسار الإرجاع) - سيتم تسليم الرسائل إلى هذا العنوان حول عدم القدرة على تسليم رسالة وردود تلقائية. هذا العنوان غير مرئي للمستخدم. يستخدم هذا العنوان أيضًا لتفويض نظام التعرف على هوية المرسل (SPF). نحن نتحقق من أن:

العنوان متاح.
إنه ليس عنوان الموظف ولا تتم إعادة توجيهه إليه لاستبعاد الإجابات التلقائية ، والرسائل المتعلقة بعدم إمكانية الوصول ، وما إلى ذلك ؛
تتم معالجته بواسطة برنامج نصي يضع علامة على عناوين المستخدمين الذين يتعذر الوصول إليهم على أنهم غير نشطين ؛
يمكن إنشاء العنوان تلقائيًا ، أي فريد لكل حرف.
يجب ألا يؤدي أي حرف إلى هذا العنوان إلى إنشاء أي خطاب استجابة ، على سبيل المثال ، رسالة حول تجاوز سعة الصندوق.

عناوين رؤوس البريد الإلكتروني

تكون هذه العناوين مرئية مباشرة للمستخدم أو تُستخدم عند الرد على خطاب.

عنوان المرسل (من :) العنوان هو العنوان واسم المرسل المعروض في قائمة الحروف وعند قراءة الرسالة. نحن نتحقق من أن:

هذا هو عنوان صديق "سهل القراءة" يحدد هوية الشركة.
لا يحتوي على البريد الإلكتروني فحسب ، بل يحتوي أيضًا على اسم المرسل.
يعد noreply @ ممكنًا ، ولكن فقط إذا أردنا التأكيد على أننا لا نتوقع تلقي رد على الرسالة ولن تتم قراءتها. من الأفضل تكرار هذه الفكرة في نص الرسالة.
في حالة وجود أحرف غير ASCII (على سبيل المثال ، السيريلية) ، يجب ترميز اسم المرسل وفقًا لـ MIME ، ويجب ترميز المجال في وجود أحرف غير ASCII في Punycode.
يجب أن يكون للحروف من نفس الفئة نفس العنوان ؛ لا يُسمح باستخدام العناوين التي يتم إنشاؤها تلقائيًا. هذا يرجع إلى حقيقة أن من: يستخدمه الأشخاص غالبًا لفرز الأحرف إلى مجلدات باستخدام عوامل التصفية.
يجب أن يكون العنوان مختلفًا (يفضل أن يكون في نطاقات فرعية مختلفة) لخطابات المعاملات والتسويق والرسائل العاجلة (مثل الرسائل من خدمة الدعم). ويرجع ذلك أيضًا إلى حقيقة أنه يمكن للمستخدم وضع علامة على رسائل البريد الإلكتروني التسويقية كرسائل غير مرغوب فيها أو تصفيتها في مجلد غير قابل للقراءة.
يجب أن يكون العنوان "من" وعنوان مغلف SMTP في نفس المجال أو في نطاقات فرعية من نفس النطاق التنظيمي لتمرير نظام التعرف على هوية المرسل (SPF) داخل DMARC.
يجب أن يكون العنوان من نطاق المؤسسة. من غير المقبول استخدام خدمات البريد المجانية ونطاقات البريد العامة الأخرى في من ، لأن هذه الرسائل لن تجتاز مصادقة SPF و DKIM في إطار DMARC.

عنوان الرد على - سيتم إرسال الردود "اليدوية" إلى هذا العنوان عندما يرد المستخدم على الرسالة. إنه اختياري: إذا كان غائبًا ، يتم استخدام العنوان من من الرد. تحقق من أن الرد على:

يمكن أن يتم إنشاؤه تلقائيًا ، أي فريد من نوعه في الحرف (يسمح لك بمعرفة الحرف الذي وصلت إليه الإجابة).
لا يجب أن يقع في صندوق الموظف لتجنب الرد على المكالمات ، ولكن من الأفضل أن يكون "ملفوفًا" في CRM.
يمكنه إنشاء إجابة تلقائية قياسية لإدارة علاقات العملاء ، ولكن لا ينبغي أن يولد أي شيء غير ضروري ، على سبيل المثال ، الرسائل حول تجاوز سعة الصندوق. عند إنشاء استجابات تلقائية ، يجب اتخاذ تدابير لتجنب التكرار ، وهي مدرجة في RFC 3834.
يمكن أن يكون من أي مجال لا يتطابق بالضرورة مع من ، ولكن في بعض الأحيان يخيف هذا المستخدمين عند الرد.
قد يكون غائبًا ، ثم يؤدي العنوان من وظائفه.
بالإضافة إلى العنوان ، يشار إلى اسم المرسل.

لمعالجة:

يجب أن يحتوي على البريد الإلكتروني للمستلم (وإلا فإنه يخيف مستلم الرسالة ويحمي مكافحة البريد العشوائي).
من الناحية المثالية ، يجب أن يحتوي على اسم المستلم. ولكن إذا كان الاسم غير معروف أو مشكوك فيه (على سبيل المثال ، لم يتم تأكيد العنوان بعد) ، فمن الأفضل عدم الإشارة إليه (يمكن لشخص ما إدخال عنوان شخص آخر باسم سيئ ، وقد يسيء إليك المستلم).

متطلبات رأس البريد الإلكتروني

يجب أن يتطابق الترميز الفعلي للنص مع الترميز المشار إليه في الرأس. من المستحسن استخدام ترميز واحد في جميع رؤوس وأجزاء الرسالة. من المستحسن استخدام UTF-8 كواحد مدعوم على نطاق واسع. تتم الإشارة إلى الترميز في رؤوس نوع المحتوى وفي علامة <META> لجزء HTML.

من: ، معرف الرسالة: والتاريخ: يجب أن تتكون الرؤوس مباشرة في البرنامج النصي لإرسال الحرف (وحسب المعايير - جنبًا إلى جنب مع نص الرسالة) ودائمًا بالتنسيق الصحيح. إذا كانت غائبة أو تم تشكيلها بشكل غير صحيح ، يمكن لأحد خوادم النقل إضافة هذه الرؤوس ، مما يؤدي إلى انتهاك سلامة توقيع DKIM.

يجب عدم وجود أحرف 8 بت في الرؤوس ، بما في ذلك سطر الموضوع (الموضوع) وأسماء الملفات المرفقة (نوع المحتوى والتخلص من المحتوى) ؛ يجب أن يتم ترميز كافة الأحرف غير ASCII ، بما في ذلك السيريلية ، في ملف اقتباس قابل للطباعة أو base64.

متطلبات هيكل الرسالة

بالنسبة لجزء HTML من الرسالة ، من المستحسن تكوين جزء نص بديل (نص عادي). من الضروري أيضًا التحقق من مطابقة وقراءة جزء النص العادي للحرف (إن وجد) والهيكل العام للحرف.

وفقًا لـ RFC 5322 ، يجب ألا يتجاوز طول السطر في الحرف 998 حرفًا من 8 بتات. يرجى ملاحظة أنه في UTF-8 ، يمكن أن يشغل الحرف عدة ثمانيات. فاصل الأسطر في البريد الإلكتروني هو زوج CRLF (<cr> ascii 13، lf> ascii 10) ، والذي يشغل 2 ثماني بتات. تحتاج إلى التحقق من صحة حرف نهاية السلسلة ، حيث يتم إرسال الحروف غالبًا باستخدام برنامج نصي Unix ، وفي Unix ، يكون حرف نهاية الخط حرفًا واحدًا - وهذا خطأ للبريد الإلكتروني. يجب عليك أيضًا التحقق لمعرفة ما إذا كانت فواصل السلاسل تكسر الأحرف المشفرة UTF-8: لا يمكنك السماح بوجود فاصل السلاسل بين ثُمانيتين من نفس الحرف ، على سبيل المثال ، السيريلية. , base64.

— «Content-Disposition: inline», , , «Content-Disposition: attachment», .
, , : , multipart- (mixed, alternative, related), multipart/mixed , multipart/related — , multipart/alternative — plain text- HTML-. , -, :

multipart/alternative
— text/plain
— text/html

, text/plain text/html multipart/related. , HTML-, - — plain-.

- :

multipart/alternative
— text/plain
— multipart/related
—— text/html
—— image/… (-)
—— image/… (-)

- Content-Disposition: inline multipart/related-.

, , , :

multipart/mixed
— multipart/alternative
—— text/plain
—— multipart/related
——— text/html
——— image/png
——— image/png
...
— application/octet-string (content-disposition: attachment)
— application/octet-string (content-disposition: attachment)
...

(multipart/related- multipart/alternative- , multipart/mixed-)

URI

URI ( src, href, ..) ( https://example.com/somepath ). (/somepath) (//example.com/somepath), , .. file://.

ASCII- ( , ) URI percent encoding.
, (.. URL, ), <>, . - , . href A , - . «», .
htt://, htts:// milto:.
http:// htts://.
(, example.com :8080/somepath), .. .
HTML- - (, , ..) , .. - , ; , , , ( - GET-, POST PUT).
List-Unsubscribe, , - , .. .
, , , (, ). . , , , , , .
لأن URI , URI data:. URI.
, . , , .
- .

. — (XSS, Crossite scripting), (interface spoofing), DOM clobbering, / (, IP- ) .., . , . :

,
/ ,
,
( ),
(.. ) ,
HTML- ( Microsoft Exchange / Outlook RTF, - Outlook ),
.

, - URI cid://, . , Mozilla Thunderbird cid:// .

- - .

. , URI, - , - , . : , ( , ).

:

, , , , .
.
, , , . ( ). . , .
, .
, , .. -, - , c, , ( , , , , - ). , , .
.
, , , . (, - ), , , , .
.
:
- : « » Mail.Ru, Yandex, Gmail, Rambler Outlook.com;
- ;
- , IMAP, , iPhone, Pixel ( Android), Samsung ( Android), MIUI ( Android-);
- : Chrome, Firefox, Edge, Internet Explorer, Opera .;
- ( ), Thunderbird, Outlook Apple Mail, The Bat! Opera Mail;
- - (Exchange, Roundcube, Communigate, Zimbra, SquirrelMail) — B2B-;
- Retina-, .
:
- , SPF/DKIM/DMARC.
- : , .
- : , , , (, «»).
- : , .., .
- .
- .
- .
- , . , , - , , .
( ) , . , .
, , , .. , , , «» .
. , DKIM- - ( DNS DKIM-, ), - ( , , From, Date Message-ID) - ( , , ). «» , .

-

, , .

, , ( ). . , , .

CTR — . postmaster.mail.ru . (), . CTR < 10% — , . CTR > 30%. CTR («») . ( ). , — . , , : https://help.mail.ru/developers/mailing_rules/technical .

- . CTR . ( ). «» — 10 000 , .

: , , . « » . , .

z3apa3a s4ever . EdT 4Alexander .

كيفية القيام برسائل البريد الإلكتروني وعدم العبث: نصائح عملية