دليل ترحيل البريد الإلكتروني من الخادم المحلي إلى السحابة

طائر

28‏/06‏/2020

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

1 min read

دليل ترحيل البريد الإلكتروني من الخادم المحلي إلى السحابة

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

    • تم بناء Bird Cloud على محرك Momentum MTA المثبت، مما يوفر للعملاء أداء نظام قديم مستضاف مع المزايا الإضافية لمنصة API بريد إلكتروني سحابية حديثة.

    • لا يزال العديد من المرسلين التقليديين يعتمدون على Momentum أو PowerMTA، وتوفر Bird مسار ترحيل واضح لكليهما - ترحيل كامل إلى السحابة أو توجيه هجين من خلال العقد المستضافة.

    • يتطلب الترحيل فهم ما إذا كنت ستقوم:

      1. بإلغاء جميع البنية التحتية المستضافة، أو

      2. مواصلة استخدام MTA الخاص بك للمعالجة المسبقة، أو التوجيه، أو القيود القديمة.

    • تقبل Bird فقط الحقن SMTP الموثق عبر المنافذ 587 أو 2525 (يوصى بشدة باستخدام TLS). كما أن حقن REST API متاح أيضًا للتسليم المباشر المستند إلى JSON.

    • الخيار رقم 1 (“الانتقال الكامل”) يسمح بإلغاء كاملة لمراكز MTAs عن طريق الإرسال مباشرة إلى Bird عبر SMTP أو REST، مما يزيل التعقيد ويعصر بنية الإرسال.

    • يدعم الخيار رقم 2 البيئات الهجينة - توجيه تدفقات مختارة من Momentum أو PMTA إلى Bird عن طريق تكوين المجالات الصادرة باستخدام SMTP_Auth إلى Bird.

    • يمكن تكوينات PowerMTA و Momentum تحويل الحركة إلى Bird بأمان باستخدام TLS و SMTP_Auth المعتمد على مفتاح API وتعريفات التوجيه.

    • يمكن للعملاء الذين يستخدمون سكربتات Lua المتقدمة أو الاستبدالات المباشرة أو التصفية قبل التسليم البقاء هجينيين حتى يتم إعادة هيكلة المنطق في الأنظمة العليا.

    • تدعم Bird BYOIP (اجلب عنوان IP الخاص بك) للعملاء الذين لديهم كتلة متصلة /24، مما يسمح لك بالاحتفاظ بسمعة IP المدفأة وتجنب التسخين الكامل لعنوان IP.

    • بالنسبة للمستخدمين غير المملوكين لعنوان IP، توفر Bird تسخين عنوان IP تلقائي، وتوصي بالترحيل المرحلي - بدءًا من أحجام صغيرة، ثم زيادة الحركة تدريجيًا.

    • تعتبر إعدادات المجال الصحيحة (DKIM و SPF و DMARC و مجالات العودة و مجالات التتبع) ضرورية للتوافق والتعايش السلس أثناء الترحيل.

    • توفر Bird بيانات أحداث الوقت الفعلي عبر الويب هوكس أو Events API، مما يمكّن الأتمتة اللاحقة، وتدفقات ETL، وإعادة بناء على نمط السجل إذا لزم الأمر.

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

  • ما هما السيناريوهان الرئيسيان للهجرة؟

    إما إلغاء جميع خوادم البريد المحلية (الخيار رقم 1) أو الحفاظ على إعداد هجين حيث يتم توجيه بعض حركة المرور عبر Momentum/PMTA قبل الوصول إلى Bird (الخيار رقم 2).

  • ما الذي يحدد ما إذا كنت ستختار الخيار رقم 1 أو الخيار رقم 2؟

    اعتمادك على نصوص Lua، أو منطق المعالجة المسبقة، أو إعادة كتابة الرسائل، أو متطلبات الأمان، أو المولدات التي لا يمكنها إرسال حركة مرور موثقة عبر المنفذ 587.

  • هل يقبل بيرد حقن SMTP عبر المنفذ 25؟

    لا — يتطلب Bird حقن SMTP عبر المنفذ 587 أو 2525، مصدق مع SMTP_Auth.

  • هل مطلوب TLS؟

    ليس مطلوبًا بشكل صارم، ولكن يُوصى بشدة لضمان حقن الرسائل من مولدات الرسائل أو من المتغيرات المحلية.

  • هل يمكن للمرسلين استخدام واجهة برمجة التطبيقات REST بدلاً من SMTP؟

    نعم - يمكن للمرسلين تسليم حمولات JSON عبر واجهة برمجة تطبيقات Transmissions REST، مما يبسط غالبًا سير العمل ويزيل الحاجة إلى إنشاء رسائل SMTP الخام.

  • ما هو برنامج BYOIP من Bird؟

    عملية تتيح للعملاء الذين لديهم كتلة متصلة /24 نقل عناوين IP الحالية الخاصة بهم إلى Bird، والحفاظ على السمعة وتخطي عملية التسخين.

  • ماذا لو كانت BYOIP ليست خيارًا؟

    استخدم نطاقات الإرسال الجديدة (مثل: sp.yourdomain.com)، قم بتشغيل كلا البيئات بشكل متوازي، واعتمد على التدفئة التلقائية لعنوان IP من Bird.

  • كيف يمكنك توجيه فقط التدفقات المحددة من خلال Bird في إعداد هجين؟

    من خلال تكوين نطاقات الصادر (Momentum) أو إعدادات التجميع / VMTAs (PowerMTA) التي تصادق وتوصل إلى نقطة نهاية SMTP الخاصة بـ Bird.

  • ما التغييرات المطلوبة على البيانات الوصفية عند الحقن عبر SMTP؟

    أضف رأس X-MSYS-API يحتوي على خصائص مثل ip_pool، campaign، وأي بيانات وصفية مخصصة تم التعامل معها مسبقًا من خلال X-Headers.

  • ماذا يجب أن يتم تكوينه في نظام أسماء النطاقات قبل الهجرة؟

    سجلات DKIM، SPF، DMARC، نطاقات الارتداد، ونطاقات التتبع لضمان توافق النطاق وتقليل مخاطر التسليم أثناء الانتقال.

  • كيف ينبغي نقل الحركة إلى بريد؟

    تدريجيًا: ابدأ بتدفق صغير، ثم 10٪، ثم 20٪، مع زيادة يومية حتى يتم نقل كل الحركة—مماثل لأفضل الممارسات في تسخين بروتوكول الإنترنت.

  • كيف يمكن للمُرسلين جمع بيانات التوصيل والمشاركة بعد الانتقال؟

    من خلال استخدام نظام Webhook في الوقت الفعلي من Bird أو واجهة برمجة التطبيقات للأحداث؛ يمكن بناء جامع الويب بسرعة وتغذية التخزين في أسفل النهر أو أنظمة ETL.

طالما سمعنا السؤال، "هل لديك كتاب قواعد من نوع ما يوضح العملية الخاصة بالانتقال من تثبيت في الموقع إلى Bird"؟

نعم، نعم لدينا. تابع القراءة.

أولاً، بعض الخلفية. تم إنشاء خدمة Bird Cloud في عام 2014 نتيجةً للنجاح الكبير لحل On-Premises Momentum MTA. Momentum يقع في جوهر Bird Cloud، حيث يوفر تسليمًا عالي السرعة وتشكيل حركة المرور لآلاف العملاء على خدمة السحابة. نظرًا لذلك، يتلقى Momentum جزءًا كبيرًا من انتباه مهندسيينا، ولكن غالبًا ما يتم دفن نتائج هذا العمل في تحسينات الأداء التي لا تحصل على الكثير من الدعاية. يرى عملاء Momentum فوائد هذا العمل في كل مرة يتم فيها نشر إصدار جديد عام من Momentum.

هذا لا يعني أن Bird هو مجرد "Momentum في السحابة". MessageBird هو أكثر من ذلك بكثير ويمكن أن يكون له فوائد إضافية للعملاء الذين يختارون الانتقال أو استخدامهم بأسلوب هجين. تنبع هذه الفوائد من بنية API البريد الإلكتروني السحابية الحديثة، والتي توفر قدرات غير متاحة في الحلول التقليدية التي تعمل في المواقع. بالإضافة إلى ذلك، لقد جعلنا من السهل جدًا لعملاء PowerMTA الانتقال أو استخدام PowerMTA مع Bird في تكوين هجين أيضًا. سوف يصف بقية هذا المستند بالتفصيل كيف يمكنك نقل تدفقات الرسائل الخاصة بك من Momentum أو PowerMTA إلى خدمة Bird Cloud.

هناك في الواقع سيناريوهين منفصلين يجب مراعاتهما عند الانتقال إلى Bird من Momentum أو PowerMTA.

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

  2. لديك سبب للاحتفاظ ببعض البصمة على الموقع لسبب أو لآخر. بعض الاحتمالات قد تكون:

  • تدفقات تسليم محددة تتطلب المعالجة المسبقة في Momentum

  • تقسيم السعة لاحتياجات الطفرات أو التعافي من الكوارث

  • دعم العملاء الأوائل في PMTA بينما يتم تحويل العملاء الجدد إلى SparkPost

 ...ثم ترغب في توجيه الرسائل الأخرى إلى Bird لمعالجة الرسائل لاحقًا.

في أي من الحالتين، تحتاج إلى أن تكون على علم بأن Bird ستقبل فقط رسائل SMTP للتسليم التي تم إدخالها عبر المنفذ 587 أو 2525 وتستخدم SMTP_Auth مع اسم مستخدم وكلمة مرور محددين (راجع وثائق SMTP هنا). نوصي أيضًا بشدة بالاتصال عبر اتصال TLS، ولكن ذلك ليس مطلوبًا بشكل صارم. إذا كنت تستبدل طبقة MTA الخاصة بك تمامًا (السيناريو 1)، فقد ترغب أيضًا في التفكير في استخدام واجهة برمجة التطبيقات Transmissions REST التي يمكن أن تقبل الرسائل عبر اتصالات HTTPS. الوثائق الخاصة بتلك الواجهة هنا.

بالنسبة للمنظمات التي تحافظ على بنية تحتية تعمل في المواقع وتتطلب قدرات بريد إلكتروني آمن، توفر دليل تنفيذ S/MIME لـ PowerMTA وMomentum تعليمات إعداد مفصلة لتسليم البريد الإلكتروني المشفر.

طالما سمعنا السؤال، "هل لديك كتاب قواعد من نوع ما يوضح العملية الخاصة بالانتقال من تثبيت في الموقع إلى Bird"؟

نعم، نعم لدينا. تابع القراءة.

أولاً، بعض الخلفية. تم إنشاء خدمة Bird Cloud في عام 2014 نتيجةً للنجاح الكبير لحل On-Premises Momentum MTA. Momentum يقع في جوهر Bird Cloud، حيث يوفر تسليمًا عالي السرعة وتشكيل حركة المرور لآلاف العملاء على خدمة السحابة. نظرًا لذلك، يتلقى Momentum جزءًا كبيرًا من انتباه مهندسيينا، ولكن غالبًا ما يتم دفن نتائج هذا العمل في تحسينات الأداء التي لا تحصل على الكثير من الدعاية. يرى عملاء Momentum فوائد هذا العمل في كل مرة يتم فيها نشر إصدار جديد عام من Momentum.

هذا لا يعني أن Bird هو مجرد "Momentum في السحابة". MessageBird هو أكثر من ذلك بكثير ويمكن أن يكون له فوائد إضافية للعملاء الذين يختارون الانتقال أو استخدامهم بأسلوب هجين. تنبع هذه الفوائد من بنية API البريد الإلكتروني السحابية الحديثة، والتي توفر قدرات غير متاحة في الحلول التقليدية التي تعمل في المواقع. بالإضافة إلى ذلك، لقد جعلنا من السهل جدًا لعملاء PowerMTA الانتقال أو استخدام PowerMTA مع Bird في تكوين هجين أيضًا. سوف يصف بقية هذا المستند بالتفصيل كيف يمكنك نقل تدفقات الرسائل الخاصة بك من Momentum أو PowerMTA إلى خدمة Bird Cloud.

هناك في الواقع سيناريوهين منفصلين يجب مراعاتهما عند الانتقال إلى Bird من Momentum أو PowerMTA.

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

  2. لديك سبب للاحتفاظ ببعض البصمة على الموقع لسبب أو لآخر. بعض الاحتمالات قد تكون:

  • تدفقات تسليم محددة تتطلب المعالجة المسبقة في Momentum

  • تقسيم السعة لاحتياجات الطفرات أو التعافي من الكوارث

  • دعم العملاء الأوائل في PMTA بينما يتم تحويل العملاء الجدد إلى SparkPost

 ...ثم ترغب في توجيه الرسائل الأخرى إلى Bird لمعالجة الرسائل لاحقًا.

في أي من الحالتين، تحتاج إلى أن تكون على علم بأن Bird ستقبل فقط رسائل SMTP للتسليم التي تم إدخالها عبر المنفذ 587 أو 2525 وتستخدم SMTP_Auth مع اسم مستخدم وكلمة مرور محددين (راجع وثائق SMTP هنا). نوصي أيضًا بشدة بالاتصال عبر اتصال TLS، ولكن ذلك ليس مطلوبًا بشكل صارم. إذا كنت تستبدل طبقة MTA الخاصة بك تمامًا (السيناريو 1)، فقد ترغب أيضًا في التفكير في استخدام واجهة برمجة التطبيقات Transmissions REST التي يمكن أن تقبل الرسائل عبر اتصالات HTTPS. الوثائق الخاصة بتلك الواجهة هنا.

بالنسبة للمنظمات التي تحافظ على بنية تحتية تعمل في المواقع وتتطلب قدرات بريد إلكتروني آمن، توفر دليل تنفيذ S/MIME لـ PowerMTA وMomentum تعليمات إعداد مفصلة لتسليم البريد الإلكتروني المشفر.

طالما سمعنا السؤال، "هل لديك كتاب قواعد من نوع ما يوضح العملية الخاصة بالانتقال من تثبيت في الموقع إلى Bird"؟

نعم، نعم لدينا. تابع القراءة.

أولاً، بعض الخلفية. تم إنشاء خدمة Bird Cloud في عام 2014 نتيجةً للنجاح الكبير لحل On-Premises Momentum MTA. Momentum يقع في جوهر Bird Cloud، حيث يوفر تسليمًا عالي السرعة وتشكيل حركة المرور لآلاف العملاء على خدمة السحابة. نظرًا لذلك، يتلقى Momentum جزءًا كبيرًا من انتباه مهندسيينا، ولكن غالبًا ما يتم دفن نتائج هذا العمل في تحسينات الأداء التي لا تحصل على الكثير من الدعاية. يرى عملاء Momentum فوائد هذا العمل في كل مرة يتم فيها نشر إصدار جديد عام من Momentum.

هذا لا يعني أن Bird هو مجرد "Momentum في السحابة". MessageBird هو أكثر من ذلك بكثير ويمكن أن يكون له فوائد إضافية للعملاء الذين يختارون الانتقال أو استخدامهم بأسلوب هجين. تنبع هذه الفوائد من بنية API البريد الإلكتروني السحابية الحديثة، والتي توفر قدرات غير متاحة في الحلول التقليدية التي تعمل في المواقع. بالإضافة إلى ذلك، لقد جعلنا من السهل جدًا لعملاء PowerMTA الانتقال أو استخدام PowerMTA مع Bird في تكوين هجين أيضًا. سوف يصف بقية هذا المستند بالتفصيل كيف يمكنك نقل تدفقات الرسائل الخاصة بك من Momentum أو PowerMTA إلى خدمة Bird Cloud.

هناك في الواقع سيناريوهين منفصلين يجب مراعاتهما عند الانتقال إلى Bird من Momentum أو PowerMTA.

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

  2. لديك سبب للاحتفاظ ببعض البصمة على الموقع لسبب أو لآخر. بعض الاحتمالات قد تكون:

  • تدفقات تسليم محددة تتطلب المعالجة المسبقة في Momentum

  • تقسيم السعة لاحتياجات الطفرات أو التعافي من الكوارث

  • دعم العملاء الأوائل في PMTA بينما يتم تحويل العملاء الجدد إلى SparkPost

 ...ثم ترغب في توجيه الرسائل الأخرى إلى Bird لمعالجة الرسائل لاحقًا.

في أي من الحالتين، تحتاج إلى أن تكون على علم بأن Bird ستقبل فقط رسائل SMTP للتسليم التي تم إدخالها عبر المنفذ 587 أو 2525 وتستخدم SMTP_Auth مع اسم مستخدم وكلمة مرور محددين (راجع وثائق SMTP هنا). نوصي أيضًا بشدة بالاتصال عبر اتصال TLS، ولكن ذلك ليس مطلوبًا بشكل صارم. إذا كنت تستبدل طبقة MTA الخاصة بك تمامًا (السيناريو 1)، فقد ترغب أيضًا في التفكير في استخدام واجهة برمجة التطبيقات Transmissions REST التي يمكن أن تقبل الرسائل عبر اتصالات HTTPS. الوثائق الخاصة بتلك الواجهة هنا.

بالنسبة للمنظمات التي تحافظ على بنية تحتية تعمل في المواقع وتتطلب قدرات بريد إلكتروني آمن، توفر دليل تنفيذ S/MIME لـ PowerMTA وMomentum تعليمات إعداد مفصلة لتسليم البريد الإلكتروني المشفر.

أي خيار يجب أن أختار؟

لتحديد ما إذا كنت في الخيار #1 أو الخيار #2، ضع في اعتبارك هذه العوامل:

الخيار

الأفضل إذا كنت

المتطلب الأساسي

التبادل

الخيار #1: الهجرة الكاملة إلى السحابة

يمكن إزالة جميع خوادم MTA المحلية

مصادقة SMTP عبر 587/2525 أو واجهة برمجة التطبيقات REST

يتطلب إعادة هيكلة أي منطق متقدم محلي

الخيار #2: التوجيه الهجين

تحتاج إلى معالجة مسبقة أو دعم تراثي

يظل Momentum أو PowerMTA متصلين بالإنترنت

زيادة التعقيد التشغيلي


  • هل تستخدم محرك البرمجة Lua من Momentum لأي شيء أكثر تعقيدًا من توجيه الرسائل؟

    • Lua هو أداة نصية شاملة لتعديل الرسائل في الوقت الفعلي، ولكن الغالبية العظمى من مستخدمينا يستخدمونه فقط لاختيار ربط للتسليم. إذا كان هذا هو الحال، يمكنك تعديل كود الجيل الخاص بك لإضافة خاصية ip_pool إلى رأس X-MSYS-API وترك Bird يحدد المسار لك. 

    • إذا كنت تستخدم Lua للقيام بأشياء أكثر تعقيدًا مثل تصفية المحتوى، إعادة كتابة Mail_From، أو حسابات وتيرة الرسائل، وإذا لم يكن من الممكن نقل تلك المنطق إلى تطبيق الإدخال الخاص بك، فقد ترغب في التفكير في الانتقال إلى خيار #2.

  • هل نظام الجيل الخاص بك قادر على إرسال الرسائل عبر المنفذ 587 باستخدام TLS وSMTP_Auth؟

    • يمكن لبعض أنظمة إدارة الحملات دفع البريد فقط عبر المنفذ 25 بنص واضح. هذا يسبب مشكلة أمنية لـ Bird، لذا قد ترغب في التفكير في خيار #2

  • هل تستخدم صيغة استبدال PowerMTA أو تغييرات أخرى في الرسائل أثناء التشغيل؟

    • إذا كان بإمكانك نقل هذه الوظيفة إلى منشئي الرسائل لديك أو استخدام لغة القوالب من Bird، فقد لا يزال بإمكانك استخدام الخيار 1، لكن بخلاف ذلك، قد تحتاج إلى التفكير في إبقاء عقدة PMTA متصلة بالإنترنت لهذا التعديل قبل الشحن إلى Bird للتسليم.

  • هل تحتاج إلى أي مسح AV/AS وارد قبل حقن الرسائل؟ على الرغم من أن هذا ممكن في Momentum وPowerMTA، فإن eBird يفترض أنك قد قمت بالفعل بإجراء جميع هذه الفحوصات.  قد ترغب في التفكير في القيام بذلك قبل الحقن.

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

لتحديد ما إذا كنت في الخيار #1 أو الخيار #2، ضع في اعتبارك هذه العوامل:

الخيار

الأفضل إذا كنت

المتطلب الأساسي

التبادل

الخيار #1: الهجرة الكاملة إلى السحابة

يمكن إزالة جميع خوادم MTA المحلية

مصادقة SMTP عبر 587/2525 أو واجهة برمجة التطبيقات REST

يتطلب إعادة هيكلة أي منطق متقدم محلي

الخيار #2: التوجيه الهجين

تحتاج إلى معالجة مسبقة أو دعم تراثي

يظل Momentum أو PowerMTA متصلين بالإنترنت

زيادة التعقيد التشغيلي


  • هل تستخدم محرك البرمجة Lua من Momentum لأي شيء أكثر تعقيدًا من توجيه الرسائل؟

    • Lua هو أداة نصية شاملة لتعديل الرسائل في الوقت الفعلي، ولكن الغالبية العظمى من مستخدمينا يستخدمونه فقط لاختيار ربط للتسليم. إذا كان هذا هو الحال، يمكنك تعديل كود الجيل الخاص بك لإضافة خاصية ip_pool إلى رأس X-MSYS-API وترك Bird يحدد المسار لك. 

    • إذا كنت تستخدم Lua للقيام بأشياء أكثر تعقيدًا مثل تصفية المحتوى، إعادة كتابة Mail_From، أو حسابات وتيرة الرسائل، وإذا لم يكن من الممكن نقل تلك المنطق إلى تطبيق الإدخال الخاص بك، فقد ترغب في التفكير في الانتقال إلى خيار #2.

  • هل نظام الجيل الخاص بك قادر على إرسال الرسائل عبر المنفذ 587 باستخدام TLS وSMTP_Auth؟

    • يمكن لبعض أنظمة إدارة الحملات دفع البريد فقط عبر المنفذ 25 بنص واضح. هذا يسبب مشكلة أمنية لـ Bird، لذا قد ترغب في التفكير في خيار #2

  • هل تستخدم صيغة استبدال PowerMTA أو تغييرات أخرى في الرسائل أثناء التشغيل؟

    • إذا كان بإمكانك نقل هذه الوظيفة إلى منشئي الرسائل لديك أو استخدام لغة القوالب من Bird، فقد لا يزال بإمكانك استخدام الخيار 1، لكن بخلاف ذلك، قد تحتاج إلى التفكير في إبقاء عقدة PMTA متصلة بالإنترنت لهذا التعديل قبل الشحن إلى Bird للتسليم.

  • هل تحتاج إلى أي مسح AV/AS وارد قبل حقن الرسائل؟ على الرغم من أن هذا ممكن في Momentum وPowerMTA، فإن eBird يفترض أنك قد قمت بالفعل بإجراء جميع هذه الفحوصات.  قد ترغب في التفكير في القيام بذلك قبل الحقن.

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

لتحديد ما إذا كنت في الخيار #1 أو الخيار #2، ضع في اعتبارك هذه العوامل:

الخيار

الأفضل إذا كنت

المتطلب الأساسي

التبادل

الخيار #1: الهجرة الكاملة إلى السحابة

يمكن إزالة جميع خوادم MTA المحلية

مصادقة SMTP عبر 587/2525 أو واجهة برمجة التطبيقات REST

يتطلب إعادة هيكلة أي منطق متقدم محلي

الخيار #2: التوجيه الهجين

تحتاج إلى معالجة مسبقة أو دعم تراثي

يظل Momentum أو PowerMTA متصلين بالإنترنت

زيادة التعقيد التشغيلي


  • هل تستخدم محرك البرمجة Lua من Momentum لأي شيء أكثر تعقيدًا من توجيه الرسائل؟

    • Lua هو أداة نصية شاملة لتعديل الرسائل في الوقت الفعلي، ولكن الغالبية العظمى من مستخدمينا يستخدمونه فقط لاختيار ربط للتسليم. إذا كان هذا هو الحال، يمكنك تعديل كود الجيل الخاص بك لإضافة خاصية ip_pool إلى رأس X-MSYS-API وترك Bird يحدد المسار لك. 

    • إذا كنت تستخدم Lua للقيام بأشياء أكثر تعقيدًا مثل تصفية المحتوى، إعادة كتابة Mail_From، أو حسابات وتيرة الرسائل، وإذا لم يكن من الممكن نقل تلك المنطق إلى تطبيق الإدخال الخاص بك، فقد ترغب في التفكير في الانتقال إلى خيار #2.

  • هل نظام الجيل الخاص بك قادر على إرسال الرسائل عبر المنفذ 587 باستخدام TLS وSMTP_Auth؟

    • يمكن لبعض أنظمة إدارة الحملات دفع البريد فقط عبر المنفذ 25 بنص واضح. هذا يسبب مشكلة أمنية لـ Bird، لذا قد ترغب في التفكير في خيار #2

  • هل تستخدم صيغة استبدال PowerMTA أو تغييرات أخرى في الرسائل أثناء التشغيل؟

    • إذا كان بإمكانك نقل هذه الوظيفة إلى منشئي الرسائل لديك أو استخدام لغة القوالب من Bird، فقد لا يزال بإمكانك استخدام الخيار 1، لكن بخلاف ذلك، قد تحتاج إلى التفكير في إبقاء عقدة PMTA متصلة بالإنترنت لهذا التعديل قبل الشحن إلى Bird للتسليم.

  • هل تحتاج إلى أي مسح AV/AS وارد قبل حقن الرسائل؟ على الرغم من أن هذا ممكن في Momentum وPowerMTA، فإن eBird يفترض أنك قد قمت بالفعل بإجراء جميع هذه الفحوصات.  قد ترغب في التفكير في القيام بذلك قبل الحقن.

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

بالنسبة للخيار رقم 1 معسكر (التوقف المفاجئ):

لنُفترض أنك موافق على الخيار 1 وأنك مستعد لإيقاف MTAs الخاصة بك في الموقع وأنك قررت الاستمرار في استخدام طريقة حقن SMTP، دون تغيير أنظمة إنشاء الرسائل الخاصة بك على الإطلاق.  يجب أن تنشئ أنظمة الجيل الخاصة بك رسالة SMTP مُنسقة بالكامل، ثم تضغط إلى Bird عبر TLS باستخدام SMTP_AUTH حيث يكون اسم المستخدم وكلمة المرور كما هو موضح في هذه الصفحة. تذكر أن "كلمة المرور" هي مفتاح API الذي تقوم بإنشائه في حساب Bird الخاص بك مع تفعيل خيار تسليم SMTP.

إذا كنت في معسكر الخيار #1، فكر في التحويل إلى واجهة برمجة التطبيقات REST مباشرة من نظام الجيل الخاص بك. في معظم الحالات، نجد أن أنظمة معالجة العملاء تستخدم بالفعل JSON عبر HTTP ويجب أن تتحول إلى SMTP قبل الحقن. يمكنك تخطي تلك الخطوة وإرسالها مباشرة إلينا كـ حمولة REST بتنسيق JSON.

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

واحدة من أكبر المخاوف التي تواجهها ESPs الكبيرة مع الهجرة هي تسخين IP. عادةً ما قضوا سنوات عديدة في الاعتناء بمخزونهم من عناوين IP بعناية شديدة، لذلك فإن التفكير في التخلي عن كل ذلك العمل مؤلم. قامت Bird بتطوير عملية Bring Your Own IP (BYOIP) التي تعالج هذه المشكلة. إذا كان لديك على الأقل كتلة CIDR متصلة /24، يمكن لـ Bird استخدام تلك عناوين IP الموجودة للتسليم، مما يوفر لك عناء الحاجة إلى تسخينها مرة أخرى. إذا كنت قادرًا على الاستفادة من ذلك الخيار، يمكنك تخطي القسم هنا حول تسخين IP.

إذا شعرت أنك مستعد للذهاب هنا، تخط إلى "جعلها تحدث"

لنُفترض أنك موافق على الخيار 1 وأنك مستعد لإيقاف MTAs الخاصة بك في الموقع وأنك قررت الاستمرار في استخدام طريقة حقن SMTP، دون تغيير أنظمة إنشاء الرسائل الخاصة بك على الإطلاق.  يجب أن تنشئ أنظمة الجيل الخاصة بك رسالة SMTP مُنسقة بالكامل، ثم تضغط إلى Bird عبر TLS باستخدام SMTP_AUTH حيث يكون اسم المستخدم وكلمة المرور كما هو موضح في هذه الصفحة. تذكر أن "كلمة المرور" هي مفتاح API الذي تقوم بإنشائه في حساب Bird الخاص بك مع تفعيل خيار تسليم SMTP.

إذا كنت في معسكر الخيار #1، فكر في التحويل إلى واجهة برمجة التطبيقات REST مباشرة من نظام الجيل الخاص بك. في معظم الحالات، نجد أن أنظمة معالجة العملاء تستخدم بالفعل JSON عبر HTTP ويجب أن تتحول إلى SMTP قبل الحقن. يمكنك تخطي تلك الخطوة وإرسالها مباشرة إلينا كـ حمولة REST بتنسيق JSON.

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

واحدة من أكبر المخاوف التي تواجهها ESPs الكبيرة مع الهجرة هي تسخين IP. عادةً ما قضوا سنوات عديدة في الاعتناء بمخزونهم من عناوين IP بعناية شديدة، لذلك فإن التفكير في التخلي عن كل ذلك العمل مؤلم. قامت Bird بتطوير عملية Bring Your Own IP (BYOIP) التي تعالج هذه المشكلة. إذا كان لديك على الأقل كتلة CIDR متصلة /24، يمكن لـ Bird استخدام تلك عناوين IP الموجودة للتسليم، مما يوفر لك عناء الحاجة إلى تسخينها مرة أخرى. إذا كنت قادرًا على الاستفادة من ذلك الخيار، يمكنك تخطي القسم هنا حول تسخين IP.

إذا شعرت أنك مستعد للذهاب هنا، تخط إلى "جعلها تحدث"

لنُفترض أنك موافق على الخيار 1 وأنك مستعد لإيقاف MTAs الخاصة بك في الموقع وأنك قررت الاستمرار في استخدام طريقة حقن SMTP، دون تغيير أنظمة إنشاء الرسائل الخاصة بك على الإطلاق.  يجب أن تنشئ أنظمة الجيل الخاصة بك رسالة SMTP مُنسقة بالكامل، ثم تضغط إلى Bird عبر TLS باستخدام SMTP_AUTH حيث يكون اسم المستخدم وكلمة المرور كما هو موضح في هذه الصفحة. تذكر أن "كلمة المرور" هي مفتاح API الذي تقوم بإنشائه في حساب Bird الخاص بك مع تفعيل خيار تسليم SMTP.

إذا كنت في معسكر الخيار #1، فكر في التحويل إلى واجهة برمجة التطبيقات REST مباشرة من نظام الجيل الخاص بك. في معظم الحالات، نجد أن أنظمة معالجة العملاء تستخدم بالفعل JSON عبر HTTP ويجب أن تتحول إلى SMTP قبل الحقن. يمكنك تخطي تلك الخطوة وإرسالها مباشرة إلينا كـ حمولة REST بتنسيق JSON.

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

واحدة من أكبر المخاوف التي تواجهها ESPs الكبيرة مع الهجرة هي تسخين IP. عادةً ما قضوا سنوات عديدة في الاعتناء بمخزونهم من عناوين IP بعناية شديدة، لذلك فإن التفكير في التخلي عن كل ذلك العمل مؤلم. قامت Bird بتطوير عملية Bring Your Own IP (BYOIP) التي تعالج هذه المشكلة. إذا كان لديك على الأقل كتلة CIDR متصلة /24، يمكن لـ Bird استخدام تلك عناوين IP الموجودة للتسليم، مما يوفر لك عناء الحاجة إلى تسخينها مرة أخرى. إذا كنت قادرًا على الاستفادة من ذلك الخيار، يمكنك تخطي القسم هنا حول تسخين IP.

إذا شعرت أنك مستعد للذهاب هنا، تخط إلى "جعلها تحدث"

استغلال الخيار رقم 2 (ما قبل المعالجة على الموقع):

إذا كنت، مع ذلك، في الفريق الخيار رقم 2، فإنك ستريد إضافة بعض التغييرات في الإعدادات إلى نشر الخاص بك. أقل طريقة مؤلمة لنقل بعض تدفقات الرسائل المختارة من Momentum أو PMTA إلى Bird مع الاستمرار في استخدام حقن SMTP من أنظمة الجيل الخاصة بك هي إضافة مسار خاص في إعدادك.

بالنسبة لمomentum:

  1. قم بإعداد إصدار من Momentum > 3.6.23. 

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ الصادر 587 بحيث يمكن لمomentum التحدث إلى Bird. قم بتكوين نطاق صادر بحيث يمكنك توجيه رسالة عبر momentum إلى Bird. 

  3. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. قم بتكوين الروابط التي ترغب في توجيهها عبر MessageBird مع TLS وقم بتوجيهها إلى النطاق الذي عرّفته أعلاه.

    ملاحظة: TLS ليس مطلوبًا بشكل صارم ولكن يُعتبر توصية قوية. إذا كان TLS غير ممكن لسبب ما، فإن السماح لقوائم IP بمفاتيح API أيضًا يُعتبر توصية قوية.

    binding "CustomerA-Outbound" {
      Gateway = "smtp-demo.sparkpostelite.com"
      TLS = "required"
      TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt"
      TLS_Key = "/etc/pki/tls/certs/trymsys.net.key"
      TLS_Ciphers = "DEFAULT"
    }

بالنسبة لـ PowerMTA:

  1. قم بإعداد إصدار من PowerMTA > 4.5.0

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ 587 بحيث يمكن لـ PowerMTA التحدث إلى Bird.

  3. قم بتكوين مسار نطاق صادر بحيث يمكنك توجيه رسالة عبر PowerMTA إلى Bird. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.  في PowerMTA، هنا أيضًا يمكنك ضبط TLS. ملاحظة أن هذا موثق بشكل أكثر تفصيلًا هنا 

<domain sparkpost.rollup>
  use-unencrypted-plain-auth yes
  auth-username SMTP_Injection
  auth-password YourAPIKeygoesherewhenyougenerateit
  route smtp.sparkpostmail.com:587
  use-starttls yes
  require-starttls yes
  max-smtp-out 10
</domain>

4. قم بتكوين VMTAs التي ترغب في توجيهها عبر Bird مع إعداد rollup {sparkpost} الذي عرّفته أعلاه.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

بمجرد إجراء تلك التغييرات في التكوين، يجب أن يتم توجيه أي رسائل تُرسل إلى "الربط" أو "VMTA" المحددة تلقائيًا عبر Bird للتسليم.  

إذا كنت، مع ذلك، في الفريق الخيار رقم 2، فإنك ستريد إضافة بعض التغييرات في الإعدادات إلى نشر الخاص بك. أقل طريقة مؤلمة لنقل بعض تدفقات الرسائل المختارة من Momentum أو PMTA إلى Bird مع الاستمرار في استخدام حقن SMTP من أنظمة الجيل الخاصة بك هي إضافة مسار خاص في إعدادك.

بالنسبة لمomentum:

  1. قم بإعداد إصدار من Momentum > 3.6.23. 

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ الصادر 587 بحيث يمكن لمomentum التحدث إلى Bird. قم بتكوين نطاق صادر بحيث يمكنك توجيه رسالة عبر momentum إلى Bird. 

  3. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. قم بتكوين الروابط التي ترغب في توجيهها عبر MessageBird مع TLS وقم بتوجيهها إلى النطاق الذي عرّفته أعلاه.

    ملاحظة: TLS ليس مطلوبًا بشكل صارم ولكن يُعتبر توصية قوية. إذا كان TLS غير ممكن لسبب ما، فإن السماح لقوائم IP بمفاتيح API أيضًا يُعتبر توصية قوية.

    binding "CustomerA-Outbound" {
      Gateway = "smtp-demo.sparkpostelite.com"
      TLS = "required"
      TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt"
      TLS_Key = "/etc/pki/tls/certs/trymsys.net.key"
      TLS_Ciphers = "DEFAULT"
    }

بالنسبة لـ PowerMTA:

  1. قم بإعداد إصدار من PowerMTA > 4.5.0

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ 587 بحيث يمكن لـ PowerMTA التحدث إلى Bird.

  3. قم بتكوين مسار نطاق صادر بحيث يمكنك توجيه رسالة عبر PowerMTA إلى Bird. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.  في PowerMTA، هنا أيضًا يمكنك ضبط TLS. ملاحظة أن هذا موثق بشكل أكثر تفصيلًا هنا 

<domain sparkpost.rollup>
  use-unencrypted-plain-auth yes
  auth-username SMTP_Injection
  auth-password YourAPIKeygoesherewhenyougenerateit
  route smtp.sparkpostmail.com:587
  use-starttls yes
  require-starttls yes
  max-smtp-out 10
</domain>

4. قم بتكوين VMTAs التي ترغب في توجيهها عبر Bird مع إعداد rollup {sparkpost} الذي عرّفته أعلاه.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

بمجرد إجراء تلك التغييرات في التكوين، يجب أن يتم توجيه أي رسائل تُرسل إلى "الربط" أو "VMTA" المحددة تلقائيًا عبر Bird للتسليم.  

إذا كنت، مع ذلك، في الفريق الخيار رقم 2، فإنك ستريد إضافة بعض التغييرات في الإعدادات إلى نشر الخاص بك. أقل طريقة مؤلمة لنقل بعض تدفقات الرسائل المختارة من Momentum أو PMTA إلى Bird مع الاستمرار في استخدام حقن SMTP من أنظمة الجيل الخاصة بك هي إضافة مسار خاص في إعدادك.

بالنسبة لمomentum:

  1. قم بإعداد إصدار من Momentum > 3.6.23. 

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ الصادر 587 بحيث يمكن لمomentum التحدث إلى Bird. قم بتكوين نطاق صادر بحيث يمكنك توجيه رسالة عبر momentum إلى Bird. 

  3. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.

    outbound_smtp_auth { }
    Keep_Message_Dicts_In_Memory = true
    Domain "smtp.sparkpostmail.com" {
      Remote_SMTP_Port = "587"
      Outbound_SMTP_AUTH_Type = "LOGIN"
      Outbound_SMTP_AUTH_user = "SMTP_Injection"
      Outbound_SMTP_AUTH_pass = "17258redacted8bd6cd7a8redacted8c22bce"
    }


  4. قم بتكوين الروابط التي ترغب في توجيهها عبر MessageBird مع TLS وقم بتوجيهها إلى النطاق الذي عرّفته أعلاه.

    ملاحظة: TLS ليس مطلوبًا بشكل صارم ولكن يُعتبر توصية قوية. إذا كان TLS غير ممكن لسبب ما، فإن السماح لقوائم IP بمفاتيح API أيضًا يُعتبر توصية قوية.

    binding "CustomerA-Outbound" {
      Gateway = "smtp-demo.sparkpostelite.com"
      TLS = "required"
      TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt"
      TLS_Key = "/etc/pki/tls/certs/trymsys.net.key"
      TLS_Ciphers = "DEFAULT"
    }

بالنسبة لـ PowerMTA:

  1. قم بإعداد إصدار من PowerMTA > 4.5.0

  2. قم بتثبيت شهادة SSL صالحة وافتح المنفذ 587 بحيث يمكن لـ PowerMTA التحدث إلى Bird.

  3. قم بتكوين مسار نطاق صادر بحيث يمكنك توجيه رسالة عبر PowerMTA إلى Bird. مع التكوين أدناه، أي رسالة تصطدم بهذا التكوين ستوجه إلى smtp.sparkpostmail.com باستخدام المنفذ 587 وSMTP_Auth مع اسم المستخدم وكلمة المرور المحددة هناك.  في PowerMTA، هنا أيضًا يمكنك ضبط TLS. ملاحظة أن هذا موثق بشكل أكثر تفصيلًا هنا 

<domain sparkpost.rollup>
  use-unencrypted-plain-auth yes
  auth-username SMTP_Injection
  auth-password YourAPIKeygoesherewhenyougenerateit
  route smtp.sparkpostmail.com:587
  use-starttls yes
  require-starttls yes
  max-smtp-out 10
</domain>

4. قم بتكوين VMTAs التي ترغب في توجيهها عبر Bird مع إعداد rollup {sparkpost} الذي عرّفته أعلاه.

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to {sparkpost}
  </domain>
</virtual-mta>

بمجرد إجراء تلك التغييرات في التكوين، يجب أن يتم توجيه أي رسائل تُرسل إلى "الربط" أو "VMTA" المحددة تلقائيًا عبر Bird للتسليم.  

جعلها تحدث

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

  1. قم بإعداد حساب Bird الخاص بك واختبره بالكامل باستخدام حساب فرعي للتطوير حتى تتمكن من تصفية تلك الحركة لاحقًا.  ستحتاج إلى القيام بذلك لأي من الخيارين لأنك ستحتاج إلى مفتاح API لكلمة مرور SMTP_Auth في كلتا الحالتين.

  2. إذا كنت تستخدم حقن SMTP، خطط لإضافة رأس X-MSYS-API لتضمين جميع البيانات التعريفية وسمات الرسالة المطلوبة.  يجب إعادة كتابة أي X-Headers كبيانات تعريف، ويجب أن تتضمن سمات ip_pool والحملة أيضًا. عينة متاحة هنا

  3. إذا لم تكن تستخدم BYOIP، فيجب عليك التأكد من إعداد مجالات إرسال مختلفة قليلاً لاستخدامها مع MessageBird حتى تتمكن من تشغيل كلا البيئتين بالتوازي طالما كان ذلك مطلوبًا.  إذا كان مجال الإرسال الحالي الخاص بك هو mycompany.com، يمكنك إعداد sp.mycompany.com خصيصًا لتسليم Bird.  هذا يتيح لك الانتقال ببطء وبعناية دون المساومة على أي من المجالين.

  4. تأكد من وجود توافق كامل للمجال وتمكين ميزات الأمان.  في DNS، قم بإعداد DKIM، SPF، DMARC، ودومينات الدفعات والتتبع حتى تبدو جميعها كما لو كانت تنتمي إلى نفس المنظمة.

  5. قم بتكوين الاحترار التلقائي لعنوان IP على IP_Pools المحددة لديك.  إذا كنت تستخدم الخيار BYOIP المذكور سابقًا، يمكنك تجاهل خطوة الاحترار.

  6. ابدأ بتدفق رسالة واحدة وانتقل من هناك.  تمامًا مثل الاحترار IP، لا ترغب في القيام بذلك دفعة واحدة. قم بتحويل بضع مئات من الرسائل أولاً، ثم 10% من الحجم، ثم 20% في اليوم التالي وزد حتى تنقل كل الحجم. إذا كنت مزود خدمة بريد إلكتروني، اختر عميلًا يمكنك العمل معه واختبر العملية بملاحظاتهم.  إذا كان كل شيء يعمل بشكل جيد، انتقل إلى التالي. إذا واجهت مشاكل، خذ الوقت لإصلاحها ودمجها في العملية للذي يليه.

  7. قم بأتمتة أكبر قدر ممكن باستخدام APIs.  باستثناء تغييرات DNS، يمكن أتمتة إعداد SparkPost بشكل كبير مع بعض مكالمات API.

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

  1. قم بإعداد حساب Bird الخاص بك واختبره بالكامل باستخدام حساب فرعي للتطوير حتى تتمكن من تصفية تلك الحركة لاحقًا.  ستحتاج إلى القيام بذلك لأي من الخيارين لأنك ستحتاج إلى مفتاح API لكلمة مرور SMTP_Auth في كلتا الحالتين.

  2. إذا كنت تستخدم حقن SMTP، خطط لإضافة رأس X-MSYS-API لتضمين جميع البيانات التعريفية وسمات الرسالة المطلوبة.  يجب إعادة كتابة أي X-Headers كبيانات تعريف، ويجب أن تتضمن سمات ip_pool والحملة أيضًا. عينة متاحة هنا

  3. إذا لم تكن تستخدم BYOIP، فيجب عليك التأكد من إعداد مجالات إرسال مختلفة قليلاً لاستخدامها مع MessageBird حتى تتمكن من تشغيل كلا البيئتين بالتوازي طالما كان ذلك مطلوبًا.  إذا كان مجال الإرسال الحالي الخاص بك هو mycompany.com، يمكنك إعداد sp.mycompany.com خصيصًا لتسليم Bird.  هذا يتيح لك الانتقال ببطء وبعناية دون المساومة على أي من المجالين.

  4. تأكد من وجود توافق كامل للمجال وتمكين ميزات الأمان.  في DNS، قم بإعداد DKIM، SPF، DMARC، ودومينات الدفعات والتتبع حتى تبدو جميعها كما لو كانت تنتمي إلى نفس المنظمة.

  5. قم بتكوين الاحترار التلقائي لعنوان IP على IP_Pools المحددة لديك.  إذا كنت تستخدم الخيار BYOIP المذكور سابقًا، يمكنك تجاهل خطوة الاحترار.

  6. ابدأ بتدفق رسالة واحدة وانتقل من هناك.  تمامًا مثل الاحترار IP، لا ترغب في القيام بذلك دفعة واحدة. قم بتحويل بضع مئات من الرسائل أولاً، ثم 10% من الحجم، ثم 20% في اليوم التالي وزد حتى تنقل كل الحجم. إذا كنت مزود خدمة بريد إلكتروني، اختر عميلًا يمكنك العمل معه واختبر العملية بملاحظاتهم.  إذا كان كل شيء يعمل بشكل جيد، انتقل إلى التالي. إذا واجهت مشاكل، خذ الوقت لإصلاحها ودمجها في العملية للذي يليه.

  7. قم بأتمتة أكبر قدر ممكن باستخدام APIs.  باستثناء تغييرات DNS، يمكن أتمتة إعداد SparkPost بشكل كبير مع بعض مكالمات API.

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

  1. قم بإعداد حساب Bird الخاص بك واختبره بالكامل باستخدام حساب فرعي للتطوير حتى تتمكن من تصفية تلك الحركة لاحقًا.  ستحتاج إلى القيام بذلك لأي من الخيارين لأنك ستحتاج إلى مفتاح API لكلمة مرور SMTP_Auth في كلتا الحالتين.

  2. إذا كنت تستخدم حقن SMTP، خطط لإضافة رأس X-MSYS-API لتضمين جميع البيانات التعريفية وسمات الرسالة المطلوبة.  يجب إعادة كتابة أي X-Headers كبيانات تعريف، ويجب أن تتضمن سمات ip_pool والحملة أيضًا. عينة متاحة هنا

  3. إذا لم تكن تستخدم BYOIP، فيجب عليك التأكد من إعداد مجالات إرسال مختلفة قليلاً لاستخدامها مع MessageBird حتى تتمكن من تشغيل كلا البيئتين بالتوازي طالما كان ذلك مطلوبًا.  إذا كان مجال الإرسال الحالي الخاص بك هو mycompany.com، يمكنك إعداد sp.mycompany.com خصيصًا لتسليم Bird.  هذا يتيح لك الانتقال ببطء وبعناية دون المساومة على أي من المجالين.

  4. تأكد من وجود توافق كامل للمجال وتمكين ميزات الأمان.  في DNS، قم بإعداد DKIM، SPF، DMARC، ودومينات الدفعات والتتبع حتى تبدو جميعها كما لو كانت تنتمي إلى نفس المنظمة.

  5. قم بتكوين الاحترار التلقائي لعنوان IP على IP_Pools المحددة لديك.  إذا كنت تستخدم الخيار BYOIP المذكور سابقًا، يمكنك تجاهل خطوة الاحترار.

  6. ابدأ بتدفق رسالة واحدة وانتقل من هناك.  تمامًا مثل الاحترار IP، لا ترغب في القيام بذلك دفعة واحدة. قم بتحويل بضع مئات من الرسائل أولاً، ثم 10% من الحجم، ثم 20% في اليوم التالي وزد حتى تنقل كل الحجم. إذا كنت مزود خدمة بريد إلكتروني، اختر عميلًا يمكنك العمل معه واختبر العملية بملاحظاتهم.  إذا كان كل شيء يعمل بشكل جيد، انتقل إلى التالي. إذا واجهت مشاكل، خذ الوقت لإصلاحها ودمجها في العملية للذي يليه.

  7. قم بأتمتة أكبر قدر ممكن باستخدام APIs.  باستثناء تغييرات DNS، يمكن أتمتة إعداد SparkPost بشكل كبير مع بعض مكالمات API.

جمع البيانات من الطيور

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

<?php
$verb = $_SERVER['REQUEST_METHOD'];
if ($verb === "POST") {
    $jsonStr = file_get_contents("php://input");
    http_response_code(200);
    $rnum = rand(1000, 9999);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

أثناء تجربتك، يمكنك تجربتها مع جامعي بيانات مجانيين مثل http://webhook.site/.

بمجرد أن تجمع كل بيانات الويب هوكس، يمكنك قراءة ذلك في مستودع بيانات لمزيد من المعالجة.  هناك أيضًا طرق لدفع الويب هوكس من خلال خدمات مثل StitchData و Segment.

المعلومات نفسها متاحة في واجهة برمجة أحداث API إذا كنت بحاجة لسحب البيانات ولا يمكنك قبول بيانات الدفع.  إليك مثال على استدعاء واجهة برمجة الأحداث:
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

توجد توثيقات كاملة لهذه واجهة برمجة التطبيقات مع أمثلة هنا:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

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

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

<?php
$verb = $_SERVER['REQUEST_METHOD'];
if ($verb === "POST") {
    $jsonStr = file_get_contents("php://input");
    http_response_code(200);
    $rnum = rand(1000, 9999);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

أثناء تجربتك، يمكنك تجربتها مع جامعي بيانات مجانيين مثل http://webhook.site/.

بمجرد أن تجمع كل بيانات الويب هوكس، يمكنك قراءة ذلك في مستودع بيانات لمزيد من المعالجة.  هناك أيضًا طرق لدفع الويب هوكس من خلال خدمات مثل StitchData و Segment.

المعلومات نفسها متاحة في واجهة برمجة أحداث API إذا كنت بحاجة لسحب البيانات ولا يمكنك قبول بيانات الدفع.  إليك مثال على استدعاء واجهة برمجة الأحداث:
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

توجد توثيقات كاملة لهذه واجهة برمجة التطبيقات مع أمثلة هنا:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

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

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

<?php
$verb = $_SERVER['REQUEST_METHOD'];
if ($verb === "POST") {
    $jsonStr = file_get_contents("php://input");
    http_response_code(200);
    $rnum = rand(1000, 9999);
    $timestamp = date("YmdHis") . $rnum;
    $filePath = './data/data_' . $timestamp . '.txt';
    // Handle duplicate filenames (edge case)
    if (file_exists($filePath)) {
        $baseName = basename($filePath, ".txt");
        $seq = 0;
        $ftail = substr($baseName, -2, 1);
        if ($ftail === "-") {
            $seq = (int)

أثناء تجربتك، يمكنك تجربتها مع جامعي بيانات مجانيين مثل http://webhook.site/.

بمجرد أن تجمع كل بيانات الويب هوكس، يمكنك قراءة ذلك في مستودع بيانات لمزيد من المعالجة.  هناك أيضًا طرق لدفع الويب هوكس من خلال خدمات مثل StitchData و Segment.

المعلومات نفسها متاحة في واجهة برمجة أحداث API إذا كنت بحاجة لسحب البيانات ولا يمكنك قبول بيانات الدفع.  إليك مثال على استدعاء واجهة برمجة الأحداث:
GET https://api.sparkpost.com/api/v1/events/message?/

recipients=recipient@example.com&templates=my-template&events

توجد توثيقات كاملة لهذه واجهة برمجة التطبيقات مع أمثلة هنا:  https://developers.sparkpost.com/api/events/#events-get-search-for-message-events

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

تقرير موجز

تأكد من أنك تتحدث إلى فريق إدارة المبيعات والنجاح لديك.  لقد قمنا بذلك من قبل ويمكننا مساعدتك في ذلك بسرعة وبتكلفة فعالة.

  1. حدد ما إذا كنت في معسكر #1 (قادر على الانتقال بالكامل من على الأرض) أو معسكر #2 (تحتاج لا يزال بعض MTA على الأرض).

  2. سجل للحصول على حساب اختبار مجاني لتقييم تفاصيل الدمج.

  3. حدد على SMTP أو أساليب إدخال REST API.

  4. إذا كنت تستخدم إدخال SMTP، فحدد كيفية الحصول على بيانات الرأس وخصائص الرسالة في رأس X-MSYS-API.

  5. أكد إذا كان يمكنك استخدام عمليتنا BYOIP.

  6. قم بتحديث DNS الخاص بك مع مجالات جديدة إذا لزم الأمر.

  7. قم بإنشاء نموذج صغير لاختبار هجرتك.  قد تحتاج إلى ضبط إعداداتك.

  8. قم بتعزيز الحجم حتى يتم نقل كل الحركة.

  9. إذا كنت في معسكر #1، يمكنك أخيرًا إيقاف تشغيل MTA الخاص بك بعد نقل كل الحركة.

عند التخطيط لتغييرات DNS لأنظمة البريد الإلكتروني ذات الحجم الكبير، كن على دراية بالتحديات المحتملة في توسيع DNS على AWS التي يمكن أن تؤثر على أداء توصيل البريد الإلكتروني على نطاق واسع.

تأكد من أنك تتحدث إلى فريق إدارة المبيعات والنجاح لديك.  لقد قمنا بذلك من قبل ويمكننا مساعدتك في ذلك بسرعة وبتكلفة فعالة.

  1. حدد ما إذا كنت في معسكر #1 (قادر على الانتقال بالكامل من على الأرض) أو معسكر #2 (تحتاج لا يزال بعض MTA على الأرض).

  2. سجل للحصول على حساب اختبار مجاني لتقييم تفاصيل الدمج.

  3. حدد على SMTP أو أساليب إدخال REST API.

  4. إذا كنت تستخدم إدخال SMTP، فحدد كيفية الحصول على بيانات الرأس وخصائص الرسالة في رأس X-MSYS-API.

  5. أكد إذا كان يمكنك استخدام عمليتنا BYOIP.

  6. قم بتحديث DNS الخاص بك مع مجالات جديدة إذا لزم الأمر.

  7. قم بإنشاء نموذج صغير لاختبار هجرتك.  قد تحتاج إلى ضبط إعداداتك.

  8. قم بتعزيز الحجم حتى يتم نقل كل الحركة.

  9. إذا كنت في معسكر #1، يمكنك أخيرًا إيقاف تشغيل MTA الخاص بك بعد نقل كل الحركة.

عند التخطيط لتغييرات DNS لأنظمة البريد الإلكتروني ذات الحجم الكبير، كن على دراية بالتحديات المحتملة في توسيع DNS على AWS التي يمكن أن تؤثر على أداء توصيل البريد الإلكتروني على نطاق واسع.

تأكد من أنك تتحدث إلى فريق إدارة المبيعات والنجاح لديك.  لقد قمنا بذلك من قبل ويمكننا مساعدتك في ذلك بسرعة وبتكلفة فعالة.

  1. حدد ما إذا كنت في معسكر #1 (قادر على الانتقال بالكامل من على الأرض) أو معسكر #2 (تحتاج لا يزال بعض MTA على الأرض).

  2. سجل للحصول على حساب اختبار مجاني لتقييم تفاصيل الدمج.

  3. حدد على SMTP أو أساليب إدخال REST API.

  4. إذا كنت تستخدم إدخال SMTP، فحدد كيفية الحصول على بيانات الرأس وخصائص الرسالة في رأس X-MSYS-API.

  5. أكد إذا كان يمكنك استخدام عمليتنا BYOIP.

  6. قم بتحديث DNS الخاص بك مع مجالات جديدة إذا لزم الأمر.

  7. قم بإنشاء نموذج صغير لاختبار هجرتك.  قد تحتاج إلى ضبط إعداداتك.

  8. قم بتعزيز الحجم حتى يتم نقل كل الحركة.

  9. إذا كنت في معسكر #1، يمكنك أخيرًا إيقاف تشغيل MTA الخاص بك بعد نقل كل الحركة.

عند التخطيط لتغييرات DNS لأنظمة البريد الإلكتروني ذات الحجم الكبير، كن على دراية بالتحديات المحتملة في توسيع DNS على AWS التي يمكن أن تؤثر على أداء توصيل البريد الإلكتروني على نطاق واسع.

أخبار أخرى

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

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.

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