尝试通过邮件接收容器启用邮件回复功能时遇到了困难。我反复遇到以下错误：
NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: 中继访问被拒绝
这是为什么？我该如何进入 mail-receiver 容器，检查 Postfix 配置并进行调试？由于与端口 25 冲突，我已禁用了运行此服务的系统上的 Postfix 服务器。这样做对吗？
我相当确定 DNS MX 记录是正确的，而且任何服务器发来的入站邮件都会出现此问题。我在应用容器中使用 Amazon SES 进行出站邮件发送，那部分工作正常。
我是 Discourse 的新手，不知道如何调试整个生态系统。我是 Postfix 专家，但不知道如何在这个容器化环境中进行配置。
首先，如果您已经运行了 Postfix 实例，则实际上不需要邮件接收容器。
您可以将 Postfix 配置为回复邮件的接收器，并配置 Discourse 来轮询该邮箱。
这篇 2014 年的 howto 将为您提供足够的入门思路，我相信您应该能够自行配置 Postfix。
我完全不同意这一点。邮件接收器的优势在于邮件是通过 API 推送的，而不是轮询。使用邮件接收器时，邮件到达 Discourse 所需的时间有显著差异（分钟级对比秒级）。
配置方面的简便性也有巨大差异：邮件接收器只需更新 yml 文件中的三行，而 Postfix OOBE 则需要……更多。
该错误表明邮件域名不匹配。
由于您隐藏了部分消息内容，我们无法轻易为您排查此问题。
如果您能正常收到预期的邮件，这意味着有人正试图利用您的邮件服务器向其他域名发送邮件。例如，有人将他们的 MX 记录指向了您的 IP 地址。或者，虽然我没听说过这种情况 
，有人可能恶意企图让您的邮件服务器发送垃圾邮件。
所有这些错误是否来自同一个 IP 地址？您能否在日志中看到这些错误消息原本打算发往哪个域名？
最简单的做法是忽略它们。
我之前修改过一个原本正常工作的 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 来发送电子邮件的情况。