بناء نظام أرشفة البريد الإلكتروني: تخزين محتوى البريد الإلكتروني

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

·

04‏/03‏/2019

بناء نظام أرشفة البريد الإلكتروني: تخزين محتوى البريد الإلكتروني

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

    • الهدف: يوضح هذا المنشور المرحلة الأولى من بناء نظام أرشفة البريد الإلكتروني باستخدام SparkPost و Amazon S3 و MySQL. يشرح كيفية تكرار البريد الإلكتروني، والتقاطه، وتخزينه للوصول طويل الأمد والامتثال.

    • الفكرة الأساسية: يقوم النظام تلقائيًا بتخزين محتوى البريد الإلكتروني الخام (بتنسيق rfc822) في S3 وتسجيل بيانات التعريف (الموضوع، المرسل، الطابع الزمني، إلخ) في MySQL للبحث السريع والاسترجاع.

    • الأساسيات المغطاة:

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

      2. ربط البيانات عبر UID: قم بتضمين معرف فريد (UID) في كل من محتوى البريد الإلكتروني وبيانات التعريف X-MSYS-API لربط الرسائل الأصلية والمحفوظة.

      3. معالجة الوارد: قم بتكوين نطاق وارد وWebhook في SparkPost لاستقبال أحمال JSON لمراسلات البريد الإلكتروني المؤرشفة عبر جامع التطبيقات.

      4. تخزين الرسائل في S3: قم بتحميل محتوى rfc822 المعالج إلى دلو S3، مع استخدام قواعد دورة الحياة (مثل، الانتقال إلى Glacier بعد عام) لتقليل تكاليف التخزين.

      5. تسجيل بيانات التعريف في MySQL: احتفظ بالمجالات الأساسية مثل RCPT_TO وFROM وSUBJECT واسم ملف S3 لت索索 البيانات واسترجاعها في المستقبل.

      6. اعتبارات الأداء: تضمن كفاءة الكود والتسجيل الحد الأدني أن يتمكن الجامع من التعامل مع مئات الطلبات في الدقيقة مع الحد الأدنى من التأخير.

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

أهم النقاط في الأسئلة والأجوبة

  • ما هو هدف هذا المشروع؟

    لإنشاء نظام أرشفة بريد إلكتروني آلي يقوم بتخزين نصوص الرسائل في Amazon S3 مع الحفاظ على بيانات وصفية قابلة للبحث في قاعدة بيانات MySQL.

  • لماذا تستخدم ميزة الأرشيف في SparkPost؟

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

  • كيف يرتبط كل بريد إلكتروني مؤرشف برسالته الأصلية؟

    يتم تضمين UID فريد في كل من نص البريد الإلكتروني والبيانات الوصفية، مما يتيح الإشارة الدقيقة بين النسخ الأصلية والأرشفية.

  • لماذا نستخدم S3 للتخزين؟

    تقدم S3 خيارات تخزين قابلة للتوسع وإدارة دورة حياة (مثل Glacier)، مما يجعلها اقتصادية للاحتفاظ بالبريد الإلكتروني على المدى الطويل.

  • ماذا يخزن قاعدة بيانات MySQL؟

    إنه يخزن حقول البيانات الوصفية القابلة للبحث - مثل سطر الموضوع، والمرسل، وختم الوقت، واسم ملف S3 - مما يسمح بالاستفسار والاسترجاع بشكل فعال.

  • ما هي خطوات التطوير التالية؟

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

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

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

لقد قمت بتفصيل الخطوات التي اتبعتها أدناه في المرحلة الأولى من المشروع:

  1. إنشاء البريد الإلكتروني المكرر للأرشفة

  2. استخدام ميزات الأرشفة وRelay الوارد من SparkPost لإرسال نسخة من البريد الإلكتروني الأصلي إلى SparkPost لمعالجته في هيكل JSON، ثم إرساله إلى مُجمع webhook (تطبيق)

  3. تفكيك هيكل JSON للحصول على المكونات اللازمة

  4. إرسال محتوى البريد الإلكتروني إلى S3 للتخزين

  5. تسجيل إدخال في MySQL لكل بريد إلكتروني للربط المرجعي

