尝试通过邮件接收容器启用邮件回复功能时遇到了困难。我反复遇到以下错误：
NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: 中继访问被拒绝
这是为什么？我该如何进入 mail-receiver 容器，检查 Postfix 配置并进行调试？由于与端口 25 冲突，我已禁用了运行此服务的系统上的 Postfix 服务器。这样做对吗？
我相当确定 DNS MX 记录是正确的，而且任何服务器发来的入站邮件都会出现此问题。我在应用容器中使用 Amazon SES 进行出站邮件发送，那部分工作正常。
我是 Discourse 的新手，不知道如何调试整个生态系统。我是 Postfix 专家，但不知道如何在这个容器化环境中进行配置。
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.
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 
, 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.
我之前修改过一个原本正常工作的 mail-receiver，随后遇到了这个问题。我原本以为重新构建容器就能解决，但显然操作并未成功，因为所有收件人都收到了多条“Relay access denied”错误。DNS 配置是正确的。
最终，执行一次常规的 git pull 并运行 launcher rebuild mail-receiver 解决了问题。特此分享，以防其他人也能从中受益。
邮件接收器报告出现同样的错误：中继访问被拒绝（在回复 RCPT TO 命令时）。
新安装的邮件接收功能不起作用，但我以前曾成功设置过。相信所有设置都已正确，但可能遗漏了什么。
这通常意味着邮件被发送到了收件人未配置接受的域。
我的设置与 discourse 站点的子域相同。
对于 MX 记录值是“subdomain.domain”，主机应该是“subdomain”还是“@”？
是否有人知道“中继访问被拒绝”错误的原因？
当收件人域与 mail-receiver.yml 中配置的域不匹配时，就会发生这种情况。
您是发送邮件到该地址吗？
邮件接收器重建后，现在可以正常使用相同的地址了。
之前重建似乎并未奏效，很高兴现在能正常工作。
为了让 mail-receiver 正常工作，我是否需要另外允许端口 25？
在这种情况下，正常工作意味着收到的电子邮件会显示在 .\launcher logs mail-receiver 中，并到达 Discourse 管理界面。
是的，您必须打开 25 端口。这可以作为可选规则添加到本指南中。
嗯，我没有打开 25 个。所以，没有。
但 ufw status 没那么有趣。nft list ruleset 才有。
更新： ufw deny 25 已应用，mail-reciver 工作正常（2025 年 2 月 7 日）
可以确认这是正确的，尽管我犯了另一个错误。这是关于我第二个实现 mail-receiver 的论坛，在第一个论坛上，我将接收邮件的域的 MX 记录的 Value 设置为 DISCOURSE_BASE_URL
现在邮件正通过我的（第二个）论坛 UI 接收，而不是只发送到我的第一个论坛 
注意：这种正确性的信念可能是我在更改 yml（2015 年 2 月 6 日）后没有运行 ./launcher rebuild mail-receiver 的原因。
我想你不需要在防火墙上允许端口 25，比如 Azure 或 VPS 面板——在 Ubuntu 之前
因为 MX 记录的值应该指向网站，而不是邮件域，真有趣
官方指南提到必须开放25端口：
我自己也遇到了邮件接收器问题，因为我忘记在防火墙中开放25端口。添加规则解决了这个问题。
更好的解决方案可能是只允许相关的 IP 地址？
别告诉我我的邮件接收者 
传出邮件使用 Amazon SES 进行。传入邮件通过 mx 到论坛的域，现在 Docker 开始工作。
原因是 Docker 及其内部工作方式。它根本不关心 ufw。如果你想要确切的详细解释，请稍等——我曾经问过为什么 Discourse 不关心我的防火墙，原因是数据包流量。但深入理解正在发生的事情不是我的强项。对我来说，只要事情能正常工作就足够了。相信我：ufw 只打开了端口 22、80 和 443。
我估计你引用了一种邮件接收者也使用 postfix 来发送电子邮件的情况。