دليل · Mailgun API

كيف ينفّذ فريق المنتج Mailgun API بأمان؟

نفّذ Mailgun API خلف عامل خادم مصرّح به. وثّق نطاق الإرسال الدقيق، واستخدم أضيق بيانات اعتماد API متاحة، وأنشئ مهمة إرسال داخلية دائمة، وأرسل بيانات نموذج متعددة الأجزاء (multipart form data) إلى نقطة Messages المحصورة بالنطاق. خزّن معرّف الرسالة الذي يعيده Mailgun، وصادق على طلبات webhook قبل معالجتها، وأزل تكرار الأحداث، وطبّق الارتدادات والشكاوى وإلغاءات الاشتراك وقت الإرسال. أبقِ قبول API ومعالجة Mailgun والتسليم إلى الخادم المستقبِل والوصول إلى صندوق الوارد حالات منفصلة.

حدد عملية منتج ضيقة قبل استدعاء Mailgun

ابدأ بحدث منتج معتمد مثل التحقق من الحساب أو إيصال أو تنبيه أمني أو إشعار طلبه المستلِم. ضع Mailgun خلف خدمة تطبيق موثوقة أو عامل طابور بدلًا من كشف بيانات اعتماد المزوّد أو نموذج رسالة تعسفي للمتصفحات وتطبيقات الجوال. فوّض المستدعي والمستأجر وهوية المُرسِل والمستلِم وفئة الرسالة والقالب قبل إنشاء حقول المزوّد. خزّن سجلًا صادرًا داخليًا بمفتاح حدث ثابت ومستأجر وإصدار قالب وعناوين معتمدة وحالة أولية. هذا السجل هو نظام القرار؛ أما Mailgun فهو تبعية النقل. يجعل فصل نية العمل عن حمولات المزوّد إعادة المحاولة والتدقيق أكثر أمانًا ويُبقي ترحيل المزوّد لاحقًا ممكنًا. ينبغي أن تبقى الحركة المعاملاتية والحركة المعتمدة على الموافقة متمايزتين في نموذج البيانات حتى لا تتحول تفضيلات المستلِمين وقواعد المنع وحوادث السمعة إلى عُرف غير رسمي في القوالب.

وثّق نطاق الإرسال الدقيق وسجلات DNS

أضف نطاقًا تتحكم فيه المؤسسة وانشر سجلات DNS التي يقدمها Mailgun حاليًا للتوثيق والمصادقة والتتبع وميزات الاستقبال المختارة فعلًا. راجع سجلات SPF وDMARC الحالية قبل تغيير DNS. لا تنشئ سجل SPF ثانيًا عند اسم مضيف واحد ولا تستبدل سياسة DMARC تنظيمية دون موافقة مالكها. تحقق من From وهوية التوقيع الفعليين اللذين يستخدمهما عبء العمل، لا من نطاق أب مجاور فقط. استخدم نطاقًا فرعيًا مخصص الغرض عندما تبرر الملكية أو فصل الحركة أو الترحيل ذلك. بعد أن يبلّغ Mailgun بالتوثيق، افحص رسالة مستلَمة خاضعة للتحكم للتأكد من عنوان From الظاهر ونطاق توقيع DKIM وReturn-Path ونتائج المصادقة وسلوك الرد. توثيق المزوّد دليل على نجاح فحص الإعداد لديه. ولا يثبت موافقة المستلِم ولا قبول الوجهة ولا سمعة المُرسِل ولا الوصول إلى صندوق الوارد. احتفظ بسجل تغييرات DNS وتعليمات التراجع خارج لوحة تحكم المزوّد.

استخدم بيانات اعتماد محدودة الصلاحيات ونقطة النهاية الإقليمية الصحيحة

يوثّق Mailgun مصادقة HTTP Basic لواجهات API الخاصة به، مع بيانات اعتماد API تختلف بحسب الصلاحية والغرض. ينبغي أن يحصل عامل الإرسال فقط على بيانات الاعتماد اللازمة للنطاق والعملية المعتمدين. أبقِ مفاتيح الحساب الرئيسية ومفاتيح الإرسال للنطاق ومواد توقيع webhook وبيانات اعتماد البيئات الدنيا منفصلة. خزّن الأسرار مباشرةً في مخزن أسرار مُدار ولا تكشفها إلا لعملية الخادم التي تحتاجها. لا تضع بيانات الاعتماد أبدًا في شيفرة العميل أو التحكم بالمصدر أو عناوين URL أو السجلات أو التحليلات أو القوالب أو التذاكر أو المطالبات (prompts). اختر عنوان URL الأساسي لـ API الموثَّق لمنطقة الحساب بدلًا من افتراض أن كل النطاقات تستخدم المضيف نفسه. تمرّن على التدوير بإنشاء بديل بالصلاحيات نفسها وتحديث العامل والتحقق من الحركة والأحداث الخاضعة للتحكم ثم إلغاء بيانات الاعتماد القديمة. نبّه عند إخفاقات المصادقة والتفويض غير المتوقعة لأنها قد تدل على إلغاء أو منطقة خاطئة أو انحراف في الصلاحيات أو انكشاف.

ابنِ طلب Messages API واحدًا ودائمًا

تقبل نقطة Messages المحصورة بالنطاق في Mailgun حقول نموذج متعددة الأجزاء للمُرسِل والمستلِمين والموضوع ومحتوى النص أو HTML وخيارات موثَّقة مثل القوالب والمرفقات والترويسات والوسوم (tags) ومتغيرات المستلِمين والتتبع والتسليم المجدول. اكشف فقط المجموعة الفرعية التي يحتاجها المنتج. تحقق من صيغة العناوين وملكية المستأجر، وحدّ عدد المستلِمين والمرفقات، وارفض حقن الأسطر الجديدة، وولّد القوالب المعتمدة بمتغيرات ذات أنواع محددة. لا تضع أسرارًا أو بيانات شخصية غير ضرورية في الوسوم أو المتغيرات المخصصة أو الترويسات لأن أحداث المزوّد وعروض النشاط قد تُظهر البيانات الوصفية بمعزل عن محتوى الرسالة. أرسل من المهمة الداخلية المستحوَذ عليها وخزّن معرّف الرسالة الذي يعيده Mailgun مع المحاولة الدقيقة. أبقِ أسماء الخيارات الخاصة بالمزوّد داخل محوّل (adapter) واحد. ينبغي أن يتلقى منطق العمل نتيجة ضيقة هي مقبولة أو مرفوضة أو غير مؤكدة، لا أن يتعلم كل حقل وشكل خطأ في Mailgun.

صمّم إعادة المحاولة حول القبول والالتباس

صنّف الاستجابات قبل إعادة المحاولة. أصلح الحقول المشوّهة والنطاقات غير المصرّح بها وبيانات الاعتماد غير الصالحة وإخفاقات الأذونات وأخطاء السياسة الدائمة بدلًا من إعادة المحاولة. أعد محاولة إخفاقات النقل المؤهلة وأخطاء خادم المزوّد والطلبات المحدودة المعدّل بتراجع أُسّي مع jitter وعدد محدود من المحاولات وحدود لعمر الطابور. تعني استجابة API المقبولة من Mailgun أن المزوّد قبل طلب الإرسال للمعالجة؛ ولا تثبت أن الخادم الوجهة قبل الرسالة. مهلة العميل ملتبسة لأن Mailgun قد يكون قبل الطلب رغم أن العامل فاتته الاستجابة. أبقِ تلك المهمة في حالة غير معروفة، وابحث عن بيانات الربط المخزَّنة أو الأحداث اللاحقة، وطبّق قاعدة مطابقة مقصودة قبل إعادة الإرسال. لا يلغي النقل عبر Mailgun الحاجة إلى مفتاح حدث ثابت للتطبيق واستحواذ من عامل واحد وسجل محاولات وضوابط لخطر التكرار. نبّه عند الإخفاقات المتكررة بحسب بيانات الاعتماد والنطاق والقالب والمستأجر ومزوّد الوجهة.

صادق على طلبات webhook قبل تحليلها

اضبط نقطة webhook عبر HTTPS واحتفظ بالحقول الدقيقة التي يستخدمها إجراء التوقيع في Mailgun. يوثّق Mailgun طابعًا زمنيًا ورمزًا (token) وتوقيعًا مشتقًا بمفتاح توقيع webhook. تحقق من التوقيع بمقارنة ثابتة الزمن (constant-time) وارفض الطوابع الزمنية خارج نافذة الحداثة في التطبيق قبل قبول الحدث. تتبّع الرموز أو معرّفات الأحداث حسب الحاجة لمقاومة إعادة التشغيل. أبقِ مفتاح توقيع webhook منفصلًا عن بيانات اعتماد الإرسال ودوّره عبر عملية مختبَرة. طبّق حدودًا لحجم الطلب ولا تثق بعناوين URL أو المستلِمين أو الوسوم أو حقول الحدث لمجرد أن المتن يُحلَّل. بعد المصادقة، خزّن الحدث بشكل دائم أو ضعه في طابور قبل إرجاع استجابة نجاح. يمنع هذا انهيار العملية من إسقاط أدلة التسليم. يثبت التحقق من webhook المصدر والسلامة في ظل السر المضبوط؛ لكنه لا يثبت أن حدث العمل ينتمي إلى المستأجر المتوقع إلى أن يربط التطبيق النطاق ومعرّفات رسائل المزوّد.

عالج إعادة محاولات webhook والأحداث المكررة بشكل غير مكرَّر (idempotent)

يوثّق Mailgun سلوك إعادة محاولة webhook عندما لا تعيد نقطة النهاية استجابة النجاح المتوقعة. يجب أن يفترض المستقبِل تسليمًا متأخرًا ومتكررًا. أزل التكرار بمعرّف حدث ثابت من المزوّد عند توفره، أو بمركّب متحفظ لا يمكنه دمج مستلِمين أو أنواع أحداث مختلفة. احتفظ بوقت الحدوث الأصلي ووقت المعالجة منفصلين. اجعل انتقالات الحالة أحادية الاتجاه (monotonic) حتى لا تمحو ملاحظة قبول أو تسليم أقدم إخفاقًا دائمًا أو شكوى أو إلغاء اشتراك لاحقًا لمجرد وصول إعادة المحاولات بترتيب غير متسلسل. لا تُعِد استجابة نجاح إلا بعد الالتقاط الدائم، لكن أبقِ معالجة الأعمال المكلفة غير متزامنة ليبقى الطرف موثوقًا. راقب إخفاقات التوقيع وزمن الاستجابة وحجم إعادة المحاولات وتأخر الأحداث وسجلات الرسائل الميتة (dead-letter). احتفظ بحمولات المزوّد الخام بقدر ما تبرره الاحتياجات التشغيلية والسياسة فقط، مع وصول مقيّد وتقليل العناوين. webhook تدفق أدلة، وليس إذنًا بكشف سجل المستلِم عبر المستأجرين.

نمذج أحداث Mailgun دون المبالغة في تقدير التسليم

يوثّق Mailgun أنواع أحداث للقبول والتسليم والإخفاق المؤقت والدائم والفتح والنقر وإلغاء الاشتراك والشكوى والتخزين ونتائج المعالجة ذات الصلة. اربط هذه الأسماء بنموذج داخلي مع الاحتفاظ بنوع حدث المزوّد ومعرّف الرسالة ونطاق المستلِم والطابع الزمني والخطورة ورد SMTP المتاح. يصف accepted استقبال Mailgun أو تقدم الطابور. ويصف delivered ملاحظة التسليم الموثَّقة، وعادةً قبول الخادم الوجهة، لكنه لا يكشف المجلد النهائي لصندوق البريد. الفتح والنقر أدوات قياس تفاعل وليست دليل نقل، وقد تؤثر فيها تقنيات الخصوصية. يمكن للإخفاقات المؤقتة أن تبرر إعادة محاولة محدودة داخل نظام النقل؛ أما الإخفاقات الدائمة والشكاوى وإلغاءات الاشتراك فيجب أن تحدّث حالة سلامة المستلِم قبل إرسال أي مهمة تطبيق لاحقة. أبقِ سجل الأحداث للإضافة فقط (append-only) واشتق الحالة الظاهرة للمستخدم عبر قواعد صريحة ليستطيع الدعم التمييز بين الدليل والتفسير.

طبّق الإخفاقات والشكاوى وإلغاءات الاشتراك وقت الإرسال

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

ضع SendHQ في الاعتبار كبديل لـ Mailgun

يوفر SendHQ بريدًا معامَلاتيًا وبريدًا تسويقيًا قائمًا على الإذن مع إرسال نطاقات موثقة وبريد وارد وأحداث تسليم وقوائم منع. راجع وثائق API العامة واختبر المصادقة والحمولات والأخطاء والمعرّفات والأحداث والنطاقات وسير عمل سلامة المستلِم قبل الترحيل.

الأسئلة الشائعة

ما نقطة النهاية التي ترسل البريد عبر Mailgun API؟

يوثّق Mailgun نقطة `POST /v3/{domain}/messages` المحصورة بالنطاق وتستخدم بيانات نموذج متعددة الأجزاء ومصادقة HTTP Basic. استدعِها فقط من شيفرة مصرّح بها على جهة الخادم.

هل ينبغي وضع مفتاح Mailgun API في شيفرة المتصفح؟

لا. خزّن أنسب بيانات اعتماد وأضيقها في مدير أسرار على جهة الخادم. أبقِ صلاحيات الإنتاج والبيئات الدنيا وإدارة الحساب وإرسال النطاق وتوقيع webhook منفصلة.

هل يعني قبول Mailgun API أن البريد سُلِّم؟

لا. إنه يعني أن Mailgun قبل الطلب للمعالجة. يمكن لأحداث موثَّقة المصدر أن تبلّغ لاحقًا عن التسليم إلى الخادم الوجهة أو الإخفاق، بينما يبقى الوصول إلى صندوق الوارد نتيجة منفصلة من جهة المستلِم.

كيف ينبغي مصادقة webhooks في Mailgun؟

تحقق من الطابع الزمني والرمز والتوقيع الموثَّقة من Mailgun بمفتاح توقيع webhook قبل المعالجة. طبّق ضوابط الحداثة وإعادة التشغيل، ثم التقط الحدث بشكل دائم قبل الإقرار به.

هل ينبغي إعادة محاولة كل إخفاق في Mailgun API؟

لا. صحّح أخطاء التحقق والمصادقة والنطاق والأذونات وسياسة الرفض الدائمة. استخدم تراجعًا محدودًا للإخفاقات العابرة المؤهلة، وطابِق المهلات الملتبسة قبل إعادة الإرسال.

هل يمكن أن يحل SendHQ محل Mailgun؟

ربما. يوفر SendHQ بريدًا معامَلاتيًا وبريدًا تسويقيًا قائمًا على الإذن مع إرسال نطاقات موثقة وبريد وارد وأحداث تسليم وقوائم منع. راجع وثائق API العامة واختبر تكاملك قبل الترحيل.

المصادر