بناء نظام أرشفة البريد الإلكتروني: التحديات وطبعًا الحل - الجزء 1
جيف جولدستاين
04/02/2019
البريد الإلكتروني
1 min read
النقاط الرئيسية
أصبحت أرشفة البريد الإلكتروني ضرورية بشكل متزايد للامتثال والتدقيق والبيئات التنظيمية.
لا يخزن SparkPost محتوى رسائل البريد الإلكتروني، ولكن ميزة الأرشفة تتيح للمُرسلين تلقي رسائل مكررة تعكس الروابط والتتبع والمحتوى.
يمكن تخزين محتويات البريد الإلكتروني في Amazon S3، في حين يمكن تخزين بيانات أحداث الرسائل في MySQL للاستعلام وعبر المراجع.
توفر أحداث رسائل SparkPost سجلات نشاط غنية (ارتدادات، توصيلات، نقرات، فتحات، إلغاء اشتراكات، شكاوى، وأكثر).
تُولَّد نسخ الأرشيف فقط عند الإرسال عبر SMTP.
تشارك أحداث الرسائل للبريد الإلكتروني الأصلي والأرشيف وCC وBCC معرف transmission_id مشترك.
يمكن أن يقوم نقل البريد الإلكتروني الوارد بمعالجة الرسائل المؤرشفة، ولكنه لا يتضمن transmission_id، مما يخلق تحديًا في ربط البيانات.
يؤدي تضمين معرف فريد مخفي (UID) في جسم الرسالة إلى سد تلك الفجوة ويربط المحتوى الوارد بالسجلات الصادرة.
يمكن أن يؤدي دمج رسائل الأرشيف + أحداث الرسائل إلى بناء نظام أرشيف قابل للبحث، وقابل للتدقيق.
يشمل المشروع طويل الأجل إصدارات من الشفرات لتخزين رسائل الأرشيف في S3 وتسجيل بيانات الأحداث في MySQL.
ستسمح التطبيق النهائي بالبحث السهل، والاطلاع، والتوافق مع محتوى البريد الإلكتروني مع جميع سجلات الأحداث ذات الصلة.
مثالي للصناعات التي تحتاج إلى امتثال قوي وتحتاج إلى رؤية كاملة لكل رسالة تم إرسالها.
أهم النقاط في الأسئلة والأجوبة
لماذا تبني نظام أرشفة البريد الإلكتروني الخاص بك؟
تتطلب الصناعات الخاضعة للتنظيم غالبًا تخزينًا طويل الأمد لكل من محتوى البريد الإلكتروني وكل سجل أحداث مرتبط. لا يقوم SparkPost بتخزين محتوى الرسائل، لذا يضمن بناء نظام مخصص الامتثال والمراجعة والرؤية.
كيف يمكنك الحصول على نسخة دقيقة من البريد الإلكتروني الأصلي المرسل؟
تتيح ميزة الأرشيف في SparkPost إرسال نسخة من كل بريد إلكتروني صادر إلى عناوين الأرشيف المحددة، مع الحفاظ على جميع الروابط المشفرة وسلوكيات التتبع.
لماذا لا تستطيع التقاط محتوى البريد الإلكتروني قبل الإرسال؟
لا تتضمن نسخة ما قبل الإرسال التعديلات التي أجرتها SparkPost (تتبع الفتح، تتبع النقر، تشفير الروابط). يضمن استخدام نسخ الأرشيف أن النسخة المحفوظة لديك تتطابق تمامًا مع ما يتلقاه المستلمون.
هل يقوم SparkPost بأرشفة الرسائل الإلكترونية تلقائيًا؟
لا. SparkPost لا تخزن محتويات الرسائل. يجب طلب نسخ الأرشيف عن طريق تحديد عناوين الأرشيف أثناء حقن SMTP.
ما الذي يتم تخزينه وأين في هذا النظام الأرشيفي؟
نص البريد الإلكتروني → أمازون S3
سجلات أحداث الرسائل → MySQL
هذا الفصل يدعم البحث السريع، والاستعلامات المنظمة، والتخزين الرخيص للأشياء.
مدة احتفاظ SparkPost ببيانات الأحداث؟
تقوم SparkPost بتخزين أحداث الرسائل لمدة 10 أيام. بعد ذلك، يجب استيعاب البيانات عبر الويب هوك أو استعلامها وتخزينها في مكان آخر.
ما هي الأحداث الرسائل المتاحة؟
سبيس بارك بوست يكشف حاليًا عن 14 حدثًا، بما في ذلك التوصيلات، الارتدادات، النقرات، الفتحات، الرفض، مشكلات السياسة، شكاوى الرسائل غير المرغوب فيها، إلغاء الاشتراكات، والمزيد.
ما هي المعرفات التي تربط جميع الأحداث معًا؟
تشترك جميع الرسائل الصادرة (الأصلية، الأرشيف، CC، BCC) في نفس transmission_id. كما تشترك الرسالة الأصلية ورسالة الأرشيف في نفس message_id.
لماذا تعتبر معالجة الوارد تحدياً؟
تعمل خدمة SparkPost لتوجيه البريد الإلكتروني الوارد على تحويل البريد الإلكتروني الوارد إلى JSON، ولكن هذا JSON لا يتضمن transmission_id. بدون بيانات إضافية، لا يمكن ربط النسخة الواردة بسجلها الخارجي.
كيف يمكنك ربط رسائل البريد الإلكتروني الأرشيفية الواردة بأحداث الرسائل الصادرة؟
أدرج معرف فريد (UID) مخفي في نص البريد الإلكتروني ومرر نفس UID في البيانات الوصفية. يصبح هذا UID المرجع المشترك عبر سجلات الوارد والصادر.
كيف يساعد البريد الوارد على أتمتة الأرشفة؟
يستقبل رسائل البريد الإلكتروني المؤرشفة المرسلة إلى مجال الأرشفة الخاص بك، ويقوم بتحليلها إلى JSON منظم، وينشرها إلى تطبيقك عبر واجهة الويب—مما يسمح بالاستخراج والتخزين التلقائي.
ما هي الرؤية طويلة المدى للمشروع؟
تطبيق كامل يقوم بـ:
تخزين رسائل الأرشيف في S3
تخزين جميع سجلات الأحداث في MySQL
يسمح للمستخدمين بالبحث عن الرسائل الإلكترونية
يعرض البريد الإلكتروني الأصلي وكل حدث مرتبط به في واجهة موحدة واحدة
قبل عام تقريبًا، كتبت مدونة عن كيفية استرجاع نسخ من الرسائل الإلكترونية للأرشفة والمشاهدة، لكنني لم أتطرق إلى تخزين الرسالة الإلكترونية أو البيانات ذات الصلة، ومؤخراً كتبت مدونة عن تخزين جميع بيانات الأحداث (مثل: متى تم إرسال الرسالة، والفتح، والنقرات، والارتباطات، وعدم الاشتراكات، وما إلى ذلك) على رسالة إلكترونية لغرض التدقيق، لكنني اخترت عدم إنشاء أي كود داعم.
مع زيادة استخدام البريد الإلكتروني في بيئات تنظيمية، قررت أنه حان الوقت لبدء مشروع جديد يجمع كل ذلك مع عينات كود حول كيفية تخزين نص الرسالة الإلكترونية وجميع بياناتها المرتبطة. خلال العام المقبل، سأستمر في بناء هذا المشروع بهدف إنشاء تطبيق لتخزين البريد الإلكتروني وعرض جميع معلومات السجل التي يتم إنتاجها بواسطة SparkPost. لا تمتلك SparkPost نظامًا يقوم بأرشفة نص الرسالة الإلكترونية، لكنها تسهل بناء منصة أرشيفية بشكل جيد.
في سلسلة المدونات هذه، سأصف العملية التي مررت بها من أجل تخزين نص الرسالة الإلكترونية على S3 (خدمة التخزين البسيط من أمازون) وجميع بيانات السجل ذات الصلة في MySQL لسهولة البحث المتقاطع. لأنظمة الأرشفة الإنتاجية التي تتطلب استراتيجيات قوية لنسخ البيانات الاحتياطية، فكر في تنفيذ عملية النسخ الاحتياطي والاستعادة من PostgreSQL لضمان حماية بيانات الأرشفة الخاصة بك بشكل صحيح. في النهاية، هذه هي نقطة البداية لبناء تطبيق سيسمح بالبحث بسهولة عن الرسائل الإلكترونية الأرشيفية، ثم عرض تلك الرسائل إلى جانب بيانات الأحداث (السجل). يمكن العثور على كود هذا المشروع في مستودع GitHub التالي: PHPArchivePlatform على GitHub
ستصف هذه المدخلة الأولى من سلسلة المدونات التحدي وتضع معمارية للحل. ستفصل المدونات المتبقية أجزاء من الحل جنبًا إلى جنب مع عينات الكود.
كانت الخطوة الأولى في عملي هي معرفة كيف كنت سأحصل على نسخة من الرسالة الإلكترونية المرسلة إلى المستلم الأصلي. للحصول على نسخة من نص الرسالة، تحتاج إما إلى:
خيارات التقاط نص الرسالة الإلكترونية
الطريقة | من ينشئ النسخة | تعكس التغييرات في التتبع | ملائمة للتشغيل الآلي | مستخدم في هذا الحل |
|---|---|---|---|---|
التقاط قبل الإرسال | التطبيق | ❌ لا | ✅ نعم | ❌ |
خادم البريد الإلكتروني يخزن النسخة | خادم البريد | ✅ نعم | ❌ محدود | ❌ |
ميزة الأرشيف لـ SparkPost | SparkPost | ✅ نعم | ✅ نعم | ✅ |
التقاط نص الرسالة قبل إرسال الرسالة الإلكترونية
جعل خادم البريد الإلكتروني يخزن نسخة
جعل خادم البريد الإلكتروني ينشئ نسخة لك لتخزينها
إذا كان خادم البريد الإلكتروني يضيف عناصر مثل تتبع الروابط أو تتبع الفتحات، فلا يمكنك استخدام #1 لأنه لن يعكس تغييرات تتبع الفتح/النقر.
هذا يعني أنه يجب على الخادم إما تخزين الرسالة الإلكترونية أو بطريقة ما أن يقدم لك نسخة من تلك الرسالة لتخزينها. نظرًا لأن SparkPost لا تمتلك آلية للتخزين لرسائل البريد الإلكتروني، لكن لديها طريقة لإنشاء نسخة من الرسالة الإلكترونية، سنجعل SparkPost ترسل لنا نسخة من الرسالة الإلكترونية لنخزنها في S3.
يتم ذلك باستخدام ميزة الأرشيف الخاصة بـ SparkPost. تعطي ميزة الأرشيف الخاصة بـ SparkPost للمرسل القدرة على إخبار SparkPost بإرسال نسخة مكررة من الرسالة إلى عنوان بريد إلكتروني واحد أو أكثر واستخدام نفس روابط التتبع والفتح مثل النسخة الأصلية. تعرف وثائق SparkPost ميزة الأرشيف الخاصة بها على النحو التالي:
سيستلم المستلمون في قائمة الأرشيف نسخة مطابقة تمامًا من الرسالة التي تم إرسالها إلى عنوان RCPT TO. على وجه الخصوص، ستكون أي روابط مشفرة مخصصة للمستلم RCPT TO متطابقة في رسائل الأرشيف
الاختلافات الوحيدة عن البريد الإلكتروني RCPT TO هي أن بعض الرؤوس ستكون مختلفة، نظرًا لأن العنوان المستهدف للبريد الإلكتروني الأرشيفي مختلف، لكن نص الرسالة سيكون نسخة مطابقة!
إذا كنت تريد تفسيرًا أعمق، هنا رابط إلى وثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من رسالة إلكترونية.
كتعليق جانبي، تسمح SparkPost في الواقع بإرسال رسائل إلكترونية إلى عناوين بريد cc و bcc والأرشيف. بالنسبة لهذا الحل، نحن نركز على عناوين الأرشيف.
* ملاحظة * يمكن إنشاء الرسائل الإلكترونية الأرشيفية فقط عند إدخال الرسائل الإلكترونية في SparkPost عبر SMTP!
الآن بعد أن عرفنا كيف نحصل على نسخة من الرسالة الأصلية، نحتاج إلى النظر في بيانات السجل التي يتم إنتاجها وبعض الفروق الدقيقة الدقيقة في تلك البيانات. تتبع SparkPost كل شيء يحدث على خوادمها وتقدم لك تلك المعلومات في شكل أحداث الرسائل. يتم تخزين تلك الأحداث على SparkPost لمدة 10 أيام ويمكن سحبها من الخادم عبر واجهة برمجة تطبيقات RESTful تسمى أحداث الرسائل، أو يمكنك أن تجعل SparkPost يدفع تلك الأحداث إلى أي عدد من تطبيقات الجمع التي تريدها. يتم تنفيذ آلية الدفع من خلال webhooks ويتم ذلك في الوقت الفعلي.
حاليًا، هناك 14 حدثًا مختلفًا قد يحدث لرسالة بريد إلكتروني. ها هي قائمة بالأحداث الحالية:
ارتداد
تأخير النقر
تسليم
فشل التوليد
رفض التوليد
فتح أولي
إلغاء الاشتراك من رابط الإدخال
إلغاء الاشتراك من القائمة
فتح
خارج النطاق
رفض السياسة شكوى البريد المزعج
* تابع هذا الرابط للحصول على مرجع محدث لوصف كل حدث جنبًا إلى جنب مع البيانات التي يتم مشاركتها لكل حدث.
كل حدث له العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل transmission_id موجودة في كل حدث، لكن قد تكون الحقول الأخرى أكثر خصوصية للحدث؛ على سبيل المثال، فقط أحداث الفتح والنقر لديها معلومات الترميز الجغرافي.
المحددات المستخدمة في نظام الأرشفة
المحدد | من أين ينشأ | مشترك عبر | الغرض | الحد |
|---|---|---|---|---|
transmission_id | SparkPost الصادرة | الأصلية، الأرشيف، cc، bcc | يربط جميع أحداث الرسائل | غير متوفر في النقل الوارد |
message_id | SparkPost الصادرة | الأصلية + الأرشيف | تحديد الرسائل الفردية | مختلف ل cc/bcc |
معرف مخفي | تم حقنه بواسطة المرسل | الصادرة + الواردة | يربط نص الرسالة الإلكترونية المؤرشف بالأحداث | يجب تنفيذه بشكل مخصص |
مدخل حدث الرسالة المهم جدًا لهذا المشروع هو transmission_id. ستشارك جميع إدخالات أحداث الرسائل للرسالة الأصلية، ورسالة الأرشيف، وأي عناوين cc و bcc نفس transmission_id.
وهناك أيضًا إدخال شائع يسمى message_id سيكون له نفس المعرف لكل إدخال من الرسالة الأصلية ورسالة الأرشيف. أي عناوين cc أو bcc سيكون لها معرف خاص بها لإدخال message_id .
حتى الآن يبدو أن هذا رائع، وبصراحة سهل نسبيًا، لكن الآن الجزء الصعب. تذكر، من أجل الحصول على البريد الإلكتروني الأرشيفي، نطلب من SparkPost إرسال نسخة مكررة من البريد الإلكتروني الأصلي إلى عنوان بريد إلكتروني آخر يتوافق مع صندوق الوارد الذي لديك وصول إليه. لكن من أجل أتمتة هذا الحل وتخزين نص الرسالة، سأستخدم ميزة أخرى من ميزات SparkPost تُسمى تمرير البريد الإلكتروني الوارد. ما تفعله هو تحمل جميع الرسائل الإلكترونية المرسلة إلى مجال محدد ومعالجتها. من خلال معالجتها، تقوم بتفكيك الرسالة الإلكترونية وإنشاء هيكل JSON يتم تسليمه بعد ذلك إلى تطبيق عبر webhook. انظر الملحق أ للحصول على عينة JSON.
إذا نظرت بعناية، ستلاحظ أن هيكل JSON المستخرج من تمرير البريد الوارد يفتقر إلى حقل مهم جدًا؛ وهو transmission_id. بينما تحتوي جميع رسائل البريد الإلكترونية الصادرة على transmission_id مع الإدخال نفسه الذي يربط كل بيانات الرسالة الأصلية، والأرشيف، وعناوين cc، و bcc، فإن SparkPost ليس لديها وسيلة لمعرفة أن الرسالة الإلكترونية الملتقطة عبر عملية الإدخال مرتبطة بأي من الرسائل الإلكترونية الصادرة. ببساطة تعرف عملية الإدخال أنه تم إرسال رسالة إلكترونية إلى مجال محدد وأنه سيتم تحليل الرسالة. هذا هو كل شيء. ستتعامل مع أي بريد إلكتروني يتم إرساله إلى ذلك المجال بنفس الطريقة، سواء كان ردًا من عمييل أو الرسالة الإلكترونية الأرشيفية المرسلة من SparkPost.
لذلك الحيلة هي؛ كيف تقوم بلصق البيانات الصادرة بعملية الإدخال التي Grabbed النسخة الأرشيفية من البريد الإلكتروني؟ ما قررت فعله هو إخفاء معرف فريد في نص الرسالة الإلكترونية. كيف يتم ذلك متروك لك، لكني أنشأت ببساطة حقل إدخال مع تعيين علامة مخفية.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
كما أضفت هذا الحقل إلى كتلة البيانات الوصفية لعناوين X-MSYS-API التي يتم تمريرها إلى SparkPost أثناء الحقن. سيصبح هذا UID المخفي هو الصمغ الذي يربط هذه العملية بأكملها، وهو مكون رئيسي من المشروع وسيتم بحثه بعمق في المدونات التالية.
الآن بعد أن لدينا UID الذي سيلصق هذا المشروع معًا ونعرف لماذا هو ضروري، يمكنني البدء في بناء رؤية المشروع العام والمدونات المقابلة.
التقاط وتخزين البريد الإلكتروني الأرشيفي مع إدخال قاعدة بيانات للبحث/الفهرسة
التقاط جميع بيانات أحداث الرسائل
إنشاء تطبيق لعرض الرسالة الإلكترونية وجميع البيانات المقابلة
إليك رسم بسيط للمشروع:
ستغطي الرمية الأولى من الكود عملية الأرشفة وتخزين الرسالة في S3، بينما ستغطي الرمية الثانية تخزين جميع بيانات السجل من أحداث الرسائل في MySQL. يمكنك توقع الرميات والمدونات الأولى في أوائل عام 2019. إذا كانت لديك أي أسئلة أو اقتراحات، فلا تتردد في تمريرها.
أرسل سعيد.
– جيف
الملحق أ:
قبل عام تقريبًا، كتبت مدونة عن كيفية استرجاع نسخ من الرسائل الإلكترونية للأرشفة والمشاهدة، لكنني لم أتطرق إلى تخزين الرسالة الإلكترونية أو البيانات ذات الصلة، ومؤخراً كتبت مدونة عن تخزين جميع بيانات الأحداث (مثل: متى تم إرسال الرسالة، والفتح، والنقرات، والارتباطات، وعدم الاشتراكات، وما إلى ذلك) على رسالة إلكترونية لغرض التدقيق، لكنني اخترت عدم إنشاء أي كود داعم.
مع زيادة استخدام البريد الإلكتروني في بيئات تنظيمية، قررت أنه حان الوقت لبدء مشروع جديد يجمع كل ذلك مع عينات كود حول كيفية تخزين نص الرسالة الإلكترونية وجميع بياناتها المرتبطة. خلال العام المقبل، سأستمر في بناء هذا المشروع بهدف إنشاء تطبيق لتخزين البريد الإلكتروني وعرض جميع معلومات السجل التي يتم إنتاجها بواسطة SparkPost. لا تمتلك SparkPost نظامًا يقوم بأرشفة نص الرسالة الإلكترونية، لكنها تسهل بناء منصة أرشيفية بشكل جيد.
في سلسلة المدونات هذه، سأصف العملية التي مررت بها من أجل تخزين نص الرسالة الإلكترونية على S3 (خدمة التخزين البسيط من أمازون) وجميع بيانات السجل ذات الصلة في MySQL لسهولة البحث المتقاطع. لأنظمة الأرشفة الإنتاجية التي تتطلب استراتيجيات قوية لنسخ البيانات الاحتياطية، فكر في تنفيذ عملية النسخ الاحتياطي والاستعادة من PostgreSQL لضمان حماية بيانات الأرشفة الخاصة بك بشكل صحيح. في النهاية، هذه هي نقطة البداية لبناء تطبيق سيسمح بالبحث بسهولة عن الرسائل الإلكترونية الأرشيفية، ثم عرض تلك الرسائل إلى جانب بيانات الأحداث (السجل). يمكن العثور على كود هذا المشروع في مستودع GitHub التالي: PHPArchivePlatform على GitHub
ستصف هذه المدخلة الأولى من سلسلة المدونات التحدي وتضع معمارية للحل. ستفصل المدونات المتبقية أجزاء من الحل جنبًا إلى جنب مع عينات الكود.
كانت الخطوة الأولى في عملي هي معرفة كيف كنت سأحصل على نسخة من الرسالة الإلكترونية المرسلة إلى المستلم الأصلي. للحصول على نسخة من نص الرسالة، تحتاج إما إلى:
خيارات التقاط نص الرسالة الإلكترونية
الطريقة | من ينشئ النسخة | تعكس التغييرات في التتبع | ملائمة للتشغيل الآلي | مستخدم في هذا الحل |
|---|---|---|---|---|
التقاط قبل الإرسال | التطبيق | ❌ لا | ✅ نعم | ❌ |
خادم البريد الإلكتروني يخزن النسخة | خادم البريد | ✅ نعم | ❌ محدود | ❌ |
ميزة الأرشيف لـ SparkPost | SparkPost | ✅ نعم | ✅ نعم | ✅ |
التقاط نص الرسالة قبل إرسال الرسالة الإلكترونية
جعل خادم البريد الإلكتروني يخزن نسخة
جعل خادم البريد الإلكتروني ينشئ نسخة لك لتخزينها
إذا كان خادم البريد الإلكتروني يضيف عناصر مثل تتبع الروابط أو تتبع الفتحات، فلا يمكنك استخدام #1 لأنه لن يعكس تغييرات تتبع الفتح/النقر.
هذا يعني أنه يجب على الخادم إما تخزين الرسالة الإلكترونية أو بطريقة ما أن يقدم لك نسخة من تلك الرسالة لتخزينها. نظرًا لأن SparkPost لا تمتلك آلية للتخزين لرسائل البريد الإلكتروني، لكن لديها طريقة لإنشاء نسخة من الرسالة الإلكترونية، سنجعل SparkPost ترسل لنا نسخة من الرسالة الإلكترونية لنخزنها في S3.
يتم ذلك باستخدام ميزة الأرشيف الخاصة بـ SparkPost. تعطي ميزة الأرشيف الخاصة بـ SparkPost للمرسل القدرة على إخبار SparkPost بإرسال نسخة مكررة من الرسالة إلى عنوان بريد إلكتروني واحد أو أكثر واستخدام نفس روابط التتبع والفتح مثل النسخة الأصلية. تعرف وثائق SparkPost ميزة الأرشيف الخاصة بها على النحو التالي:
سيستلم المستلمون في قائمة الأرشيف نسخة مطابقة تمامًا من الرسالة التي تم إرسالها إلى عنوان RCPT TO. على وجه الخصوص، ستكون أي روابط مشفرة مخصصة للمستلم RCPT TO متطابقة في رسائل الأرشيف
الاختلافات الوحيدة عن البريد الإلكتروني RCPT TO هي أن بعض الرؤوس ستكون مختلفة، نظرًا لأن العنوان المستهدف للبريد الإلكتروني الأرشيفي مختلف، لكن نص الرسالة سيكون نسخة مطابقة!
إذا كنت تريد تفسيرًا أعمق، هنا رابط إلى وثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من رسالة إلكترونية.
كتعليق جانبي، تسمح SparkPost في الواقع بإرسال رسائل إلكترونية إلى عناوين بريد cc و bcc والأرشيف. بالنسبة لهذا الحل، نحن نركز على عناوين الأرشيف.
* ملاحظة * يمكن إنشاء الرسائل الإلكترونية الأرشيفية فقط عند إدخال الرسائل الإلكترونية في SparkPost عبر SMTP!
الآن بعد أن عرفنا كيف نحصل على نسخة من الرسالة الأصلية، نحتاج إلى النظر في بيانات السجل التي يتم إنتاجها وبعض الفروق الدقيقة الدقيقة في تلك البيانات. تتبع SparkPost كل شيء يحدث على خوادمها وتقدم لك تلك المعلومات في شكل أحداث الرسائل. يتم تخزين تلك الأحداث على SparkPost لمدة 10 أيام ويمكن سحبها من الخادم عبر واجهة برمجة تطبيقات RESTful تسمى أحداث الرسائل، أو يمكنك أن تجعل SparkPost يدفع تلك الأحداث إلى أي عدد من تطبيقات الجمع التي تريدها. يتم تنفيذ آلية الدفع من خلال webhooks ويتم ذلك في الوقت الفعلي.
حاليًا، هناك 14 حدثًا مختلفًا قد يحدث لرسالة بريد إلكتروني. ها هي قائمة بالأحداث الحالية:
ارتداد
تأخير النقر
تسليم
فشل التوليد
رفض التوليد
فتح أولي
إلغاء الاشتراك من رابط الإدخال
إلغاء الاشتراك من القائمة
فتح
خارج النطاق
رفض السياسة شكوى البريد المزعج
* تابع هذا الرابط للحصول على مرجع محدث لوصف كل حدث جنبًا إلى جنب مع البيانات التي يتم مشاركتها لكل حدث.
كل حدث له العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل transmission_id موجودة في كل حدث، لكن قد تكون الحقول الأخرى أكثر خصوصية للحدث؛ على سبيل المثال، فقط أحداث الفتح والنقر لديها معلومات الترميز الجغرافي.
المحددات المستخدمة في نظام الأرشفة
المحدد | من أين ينشأ | مشترك عبر | الغرض | الحد |
|---|---|---|---|---|
transmission_id | SparkPost الصادرة | الأصلية، الأرشيف، cc، bcc | يربط جميع أحداث الرسائل | غير متوفر في النقل الوارد |
message_id | SparkPost الصادرة | الأصلية + الأرشيف | تحديد الرسائل الفردية | مختلف ل cc/bcc |
معرف مخفي | تم حقنه بواسطة المرسل | الصادرة + الواردة | يربط نص الرسالة الإلكترونية المؤرشف بالأحداث | يجب تنفيذه بشكل مخصص |
مدخل حدث الرسالة المهم جدًا لهذا المشروع هو transmission_id. ستشارك جميع إدخالات أحداث الرسائل للرسالة الأصلية، ورسالة الأرشيف، وأي عناوين cc و bcc نفس transmission_id.
وهناك أيضًا إدخال شائع يسمى message_id سيكون له نفس المعرف لكل إدخال من الرسالة الأصلية ورسالة الأرشيف. أي عناوين cc أو bcc سيكون لها معرف خاص بها لإدخال message_id .
حتى الآن يبدو أن هذا رائع، وبصراحة سهل نسبيًا، لكن الآن الجزء الصعب. تذكر، من أجل الحصول على البريد الإلكتروني الأرشيفي، نطلب من SparkPost إرسال نسخة مكررة من البريد الإلكتروني الأصلي إلى عنوان بريد إلكتروني آخر يتوافق مع صندوق الوارد الذي لديك وصول إليه. لكن من أجل أتمتة هذا الحل وتخزين نص الرسالة، سأستخدم ميزة أخرى من ميزات SparkPost تُسمى تمرير البريد الإلكتروني الوارد. ما تفعله هو تحمل جميع الرسائل الإلكترونية المرسلة إلى مجال محدد ومعالجتها. من خلال معالجتها، تقوم بتفكيك الرسالة الإلكترونية وإنشاء هيكل JSON يتم تسليمه بعد ذلك إلى تطبيق عبر webhook. انظر الملحق أ للحصول على عينة JSON.
إذا نظرت بعناية، ستلاحظ أن هيكل JSON المستخرج من تمرير البريد الوارد يفتقر إلى حقل مهم جدًا؛ وهو transmission_id. بينما تحتوي جميع رسائل البريد الإلكترونية الصادرة على transmission_id مع الإدخال نفسه الذي يربط كل بيانات الرسالة الأصلية، والأرشيف، وعناوين cc، و bcc، فإن SparkPost ليس لديها وسيلة لمعرفة أن الرسالة الإلكترونية الملتقطة عبر عملية الإدخال مرتبطة بأي من الرسائل الإلكترونية الصادرة. ببساطة تعرف عملية الإدخال أنه تم إرسال رسالة إلكترونية إلى مجال محدد وأنه سيتم تحليل الرسالة. هذا هو كل شيء. ستتعامل مع أي بريد إلكتروني يتم إرساله إلى ذلك المجال بنفس الطريقة، سواء كان ردًا من عمييل أو الرسالة الإلكترونية الأرشيفية المرسلة من SparkPost.
لذلك الحيلة هي؛ كيف تقوم بلصق البيانات الصادرة بعملية الإدخال التي Grabbed النسخة الأرشيفية من البريد الإلكتروني؟ ما قررت فعله هو إخفاء معرف فريد في نص الرسالة الإلكترونية. كيف يتم ذلك متروك لك، لكني أنشأت ببساطة حقل إدخال مع تعيين علامة مخفية.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
كما أضفت هذا الحقل إلى كتلة البيانات الوصفية لعناوين X-MSYS-API التي يتم تمريرها إلى SparkPost أثناء الحقن. سيصبح هذا UID المخفي هو الصمغ الذي يربط هذه العملية بأكملها، وهو مكون رئيسي من المشروع وسيتم بحثه بعمق في المدونات التالية.
الآن بعد أن لدينا UID الذي سيلصق هذا المشروع معًا ونعرف لماذا هو ضروري، يمكنني البدء في بناء رؤية المشروع العام والمدونات المقابلة.
التقاط وتخزين البريد الإلكتروني الأرشيفي مع إدخال قاعدة بيانات للبحث/الفهرسة
التقاط جميع بيانات أحداث الرسائل
إنشاء تطبيق لعرض الرسالة الإلكترونية وجميع البيانات المقابلة
إليك رسم بسيط للمشروع:
ستغطي الرمية الأولى من الكود عملية الأرشفة وتخزين الرسالة في S3، بينما ستغطي الرمية الثانية تخزين جميع بيانات السجل من أحداث الرسائل في MySQL. يمكنك توقع الرميات والمدونات الأولى في أوائل عام 2019. إذا كانت لديك أي أسئلة أو اقتراحات، فلا تتردد في تمريرها.
أرسل سعيد.
– جيف
الملحق أ:
قبل عام تقريبًا، كتبت مدونة عن كيفية استرجاع نسخ من الرسائل الإلكترونية للأرشفة والمشاهدة، لكنني لم أتطرق إلى تخزين الرسالة الإلكترونية أو البيانات ذات الصلة، ومؤخراً كتبت مدونة عن تخزين جميع بيانات الأحداث (مثل: متى تم إرسال الرسالة، والفتح، والنقرات، والارتباطات، وعدم الاشتراكات، وما إلى ذلك) على رسالة إلكترونية لغرض التدقيق، لكنني اخترت عدم إنشاء أي كود داعم.
مع زيادة استخدام البريد الإلكتروني في بيئات تنظيمية، قررت أنه حان الوقت لبدء مشروع جديد يجمع كل ذلك مع عينات كود حول كيفية تخزين نص الرسالة الإلكترونية وجميع بياناتها المرتبطة. خلال العام المقبل، سأستمر في بناء هذا المشروع بهدف إنشاء تطبيق لتخزين البريد الإلكتروني وعرض جميع معلومات السجل التي يتم إنتاجها بواسطة SparkPost. لا تمتلك SparkPost نظامًا يقوم بأرشفة نص الرسالة الإلكترونية، لكنها تسهل بناء منصة أرشيفية بشكل جيد.
في سلسلة المدونات هذه، سأصف العملية التي مررت بها من أجل تخزين نص الرسالة الإلكترونية على S3 (خدمة التخزين البسيط من أمازون) وجميع بيانات السجل ذات الصلة في MySQL لسهولة البحث المتقاطع. لأنظمة الأرشفة الإنتاجية التي تتطلب استراتيجيات قوية لنسخ البيانات الاحتياطية، فكر في تنفيذ عملية النسخ الاحتياطي والاستعادة من PostgreSQL لضمان حماية بيانات الأرشفة الخاصة بك بشكل صحيح. في النهاية، هذه هي نقطة البداية لبناء تطبيق سيسمح بالبحث بسهولة عن الرسائل الإلكترونية الأرشيفية، ثم عرض تلك الرسائل إلى جانب بيانات الأحداث (السجل). يمكن العثور على كود هذا المشروع في مستودع GitHub التالي: PHPArchivePlatform على GitHub
ستصف هذه المدخلة الأولى من سلسلة المدونات التحدي وتضع معمارية للحل. ستفصل المدونات المتبقية أجزاء من الحل جنبًا إلى جنب مع عينات الكود.
كانت الخطوة الأولى في عملي هي معرفة كيف كنت سأحصل على نسخة من الرسالة الإلكترونية المرسلة إلى المستلم الأصلي. للحصول على نسخة من نص الرسالة، تحتاج إما إلى:
خيارات التقاط نص الرسالة الإلكترونية
الطريقة | من ينشئ النسخة | تعكس التغييرات في التتبع | ملائمة للتشغيل الآلي | مستخدم في هذا الحل |
|---|---|---|---|---|
التقاط قبل الإرسال | التطبيق | ❌ لا | ✅ نعم | ❌ |
خادم البريد الإلكتروني يخزن النسخة | خادم البريد | ✅ نعم | ❌ محدود | ❌ |
ميزة الأرشيف لـ SparkPost | SparkPost | ✅ نعم | ✅ نعم | ✅ |
التقاط نص الرسالة قبل إرسال الرسالة الإلكترونية
جعل خادم البريد الإلكتروني يخزن نسخة
جعل خادم البريد الإلكتروني ينشئ نسخة لك لتخزينها
إذا كان خادم البريد الإلكتروني يضيف عناصر مثل تتبع الروابط أو تتبع الفتحات، فلا يمكنك استخدام #1 لأنه لن يعكس تغييرات تتبع الفتح/النقر.
هذا يعني أنه يجب على الخادم إما تخزين الرسالة الإلكترونية أو بطريقة ما أن يقدم لك نسخة من تلك الرسالة لتخزينها. نظرًا لأن SparkPost لا تمتلك آلية للتخزين لرسائل البريد الإلكتروني، لكن لديها طريقة لإنشاء نسخة من الرسالة الإلكترونية، سنجعل SparkPost ترسل لنا نسخة من الرسالة الإلكترونية لنخزنها في S3.
يتم ذلك باستخدام ميزة الأرشيف الخاصة بـ SparkPost. تعطي ميزة الأرشيف الخاصة بـ SparkPost للمرسل القدرة على إخبار SparkPost بإرسال نسخة مكررة من الرسالة إلى عنوان بريد إلكتروني واحد أو أكثر واستخدام نفس روابط التتبع والفتح مثل النسخة الأصلية. تعرف وثائق SparkPost ميزة الأرشيف الخاصة بها على النحو التالي:
سيستلم المستلمون في قائمة الأرشيف نسخة مطابقة تمامًا من الرسالة التي تم إرسالها إلى عنوان RCPT TO. على وجه الخصوص، ستكون أي روابط مشفرة مخصصة للمستلم RCPT TO متطابقة في رسائل الأرشيف
الاختلافات الوحيدة عن البريد الإلكتروني RCPT TO هي أن بعض الرؤوس ستكون مختلفة، نظرًا لأن العنوان المستهدف للبريد الإلكتروني الأرشيفي مختلف، لكن نص الرسالة سيكون نسخة مطابقة!
إذا كنت تريد تفسيرًا أعمق، هنا رابط إلى وثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من رسالة إلكترونية.
كتعليق جانبي، تسمح SparkPost في الواقع بإرسال رسائل إلكترونية إلى عناوين بريد cc و bcc والأرشيف. بالنسبة لهذا الحل، نحن نركز على عناوين الأرشيف.
* ملاحظة * يمكن إنشاء الرسائل الإلكترونية الأرشيفية فقط عند إدخال الرسائل الإلكترونية في SparkPost عبر SMTP!
الآن بعد أن عرفنا كيف نحصل على نسخة من الرسالة الأصلية، نحتاج إلى النظر في بيانات السجل التي يتم إنتاجها وبعض الفروق الدقيقة الدقيقة في تلك البيانات. تتبع SparkPost كل شيء يحدث على خوادمها وتقدم لك تلك المعلومات في شكل أحداث الرسائل. يتم تخزين تلك الأحداث على SparkPost لمدة 10 أيام ويمكن سحبها من الخادم عبر واجهة برمجة تطبيقات RESTful تسمى أحداث الرسائل، أو يمكنك أن تجعل SparkPost يدفع تلك الأحداث إلى أي عدد من تطبيقات الجمع التي تريدها. يتم تنفيذ آلية الدفع من خلال webhooks ويتم ذلك في الوقت الفعلي.
حاليًا، هناك 14 حدثًا مختلفًا قد يحدث لرسالة بريد إلكتروني. ها هي قائمة بالأحداث الحالية:
ارتداد
تأخير النقر
تسليم
فشل التوليد
رفض التوليد
فتح أولي
إلغاء الاشتراك من رابط الإدخال
إلغاء الاشتراك من القائمة
فتح
خارج النطاق
رفض السياسة شكوى البريد المزعج
* تابع هذا الرابط للحصول على مرجع محدث لوصف كل حدث جنبًا إلى جنب مع البيانات التي يتم مشاركتها لكل حدث.
كل حدث له العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل transmission_id موجودة في كل حدث، لكن قد تكون الحقول الأخرى أكثر خصوصية للحدث؛ على سبيل المثال، فقط أحداث الفتح والنقر لديها معلومات الترميز الجغرافي.
المحددات المستخدمة في نظام الأرشفة
المحدد | من أين ينشأ | مشترك عبر | الغرض | الحد |
|---|---|---|---|---|
transmission_id | SparkPost الصادرة | الأصلية، الأرشيف، cc، bcc | يربط جميع أحداث الرسائل | غير متوفر في النقل الوارد |
message_id | SparkPost الصادرة | الأصلية + الأرشيف | تحديد الرسائل الفردية | مختلف ل cc/bcc |
معرف مخفي | تم حقنه بواسطة المرسل | الصادرة + الواردة | يربط نص الرسالة الإلكترونية المؤرشف بالأحداث | يجب تنفيذه بشكل مخصص |
مدخل حدث الرسالة المهم جدًا لهذا المشروع هو transmission_id. ستشارك جميع إدخالات أحداث الرسائل للرسالة الأصلية، ورسالة الأرشيف، وأي عناوين cc و bcc نفس transmission_id.
وهناك أيضًا إدخال شائع يسمى message_id سيكون له نفس المعرف لكل إدخال من الرسالة الأصلية ورسالة الأرشيف. أي عناوين cc أو bcc سيكون لها معرف خاص بها لإدخال message_id .
حتى الآن يبدو أن هذا رائع، وبصراحة سهل نسبيًا، لكن الآن الجزء الصعب. تذكر، من أجل الحصول على البريد الإلكتروني الأرشيفي، نطلب من SparkPost إرسال نسخة مكررة من البريد الإلكتروني الأصلي إلى عنوان بريد إلكتروني آخر يتوافق مع صندوق الوارد الذي لديك وصول إليه. لكن من أجل أتمتة هذا الحل وتخزين نص الرسالة، سأستخدم ميزة أخرى من ميزات SparkPost تُسمى تمرير البريد الإلكتروني الوارد. ما تفعله هو تحمل جميع الرسائل الإلكترونية المرسلة إلى مجال محدد ومعالجتها. من خلال معالجتها، تقوم بتفكيك الرسالة الإلكترونية وإنشاء هيكل JSON يتم تسليمه بعد ذلك إلى تطبيق عبر webhook. انظر الملحق أ للحصول على عينة JSON.
إذا نظرت بعناية، ستلاحظ أن هيكل JSON المستخرج من تمرير البريد الوارد يفتقر إلى حقل مهم جدًا؛ وهو transmission_id. بينما تحتوي جميع رسائل البريد الإلكترونية الصادرة على transmission_id مع الإدخال نفسه الذي يربط كل بيانات الرسالة الأصلية، والأرشيف، وعناوين cc، و bcc، فإن SparkPost ليس لديها وسيلة لمعرفة أن الرسالة الإلكترونية الملتقطة عبر عملية الإدخال مرتبطة بأي من الرسائل الإلكترونية الصادرة. ببساطة تعرف عملية الإدخال أنه تم إرسال رسالة إلكترونية إلى مجال محدد وأنه سيتم تحليل الرسالة. هذا هو كل شيء. ستتعامل مع أي بريد إلكتروني يتم إرساله إلى ذلك المجال بنفس الطريقة، سواء كان ردًا من عمييل أو الرسالة الإلكترونية الأرشيفية المرسلة من SparkPost.
لذلك الحيلة هي؛ كيف تقوم بلصق البيانات الصادرة بعملية الإدخال التي Grabbed النسخة الأرشيفية من البريد الإلكتروني؟ ما قررت فعله هو إخفاء معرف فريد في نص الرسالة الإلكترونية. كيف يتم ذلك متروك لك، لكني أنشأت ببساطة حقل إدخال مع تعيين علامة مخفية.
<input name="ArchiveCode" type="hidden" value="<<UID>>">
كما أضفت هذا الحقل إلى كتلة البيانات الوصفية لعناوين X-MSYS-API التي يتم تمريرها إلى SparkPost أثناء الحقن. سيصبح هذا UID المخفي هو الصمغ الذي يربط هذه العملية بأكملها، وهو مكون رئيسي من المشروع وسيتم بحثه بعمق في المدونات التالية.
الآن بعد أن لدينا UID الذي سيلصق هذا المشروع معًا ونعرف لماذا هو ضروري، يمكنني البدء في بناء رؤية المشروع العام والمدونات المقابلة.
التقاط وتخزين البريد الإلكتروني الأرشيفي مع إدخال قاعدة بيانات للبحث/الفهرسة
التقاط جميع بيانات أحداث الرسائل
إنشاء تطبيق لعرض الرسالة الإلكترونية وجميع البيانات المقابلة
إليك رسم بسيط للمشروع:
ستغطي الرمية الأولى من الكود عملية الأرشفة وتخزين الرسالة في S3، بينما ستغطي الرمية الثانية تخزين جميع بيانات السجل من أحداث الرسائل في MySQL. يمكنك توقع الرميات والمدونات الأولى في أوائل عام 2019. إذا كانت لديك أي أسئلة أو اقتراحات، فلا تتردد في تمريرها.
أرسل سعيد.
– جيف
الملحق أ:
