أعتقد أن أفضل طريقة لتنفيذ مستقبل البريد (نظرًا لأنني أستخدم بالفعل AWS SES) هي استخدام واجهة برمجة التطبيقات (API) عبر وظيفة Lambda لاستدعاء نقطة النهاية API /admin/email/handle_mail
هناك دروس تعليمية حول كيفية إرسال البريد إلى SES وتمريره عبر S3 إلى وظيفة Lambda. توجد وظائف جاهزة بلغة Node.js لالتقاط هذا البريد وإعادة توجيهه إلى خادم بريد.
ولكن بدلاً من القيام بذلك، يبدو أنه من الأفضل استدعاء واجهة برمجة التطبيقات مباشرة من وظيفة Lambda وتمرير البريد الإلكتروني. (لا أقوم بصيانة خادم بريد محلي خاص بي ولا أرغب في استخدام الاستقصاء على أي حال).
لذلك، يمكنني الاستعانة ببعض المساعدة إما من خلال وثائق أكثر تفصيلاً (لا توجد صفحات وثائق على حد علمي) حول استدعاء نقطة النهاية هذه وما الذي يجب إرساله بالضبط (هل هي نقطة نهاية REST؟ هل هناك بديل لـ WebSocket؟ تنسيق ما يجب إرساله؟) أو بعض التعليمات البرمجية للمشاركة. هل ما زلت بحاجة إلى تشغيل هذه الحاوية الإضافية؟ Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver (هذه المشاركة عمرها 6 سنوات الآن)
كيف يمكن إنشاء مفتاح API (مشفر)؟ هل يحتاج إلى تشفير؟
هل أحتاج إلى تحديد “تم تمكين الاستقصاء اليدوي” رسائل البريد الإلكتروني الفورية باستخدام واجهة برمجة التطبيقات للردود على البريد الإلكتروني. للحصول على نقطة نهاية واجهة برمجة التطبيقات لتكون نشطة أم أنها كذلك افتراضيًا؟
هل هناك أي شيء يجب الانتباه إليه فيما يتعلق بأذونات AWS أو قاعدة SES؟
هل يوجد مكان في واجهة المستخدم الرسومية على الويب حيث يمكن إنشاء مفتاح واجهة برمجة التطبيقات (API key)؟ لا يمكنني العثور على أي مكان في الإعدادات. ربما يمكنك تعيينه إلى ما تريده كمتغير بيئة (environment variable) عند البناء؟ على أي حال، ليس لدي أي فكرة عن كيفية إنشاء مفتاح واجهة برمجة التطبيقات.
نعم، رأيت ذلك ولكني لم أعتقد أنه صحيح لأن “granular” لم يكن لديه إذن handle_email وكنت غير متأكد من المستخدم الذي يجب اختياره أو جميع المستخدمين.
لذلك، قمت بإنشاء مفتاح للمستخدم “system” بصلاحية عامة. هل هذا ما فعلته؟
حسنًا، كنت أرغب في استخدام تطبيق “postman” الخاص بي للتعلم/التجربة ولكن بدون وثائق، لا أعرف ما الذي يجب إرساله بتنسيقات وما هي وكيفية تمرير المفتاح. إذا كنت أكثر دراية بلغة بايثون، ربما يمكنني فهم ذلك من خلال النظر إلى الكود الخاص بك.
أعلم أن هذا مشروع مفتوح المصدر، لذا فمن المفهوم أنه لا توجد وثائق حقيقية حول استخدام واجهة برمجة تطبيقات handle_mail، فقط بعض المساعدة من أشخاص مثلك… شكرًا!
إنه ليس غير موثق لأنه مفتوح المصدر، بل هو غير موثق لأنه لم يطلب أحد (أو لم يطلب الكثيرون).
اقتراحات بأنك تريد إرسال البريد الإلكتروني المشفر عبر POST في شيء يسمى email_encoded. يوضح routes.rb أنه POST والمسار، وهو https://discourse.example.com/admin/email/handle_mail. حصلت عليه من قالب عينة مستلم البريد (وأوصي بأن تستخدمه فقط، كما لو كنت قد فعلت ذلك، لكانت قد انتهيت بالفعل) ولكنه موجود أيضًا في discourse/config/routes.rb at main · discourse/discourse · GitHub (والذي لا يوضح على الفور ما يحدث إلا إذا كنت تفهم rals).
@dltj تمكنت من إعادة كتابة الكود الخاص بك إلى nodejs باستخدام aws-sdk ووحدات get. شكراً جزيلاً.
كانت هناك عدة عقبات على طول الطريق، من AWS (ses,IAM,S3,lambda)، والعبث بالـ serverless، والحصول على استدعاء API بشكل صحيح، إلى ضبط إعدادات discourse بشكل مناسب.
ما سأفعله هو كتابة موضوع مفصل حول ما فعلته بالضبط للحصول على هذا العمل، بتفاصيل كافية تمكن شخصًا ما من تمكينه دون الحاجة إلى أي برمجة أو شد الشعر. الميزة الحقيقية لهذه الطريقة هي أنه باستخدام ses، لا يحتاج المرء إلى إعداد خادم بريد إلكتروني للنطاق. هذا يترك لك حرية إعداد خادم بريد إلكتروني مستقل تمامًا لنطاقك.
إذا كنت مهتمًا بكيفية القيام بذلك، فتحقق مرة أخرى، سأنشر رابطًا هنا عندما يكون جاهزًا (بعد بضعة أيام).
بالإضافة إلى ذلك، @dltj سنقوم بإزالة المعلمة email من المسار admin/email/handle_mail قريبًا، تحتاج إلى إرسال نص البريد الإلكتروني كسلسلة مشفرة بـ base64 في معلمة email_encoded إلى هذا المسار.
كان الترميز إحدى المشكلات التي لم أتمكن من حلها
لم أتمكن من جعل البريد الإلكتروني المشفر يعمل
@martin وفقًا لمنشورك، email_encoded غير صحيح. لقد جربت كليهما، email_encoded يرمي خطأ، ولكن encoded_email لا يزال يعطي التحذير.
body: 'warning: the email parameter is deprecated. all POST requests to this route should be sent with a base64 strict encoded encoded_email parameter instead. email has been received and is queued for processing',
هل أحتاج إلى تحويل بريدي الوارد إلى نص عادي (وهو ما أفعله الآن) والعودة إلى base64 أم من المحتمل أن ما يخزنه AWS Ses في الحاوية هو بالفعل base64؟ إذا مررت نص البريد الإلكتروني كما حفظه SES، فلن يظهر في سجل البريد المستلم. يعرض الأمر POST لا خطأ فقط التحذير. لذا أنا عالق هنا بشكل أساسي.
يرجى تأخير إزالة مفتاح email حتى نتمكن من جعل هذا يعمل.
مرة أخرى، إذا أرسلت نصًا عاديًا مع “emal”، يتم استلام الرسالة نفسها ومعالجتها.
هل تقول “صارم” يعني أي شيء؟ Nodejs/JS لديها نكهتان فقط من base64 “base64” “base64url”.
لماذا تستمر واجهة برمجة التطبيقات في إعطاء التحذير إذا استخدمت encoded_email حتى لو كان لدي خطأ في الترميز.
هذا رائع، شكراً لك على المشاركة.
كنا نستخدم الإصدار القديم الذي تم إهماله قبل ترميز base64 لمدة ثلاث سنوات على Lambda وانقطع قبل شهر.
لا يمكننا استخدام SMTP :25 لأننا نستضيف خلف نفق cloudflared ولماذا نلعب بالمنفذ 25 إذا كانت أمازون تقوم بعمل جيد في حظر الضوضاء باستخدام SES؟
على أي حال، لقد نفد صبري.
الكود يعمل مع Postman و python الذي يتم تنفيذه على جهاز كمبيوتر محلي. يبدو أن شيئًا ما يتم إفساده عند إرساله من AWS Lambda بنفس الكود.
Forbidden
UTF-8
حسنًا، لقد قمت بحل مشكلتي -
على الرغم من أن الاستعلامات تم تمريرها، فإن ‘وضع مكافحة الروبوت’ لا يعمل بشكل جيد مع واجهة برمجة تطبيقات Discourse. ربما بسبب الترميز base64؟
آمل أن يوفر هذا على شخص ما 72 ساعة من حياته:
قم بإيقاف تشغيل هذا: