هذا للإعداد الأولي، وأنا لست خبيرًا في DNS بأي حال من الأحوال! إليك ما وصلت إليه:
اختبارات البريد الصادر تعمل بشكل ممتاز. أستخدم MailGun مع نطاق فرعي موصى به “mg”. أقوم بالإرسال عبر المنفذ 2525. لقد أدخلت API الخاص بـ MailGun للويب هوكس في الحقل المخصص لذلك في الإعدادات (لديهم ثلاثة APIs—هل هذا هو الصحيح؟). كما قمت بإدخال سجلات MX للنطاق الفرعي “mg” في إعدادات DNS الخاصة بي. تشير نتيجة التحقق من Mailgun إلى أن كل شيء يعمل بشكل صحيح، وكذلك هو الحال مع mail-tester.com.
تم تكوين البريد الوارد باستخدام نطاق فرعي يُدعى “inbound”. إذا أرسلت بريدًا إلكترونيًا من حساب Gmail إلى fake@inbound.[mydomain].org، يمكنني رؤية وصول البريد في سجل استقبال البريد. أما إذا أرسلت من Discourse بريدًا تجريبيًا إلى نفس العنوان عبر الإعدادات > البريد، يبدو أن البريد يختفي—لا يظهر أي شيء في سلة المرفوضات. أنا أستخدم التسليم المباشر للبريد الوارد بطريقة مباشرة لباقي الإعدادات.
بسبب أخطاء أخرى ارتكبتها بنفسي أثناء عملية الإعداد، قررت البدء من الصفر: قمت بحذف الـ droplet، وأعدت تثبيت Discourse وبدأت من جديد. ومع ذلك، لم أحذف حساب MailGun، بل أنا أستخدم نفس ويب هوك API كما من قبل. هل يمكن أن يكون هذا هو المشكلة؟ أنا أستخدم مفتاح API جديد صادر عن Discourse (المفتاح القديم، من الواضح، قد تبخر عند حذف الـ droplet).
أفكر في شيء آخر فقط، وهو نقطة النهاية في ملف mail-receiver.yml. يبدو ملفي كالتالي: DISCOURSE_MAIL_ENDPOINT: 'https://inbound.[mydomain].org/admin/email/handle_mail'
هل لديك أي أفكار حول مكان المشكلة؟ (الزينة على الكعكة هي أنني كنت قد نجحت في جعل كل شيء يعمل منذ فترة ليست ببعيدة—قبل حذف الـ droplet. يبدو أنني بطيء التعلم ). شكرًا لكم جميعًا!
يجب أن يكون هذا نطاق منتداك، وليس بريدك الإلكتروني. هل يمكنك تأكيد أن منتداك ليس على عنوان inbound.[mydomain].org؟ على سبيل المثال، إذا كان موقع meta يستخدم هذه الطريقة، فسيبدو الرابط كالتالي:
أيضًا… لا علاقة لهذا بـ Mailgun، إلا للتأكد من تجاهل تعليمات Mailgun التي تطلب إضافة سجلات MX للنطاق. وفقًا لما يلي:
ملاحظة: قد تطلب منك مزودو البريد الصادر مثل Mailgun إضافة سجلات MX تشير إلى خوادمهم. يجب عليك إزالة هذه السجلات بحيث تشير سجلات MX الخاصة بمنتداك فقط إلى اسم نطاق منتداك. يجب أن تشير سجلات SPF و DKIM لا تزال إلى خوادم مزود البريد الصادر لديك حتى تتمكن من إرسال البريد الإلكتروني.
@tobiaseigen اقتربنا أكثر! قمت بإجراء التغيير عن طريق إزالة نطاق البريد الوارد من نقطة النهاية. ثم حفظت التغيير وأعدت تشغيل مستلم البريد (لأنني لا أعرف ما أفعل!). جربت، لكن دون نجاح. ثم قمت بإعادة بناء التطبيق بالكامل. بعد ذلك أنشأت حسابين جديدين باستخدام عناوين بريد إلكتروني مختلفة. ثم استخدمت حساب المسؤول لإرسال رسالة خاصة إلى أحد هذين الحسابين. وقد تم توليد بريد إلكتروني كما هو متوقع. ثم قمت بالرد على الرسالة الخاصة عبر البريد الإلكتروني. إليك النتيجة في سجل البريد:
أواجه بعض الصعوبة في فهم استخدامك لأسماء النطاقات. في موقعي، نقطة نهاية البريد الإلكتروني (DISCOURSE_MAIL_ENDPOINT) وسجل MX لاستقبال البريد الإلكتروني هما نفس النطاق، ويشيران إلى خادم Discourse، كما هو موضح في المنشور الأصلي في Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver. يبدو أنك تحاول استخدام نطاقات مختلفة.
بشكل عام، يُفضل استخدام نطاق فرعي مثل forum.mydomain.org لمنصة Discourse، لفصل المنتدى عن موقع الويب الرئيسي والبريد الإلكتروني على mydomain.org.
يسعدني التوضيح وسأفترض أن نطاقى هو thesite.org للتبسيط. ما ألاحظه هو مشكلة SSL في سجلات استلام البريد: <19>Nov 25 19:11:29 receive-mail[160]: Failed to POST the e-mail to https://inbound.thesite.org/admin/email/handle_mail: hostname "inbound.thesite.org" does not match the server certificate (OpenSSL::SSL::SSLError)
ولكن للإجابة على سؤالك، كان لدي هدفان أظنهما شائعين للغاية:
أن يصبح admin@thesite.org عنوانًا يستخدمه المستخدمون للاتصال بالمسؤول.
أن يُطلق thesite.org المنتدى (بدون نطاق فرعي).
حاليًا، تبدو إعدادات DNS الخاصة بي على Namecheap كالتالي (TTL = تلقائي و Priority = 10):
1 سجل A @ (عنوان IP)
2 سجل A inbound. (عنوان IP)
3 سجل CNAME email.mg. mailgun.org.
4 سجل CNAME inbound. thesite.org.
5 سجل CNAME www. thesite.org.
6 سجل TXT @ forward-email=(معلومات)
7 سجل TXT mg v=spf1 include:mailgun.org ~all
8 سجل TXT smtp._domainkey.mg. k=rsa; p=(معلومات)
9 سجل MX @ mx1.forwardemail.net.
10 سجل MX @ mx2.forwardemail.net.
11 سجل MX inbound. thesite.org.
12 سجل MX mg. mxa.mailgun.org.
13 سجل MX mg. mxb.mailgun.org.
إعدادات ملف containers/mail-receiver.yml الخاصة بي هي:: MAIL_DOMAIN: inbound.thesite.org DISCOURSE_MAIL_ENDPOINT: 'https://thesite.org/admin/email/handle_mail' DISCOURSE_API_KEY: (معلومات) DISCOURSE_API_USERNAME: system ← نفس مفتاح API
* ملاحظة—> تركت سطور LetsEncrypt كما هي (لم أحذف علامة “#”)
إعدادات أخرى:
تم تغيير اسم المضيف عبر سطر الأوامر إلى inbound.thesite.org
عنوان البريد الإلكتروني للتواصل = admin@thesite.org
عنوان البريد الإلكتروني للإشعارات = noreply@mg.thesite.org
البريد الإلكتروني للرد عبر الرابط1 = replies+%{reply_key}@inbound.thesite.org
البريد الإلكتروني للرد عبر الرابط2 = %{reply_key}@inbound.thesite.org
العثور على المنشور ذي الصلة باستخدام المفتاح = مفعل
الاستطلاع اليدوي = مفعل
مفتاح API الخاص بـ Mailgun = تم إدخاله …ولكن قد تكون هذه مشكلة لأنه من محاولة تثبيت سابقة
هل لديك أي أفكار حول الخطوة التالية؟ … وشكرًا جزيلاً مسبقًا! وأود أيضًا التنبيه إلى @pfaffman حيث كان أيضًا مصدرًا كريمًا ساعدني في الصعوبات السابقة المتعلقة بالإعداد. كما كان دليلك “البسيط” مفيدًا للغاية. تحياتي!
هل قمت بإعادة بناء حاويات البريد والتطبيق معًا؟ أعتقد أن الحل السهل هو إزالة الأشياء التي تحاول منح شهادة لمستقبل البريد. هل تعمل الشهادة للموقع؟
إذا لم يكن موقع Discourse موجودًا على inbound.thesite.org، فهذه هي المشكلة. الفكرة هي أن اسم المضيف لموقع Discourse ومستقبل البريد سيكونان متطابقين. ستحتاج إلى العثور على إعداد Let’s Encrypt مع نطاقات متعددة لحل هذه المشكلة.
هذا الأمر يتجاوز نطاق دليل استقبال البريد المقصود. إذا لم يكن هذا كافيًا لإعادتك على المسار الصحيح ولديك ميزانية، فلا تتردد في الاتصال بي.
إذن يصبح السؤال: هل يمكن تحقيق كلا الهدفين اللذين حددتهما أعلاه (يبدوان شائعين بشكل مبالغ فيه)؟ هل الحل الوحيد هو إعادة توجيه الزوار الذين يكتبون www.thesite.org و/أو thesite.org إلى subdomain.thesite.org في إعدادات DNS؟ إذا كان هذا صحيحًا، فسأضطر إلى مجرد التعايش مع تغيير عنوان البريد الإلكتروني الظاهر إلى شيء قبيح مثل admin@subdomain.thesite.org.
يمكنني التعايش مع تغيير عنوان البريد الإلكتروني للإدارة إذا اضطررت إلى ذلك حقًا. يبدو أننا نتغاضى عن شيء واضح، لكن ربما أكون خارج السياق تمامًا (وربما أكون كذلك)!
إذا كان ما تريده هو أن يستقبل مستقبل البريد الرسائل في نطاق مختلف عن نطاق discourse الخاص بك، فأعتقد أنه يمكنك ذلك. أسهل طريقة هي عدم استخدام شهادة Let’s Encrypt في مستقبل البريد.
بعد اتباع دليل “إعداد Let’s Encrypt مع نطاقات متعددة”، أعيد بناء Discourse ثم أعيد بناء mail-receiver (وربما لم يكن إعادة بناء أحدهما ضروريًا)، وقد نجحت العملية. ها هو!
في وقت لاحق من المساء، أرغب في نسخ ولصق عنوان الموضوع “التسليم المباشر البسيط للبريد الوارد” إلى مستند Google وتقديم تعديلاتي المقترحة عليه. وليس هناك أي خطأ منكم، ولكن هناك أجزاء من عنوان الموضوع ليست بديهية لشخص مثلي لا يعرف أو يفهم أوامر سطر الأوامر. أعتقد أن الهدفين اللذين حددتهما أعلاه شائعان جدًا في العديد من التثبيتات، والآن أعرف أنه يمكن تحقيق الهدف النهائي.
لديّ اقتراحات أخرى لدليل الإعداد بأكمله. لدي قائمة متنامية بالتعديلات المقترحة لجعل العملية بسيطة قدر الإمكان.
). شكرًا لكم جميعًا!
وسأفترض أن نطاقى هو 