بناء نظام أرشفة البريد الإلكتروني: التحديات وبالطبع الحل – الجزء 1

جيف غولدستين

04‏/02‏/2019

البريد الإلكتروني

1 min read

بناء نظام أرشفة البريد الإلكتروني: التحديات وبالطبع الحل – الجزء 1

النقاط الرئيسية

    • أصبح أرشفة البريد الإلكتروني أمرًا ضروريًا بشكل متزايد في البيئات التنظيمية والامتثال والتدقيق.

    • لا يقوم SparkPost بتخزين محتويات البريد الإلكتروني، ولكن تتيح ميزة الأرشيف للمرسلين تلقي رسائل مكررة تعكس الروابط والرسائل التتبعية.

    • يمكن تخزين محتويات البريد الإلكتروني في Amazon S3، بينما يمكن تخزين بيانات أحداث الرسائل في MySQL للاستعلام والمراجع المتقاطعة.

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

    • يتم إنشاء نسخ الأرشيف فقط عند إرسال البريد الإلكتروني عبر SMTP.

    • تشارك أحداث الرسائل للبريد الأصلي، الأرشيف، CC، و BCC معرف transmission_id مشترك.

    • يمكن لميزة Inbound Email Relay استيعاب الرسائل المؤرشفة ولكنها لا تتضمن transmission_id، مما يخلق تحدي ربط البيانات.

    • يسد تضمين معرف فريد مخفي (UID) في جسد الرسالة تلك الفجوة ويربط المحتوى الوارد بسجلات الخارج.

    • يتيح الجمع بين رسائل البريد المؤرشفة + أحداث الرسائل بناء نظام أرشفة قابل للبحث والتدقيق.

    • يشمل المشروع الطويل المدى إصدارات الأكواد لتخزين رسائل الأرشيف في S3 وتسجيل بيانات الحدث في MySQL.

    • سيسمح التطبيق النهائي بالبحث بسهولة، وعرض، وتسوية محتوى البريد الإلكتروني مع جميع التاريخ المتعلق بالأحداث.

    • مثالي للصناعات التي تتطلب امتثالًا صارمًا وتحتاج إلى رؤية كاملة لكل رسالة مرسلة.

أبرز الأسئلة والأجوبة

  • لماذا تقوم ببناء نظام أرشفة البريد الإلكتروني الخاص بك؟

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

  • كيف يمكنك الحصول على نسخة مطابقة من البريد الإلكتروني الأصلي المرسل؟

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

  • لماذا لا يمكنك التقاط نص البريد الإلكتروني قبل الإرسال؟

    الالتقاط المسبق لا يتضمن تعديلات SparkPost (تتبع الفتح، تتبع النقر، ترميز الروابط). استخدام نسخ الأرشيف يضمن أن النسخة المحفوظة لديك تطابق تمامًا ما يتلقاه المستلمون.

  • هل يقوم SparkPost بأرشفة الرسائل تلقائيًا؟

    لا، SparkPost لا يخزن محتويات الرسائل. يجب طلب نسخ الأرشيف عن طريق تحديد عناوين الأرشيف أثناء إدخال SMTP.

  • ما الذي يتم تخزينه وأين في نظام الأرشفة هذا؟

    • محتوى البريد الإلكتروني → Amazon S3

    • سجلات أحداث الرسائل → MySQL
      هذا الفصل يدعم البحث السريع والاستعلامات المنظمة وتخزين الكائنات منخفض التكلفة.

  • إلى متى تحتفظ SparkPost ببيانات الحدث؟

    يقوم SparkPost بتخزين أحداث الرسائل لمدة 10 أيام. بعد ذلك، يجب تناول البيانات عبر ويب هوك أو استعلامها وتخزينها في مكان آخر.

  • ما هي أنواع الرسائل المتاحة؟

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

  • ما هي المُعرفات التي تربط جميع الأحداث معًا؟

    تشارك جميع الرسائل الصادرة (الأصلية، الأرشيف، CC، BCC) نفس transmission_id. كما تشارك الرسائل الأصلية والأرشيف نفس message_id.

  • لماذا تكون معالجة البيانات الواردة تحديًا؟

    تحويل البريد الإلكتروني الوارد في SparkPost إلى JSON، ولكن هذا JSON لا يحتوي على transmission_id. بدون بيانات إضافية، لا يمكن ربط النسخة الواردة بسجل السجل الخارج.

  • كيف تقوم بربط رسائل الأرشيف الواردة بأحداث الرسائل الصادرة؟

    أضف معرفًا فريدًا (UID) مخفيًا في نص البريد الإلكتروني ومرر نفس UID في البيانات الوصفية. يصبح هذا UID مرجعًا مشتركًا عبر السجلات الواردة والصادرة.

  • كيف تساعد خدمة Inbound Email Relay في أتمتة الأرشفة؟

    يتلقى رسائل الأرشيف المرسلة إلى نطاق الأرشيف الخاص بك، ويحللها إلى JSON منظم، ويرسلها إلى التطبيق الخاص بك عبر webhook—مما يسمح بالاستخلاص والتخزين التلقائي.

  • ما هي الرؤية طويلة المدى للمشروع؟

    تطبيق كامل يقوم ب:

    • تخزين رسائل البريد الإلكتروني المؤرشفة في S3

    • تخزين جميع سجلات الأحداث في MySQL

    • يسمح للمستخدمين بالبحث عن رسائل البريد الإلكتروني

    • عرض البريد الإلكتروني الأصلي وكل حدث مرتبط في واجهة موحدة واحدة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ارتداد

  • تأخير النقر

  • تسليم

  • فشل التوليد

  • رفض التوليد

  • فتح مبكر

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

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

  • فتح

  • خارج النطاق

  • رفض السياسة الشكوى من الرسائل الغير مرغوب فيها


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

كل حدث لديه العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل 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.

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

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

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

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

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

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

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

إليك رسمًا بسيطًا للمشروع:

build an email archiving system - diagram


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

إرسال سعيد.
– جيف


ملحق أ:

JSON file example - email archiving system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ارتداد

  • تأخير النقر

  • تسليم

  • فشل التوليد

  • رفض التوليد

  • فتح مبكر

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

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

  • فتح

  • خارج النطاق

  • رفض السياسة الشكوى من الرسائل الغير مرغوب فيها


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

كل حدث لديه العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل 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.

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

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

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

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

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

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

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

إليك رسمًا بسيطًا للمشروع:

build an email archiving system - diagram


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

إرسال سعيد.
– جيف


ملحق أ:

JSON file example - email archiving system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ارتداد

  • تأخير النقر

  • تسليم

  • فشل التوليد

  • رفض التوليد

  • فتح مبكر

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

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

  • فتح

  • خارج النطاق

  • رفض السياسة الشكوى من الرسائل الغير مرغوب فيها


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

كل حدث لديه العديد من الحقول التي تتطابق مع نوع الحدث. بعض الحقول مثل 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.

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

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

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

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

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

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

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

إليك رسمًا بسيطًا للمشروع:

build an email archiving system - diagram


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

إرسال سعيد.
– جيف


ملحق أ:

JSON file example - email archiving system

أخبار أخرى

اقرأ المزيد من هذه الفئة

A person is standing at a desk while typing on a laptop.

المنصة الأصلية للذكاء الاصطناعي التي تتوسع مع عملك.

اتصل بالمبيعات

ابدأ مجانًا

© 2025 Bird

اتصل بالدعم

A person is standing at a desk while typing on a laptop.

المنصة الأصلية للذكاء الاصطناعي التي تتوسع مع عملك.

اتصل بالمبيعات

ابدأ مجانًا

© 2025 Bird

اتصل بالدعم

A person is standing at a desk while typing on a laptop.

المنصة الأصلية للذكاء الاصطناعي التي تتوسع مع عملك.

اتصل بالمبيعات

ابدأ مجانًا

© 2025 Bird

اتصل بالدعم