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

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

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

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

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

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

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

3. أن يقوم خادم البريد الإلكتروني بإنشاء نسخة لك لتخزينها
   
   

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

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

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

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

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

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

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

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

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

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

• ارتداد

• تأخير النقرة

• تسليم

• فشل التوليد

• رفض التوليد

• فتح أولي

• إلغاء الاشتراك عبر الرابط

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

• فتح

• خارج النطاق

• رفض السياسة

• 
  

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

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

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

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

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

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

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

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

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

الآن بعد أن عرفناه، يمكننا بدء بناء رؤية المشروع بالكامل ومشاركات المدونة المقابلة.

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

2. التقاط جميع بيانات أحداث الرسائل

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

   
   

فيما يلي مخطط بسيط للمشروع:

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

إرسال سعيد.

– جيف

الملحق أ: