应用软件不应该将示例名称识别为特殊名称，而应该像使用其他域名一样使用示例名称。
目前，这些示例域名已设置了网络服务器，以说明其用途。这些域名缺少任何 MX 记录；它没有空 MX记录。因此，MTA 会尝试将邮件投递到不接受邮件的 A 记录（即 Web 服务器的 IP），从而导致邮件在我的 MTA 上排队，直到最终过期。
显然，以下RFC6761如果你是邮政局长的话，效果就没那么好了。
拒绝所有发往示例地址的邮件有什么缺点吗？是否有任何来源对此提出建议？
编辑上下文：我们会自动检查队列大小，如果队列太大，就必须有人手动检查为什么会发生这种情况。最近，这种情况的发生是因为一个应用程序向示例域发送邮件。当然，它不应该这样做，正确的解决方案是修复应用程序，但由于我不会深入讨论的原因，这不会发生。由于这种情况，我觉得在我们的邮件过滤器中拒绝邮件比在我们的警报软件中忽略邮件更好。
FWIW：我同意“你不应该这样做”的观点，但是有时世界并不完美。
答案1
导致此类邮件进入您的系统的大多数情况都属于以下类别之一，其中无需对示例域进行特殊处理：
人类故意进入这些领域是为了看看会发生什么。
他们应该使用他们控制的域名/具有明确定义（而不仅仅是已知/观察到的）记录进行测试。不太有用的测试方法产生的不太有用的结果不应该让您作为邮政局长担心。
错误地使用文档示例配置的应用程序会将邮件发送到那里，而它们应该被配置为将邮件发送到其他地方。
犯下此类错误的人应该在超时发生之前就开始收到“邮件延迟”警告。对于注意到此类错误而言，邮件在队列中实际过期之前的延迟并不重要。
滥用触发邮件的公共方法会导致 MTA 资源耗尽。
无论如何，对于有效的邮件接收域，都必须处理此问题。示例域可能是至少重要的目标域 - 他们是唯一不会合理地抱怨未经请求的邮件的收件人。
导致此类邮件进入您的系统的事件无法从源头解决，但无论如何，它们的数量正在造成问题。
我相信通过更好的邮件系统配置可以避免大多数此类问题。
物理邮件队列大小是否会成为一个问题？
您的 MTA 应该准备好将所有收到的邮件排队很长时间；这可能与管理员响应时间和/或队列到期时间有关。同样，不需要对域名进行特殊处理。
邮件队列中不必要的内容是否会造成管理开销？
我不明白建议扩展到邮件管理员明确输入的过滤器以帮助决定要详细审查哪些投递问题。无论如何，我强烈建议部署工具来汇总邮件队列统计信息，然后再将它们传递给监控/通知邮件管理员。
不仅仅是因为反复处理误报很烦人，还因为当你能立即看到它时，它有助于快速评估真正问题的严重性“99% 的故障都与这家供应商有关”。