مع زيادة استخدام البريد الإلكتروني في البيئات التنظيمية، قررت أنه حان الوقت لبدء مشروع جديد يجمع كل هذا معًا مع أمثلة برمجية حول كيفية تخزين محتوى البريد الإلكتروني وجميع البيانات المرتبطة به.
منذ حوالي عام كتبت مدونة حول كيفية استرجاع نسخ من رسائل البريد الإلكتروني لأغراض الأرشفة والمشاهدة ولكنني لم أتطرق إلى تخزين الرسالة الإلكترونية أو البيانات المرتبطة، ومؤخرًا كتبت مدونة عن تخزين جميع بيانات الأحداث (أي عندما تم إرسال البريد الإلكتروني، الفتح، النقرات، الارتداد، إلغاء الاشتراك، إلخ) على بريد إلكتروني لغرض التدقيق، لكنني اخترت عدم إنشاء أي كود داعم.
مع زيادة استخدام البريد الإلكتروني في بيئات التنظيم، قررت أن الوقت قد حان لبدء مشروع جديد يجمع كل ذلك مع عينة من الأكواد حول كيفية تخزين جسم البريد الإلكتروني وجميع بياناته المترابطة. على مدار العام المقبل، سأستمر في بناء هذا المشروع بهدف إنشاء تطبيق عملي لتخزين وعرض رسائل البريد الإلكتروني المؤرشفة وجميع معلومات السجل التي تنتجها SparkPost. لا تمتلك SparkPost نظامًا يؤرشف جسم البريد الإلكتروني ولكنه يجعل بناء منصة أرشفة أمرًا سهلاً إلى حد ما.
في سلسلة المدونات هذه، سأصف العملية التي مررت بها من أجل تخزين جسم البريد الإلكتروني على S3 (خدمة التخزين البسيطة من أمازون) وجميع بيانات السجل ذات الصلة في MySQL لسهولة الرجوع المتبادل. بالنسبة لأنظمة الأرشفة الإنتاجية التي تتطلب استراتيجيات النسخ الاحتياطي الشاملة للقاعدة البيانات، فكر في تنفيذ عملية النسخ الاحتياطي والاستعادة في PostgreSQL لضمان حماية بيانات الأرشيف الخاصة بك بشكل صحيح. في النهاية، هذه هي نقطة البداية لبناء تطبيق سيسمح بالبحث السهل عن رسائل البريد الإلكتروني المؤرشفة، ثم عرض تلك الرسائل مع بيانات الحدث (السجل). يمكن العثور على كود هذا المشروع في مستودع GitHub التالي: https://github.com/jeff-goldstein/PHPArchivePlatform
ستصف هذه المدخلة الأولى من سلسلة المدونات التحدي وتضع هندسة للحل. وستتفصل بقية المدونات في أجزاء من الحل مع عينة من الأكواد.
كانت الخطوة الأولى في عمليتي هي معرفة كيفية الحصول على نسخة من البريد الإلكتروني المُرسل إلى المستلم الأصلي. للحصول على نسخة من جسم البريد الإلكتروني، تحتاج إما إلى:
التقاط جسم البريد الإلكتروني قبل إرسال البريد
الحصول على خادم البريد الإلكتروني لتخزين نسخة
جعل خادم البريد الإلكتروني ينشئ نسخة لك لتخزينها
إذا كان خادم البريد الإلكتروني يضيف عناصر مثل تتبع الروابط أو تتبع الفتحات، فلا يمكنك استخدام الخيار #1 لأنه لن يعكس تغيرات تتبع الفتح/النقر.
هذا يعني أنه إما يجب على الخادم أن يخزن البريد الإلكتروني أو بطريقة ما يوفر لك نسخة من هذا البريد لتخزينها. نظرًا لأن SparkPost لا تمتلك آلية تخزين لجسم البريد الإلكتروني ولكنها تمتلك طريقة لإنشاء نسخة من البريد الإلكتروني، فسنطلب من SparkPost إرسال نسخة مكررة من البريد الإلكتروني لنا لنقوم بتخزينها في S3.
يتم ذلك باستخدام ميزة الأرشيف من SparkPost. تقدم ميزة الأرشيف في SparkPost للمرسل القدرة على إبلاغ SparkPost بإرسال نسخة مكررة من البريد الإلكتروني إلى عنوان واحد أو أكثر واستخدام نفس روابط التتبع والفتح كالأصلية. تحدد وثائق SparkPost ميزة الأرشيف بالطريقة التالية:
سيحصل المستلمون في قائمة الأرشيف على نسخة مطابقة للرسالة التي تم إرسالها إلى عنوان RCPT TO. على وجه الخصوص، ستكون أي روابط مشفرة مخصصة لمتلقي RCPT TO متطابقة في رسائل الأرشيف
الاختلافات الوحيدة عن البريد الإلكتروني RCPT TO هي أن بعض الرؤوس ستكون مختلفة حيث أن العنوان المستهدف لبريد الأرشفة مختلف، لكن جسم البريد الإلكتروني سيكون مطابقًا تمامًا!
إذا كنت تريد تفسيرًا أعمق هنا رابط إلى وثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيفية) من البريد الإلكتروني.
كنقطة جانبية، يمكن لـ SparkPost بالفعل إرسال رسائل البريد الإلكتروني إلى cc، bcc، وعناوين البريد الأرشيفية. لهذه الحل، نحن نركز على عناوين الأرشيف.
* ملاحظة * يمكن إنشاء رسائل البريد الإلكتروني المؤرشفة فقط عند حقن البريد الإلكتروني في SparkPost عبر SMTP!
الآن بعد أن عرفنا كيفية الحصول على نسخة من البريد الإلكتروني الأصلي، نحتاج إلى النظر في بيانات السجل التي تم إنتاجها وبعض الفروق الدقيقة داخل تلك البيانات. يتتبع SparkPost كل ما يحدث على الخوادم الخاصة به ويعرض تلك المعلومات لك في شكل أحداث الرسائل. يتم تخزين تلك الأحداث على SparkPost لمدة 10 أيام ويمكن سحبها من الخادم عبر واجهة API RESTful تسمى أحداث الرسائل، أو يمكنك أن تجعل SparkPost يدفع تلك الأحداث إلى أي عدد ترغب من التطبيقات التجميعية. تتم آلية الدفع عبر webhooks وهي في الوقت الحقيقي.
حاليًا، هناك 14 حدثًا مختلفًا قد يحدث لبريد إلكتروني. فيما يلي قائمة بالأحداث الحالية:
ارتداد
ClickDelay
التسليم
فشل التوليد
رفض التوليد
الفتح الأولي
إلغاء الاشتراك من الرابط الإقحامي
إلغاء الاشتراك من القائمة
فتح
خارج الشريط
سياسة الرفض و شكوى البريد المزعج
* اتبع هذا الرابط للحصول على دليل مرجعي مُحدث لوصف كل حدث مع البيانات التي تتم مشاركتها لكل حدث.
كل حدث يحتوي على العديد من الحقول التي تتناسب مع نوع الحدث. بعض الحقول مثل transmission_id توجد في كل حدث، ولكن الحقول الأخرى قد تكون أكثر تحديدًا لبعض الأحداث؛ على سبيل المثال، تحتوي فقط أحداث الفتح والنقر على معلومات تحديد الجغرافيا.
واحدة من الرسائل الحدثية الهامة جدًا لهذا المشروع هي 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.
لذلك الحيلة هي؛ كيف تدمج البيانات الصادرة مع العملية الواردة التي التقطت للتو النسخة المؤرشفة من البريد الإلكتروني؟ ما قررت القيام به هو إخفاء معرف فريد في جسم البريد الإلكتروني. كيف يتم ذلك متروك لك، لكنني ببساطة قمت بإنشاء حقل إدخال مع إيقاف العلامة المخفية.
كما أضفت ذلك الحقل إلى كتلة البيانات الوصفية في رأس X-MSYS-API الذي يتم تمريره إلى SparkPost أثناء الإرسال. سينتهي الأمر إلى أن يكون هذا المعرف المخفي الواجهة للكل العملية، وهو المكون الرئيسي للمشروع وسيتم مناقشته بعمق في المشاركات المدونة التالية.
الآن بعد أن حصلنا على المعرف الفريد الذي سيربط هذا المشروع سويًا وفهم سبب ضرورته، يمكنني البدء في بناء رؤية المشروع الكلي والمشاركات المدونة المقابلة.
التقاط وتخزين البريد الإلكتروني المؤرشف إلى جانب إدخال قاعدة بيانات للبحث/الفهرسة
التقاط جميع بيانات أحداث الرسائل
إنشاء تطبيق لعرض البريد الإلكتروني وجميع البيانات المترابطة
إليك رسم بياني بسيط للمشروع:
ستغطي أول دفعة من الكود عملية الأرشيف وتخزين البريد الإلكتروني على S3، بينما ستغطي الدفعة الثانية من الكود تخزين جميع بيانات السجل من الأحداث الرسائلية في MySQL. يمكنك توقع أول دفعتين من الأكواد ودخول المدونة في أوائل عام 2019. إذا كان لديك أي أسئلة أو اقتراحات، لا تتردد في نشرها.
إرسال سعيد.
– جيف
الملحق أ:
