كيفية استخدام Amazon Simple Email Service (SES) لاستبدال خادم البريد الإلكتروني القائم على الخادم

ذات يوم جيد ، وبدون سبب واضح ، توقف خادم الأعمال Ubuntu 18.04 الخاص بي عن إعادة توجيه البريد إلى عنوان Gmail الخاص بي.

في اليوم السابق فقط ، كانت الملفات .forward التي أنشأتها في الدلائل الرئيسية لحسابات الخادم المحلي التي أستخدمها للبريد الإلكتروني - مثل / home/office/.forward - تعيد توجيه كل البريد الموجه إلى عناوين عملي اليومية إلى بلدي -استخدام حساب Gmail. ثم توقفوا فجأة.

عندما لاحظت وجود خطأ ما ، استشرت على الفور سجلات الخادم. /var/log/mail.err كان يبث رسائل ساحرة تتضمن أشياء مثل:

status=deferred (delivery temporarily suspended: connect to alt2.gmail-smtp-in.l.google.com[219.8.202.27]:25: Connection timed out)

أخبرني التحقق من علب بريد الخادم أن البريد قادم ، لكن Postfix لم يتمكن من إنشاء اتصال بـ Gmail لإعادة توجيه الرسائل إلى عنواني.

بطبيعة الحال ، قمت بإعادة تشغيل Postfix ، لكن ذلك لم يساعد.

sudo systemctl restart postfix

لقد أكدت أنه لا يوجد شيء يمنع الرسائل الصادرة من مغادرة خادمي على المنفذ 25 (SMTP). ثم تحققت للتأكد من عدم إدراج نطاقي في القائمة السوداء بطريقة ما (هناك العديد من الأدوات عبر الإنترنت التي ستفعل ذلك من أجلك) ، وألقيت نظرة خاطفة على حالة سجلات MX الخاصة بي عن طريق تشغيل الحفر من سطر الأوامر:

dig MX bootstrap-it.com

لا شيء يفعل. يبدو أن كل شيء يتم سحبه.

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

لكوني مهندس حلول AWS وشاركت في تأليف كتابين لـ Wiley / Sybex على AWS (أحدهما دليل لامتحان Cloud Practitioners والآخر لامتحان Solutions Architect Associate) ، لا ينبغي أن أكون مستعدًا وقادرًا على بناء مجموعتي الخاصة من أدوات AWS التي ستتعامل مع احتياجات خادم البريد الإلكتروني الخاص بي في السحابة؟

حسنًا ، اتضح أنني كنت على استعداد - وبعد بعض الأبحاث الجادة والتجربة والخطأ - كنت قادرًا. يتطلب القيام بذلك:

  • إنشاء حاوية S3 حيث سيتم تخزين رسائل البريد الإلكتروني الواردة.
  • إنشاء موضوع خدمة إعلام بسيط (SNS) لإرسال إشعار إليّ عبر البريد الإلكتروني في كل مرة يصل فيها بريد إلكتروني جديد.
  • تكوين خدمة البريد الإلكتروني البسيطة من Amazon (SES) لتولي مجال البريد الإلكتروني الخاص بي (bootstrap-it.com) والتعامل مع البريد الوارد. يتضمن ذلك إضافة سجل MX إلى المسار 53 (حيث تتم إدارة المجالات الخاصة بي) وتوجيه SES إلى المجال الخاص بي ؛ إضافة والتحقق من كل عنوان بريد إلكتروني أريد أن تتحكم فيه SES ؛ ثم إخبار SES بإرسال رسائل جديدة إلى حاوية S3 الخاصة بي أثناء تشغيل تنبيه لموضوع SNS.
  • بافتراض أنك سترغب أيضًا في إرسال رسائل بريد إلكتروني من خلال الخدمة ، فمن الجيد أيضًا تكوين SES لتوقيع رسائلك الصادرة باستخدام DomainKeys Identified Mail (DKIM).

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

سيتعين عليك إضافة سجل MX إلى المنطقة المستضافة DNS الخاصة بك لكل مجال تستخدمه. حتى إذا كانت نطاقاتك تُدار داخل Amazon's Route 53 ، فستحتاج إلى توفير قيمة لسجلك.

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

10 inbound-smtp.us-east-1.amazonaws.com

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

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

ومع ذلك ، فإن إنشاء بروتوكول لأتمتة هذه العملية هو في الحقيقة مشكلة نظام تشغيل محلي تتطلب مجموعة مختلفة تمامًا من الأدوات. لقد قمت بحل المشكلة بنفسي باستخدام AWS CLI ونص رائع Bash. إذا كنت ترغب في معرفة كيف فعلت ذلك ، فانقر فوق هذه المقالة.

هناك الكثير من الخير الإداري في شكل كتب ودورات تدريبية ومقالات متوفرة في my bootstrap-it.com.