我从 1995 年就开始使用 sendmail 了。我有一台 Ubuntu 12.04LTS 服务器，据我所知，它使用 sendmail 8.14.4。我遇到一个问题，邮件来自一个发往本地地址的 IP 地址，带有一个投递状态通知请求，显然是来自一个不相关域的用户，我相信这是一个 DDOS 目标域。即使有：
功能（'require_rdns'）dnl
FEATURE('block_bad_helo')dnl
功能（'badmx'）dnl
我不知道为什么 sendmail 没有将其标记为伪造邮件和可能的垃圾邮件并直接拒绝它，但这是另一个问题。如果我能解决这个问题，就可以避免接下来的问题。
需要明确的是，这封邮件是发给本地用户的，因此原始邮件不会被识别为中继尝试。通过请求传递状态通知，该电子邮件导致我的服务器向明显的发件人发送电子邮件，我确信该发件人从未发送过原始电子邮件，实际上是 DDOS 攻击的目标。从明显的发件人发出的消息失败了，sendmail 仍在继续尝试发送此传递状态通知。
我已经设置好了（请原谅我从一台电脑走到另一台电脑重新输入，可能这里的字符不够完美）：
在 sendmail.mc 中定义（'conf_PRIVACY_FLAGS'，'......，noreceipts'）dnl
并已证实
O PrivacyOptions=......,sendmail.cf 中的 noreceipts
我已经执行了 sudo 重新加载，并至少重新启动了两次服务器，应该可以使用新的 sendmail.cf 文件。我搜索了一下，发现有关 DSN 的信息很少，只有一条建议插入“noreceipts”，另一条建议不要这样做，因为这样做太严格，会导致问题。
我担心的是以下两种情况之一：
DDOS 攻击者可能正在使用垃圾邮件路由来获得成功：他已经找到了一种方法，可以将看似来自目标域的电子邮件发送到我的服务器，以便通过对伪造邮件的定期检查，并且我的服务器正在本地发送垃圾邮件（我检查过它是垃圾邮件），然后反复尝试提供请求的成功通知。这导致了 DDOS 攻击者最初想要的结果，即我的服务器正在参与对看似发起域的 DDOS 攻击，依赖于我的服务器反复尝试频繁重新发送通知。我的日志中充满了这些尝试。如果有成千上万台其他服务器也在做同样的事情，那么 DDOS 可能会成功。
或者...僵尸网络确实危害了我的网络中的某些内容（正如 CBL 报告的那样），并且这使我的服务器进入了发送域使用的拒绝列表，这就是垃圾邮件的成功通知无法送达的原因......但垃圾邮件显然一直来自这些域，并不断请求 DSN。
但是，这两个问题都引出了一个问题，为什么在我编辑 .mc、编译为 .cf、执行重新加载和重新启动并手动反复刷新 mqueue 之后，sendmail 会忽略“noreceipts”并继续尝试发送这些通知？
我究竟如何防止 sendmail 8.14 生成成功传递状态通知？
谢谢