Mail-receiver relay access denied

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.

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.

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

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

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

メール受信レポートでも同じエラーが発生しています: Relay access denied (in reply to RCPT TO command)。

新規インストールでメール受信が機能していませんが、以前は機能していました。すべての設定は正しいと思いますが、何か見落としている可能性があります。

これは通常、受信者が受け入れるように構成されていないドメインにメールが配信されていることを意味します。

ディスコースサイトと同じサブドメインに設定しています。

MXレコードの値は「サブドメイン.ドメイン」で、ホストは「サブドメイン」または「@」であるべきですか?

「Relay access denied」エラーの原因を知っている人はいますか?

受信者のドメインが mail-receiver.yml で設定されているドメインと一致しない場合に発生します。

「いいね!」 1

メールはそのアドレスに送っていますか?

メール受信者の再構築後、同じアドレスで動作するようになりました。

以前にも再構築したものの、動作していなかったようですが、現在は正常に動作していて良かったです。

メール受信者(mail-receiver)が正常に機能するために、ポート 25 を追加で許可する必要がありますか?

この場合、正常に機能するとは、.\launcher logs mail-receiver に表示される受信メールが Discourse 管理 UI に到達することです。

はい、ポート 25 を開く必要があります。これは、このガイドにオプションのルールとして追加できます。

「いいね!」 1

いや、25個開いていないので、ダメです。

しかし、ufw status はそれほど面白くありません。代わりに nft list ruleset が面白いです。

「いいね!」 1

更新: ufw deny 25 が適用され、mail-reciver は正常に動作しています (2025/02/07)

これは正しいことを確認できますが、もう 1 つ間違いを犯していました。これは、メールを受信するドメインの MX レコードを DISCOURSE_BASE_URL として設定した、2 番目のフォーラムに mail-receiver を実装することに関するものです。

これで、メールが最初のフォーラムだけでなく、(2 番目の) フォーラム UI にも届くようになりました :tada:

注: この正確さに関する確信は、(2015/02/06) に yml を変更した後 ./launcher rebuild mail-receiver を実行しなかったためである可能性があります。

AzureやVPSパネルのファイアウォールでポート25を許可する必要はないと思います。Ubuntuより前ですね。

MXレコードの値は、ウェブサイトではなく、メールドメインを指すべきです。興味深いですね。

公式ガイドでは、ポート25が開いている必要があると記載されています。

私自身も、ファイアウォールでポート25を開けるのを忘れていたためにメール受信の問題に遭遇しました。ルールを追加したことで問題は解決しました。

関連するIPアドレスのみを許可する方が良いのではないでしょうか?

私のメール受信者には内緒にしておきましょう :wink:

送信はAmazon SESを使用しています。受信はMXレコード経由でフォーラムのドメインに来て、次にDockerが介入します。

その理由はDockerとその内部的な動作方法にあります。ufwは無視されます。正確で詳細な説明が必要な場合は、少しお待ちください。以前、Discourseがなぜ私のファイアウォールを無視するのか尋ねたことがあり、その理由はパケットトラフィックでした。しかし、何が起こっているのかを深く理解することは私の得意分野ではありません。私にとっては、物事が機能すれば十分です。そして、信じてください:ufwではポート22、80、443のみが開いています。

メール受信者がpostfixを使用してメール送信も担当する状況を引用したのだと思います。

「いいね!」 1