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

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

في هذه السلسلة من المدونات، سأصف العملية التي مررت بها من أجل تخزين محتوى البريد الإلكتروني على S3 (خدمة التخزين البسيط من Amazon) وكل بيانات السجل ذات الصلة في MySQL لسهولة الاسترجاع المتبادل.  في نهاية المطاف، هذه هي نقطة الانطلاق لبناء تطبيق يسمح بالبحث السهل عن رسائل البريد الإلكتروني المؤرشفة، ثم عرض تلك الرسائل مع بيانات الحدث (السجل). يمكن العثور على الكود لهذا المشروع في مستودع GitHub التالي: https://github.com/jeff-goldstein/PHPArchivePlatform

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

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

1. التقاط محتوى البريد الإلكتروني قبل إرسال البريد الإلكتروني

2. جعل خادم البريد الإلكتروني يخزن نسخة

3. جعل خادم البريد الإلكتروني ينشئ نسخة لتخزينها
   
   

إذا كان خادم البريد الإلكتروني يضيف عناصر مثل تتبع الروابط أو تتبع الفتحات، لا يمكنك استخدام #1 لأنه لن يعكس التغييرات في تتبع الفتح/النقر.

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

يتم ذلك باستخدام ميزة الأرشيف الخاصة بـ SparkPost. تمنح ميزة الأرشيف في SparkPost المرسل القدرة على إخبار SparkPost بإرسال نسخة مكررة من البريد الإلكتروني إلى عنوان بريد إلكتروني واحد أو أكثر واستخدام نفس روابط التتبع والفتح كما في الأصل. تعرف وثائق SparkPost ميزة الأرشيف في النحو التالي:

سيتلقى المستلمون في قائمة الأرشيف نسخة مطابقة تمامًا للرسالة المرسلة إلى عنوان RCPT TO . وعلى وجه الخصوص، أي روابط مشفرة مخصصة لمستلم RCPT TO ستكون متطابقة في رسائل الأرشيف

الاختلافات الوحيدة عن بريد RCPT TO الإلكتروني هي أن بعض الرؤوس ستكون مختلفة نظرًا لأن عنوان الهدف للبريد الأرشيفي مختلف، لكن محتوى البريد الإلكتروني سيكون نسخة مطابقة تمامًا!

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

كملاحظة جانبية، يسمح SparkPost بالفعل بإرسال رسائل البريد الإلكتروني إلى عنوان cc، bcc، وعناوين الأرشيف. بالنسبة لهذا الحل، نركز على عناوين الأرشيف.

* ملاحظة * لا يمكن إنشاء رسائل بريد إلكتروني مؤرشفة إلا عند حقن رسائل البريد الإلكتروني في SparkPost عبر SMTP!

الآن بعد أن نعرف كيف نحصل على نسخة من البريد الإلكتروني الأصلي، نحتاج إلى النظر في بيانات السجل التي يتم إنتاجها وبعض التفاصيل الدقيقة في تلك البيانات. يتتبع SparkPost كل ما يحدث على خوادمه ويقدم تلك المعلومات لك على شكل رسائل أحداث. يتم تخزين تلك الأحداث على SparkPost لمدة 10 أيام ويمكن سحبها من الخادم عبر واجهة برمجة تطبيقات RESTful تسمى message-events، أو يمكنك أن تطلب من SparkPost نقل تلك الأحداث إلى أي عدد من تطبيقات التجميع التي ترغب فيها.  تمت عملية النقل عبر الويب وتمت في الوقت الفعلي.

حاليًا، هناك 14 حدثا مختلفا قد يحدث لبريد إلكتروني.  هنا قائمة بالأحداث الحالية:

• ارتداد

• ClickDelay

• التسليم

• فشل التوليد

• رفض التوليد

• الفتح الأولي

• إلغاء الاشتراك برابط الحقن

• إلغاء الاشتراك من القائمة

• فتح

• خارج النطاق

• رفض السياسة - شكوى من الرسائل الاقتحامية

  
  

* اتبع هذا الرابط للحصول على دليل مرجعي محدث لوصف كل حدث جنبًا إلى جنب مع البيانات المشتركة لكل حدث.

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

إدخال الحدث الرسالي المهم جدًا لهذا المشروع هو transmission_id. ستشارك جميع إدخالات الأحداث الرسالية للبريد الإلكتروني الأصلي، البريد الإلكتروني المؤرشف، وأي عناوين cc وbcc نفس transmission_id.

هناك أيضًا إدخال مشترك يسمى message_id الذي سيكون لديه نفس المعرف لكل إدخال للبريد الإلكتروني الأصلي والبريد الإلكتروني المؤرشف. سيكون لأي عناوين cc أو bcc معرفها الخاص لإدخال message_id.

حتى الآن، يبدو هذا رائعًا وبصراحة سهل للغاية، لكن الآن هو الجزء الصعب. تذكر، من أجل الحصول على البريد الإلكتروني المؤرشف، نطلب من SparkPost إرسال نسخة مكررة من البريد الإلكتروني الأصلي إلى عنوان بريد إلكتروني آخر يتوافق مع صندوق بريد لديك حق الوصول إليه. لكن من أجل أتمتة هذا الحل وتخزين محتوى البريد الإلكتروني، سأستخدم ميزة أخرى لـ SparkPost تسمى Inbound Email Relaying. ما يفعله هو التعامل مع جميع رسائل البريد الإلكتروني المرسلة إلى نطاق محدد ومعالجتها. وعن طريق معالجتها، يتم تفكيك البريد الإلكتروني وإنشاء هيكل JSON يتم إرساله بعد ذلك إلى تطبيق عبر webhook. راجع الملحق A لمثال JSON.

إذا نظرت بعناية، ستلاحظ أن هيكل JSON الوارد يخلو من حقل مهم جداً؛ هو transmission_id. بينما تحتوي جميع رسائل البريد الإلكتروني الصادرة على transmission_id بنفس الإدخال الذي يربط جميع البيانات من البريد الإلكتروني الأصلي، الأرشيفي، و عناوين cc وbcc ، لا يعرف SparkPost كيفية معرفة أن البريد الإلكتروني الملتقط بالعملية الواصلة مرتبط بأي من رسائل البريد الإلكتروني الصادرة. العملية الواصلة ببساطة تعرف أنه تم إرسال بريد إلكتروني إلى نطاق محدد لفك البريد الإلكتروني. هذا هو كل ما في الأمر. ستعامل أي بريد إلكتروني مرسل إلى ذلك النطاق بنفس الطريقة، سواء كان ردًا من عميل أو بريد الأرشيف المرسل من SparkPost.

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

<input name="ArchiveCode" type="hidden" value="<<UID>>">

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

الآن وبعد أن لدينا الـ UID الذي سيربط هذا المشروع معًا ونفهم لماذا هو ضروري، يمكنني أن أبدأ في بناء الرؤية للمشروع الكامل والمدونات المصاحبة له.

1. التقاط وتخزين بريد الأرشفة مع إدخال قاعدة بيانات للبحث/الفهرسة

2. التقاط كل بيانات الحدث الرسالي

3. إنشاء تطبيق لعرض البريد الإلكتروني وجميع البيانات المرتبطة

   
   

هنا رسم بياني بسيط للمشروع:

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

إرسال سعيد.

– جيف

الملحق A: