ولكن هناك بعض المشكلات مع Elastic Email أيضًا Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail - #8 by pfaffman
جاي، شكرًا لك على لفت الانتباه إلى هذا. دعني أفهم الأمر بشكل أفضل:
ما تثير انتباهنا إليه هو: عندما يتلقى الأشخاص بريدًا إلكترونيًا من Elastic Email، يتم تزويدهم برابط بارز جدًا يمكنهم من خلاله إلغاء الاشتراك في استلام البريد الإلكتروني بشكل أحادي، دون أن يعلم Discourse بذلك؟ وبالتالي، لن تكون أنت بصفتك مسؤول النظام على علم بذلك؟
ليس لدي خبرة مباشرة في هذا الشأن.
يبدو أنهم يقومون بإدراج رابط إلغاء الاشتراك، وأن هناك رأسًا خاصًا مطلوبًا لجعله يختفي. لا أعرف ما إذا كان هناك طريقة لاستخدام Elastic Email مع ويب هوك لإشعار Discourse بالإلغاءات، لكنهم غير مدرجين في Configure VERP to handle bouncing e-mails.
أعتقد أنه إذا تمكنت من جعل AWS يعمل، فسيكون ذلك على الأرجح أفضل حل، لكنه ليس حلاً جيدًا للأشخاص الذين يأتون إلى هنا لتعلم كيفية جعل البريد الإلكتروني يعمل.
Mailgun سهل جدًا.
شكرًا لك.
هذا الأمر غير ذي صلة بي إلى حد ما، وسأخبرك بالسبب: فقد فعلت SparkPost الشيء نفسه بالضبط - مع الاعتراف بأنني لم أتحقق أبدًا مما إذا كانت هناك أي روابط (hooks) كنت أستطيع استخدامها (أنا غبي، لأن هناك روابط وهي موجودة، والعام 2019).
في تلك الحالة، اكتشفت الأمر فقط لأن الموقع المتأثر يخدم مجتمعنا المحلي، لذا صادفت الشخص الذي نقر بالخطأ على رابط إلغاء الاشتراك في البريد الذي أرسلته SparkPost، وكان يشكو من عدم تلقيه أي من رسائل إعادة تعيين كلمة المرور. ومع ذلك، فإن SparkPost توفر سجل تدقيق لهذا الغرض، وتمتلك قدرة للمسؤولين على إعادة اشتراك شخص ما (بالطبع يجب استخدام هذه الميزة بحذر!)، لذا بمجرد معرفتي بالمشكلة، كان الحل سهلاً. وسأعرف كيفية تكوين بريدي الإلكتروني بشكل أفضل في المرة القادمة.
أنت تجعلني أميل نحو Mailgun الآن، شكرًا لك!
أتمنى حقًا أن يكون هناك طريقة أكثر “عمومية” للتعامل مع ويب هوك لبريد ديسكورتس المرتد. مزودنا المفضل (Postmark) غير مدرج أيضًا في القائمة، مما يعني أننا نستمر في إرسال رسائل بريد إلكتروني إلى أشخاص عادت عنا عناوينهم.
سيكون وجود محلل ويب هوك سحري عام لرسائل JSON الواردة الخاصة بالبريد المرتد أمرًا رائعًا!
ما تقصده هو أن وجود “معيار سحري لـ JSON webhooks” سيكون رائعًا. كما هو الحال حاليًا، كل خدمة بريدية تضع معيارها الخاص، لذا فإن الحاجة إلى محلل webhook منفصل تظل قائمة. إنشاء إضافة تقوم بذلك لن يكون صعبًا جدًا، ويمكن الحصول عليه في Marketplace (وربما يُقبل كـ PR) مقابل مبلغ يقارب 500 دولار.
نعم، كنت أفكر للتو أنه بافتراض أن أكثر من 90% من بيانات الارتداد الواردة تكون بصيغة JSON أو أي صيغة أخرى قابلة للمعالجة عبر التعابير النمطية (regex)، فقد يكون من الممكن تحديد حقل JSON الذي يمثل عنوان البريد الإلكتروني المرتد عبر إعداد ما، وربما أيضًا تحديد الحقل الآخر الذي يمثل نوع الارتداد (قوي، ضعيف، إلخ).
يمكن تسميته “محلل تعابير نمطية عام لويب هوك رسائل الارتداد الواردة”. الاسم ينساب بسهولة من اللسان 
وقد يساعد ذلك في التغلب على التغير المستمر الذي من المرجح أن نستمر في ملاحظته لهذا النوع بالتحديد من الخدمات.
نحن موقع intranet داخلي للموظفين بحجم منخفض نسبيًا، لذا سنكتفي بالوضع الحالي إلى أن يتغير الأمر.
من موضوع آخر، يمكنك أيضًا إزالة رابط إلغاء الاشتراك الإضافي من ElasticMail عن طريق إخبارهم بمكان وجود رابط إلغاء الاشتراك الخاص بـ Discourse: عن طريق إضافة تعليق خاص عليه بصيغة {unsubscribe:{https://.....}} (أوصي بالتأكد من ذلك مع الدعم الفني قبل إرسال طلب سحب).
ربما يمكن تحقيق ذلك عبر تعديل الترجمات؟
كنتُ أيضًا أستخدم SparkPost لأمثلة Discourse الخاصة بي، وتلقيتُ مؤخرًا إشعارًا من SparkPost.
لذلك شرعتُ في البحث عن بديل.
أعدّدتُ SendGrid ويبدو أنه يعمل بشكل جيد حتى الآن. أنا أستخدم الخطة الأساسية مقابل 15 دولارًا في الشهر.