إنشاء نسخة مكررة من البريد الإلكتروني

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

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

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

إذا كنت تريد شرحًا أعمق، فإليك رابط لوثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من البريد الإلكتروني. تظهر عناوين X-MSYS-API النموذجية لهذا المشروع لاحقًا في هذه المدونة.

هناك تحذير واحد لهذه الطريقة؛ بينما يتم ربط جميع معلومات الحدث في البريد الإلكتروني الأصلي بواسطة كل من transmission_id و message_id، لا توجد معلومات في حدث إعادة الترحيل الوارد (آلية الحصول على البريد الإلكتروني الأرشيفي ونشره) للبريد الإلكتروني المكرر الذي يربط مرة أخرى بإحدى هذين المعرفين وبالتالي المعلومات للبريد الإلكتروني الأصلي. هذا يعني أننا بحاجة إلى وضع بيانات في نص البريد الإلكتروني ورأس البريد الإلكتروني الأصلي كطريقة لربط جميع بيانات SparkPost من البريد الإلكتروني الأصلي والأرشيفي.

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

  1. في مكان ما في نص البريد الإلكتروني، وضعت الإدخال التالي:<input name="ArchiveCode" type="hidden" value="<<UID>>">

  2. ثم أنشأت رمزًا فريدًا واستبدلت حقل <<UID>>: $uid = md5(uniqid(rand(), true)); $emailBody = str_replace("<<UID>>,$uid,$emailBody);

    ها هي مخرجات مثال:

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

  3. بعد ذلك، تأكدت من أنني أضفت $UID إلى كتلة meta_data في رأس X-MSYS-API. تضمن هذه الخطوة تضمين UID في كل مخرجات الحدث للبريد الإلكتروني الأصلي:

X-MSYS-API: {
  "campaign_id": "<my_campaign>",
  "metadata": {
    "UID": "<UID>"
  },
  "archive": [
    {
      "email": "archive@geekwithapersonality.com"
    }
  ],
  "options": {
    "open_tracking": false,
    "click_tracking": false,
    "transactional": false,
    "ip_pool": "<my_ip_pool>"
  }
}

الآن لدينا طريقة لربط جميع البيانات من البريد الإلكتروني الأصلي بنص البريد الإلكتروني الخاص بالأرشيف.

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

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

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

إذا كنت تريد شرحًا أعمق، فإليك رابط لوثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من البريد الإلكتروني. تظهر عناوين X-MSYS-API النموذجية لهذا المشروع لاحقًا في هذه المدونة.

هناك تحذير واحد لهذه الطريقة؛ بينما يتم ربط جميع معلومات الحدث في البريد الإلكتروني الأصلي بواسطة كل من transmission_id و message_id، لا توجد معلومات في حدث إعادة الترحيل الوارد (آلية الحصول على البريد الإلكتروني الأرشيفي ونشره) للبريد الإلكتروني المكرر الذي يربط مرة أخرى بإحدى هذين المعرفين وبالتالي المعلومات للبريد الإلكتروني الأصلي. هذا يعني أننا بحاجة إلى وضع بيانات في نص البريد الإلكتروني ورأس البريد الإلكتروني الأصلي كطريقة لربط جميع بيانات SparkPost من البريد الإلكتروني الأصلي والأرشيفي.

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

  1. في مكان ما في نص البريد الإلكتروني، وضعت الإدخال التالي:<input name="ArchiveCode" type="hidden" value="<<UID>>">

  2. ثم أنشأت رمزًا فريدًا واستبدلت حقل <<UID>>: $uid = md5(uniqid(rand(), true)); $emailBody = str_replace("<<UID>>,$uid,$emailBody);

    ها هي مخرجات مثال:

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

  3. بعد ذلك، تأكدت من أنني أضفت $UID إلى كتلة meta_data في رأس X-MSYS-API. تضمن هذه الخطوة تضمين UID في كل مخرجات الحدث للبريد الإلكتروني الأصلي:

X-MSYS-API: {
  "campaign_id": "<my_campaign>",
  "metadata": {
    "UID": "<UID>"
  },
  "archive": [
    {
      "email": "archive@geekwithapersonality.com"
    }
  ],
  "options": {
    "open_tracking": false,
    "click_tracking": false,
    "transactional": false,
    "ip_pool": "<my_ip_pool>"
  }
}

الآن لدينا طريقة لربط جميع البيانات من البريد الإلكتروني الأصلي بنص البريد الإلكتروني الخاص بالأرشيف.

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

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

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

إذا كنت تريد شرحًا أعمق، فإليك رابط لوثائق SparkPost حول إنشاء نسخ مكررة (أو أرشيف) من البريد الإلكتروني. تظهر عناوين X-MSYS-API النموذجية لهذا المشروع لاحقًا في هذه المدونة.

هناك تحذير واحد لهذه الطريقة؛ بينما يتم ربط جميع معلومات الحدث في البريد الإلكتروني الأصلي بواسطة كل من transmission_id و message_id، لا توجد معلومات في حدث إعادة الترحيل الوارد (آلية الحصول على البريد الإلكتروني الأرشيفي ونشره) للبريد الإلكتروني المكرر الذي يربط مرة أخرى بإحدى هذين المعرفين وبالتالي المعلومات للبريد الإلكتروني الأصلي. هذا يعني أننا بحاجة إلى وضع بيانات في نص البريد الإلكتروني ورأس البريد الإلكتروني الأصلي كطريقة لربط جميع بيانات SparkPost من البريد الإلكتروني الأصلي والأرشيفي.

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

  1. في مكان ما في نص البريد الإلكتروني، وضعت الإدخال التالي:<input name="ArchiveCode" type="hidden" value="<<UID>>">

  2. ثم أنشأت رمزًا فريدًا واستبدلت حقل <<UID>>: $uid = md5(uniqid(rand(), true)); $emailBody = str_replace("<<UID>>,$uid,$emailBody);

    ها هي مخرجات مثال:

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

  3. بعد ذلك، تأكدت من أنني أضفت $UID إلى كتلة meta_data في رأس X-MSYS-API. تضمن هذه الخطوة تضمين UID في كل مخرجات الحدث للبريد الإلكتروني الأصلي:

X-MSYS-API: {
  "campaign_id": "<my_campaign>",
  "metadata": {
    "UID": "<UID>"
  },
  "archive": [
    {
      "email": "archive@geekwithapersonality.com"
    }
  ],
  "options": {
    "open_tracking": false,
    "click_tracking": false,
    "transactional": false,
    "ip_pool": "<my_ip_pool>"
  }
}

الآن لدينا طريقة لربط جميع البيانات من البريد الإلكتروني الأصلي بنص البريد الإلكتروني الخاص بالأرشيف.

الحصول على نسخة الأرشيف

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

  1. إنشاء نطاق فرعي ستقوم بإرسال جميع رسائل البريد الإلكتروني الأرشيفية (المكررة) إليه

  2. تعيين سجلات DNS المناسبة لجعل جميع رسائل البريد الإلكتروني المرسلة إلى ذلك النطاق الفرعي تذهب إلى SparkPost

  3. إنشاء مجال وارد في SparkPost

  4. إنشاء نقطة وصول واردة في SparkPost

  5. إنشاء تطبيق (جَامِع) لاستلام تدفق بيانات نقطة وصول SparkPost

يمكن استخدام الرابطين التاليين لمساعدتك في توجيهك خلال هذه العملية:

  1. وثيقة SparkPost التقنية: تمكين توجيه البريد الإلكتروني الوارد ونقاط وصول التوجيه

  2. أيضًا، المدونة التي كتبتها العام الماضي، أرشفة رسائل البريد الإلكتروني: دليل حول تتبع البريد المرسل ستساعدك في إنشاء نقطة الوصول الواردة ضمن SparkPost

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

الحصول على البريد الإلكتروني المكرر في هيكل JSON

في المرحلة الأولى من هذا المشروع، كل ما أخزنه هو تنسيق البريد الإلكتروني rfc822 في S3 وبعض حقول الوصف عالية المستوى في جدول SQL للبحث.  نظرًا لأن SparkPost سترسل بيانات البريد الإلكتروني في هيكل JSON إلى منصة الأرشفة الخاصة بي عبر تدفقات بيانات webhook، فقد قمت ببناء تطبيق (غالبًا ما يُشار إليه بـ جامع) يقبل تدفق بيانات Relay_Webhook.

ستحتوي كل حزمة من SparkPost Relay_Webhook على معلومات بريد إلكتروني مكرر واحد في كل مرة، لذا فإن تفكيك هيكل JSON إلى المكونات المستهدفة لهذا المشروع هو أمر سهل نسبيًا.  في كود PHP الخاص بي، كانت الحصول على البريد الإلكتروني بتنسيق rfc822 سهلة مثل الأسطر القليلة التالية من الكود:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $body = file_get_contents("php://input");
    $fields = json_decode($body, true);
    $rfc822body = $fields[0]['msys']['relay_message']['content']['email_rfc822'];
    $htmlbody = $fields[0]['msys']['relay_message']['content']['html'];
    $headers  = $fields[0]['msys']['relay_message']['content']['headers'];
}

بعض المعلومات التي أريد تخزينها في جدول SQL الخاص بي موجودة في مصفوفة حقول الرؤوس.  لذا كتبت وظيفة صغيرة تقبل مصفوفة الرؤوس وتقوم بالتكرار عبر المصفوفة من أجل الحصول على البيانات التي كنت مهتمًا بتخزينها:

function get_important_headers($headers, &$original_to, &$headerDate, &$subject, &$from) {
    foreach ($headers as $headerGroup) {
        foreach ($headerGroup as $key => $value) {
            if ($key === 'To') {
                $original_to = $value;
            } elseif ($key === 'Date') {
                $headerDate = $value;
            } elseif ($key === 'Subject') {
                $subject = $value;
            } elseif ($key === 'From') {
                $from = $value;
            }
        }
    }
}

الآن بعد أن حصلت على البيانات، أنا مستعد لتخزين الجسم في S3.

في المرحلة الأولى من هذا المشروع، كل ما أخزنه هو تنسيق البريد الإلكتروني rfc822 في S3 وبعض حقول الوصف عالية المستوى في جدول SQL للبحث.  نظرًا لأن SparkPost سترسل بيانات البريد الإلكتروني في هيكل JSON إلى منصة الأرشفة الخاصة بي عبر تدفقات بيانات webhook، فقد قمت ببناء تطبيق (غالبًا ما يُشار إليه بـ جامع) يقبل تدفق بيانات Relay_Webhook.

ستحتوي كل حزمة من SparkPost Relay_Webhook على معلومات بريد إلكتروني مكرر واحد في كل مرة، لذا فإن تفكيك هيكل JSON إلى المكونات المستهدفة لهذا المشروع هو أمر سهل نسبيًا.  في كود PHP الخاص بي، كانت الحصول على البريد الإلكتروني بتنسيق rfc822 سهلة مثل الأسطر القليلة التالية من الكود:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $body = file_get_contents("php://input");
    $fields = json_decode($body, true);
    $rfc822body = $fields[0]['msys']['relay_message']['content']['email_rfc822'];
    $htmlbody = $fields[0]['msys']['relay_message']['content']['html'];
    $headers  = $fields[0]['msys']['relay_message']['content']['headers'];
}

بعض المعلومات التي أريد تخزينها في جدول SQL الخاص بي موجودة في مصفوفة حقول الرؤوس.  لذا كتبت وظيفة صغيرة تقبل مصفوفة الرؤوس وتقوم بالتكرار عبر المصفوفة من أجل الحصول على البيانات التي كنت مهتمًا بتخزينها:

function get_important_headers($headers, &$original_to, &$headerDate, &$subject, &$from) {
    foreach ($headers as $headerGroup) {
        foreach ($headerGroup as $key => $value) {
            if ($key === 'To') {
                $original_to = $value;
            } elseif ($key === 'Date') {
                $headerDate = $value;
            } elseif ($key === 'Subject') {
                $subject = $value;
            } elseif ($key === 'From') {
                $from = $value;
            }
        }
    }
}

الآن بعد أن حصلت على البيانات، أنا مستعد لتخزين الجسم في S3.

في المرحلة الأولى من هذا المشروع، كل ما أخزنه هو تنسيق البريد الإلكتروني rfc822 في S3 وبعض حقول الوصف عالية المستوى في جدول SQL للبحث.  نظرًا لأن SparkPost سترسل بيانات البريد الإلكتروني في هيكل JSON إلى منصة الأرشفة الخاصة بي عبر تدفقات بيانات webhook، فقد قمت ببناء تطبيق (غالبًا ما يُشار إليه بـ جامع) يقبل تدفق بيانات Relay_Webhook.

ستحتوي كل حزمة من SparkPost Relay_Webhook على معلومات بريد إلكتروني مكرر واحد في كل مرة، لذا فإن تفكيك هيكل JSON إلى المكونات المستهدفة لهذا المشروع هو أمر سهل نسبيًا.  في كود PHP الخاص بي، كانت الحصول على البريد الإلكتروني بتنسيق rfc822 سهلة مثل الأسطر القليلة التالية من الكود:

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $body = file_get_contents("php://input");
    $fields = json_decode($body, true);
    $rfc822body = $fields[0]['msys']['relay_message']['content']['email_rfc822'];
    $htmlbody = $fields[0]['msys']['relay_message']['content']['html'];
    $headers  = $fields[0]['msys']['relay_message']['content']['headers'];
}

بعض المعلومات التي أريد تخزينها في جدول SQL الخاص بي موجودة في مصفوفة حقول الرؤوس.  لذا كتبت وظيفة صغيرة تقبل مصفوفة الرؤوس وتقوم بالتكرار عبر المصفوفة من أجل الحصول على البيانات التي كنت مهتمًا بتخزينها:

function get_important_headers($headers, &$original_to, &$headerDate, &$subject, &$from) {
    foreach ($headers as $headerGroup) {
        foreach ($headerGroup as $key => $value) {
            if ($key === 'To') {
                $original_to = $value;
            } elseif ($key === 'Date') {
                $headerDate = $value;
            } elseif ($key === 'Subject') {
                $subject = $value;
            } elseif ($key === 'From') {
                $from = $value;
            }
        }
    }
}

الآن بعد أن حصلت على البيانات، أنا مستعد لتخزين الجسم في S3.

تخزين البريد الإلكتروني المكرر في S3

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

https://docs.aws.amazon.com/quickstarts/latest/s3backup/step-1-create-bucket.html
https://aws.amazon.com/blogs/security/wheres-my-secret-access-key/

ما سأفعله هو الإشارة إلى بعض الإعدادات التي اخترتها والتي تتعلق بمشروع مثل هذا.

  1. التحكم في الوصول.  لا تحتاج فقط إلى تعيين الأمان للدلو، بل تحتاج إلى تعيين الأذونات للعناصر نفسها.  في مشروعي، استخدمت سياسة مفتوحة جدًا للقراءة العامة لأن البيانات النموذجية ليست شخصية وأردت الوصول السهل إلى البيانات.  من المحتمل أنك ستحتاج إلى مجموعة أكثر صرامة من سياسات ACL. إليك مقال جميل حول إعدادات ACL: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

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

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

بالنسبة للاسم الفريد للملف، سأبحث في جسم البريد الإلكتروني عن المعرف المخفي الذي وضعته التطبيق المرسل في البريد الإلكتروني وسأستخدم ذلك المعرف كاسم للملف. هناك طرق أكثر أناقة لجلب connectorId من جسم HTML، ولكن من أجل البساطة والوضوح سأستخدم الكود التالي:

$start = strpos($htmlbody, $inputField);
if ($start !== false) {
    $start = strpos($htmlbody, 'value="', $start);
    if ($start !== false) {
        $start += 7; // Move past 'value="'
        $end = strpos($htmlbody, '"', $start);
        if ($end !== false) {
            $length = $end - $start;
            $UID = substr($htmlbody, $start, $length);
        }
    }
}

* نحن نفترض أن $inputField يحمل القيمة “ArchiveCode” وتم العثور عليه في ملف config.php الخاص بي.

مع UID، يمكننا بعد ذلك إنشاء اسم الملف الذي سيتم استخدامه في S3:

$fileName = $ArchiveDirectory . '/' . $UID . '.eml';

الآن يمكنني فتح الاتصال الخاص بي بـ S3 وتحميل الملف. إذا نظرت إلى ملف s3.php في مستودع GitHub، سترى أنه يستغرق القليل جدًا من الشيفرة لتحميل الملف.

خطوتي الأخيرة هي تسجيل هذا الإدخال في جدول MYSQL.

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

https://docs.aws.amazon.com/quickstarts/latest/s3backup/step-1-create-bucket.html
https://aws.amazon.com/blogs/security/wheres-my-secret-access-key/

ما سأفعله هو الإشارة إلى بعض الإعدادات التي اخترتها والتي تتعلق بمشروع مثل هذا.

  1. التحكم في الوصول.  لا تحتاج فقط إلى تعيين الأمان للدلو، بل تحتاج إلى تعيين الأذونات للعناصر نفسها.  في مشروعي، استخدمت سياسة مفتوحة جدًا للقراءة العامة لأن البيانات النموذجية ليست شخصية وأردت الوصول السهل إلى البيانات.  من المحتمل أنك ستحتاج إلى مجموعة أكثر صرامة من سياسات ACL. إليك مقال جميل حول إعدادات ACL: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

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

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

بالنسبة للاسم الفريد للملف، سأبحث في جسم البريد الإلكتروني عن المعرف المخفي الذي وضعته التطبيق المرسل في البريد الإلكتروني وسأستخدم ذلك المعرف كاسم للملف. هناك طرق أكثر أناقة لجلب connectorId من جسم HTML، ولكن من أجل البساطة والوضوح سأستخدم الكود التالي:

$start = strpos($htmlbody, $inputField);
if ($start !== false) {
    $start = strpos($htmlbody, 'value="', $start);
    if ($start !== false) {
        $start += 7; // Move past 'value="'
        $end = strpos($htmlbody, '"', $start);
        if ($end !== false) {
            $length = $end - $start;
            $UID = substr($htmlbody, $start, $length);
        }
    }
}

* نحن نفترض أن $inputField يحمل القيمة “ArchiveCode” وتم العثور عليه في ملف config.php الخاص بي.

مع UID، يمكننا بعد ذلك إنشاء اسم الملف الذي سيتم استخدامه في S3:

$fileName = $ArchiveDirectory . '/' . $UID . '.eml';

الآن يمكنني فتح الاتصال الخاص بي بـ S3 وتحميل الملف. إذا نظرت إلى ملف s3.php في مستودع GitHub، سترى أنه يستغرق القليل جدًا من الشيفرة لتحميل الملف.

خطوتي الأخيرة هي تسجيل هذا الإدخال في جدول MYSQL.

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

https://docs.aws.amazon.com/quickstarts/latest/s3backup/step-1-create-bucket.html
https://aws.amazon.com/blogs/security/wheres-my-secret-access-key/

ما سأفعله هو الإشارة إلى بعض الإعدادات التي اخترتها والتي تتعلق بمشروع مثل هذا.

  1. التحكم في الوصول.  لا تحتاج فقط إلى تعيين الأمان للدلو، بل تحتاج إلى تعيين الأذونات للعناصر نفسها.  في مشروعي، استخدمت سياسة مفتوحة جدًا للقراءة العامة لأن البيانات النموذجية ليست شخصية وأردت الوصول السهل إلى البيانات.  من المحتمل أنك ستحتاج إلى مجموعة أكثر صرامة من سياسات ACL. إليك مقال جميل حول إعدادات ACL: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

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

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

بالنسبة للاسم الفريد للملف، سأبحث في جسم البريد الإلكتروني عن المعرف المخفي الذي وضعته التطبيق المرسل في البريد الإلكتروني وسأستخدم ذلك المعرف كاسم للملف. هناك طرق أكثر أناقة لجلب connectorId من جسم HTML، ولكن من أجل البساطة والوضوح سأستخدم الكود التالي:

$start = strpos($htmlbody, $inputField);
if ($start !== false) {
    $start = strpos($htmlbody, 'value="', $start);
    if ($start !== false) {
        $start += 7; // Move past 'value="'
        $end = strpos($htmlbody, '"', $start);
        if ($end !== false) {
            $length = $end - $start;
            $UID = substr($htmlbody, $start, $length);
        }
    }
}

* نحن نفترض أن $inputField يحمل القيمة “ArchiveCode” وتم العثور عليه في ملف config.php الخاص بي.

مع UID، يمكننا بعد ذلك إنشاء اسم الملف الذي سيتم استخدامه في S3:

$fileName = $ArchiveDirectory . '/' . $UID . '.eml';

الآن يمكنني فتح الاتصال الخاص بي بـ S3 وتحميل الملف. إذا نظرت إلى ملف s3.php في مستودع GitHub، سترى أنه يستغرق القليل جدًا من الشيفرة لتحميل الملف.

خطوتي الأخيرة هي تسجيل هذا الإدخال في جدول MYSQL.

تخزين البيانات الوصفية في MySQL

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

حقول بيانات MySQL

الحقل

الغرض

التاريخ/الوقت (تلقائي)

علامة الوقت عند تسجيل الإدخال

عنوان RCPT_TO

عنوان البريد الإلكتروني المستهدف للرسالة المؤرشفة

علامة الوقت لهيئة DATE

وقت إرسال البريد الإلكتروني الأصلي

عنوان SUBJECT

خط الموضوع للترتيب والبحث

عنوان FROM

معرف المرسل للبحث

دليل S3

مسار الدليل داخل دلو S3

اسم ملف S3

ملف .eml فريد مخزن في S3

تقوم الوظيفة المسماة MySQLLog داخل ملف التطبيق upload.php بالمرور عبر الخطوات اللازمة لفتح الرابط إلى MySQL، حقن الصف الجديد، اختبار النتائج وإغلاق الرابط. أضفت واحدة أخرى لمزيد من التأكد، وهي تسجيل هذه البيانات في ملف نصي. هل ينبغي علي القيام بمزيد من تسجيل الأخطاء؟ نعم. لكنني أرغب في الحفاظ على هذا الكود خفيفًا للسماح له بالعمل بسرعة كبيرة. في بعض الأحيان، سيتم استدعاء هذا الكود مئات المرات في الدقيقة ويحتاج إلى أن يكون فعالاً قدر الإمكان. في التحديثات المستقبلية، سأضيف كودًا إضافيًا ستقوم بمعالجة الإخفاقات وإرسال تلك الإخفاقات إلى مدير المراقبة.

اختتام ذلك

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

في التعديلات المستقبلية لهذا المشروع، أتوقع أن:

  1. أخزن جميع أحداث سجل البريد الإلكتروني الأصلي

  2. أرسل أخطاء التخزين إلى المدير عندما يحدث فشل في التحميل أو التسجيل

  3. أقلل من تعقيد المجمع.

  4. أضيف واجهة مستخدم لعرض جميع البيانات

  5. أدعم القدرة على إعادة إرسال البريد الإلكتروني

في غضون ذلك، آمل أن يكون هذا المشروع قد كان ممتعًا ومفيدًا لك؛ إرسال سعيد.

أخبار أخرى

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

12‏/02‏/2018

15 أفضل ممارسات توصيل البريد الإلكتروني لجيميل

07‏/03‏/2023

سبارك بوست أصبحت الآن بيرد إيميل

12‏/06‏/2018

البدء بإشعارات البريد الإلكتروني

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

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

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

ابدأ مجانًا

© ٢٠٢٦ بيرد

الاتصال بالدعم

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

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

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

ابدأ مجانًا

© ٢٠٢٦ بيرد

الاتصال بالدعم

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

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

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

ابدأ مجانًا

© ٢٠٢٦ بيرد

الاتصال بالدعم