我们正在运行 Debian Bullseye 服务器来处理我们域的电子邮件。我们用作sendmailMTA。我们已禁用中继并仅在 SMTP 身份验证后接受电子邮件。
今天，我们偶然发现了一个令人难以理解的有趣情况。似乎发生了以下情况：
垃圾邮件发送者向我们发送了一条消息。在他和我们的服务器之间的 SMTP 会话期间，他使用了有效的信封收件人地址的形式[email protected]。但To:该邮件中的标头不同，并且包含不属于我们域的地址，因此无法由我们的电子邮件系统处理，例如[email protected]。信封发件人地址与邮件的From:和标头中的地址相同。Return-Path:
总结一下：
Envelope-From: [email protected]
'From' header: [email protected]
'Return-Path' header: [email protected]
Envelope-To: [email protected]
'To' header: [email protected]
现在我们遇到了以下问题：相信尝试sendmail向 发送退回消息somebody-else.com，最终通知他们消息[email protected]无法送达。
由于 DNS 解析失败，我们无法找到该退回邮件的完整收件人地址。somebody-else.com正是这个意外让我们首先注意到了问题：因此，我们收到了来自系统的退回邮件，因为无法解析该域名somebody-else.com。
因此，上面段落中的粗体“我们相信”：sendmail 实际尝试向其发送退回邮件的唯一迹象somebody-else.com是它尝试解析该域名。由于它没有理由尝试，如果它不想发送消息，我们得出的结论是它想向该域发送退回邮件。
这个假设可能是错误的。在这种情况下，如果有人能够简短地解释 sendmail 尝试解析该域名的其他原因，我们将不胜感激。
如果我们的假设是正确的：我们如何防止sendmail将退回邮件发送到收到邮件标头中的域To:（除非该域的电子邮件由我们的系统处理）？
[旁注：我们希望阻止sendmail这样做，因为我们担心它将原始邮件附加到退回邮件中，这将允许垃圾邮件发送者滥用我们的 SMTP 服务器To:至少将他们的垃圾发送给他们发送给我们的垃圾邮件标头中的域的邮政局长。 ]
更新2022-12-19
我们经常收到此类消息，并已进一步调查情况。幸运的是，我们的系统不会发送反向散射垃圾邮件。我们已经检查了几十个这样的案例，并且在任何情况下都sendmail没有将消息发送回收到To:的垃圾邮件消息标头中的域。
促使我写下这个问题的特定消息以及我们检查过的其他消息一定有什么特别的地方。我们注意到两个差异：
我们检查过的其他垃圾邮件已发送到我们为此目的创建的收件箱。此问题涉及的垃圾邮件有不是尽管信封收件人与其他邮件中的相同，但已发送到任何邮箱有已交付。
sendmail（显然）无法解析To:此问题所涉及的消息标头中的域。但是（同样显然）To:我们调查的其他消息的标头中的域不存在该问题。
目前，我们怀疑只有在无法解析收到的垃圾邮件标头sendmail中的域名的情况下才会出现奇怪的情况。To: