我一直在阅读 SMTP 规范和其他相关的 RFC（主要是8314和6409），但无法理解它，所以我希望你们能帮助我。
我正在尝试设置一个 SMTP 服务器来测试事务消息的传递，并且它在提交时按预期工作，也就是说，如果我们将邮件发件人指向它，它将成功请求身份验证、获取消息并存储它。所有这些都通过使用 TLS 的端口 587 进行。
现在我想添加一个包罗万象的机制，以便所有发送到 *@mydomain.com 的电子邮件都存储在同一个数据库中，所以我开始做一些研究。我发现，一旦您通过 SMTP 发送电子邮件，MTA 也会使用 SMTP 传送电子邮件，这在规范中称为“消息中继”。
据我了解，您需要侦听两个端口，587 用于“消息提交”（带身份验证，检查发件人是否在您的服务器上）和端口 25 用于“消息中继”（不带身份验证，检查收件人是否在您的服务器上）你的服务器）。由于底层服务器框架的限制，将不支持 STARTTLS，仅支持隐式 TLS，因此没有端口 465。
所以，问题是“我的理解是否正确，应该有两个具有不同目的的监听端口？”
还有一个额外的好处：当端口可互换时，服务器如何协商身份验证（例如在 CPanel 上，您可以使用 465 或 25 进行提交，唯一的区别是每个端口上的 TLS 支持；而且它们还通过端口 25 接收传入邮件）？
需要注意的是，服务器的目的不是发送任何消息，而只是从 Web 应用程序（例如测试其密码重置邮件是否有效）或从其他邮件服务器/MTA（如 Mailinator 所做的那样，带有通配符 MX 记录，用于测试传入消息/回复）。
提前致谢！
端口 25 上的 SMTP 始终是 MTA 到 MTA 连接。它最初非常开放，因此您的组织可以接收来自任何其他组织的电子邮件，而无需提前安排身份验证。
在 PC 上的 MUA 早期，他们还会通过 SMTP 将其发送到其组织 MTA 的端口 25，但这会导致垃圾邮件发送者可能滥用的“开放中继”问题。因此，端口 587 被定义为 MUA 在向其组织的 MTA 提交电子邮件时使用的新端口，因此端口 587 可能需要身份验证以阻止垃圾邮件发送者。而且，正如您所指出的，进入端口 25 的任何内容都必须针对有效的本地用户，否则将被拒绝，这也是为了避免滥用。
因此，一般来说，如果您需要您的 MTA 接收来自其他 MTA 的邮件，则需要打开端口 25，如果您需要邮件服务器接收来自其他主机上运行的 MUA 的邮件，则需要打开端口 587（需要身份验证） 。