我想知道当我尝试向相应服务器没有运行 SMTP 守护程序实例的地址发送电子邮件时（无论出于何种原因），我应该期待什么样的行为。
我的期望：负责发出 SMTP 请求的邮件守护进程应该检测到某些异常，并为发件人生成错误消息。
现实：邮件发出时没有任何错误，而且似乎就消失了。
我知道基本上每个人都应该意识到，一封没有错误的电子邮件并不一定意味着它已经安全到达，但我想我可能在这里遗漏了一些东西。
细节：
有一个正在运行的 Debian 主机，上面还有一些其他守护进程，但据我所知没有任何与邮件相关的进程，因此肯定没有任何东西在监听端口 25。我刚刚设置好一个域，其中的 DNS A 记录指向该主机的 IP，但没有任何 MX 记录，所以如果我没记错的话，它会回退到 A 记录。
不幸的是，我以前没有设置过电子邮件地址转发或管理邮件服务器，但将来我可能也想使用这个域名来处理电子邮件。所以我觉得探索一下如果没有任何预先设置，我尝试向这个域名上虚构的用户发送一些内容会发生什么会很有趣。它会返回一些合理的错误消息吗？我尝试过从 gmail 和 proton 发送，但如上所述，它们没有任何抱怨。而且很奇怪，因为端口 25 上没有服务。使用 telnet，我得到端口 25 的“无法连接到远程主机：连接被拒绝”，这正是我所期望的。
当然，在这种情况下无法访问的原因是显而易见的，但我认为如果以前工作的 SMTP 守护程序已停止或主机离线，情况不会有太大不同。
那么我遗漏了什么？
如果这是可以预料到的并且不必担心的事情，那么我认为应该清楚的是，在像我这样的情况下，应该设置一个 SMTP 守护进程来明确拒绝任何传入的内容，对吗？
更新
正如下面提到的，事实证明我有点不耐烦，过了一段时间后我收到了我错过的通知。
为了供将来参考，以下是我尝试这两项服务的时间间隔。
邮箱：
- 邮件守护程序的第一条消息大约在 T+26h 时发送，表示系统将尝试在接下来的 45 小时内传递该消息。
- 第二条消息是在 T+53 时发送的，承诺再尝试 19 个小时。
- 最后第三条消息在 T+75h 时到达，表示失败。
我对这种现象感到困惑，又尝试了两次，得到了类似的结果：
- 时间 +25 小时 30 分、时间 +51 小时、时间 +75 小时
- 时间 +26 小时、时间 +50 小时、时间 +77 小时
所有消息都附有描述FAILED_PRECONDITION: connect error (111): Connection refused，这与我之前收到的 telnet 响应一致。
ProtonMail：
- 首先，邮件守护程序在 T+13h 发送了一个警告，内容是将重试投递，直到邮件发送 2 天后。
- 第二次也是最后一次通知按照承诺在 T+49h 发出。
再次，这两条消息都Diagnostic-Code: [...] Connection refused如预期般显示了声明。
答案1
如果邮件是从配置正确的常规邮件服务器发送的，您不会立即看到任何错误消息。您可能很快就会收到一条错误消息（大约 12 小时后）。
发生了什么：接受用户发送邮件到您的 Debian 服务器的邮件服务器将此消息放入队列中。下一步，它会尝试清空此队列，并初始化与收件人域对应的 smtp 服务器的连接。您说得对，它要么是 MX，要么是 A。
如果无法立即发送消息（如您的情况），则会推迟发送，并在几分钟/几小时/几天后再次尝试。如果再次尝试失败，您可能收到邮件守护进程的通知，该消息仍在队列中并且目前无法投递，但服务器将继续尝试。
这个过程可能持续一周左右。一周后，服务器会认为该邮件根本无法投递，并会向您发送“退回邮件”通知，告知您该邮件无法投递，现已从队列中删除。
我提到的所有这些时间间隔都取决于邮件服务器配置，您无法提前知道何时会向您发送第一条通知以及服务器何时会停止尝试。