إعداد mail-receiver، ولكن الموقع توقف عن إرسال أي إيميلات؟

[ToddZ]

حسنًا. لدي نفس إعداد Vultr مثل @MathiasFoster و @jryans هنا، وواجهت نفس المشكلة (Net::OpenTimeout). ufw allow https جعل بريدي الإلكتروني الوارد يعمل.

لكن الموقع الآن لا يرسل أي بريد. قبل إعداد البريد الوارد، كان البريد الصادر يعمل بشكل جيد.

ليس لدي أي شيء معقد يحدث:
notification_email هو admin@tasat.org.
البريد الصادر يستخدم smtp.titan.email في Hostinger.

يحتوي mail_receiver.yml على:

`MAIL_DOMAIN` = forum.tasat.org
`DISCOURSE_MAIL_ENDPOINT` = https://forum.tasat.org/admin/email/handle_mail
`DISCOURSE_API_KEY` = [redacted]

في البريد الإلكتروني المتخطي، أرى \u003creplies+verp-14c9cc6eb915b08d4983c90c744ba4b4@forum.tasat.org\u003e: تم رفض عنوان المرسل: لا يملكه المستخدم admin@tasat.org

أنا جديد في صناعة البريد الإلكتروني. هل يجب أن أزيل “forum.” من سلاسل mail_receiver.yml وأجعل “replies@tasat.org” اسم مستعار للإرسال من “admin@tasat.org”؟

[Simon_Manning]

مستقبل البريد مستقل عن Discourse وإرسال البريد الإلكتروني، فهو يعمل ببساطة كخادم بريد إلكتروني بسيط تم تكوينه لاستقبال رسائل البريد الإلكتروني فقط، باستخدام واجهة برمجة تطبيقات Discourse لدفع رسائل البريد الإلكتروني هذه إلى Discourse.

الشيء الوحيد الذي يمكنني التفكير فيه عند إعداده والذي قد يؤثر على الإرسال هو تعيين “الرد عبر عنوان البريد الإلكتروني”، على الرغم من أنه يجب أن يقوم فقط بتعيين “Reply-To” على رسائل البريد الإلكتروني الصادرة ولا يؤثر على عنوان المرسل.

فقط للتأكيد، يبدو أن لديك هذه (من بين أمور أخرى) في app.yml:

DISCOURSE_SMTP_USER_NAME: admin@tasat.org
DISCOURSE_NOTIFICATION_EMAIL: admin@tasat.org

وهذا في “الرد عبر عنوان البريد الإلكتروني”:

replies+%{reply_key}@forum.tasat.org

هل هذا صحيح؟

إذا كان الأمر كذلك، فهل لا تزال إشعارات البريد الإلكتروني التي لا تقبل الردود تعمل؟ أعتقد أن التحقق من البريد الإلكتروني هو مثال على ذلك، لذا يمكنك محاولة إنشاء حساب ومعرفة ما إذا كان هذا البريد الإلكتروني قد تم إرساله بنجاح.

مع هذا الترتيب، ما يجب أن يحدث للرسائل الإلكترونية التي يمكنها قبول الردود هو أن البريد الإلكتروني المرسل يستخدم:
From: admin@tasat.org (عنوان المرسل أيضًا)
Reply-To: replies+abc123@forum.tasat.org

عادةً لا يتم التعامل مع Reply-To كجزء من معلومات المرسل، بل يوفر عنوان To افتراضي لاستخدامه عند الرد، ولكن ربما تعامل Hostinger معه على هذا النحو. قد تتمكن من إضافة اسم مستعار للإرسال لـ replies@forum.tasat.org.

[pfaffman (Jay Pfaffman)]

@ToddZ

لكن الموقع الآن لن يرسل أي بريد. قبل إعداد البريد الوارد، كان البريد الصادر يعمل بشكل جيد.

ماذا يحدث إذا حاولت إرسال بريد تجريبي إلى عنوان تحصل عليه من Wrong testing address

لا أرى كيف يمكن لتغيير ufw allow https أن يؤثر على البريد الوارد.

من الممكن أن Vultr لا تسمح بالاتصالات الصادرة إلى المنفذ 25. هذا من شأنه أن يفسر عدم عمل البريد الصادر.

البريد الصادر والوارد منفصلان إلى حد كبير عن بعضهما البعض.

[Simon_Manning]

@pfaffman

لا أرى كيف يمكن لتغيير ufw allow https أن يؤثر على البريد الوارد.

أعتقد أن Vultr (أو ربما مجرد تثبيت Docker عندما يكون ufw موجودًا) لديه بعض القواعد التي تمنع الحاويات من التحدث مع بعضها البعض، مما يعني أن مستلم البريد لا يمكنه الاتصال بـ Discourse. ufw allow https يتجاوز ذلك.

[Jagster (Jakke Lehtonen)]

ولكن دوكر يتجاوز جدار الحماية غير الموجه، أليس كذلك؟

[Simon_Manning]

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

عندما يبحث مستلم البريد عن اسم نطاق Discourse الخاص بك، فلن يحصل على عنوان IP المحلي هذا، لذا سيتعين عليه مغادرة شبكة Docker الخاصة به وسيمر عبر ufw مرة واحدة على الأقل للوصول إلى Discourse.

[Jagster (Jakke Lehtonen)]

كنت أفكر في هذا الموضوع، حيث كنت تشارك فيه أيضًا:

Will UFW limit Discourse too?

How can Discourse bypass UFW? I had enabled only port 22 so all other ports should be closed then. But a forum worked anyway. How’s that possible? DigitalOcean droplet, but that should not mean anything. And no one-click install, but official way. This is not a pure support question, but we don’t have here a catogory named Stupid basic questions by beginners

[Simon_Manning]

هذا وضع منفصل، وإن كان ذا صلة. هذه اتصالات واردة من الخارج ويضيف Docker قواعد للسماح بمرور المنافذ المكشوفة.

@supermathie

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:https to:172.17.0.2:443
  107  6848 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:http to:172.17.0.2:80

لست ملمًا جدًا بقواعد سلاسل netfilter/iptables ولكن أعتقد أن ما ورد أعلاه يوضح:

1. إذا كان الاتصال واردًا من docker0، أي من شبكة Docker الافتراضية، فارجع إلى السلسلة السابقة (توقف عن معالجة القواعد في تلك السلسلة).
2. بخلاف ذلك، إذا كان الاتصال واردًا من أي شيء باستثناء docker0، وإذا كان أيضًا https أو http، فحدد DNAT مما يتسبب في الانتقال إلى سلسلة FORWARD.

لذلك، مع الترتيب الموضح في الموضوع الآخر، ما يحدث هو أنه إذا كان اتصال https أو http واردًا من الخارج، فسيتم توجيهه إلى Docker. أما إذا جاء الاتصال من شبكة Docker، فسيتم إرجاعه ورفضه أو إسقاطه بواسطة سلسلة INPUT.

ما يفعله ufw allow https هو إضافة قاعدة إلى سلسلة INPUT لقبولها. بهذه الطريقة، عندما يتم إرجاع الاتصال إلى سلسلة INPUT كما هو موضح أعلاه، فسيتم قبوله وسيجد Docker يستمع، وسيتم توجيهه في النهاية إلى الحاوية.

[ToddZ]

@Simon_Manning @pfaffman –

تعديل: انظر نهاية الرسالة

شكراً على الردود! اضطررت للانشغال قليلاً، لكنني أعود للبحث في هذا الأمر…

@Simon_Manning

للتأكيد فقط، يبدو أن لديك هذه (ضمن البقية) في app.yml:

DISCOURSE_SMTP_USER_NAME: admin@tasat.org
DISCOURSE_NOTIFICATION_EMAIL: admin@tasat.org

وهذا في reply by email address:

replies+%{reply_key}@forum.tasat.org

هل هذا صحيح؟

نعم، هذا ما لدي في الوقت الحالي.

@Simon_Manning

إذا كان الأمر كذلك، فهل لا تزال إشعارات البريد الإلكتروني التي لا تقبل الردود تعمل؟ أعتقد أن التحقق من البريد الإلكتروني هو مثال على ذلك، لذا يمكنك محاولة إنشاء حساب ومعرفة ما إذا كان هذا البريد الإلكتروني قد تم إرساله بنجاح.

عندما أحاول إنشاء حساب الآن، لا يفعل زر الإرسال شيئًا. كما لو أنه يعرف أنه لن ينجح. (ولا يظهر شيء في “تم التخطي” أو في أي مكان آخر.)

@Simon_Manning

عادةً لا يتم التعامل مع Reply-To كجزء من معلومات المرسل، بل يوفر عنوان To افتراضي لاستخدامه عندما يرد الأشخاص، ولكن ربما تعامل Hostinger معه على هذا النحو. قد تتمكن من إضافة اسم مستعار للإرسال لـ replies@forum.tasat.org.

تعديل: لقد قمت بتعيين “replies@tasat.org” كاسم مستعار للإرسال لـ admin@tasat.org، وتأكدت من أنه يعمل للإرسال والاستقبال. لقد تأكدت أيضًا من تسليم بريد إلكتروني تم إرساله من عميل خارجي موجه إلى replies+verp-174bc7d8411bc4ec2cfa84c55bd31425@forum.tasat.org

من أجل محاولة شيء ما، قمت بتغيير reply by email address:
من replies+%{reply_key}@forum.tasat.org
إلى replies+%{reply_key}@tasat.org

لكنه لا يغير النتائج.

ماذا يحدث إذا حاولت إرسال بريد إلكتروني تجريبي إلى عنوان تحصل عليه من Wrong testing address

لا يصل إلى mail-tester. تنتهي جميع محاولات الإرسال الصادرة تحت “تم التخطي” مع مجموعة متنوعة من هذه الرسالة:

553 5.7.1 <replies+verp-8c79cd4e83023bda6df0624c2cacd36e@tasat.org>:
Sender address rejected: not owned by user admin@tasat.org

ربما يكون هذا مثيرًا للاهتمام..؟ عندما أقوم بتشغيل discourse-doctor، يفشل البريد الصادر كما يلي:

==================== MAIL TEST ====================
لإجراء اختبار قوي، احصل على عنوان من http://www.mail-tester.com/
إرسال بريد إلى REDACTED . .
اختبار الإرسال إلى admin@tasat.org باستخدام smtp.titan.email:587،
اسم المستخدم: admin@tasat.org مع مصادقة عادية.
تم الاتصال بخادم SMTP بنجاح.
إرسال إلى admin@tasat.org. . .
لم يتم إرسال البريد.

السبب: 553 5.7.1 <replies+verp-3cc19f7b135e6f56219e030999db9e29@tasat.org>:
Sender address rejected: not owned by user admin@tasat.org

الإرسال مباشرة إلى عنوان replies+ (أو عنوان forum.tasat.org) من عميل بريد إلكتروني يعمل - فهو يتبع الاسم المستعار “replies” وينتهي في صندوق الوارد الخاص بالمسؤول. من أين يأتي الرفض؟

لقد نظرت في قسم المقالة “منع تداخل البريد الإلكتروني للمضيف الصادر”. ليس لدي مسار /etc/postfix - ولكن إليك ناتج netstat الخاص بي:

root@forum:/var/discourse# netstat -tulpn | grep :25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1487576/docker-prox
tcp6       0      0 :::25                   :::*                    LISTEN      1487581/docker-prox

تعديل كبير - لقد تلقيت رداً من دعم Titan الليلة: “يجب أن يكون عنوان الرد (reply-to) وعنوان المرسل (from) متماثلين وإلا فلن يتم إرسال البريد الإلكتروني.” لذا أعتقد أن كل استكشاف الأخطاء وإصلاحها ذهب هباءً وعليّ البحث عن مضيف بريد إلكتروني جديد لا يفرض هذا المطلب.

[Simon_Manning]

@ToddZ

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

بالتأكيد ليست شاملة، ولكن هناك بعض توصيات خدمة الإرسال في وثائق التثبيت مع بعض المعلومات الأساسية حول استخدامها في Discourse: discourse/docs/INSTALL-email.md at main · discourse/discourse · GitHub

الموضوع التالي (المُدرج في أسفل هذا المستند) يحتوي أيضًا على معلومات حول معالجة الارتداد لتلك الخدمات وغيرها:

Configure VERP to handle bouncing e-mails

Setting up bounces handling Discourse uses the Variable envelope return path (VERP) technique to handle bouncing e-mails. To enable VERP, set the “reply by email address” site setting with an email address template that uses the + sign. The default of replies+%{reply_key}@discourse.example.com … works fine. If you are using your own or your company’s email server, then, that’s it Your discourse instance must be able to receive email sent to this address. This should work via POP, bu…

أنا أستخدم خطة Mailgun flex (بالكامل ضمن الحد المجاني) بنفسي، ولكني أعلم أنه كان هناك ارتباك حول تسعيرهم وربما تغيرت الأمور للمستخدمين الجدد منذ انضمامي. آخر ما رأيته (لا أعرف ما إذا كان لا يزال صحيحًا)، كان من الممكن الانتقال إلى flex بعد انتهاء الفترة التجريبية، فقط كان الأمر غير واضح للغاية.

[pfaffman (Jay Pfaffman)]

@ToddZ

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

صحيح.
يمكنك التبديل إلى mailgun flex، على الرغم من أنهم يجعلون الأمر صعبًا لمعرفة ذلك. مرة واحدة في الشهر تقريبًا، أرسل لهم بريدًا إلكترونيًا أسأل فيه عن سبب صعوبة العثور عليه.

[ToddZ]

شكراً لك مرة أخرى @Simon_Manning و @pfaffman على المدخلات والإرشادات، لقد وضعتني على المسار الصحيح.

قررت تجربة MailerSend، حيث أن خطتهم المجانية الحالية سخية للغاية. يجب أن تناسب جهودنا غير الربحية لبعض الوقت. الأمور تسير على ما يرام حتى الآن