メール受信コンテナを使用して、メールでの返信を有効化しようと必死に取り組んでいます。しかし、一貫して以下のエラーが発生します。
NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied
なぜこのようなエラーになるのでしょうか？また、mail-receiver コンテナにアクセスして Postfix の設定を確認し、デバッグするにはどうすればよいでしょうか？ポート 25 の競合を避けるため、このシステム上で動作している Postfix サーバーは無効化しています。これは間違いでしょうか？
DNS の MX レコードは正しいと確信しています。この問題は、インバウンドメールを送信するどのサーバーからでも発生します。アプリコンテナ内ではアウトバウンドに Amazon SES を使用しており、こちらは正常に動作しています。
Discourse の初心者であり、このエコシステムのデバッグ方法がわかりません。Postfix のエキスパートですが、このコンテナ化された環境での設定方法がわかりません。
まず最初に、すでに Postfix インスタンスが動作している場合、メール受信コンテナは必ずしも必要ありません。
Postfix をリプライ用メールの受信サーバーとして設定し、Discourse がそのメールをポーリングするように設定できます。
この 2014 年の howto は始めるための十分なヒントを提供するでしょうし、Postfix の設定はご自身で対応可能だと想定しています。
これには全く同意できません。mail-receiver の利点は、メールがポーリングされるのではなく、API を経由してプッシュされる点です。mail-receiver を使用した場合と Discourse でメールを受信するまでの時間には大きな差があります（数分対数秒）。
設定の簡便さにおいても大きな違いがあります。mail-receiver では yml ファイルの 3 行を更新するだけで済みますが、postfix OOBE では… それ以上 必要です。
このエラーは、メールドメインが一致していないことを示唆しています。
メッセージの一部を伏字にしているため、私たちはあなたのために簡単にトラブルシューティングを行うことができません。
もし、あなたが期待通りにメールが配信されているなら、これは誰かがあなたのメールサーバーを介して他のドメイン宛てにメールを送ろうとしていることを意味します。例えば、誰かが MX レコードをあなたの IP アドレスに指していた場合などです。あるいは、聞いたことがありませんが 
、誰かが悪意を持ってあなたのメールサーバーから不要なメールを送らせようとしている可能性もあります。
これらのエラーはすべて同じ IP からのものですか？ログを確認して、誤ったメッセージがどのドメイン宛てに送られようとしているか確認できますか？
最も簡単な対処法は、これを無視することです。
以前は正常に動作していた mail-receiver で、変更を加えた後にこの問題が発生しました。コンテナを再構築するつもりでしたが、どうやら何かうまくいかなかったようで、すべての受信者に対して複数の「Relay access denied」エラーが表示されました。DNS の設定は正しかったです。
結局、いつものように git pull と launcher rebuild mail-receiver を実行することで解決しました。もし他の誰かの助けになればと思い、投稿しました。
メール受信レポートでも同じエラーが発生しています: Relay access denied (in reply to RCPT TO command)。
新規インストールでメール受信が機能していませんが、以前は機能していました。すべての設定は正しいと思いますが、何か見落としている可能性があります。
これは通常、受信者が受け入れるように構成されていないドメインにメールが配信されていることを意味します。
ディスコースサイトと同じサブドメインに設定しています。
MXレコードの値は「サブドメイン.ドメイン」で、ホストは「サブドメイン」または「@」であるべきですか？
「Relay access denied」エラーの原因を知っている人はいますか？
受信者のドメインが mail-receiver.yml で設定されているドメインと一致しない場合に発生します。
メールはそのアドレスに送っていますか？
メール受信者の再構築後、同じアドレスで動作するようになりました。
以前にも再構築したものの、動作していなかったようですが、現在は正常に動作していて良かったです。
メール受信者（mail-receiver）が正常に機能するために、ポート 25 を追加で許可する必要がありますか？
この場合、正常に機能するとは、.\launcher logs mail-receiver に表示される受信メールが Discourse 管理 UI に到達することです。
はい、ポート 25 を開く必要があります。これは、このガイドにオプションのルールとして追加できます。
いや、25個開いていないので、ダメです。
しかし、ufw status はそれほど面白くありません。代わりに nft list ruleset が面白いです。
更新: ufw deny 25 が適用され、mail-reciver は正常に動作しています (2025/02/07)
これは正しいことを確認できますが、もう 1 つ間違いを犯していました。これは、メールを受信するドメインの MX レコードを DISCOURSE_BASE_URL として設定した、2 番目のフォーラムに mail-receiver を実装することに関するものです。
これで、メールが最初のフォーラムだけでなく、(2 番目の) フォーラム UI にも届くようになりました 
注: この正確さに関する確信は、(2015/02/06) に yml を変更した後 ./launcher rebuild mail-receiver を実行しなかったためである可能性があります。
AzureやVPSパネルのファイアウォールでポート25を許可する必要はないと思います。Ubuntuより前ですね。
MXレコードの値は、ウェブサイトではなく、メールドメインを指すべきです。興味深いですね。
公式ガイドでは、ポート25が開いている必要があると記載されています。
私自身も、ファイアウォールでポート25を開けるのを忘れていたためにメール受信の問題に遭遇しました。ルールを追加したことで問題は解決しました。
関連するIPアドレスのみを許可する方が良いのではないでしょうか？
私のメール受信者には内緒にしておきましょう
送信はAmazon SESを使用しています。受信はMXレコード経由でフォーラムのドメインに来て、次にDockerが介入します。
その理由はDockerとその内部的な動作方法にあります。ufwは無視されます。正確で詳細な説明が必要な場合は、少しお待ちください。以前、Discourseがなぜ私のファイアウォールを無視するのか尋ねたことがあり、その理由はパケットトラフィックでした。しかし、何が起こっているのかを深く理解することは私の得意分野ではありません。私にとっては、物事が機能すれば十分です。そして、信じてください：ufwではポート22、80、443のみが開いています。
メール受信者がpostfixを使用してメール送信も担当する状況を引用したのだと思います。