تم رفض وصول المييل-مستلم relais

تثبيت
1

Trying hard to enable replies by email using the mail-receiver container. I consistently get errors:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied

Why is this? How can I get into the mail-receiver container and examine the postfix config and debug it? I have disabled the postfix server on the system on which this is running, because of clash with port 25. Is that wrong?

I am reasonably sure DNS MX records are right, and this happens from any server sending mail inbound, I am using Amazon SES for outbound in the app container and that works fine.

I am a Discourse newbie and I dont know how to debug the ecosystem. I am an expert in postfix, but I don’t know how to configure it in this containerized universe.

2

First thing first, if You already have a postfix instance running, You don’t really need the mail receiver container.

You can configure postfix as an email receiver for the replies email and configure discourse to poll that email.

This howto from 2014 shall give you enough idea to get started and I assume you can figure postfix on your own.

3

I don’t agree with this at all, the benefit of the mail-receiver is that emails are pushed via the API, rather than polled. There’s a significant difference in the time taken for email to arrive in Discourse using the mail-receiver (minutes versus seconds).

There’s also a huge difference in simplicity in configuration, mail-receiver requires three lines of a yml file be updated, the postfix OOBE requires… more.

That error implies the mail domains don’t match.

As you’re obfuscating parts of the message we can’t easily troubleshoot this for you.

3 إعجابات
4

If you’re getting any mail delivered as you expect, then this implies that someone is trying to use your mail server to deliver mail to some other domain. If, for example, someone pointed their MX record to your IP address. Or, and I’ve never heard of this :wink: , someone was trying to nefariously have your mail server deliver unwanted mail.

Are all of these errors from the same IP? Can you see in the logs what domain they the errant messages are intended for?

The easiest thing to do is to ignore it.

3 إعجابات
5

I had this issue on a previously working mail-receiver which I’d made some changes to. I had thought I’d rebuild the container but clearly something hadn’t gone right as I got multiple ’ Relay access denied’ errors for all recipients. DNS was correctly configured.

In the end a good old git pull and launcher rebuild mail-receiver fixed it. Just posting this in case it works for anyone else.

إعجابَين (2)
6

لدي نفس الخطأ مع تقارير mail-receiver: تم رفض الوصول إلى الترحيل (ردًا على أمر RCPT TO).\n\nاستلام البريد لا يعمل للتثبيت الجديد ولكني تمكنت من جعل هذا يعمل من قبل. أعتقد أن جميع الإعدادات صحيحة ولكن ربما فاتني شيء ما.

7

يعني هذا عادةً أن البريد يتم تسليمه إلى نطاق غير النطاق الذي تم تكوين المستلم لقبوله.

8

لقد قمت بتعيينه لنفس النطاق الفرعي مثل موقع discourse.

بالنسبة لقيمة سجل MX، هل هي “subdomain.domain” والسجل هو “subdomain” أو “@”؟

9

هل يعرف أحد ما الذي يسبب خطأ “Relay access denied”؟

10

يحدث هذا عندما لا يتطابق نطاق المستلم مع النطاق الذي تم تكوينه في mail-receiver.yml.

إعجاب واحد (1)
11

هل هذا هو العنوان الذي ترسل إليه البريد؟

12

نفس العنوان، يعمل الآن بعد إعادة بناء مستقبل البريد.
أعتقد أنني قمت بإعادة بنائه من قبل ولكنه لم يكن يعمل، من الجيد أنه يعمل الآن.

13

هل أحتاج إلى السماح بمنفذ 25 إضافيًا لكي يعمل mail-receiver بشكل صحيح.

في هذه الحالة، العمل بشكل صحيح يعني ظهور رسائل البريد الإلكتروني الواردة في .\launcher logs mail-receiver والوصول إلى واجهة مسؤول Discourse.

14

نعم، يجب عليك فتح المنفذ 25. يمكن إضافة ذلك إلى هذا الدليل كقاعدة اختيارية.

إعجاب واحد (1)
15

حسنًا، ليس لدي 25 مفتوحة. لذا، لا.

لكن ufw status ليس مثيرًا للاهتمام. بدلاً من ذلك، nft list ruleset هو كذلك.

إعجاب واحد (1)
16

تحديث: تم تطبيق ufw deny 25 و يعمل mail-reciver بشكل جيد (07/02/2025)

يمكنني تأكيد أن هذا صحيح، على الرغم من أنني ارتكبت خطأً آخر. يتعلق هذا بمنتدىي الثاني لتطبيق mail-receiver، وفي المنتدى الأول، كان سجل MX الخاص بالنطاق الذي يستقبل رسائل البريد الإلكتروني Value هو DISCOURSE_BASE_URL.

الآن تصل رسائل البريد الإلكتروني إلى واجهة المستخدم الخاصة بمنتدىي (الثاني)، بدلاً من المنتدى الأول فقط :tada:

ملاحظة: قد يكون هذا الاعتقاد بالصحة ناتجًا عن عدم تشغيل ./launcher rebuild mail-receiver بعد تغيير ملف yml (06/02/2015)

17

أتخيل أنك لا تحتاج إلى السماح بالمنفذ 25، على سبيل المثال، في جدار حماية لوحة تحكم Azure أو VPS - لذلك قبل Ubuntu

لأن قيمة سجل MX يجب أن تشير إلى موقع الويب، وليس إلى نطاق البريد، هذا مثير للاهتمام

18

الدليل الرسمي يذكر أن المنفذ 25 يجب أن يكون مفتوحًا:

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

19

قد يكون الحل الأفضل هو السماح بعنوان IP ذي الصلة فقط؟

20

دعنا لا نخبر بذلك لمستقبل بريدي :wink:

يتم الإرسال باستخدام Amazon SES. الوارد يأتي عبر mx إلى نطاق المنتدى والآن يدخل Docker.

السبب في ذلك هو Docker وطريقته الداخلية للعمل. إنه لا يهتم بـ ufw. إذا كنت تريد شرحًا مفصلاً ودقيقًا، انتظر ثانية - سألت مرة لماذا لا يهتم Discourse بجدار الحماية الخاص بي، وكان السبب هو حركة مرور الحزم. لكن فهم ما يحدث بعمق ليس من اختصاصي. يكفيني أن الأمور تعمل. وثق بي: ufw مفتوح فقط للمنافذ 22 و 80 و 443.

أعتقد أنك اقتبست موقفًا حيث يعتني مستقبل البريد بإرسال رسائل البريد الإلكتروني أيضًا باستخدام postfix.

إعجاب واحد (1)