postfix：使用 milter 时有条件地忽略某些“虚拟邮箱表中的用户未知”错误

Question

注意：我最初在 Unix/Linux StackExchange 上发布了这个问题，但一周后，没有得到任何回复。我看到这里有更多的与 postfix 相关的讨论，所以我投票关闭了 StackExchange 版本的我的提问，并将我的问题移到了这里。

我正在努力postfix version 2.93，Debian 8并试图完成一些不寻常的事情。

多年来，我一直在使用一款自制的邮件过滤器，效果很好。它在 SMTP 对话的每个阶段都会运行各种测试：ehlo、、、mail fromrcpt toETC。

我已经配置postfix为对“虚拟邮箱表中的用户未知”进行标准检查，并且它也按预期工作。

然而 ...

在某些罕见情况下，我想在此rcpt to阶段拦截传入的消息，前 postfix确定“虚拟邮箱表中的用户未知”，并且如果这些邮件来自特定的一小组选择发件人并针对一小部分特定的未知群体收件人姓名，我想通过那个更温和的步骤以不同于平常的方式处理它们。

在 milter 步骤中有足够的信息可用rcpt to来执行这个特殊处理，但不幸的是，“虚拟邮箱表中的未知用户”postfix处理在调用 milter 步骤之前已经拒绝了发送给未知用户的消息rcpt to，因此该 milter 步骤从未执行。

有没有办法配置postfix仅在发件人姓名与某些特殊模式不匹配时拒绝“虚拟邮箱表中的用户未知”的消息？

如果是的话，postfix可以继续自动拒绝发送消息最多未知用户，然后它就可以只将那些罕见的特殊消息传递给过滤器，以便在步骤中对其进行处理rcpt to。

我知道我可以完全禁用postfix未知收件人测试，然后在rcpt to所有传入消息的 milter 步骤中自行管理。但是，如果可能的话，我想避免这种情况，并以某种方式postfix告诉有条件的拒绝发送给未知用户的大部分邮件，仅将来自特殊发件人的一小部分来电邮件传递到邮件过滤器处理。

我对这在 下是否能实现并不乐观postfix，但也许你们中的一个或多个人知道我可以完成这项不寻常任务的方法。

非常感谢您的任何想法和建议。

Answer 1

check_sender_access列表中查找的右侧smtpd_*_restrictions可以依次包含命名的条件限制（记录在RESTRICTION_CLASS_README 文件)。这意味着，如果拒绝向未知收件人发送邮件的标准完全取决于 rfc5321.MailFrom（“信封发件人”），那么将语句reject_unverified_recipient从列表smtpd_*_restrictions本身移到依赖于发件人的查找中应该可以解决问题：

# OLD (example, you get the idea)
smtpd_recipients_restrictions =
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    reject_unverified_recipient

# NEW (just a single replacement, adapt to your OLD version)
smtpd_recipients_restrictions =
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    check_sender_access pcre:/etc/postfix/maps/no-recipient-lookups.pcre

# /etc/postfix/maps/no-recipient-lookups.pcre
/.*@example.org/   DUNNO
/./                reject_unverified_recipient

对于每个列出的发件人（或任何其他单一check_*_access条件），这将跳过“这个收件人存在吗？”检查，对于所有其他发件人，它将强制进行该检查。

现在，整个练习只有在你稍后才有意义无条件地拒绝任何受到这种特殊处理的消息，因为 Postfix 应该早就检查过它无法投递这些消息，否则它无法处理这些消息。在 SMTP 阶段可能被拒绝的情况下，您永远不应该发出未送达报告。如果您的邮件过滤器只需要消息头（正如您调查滥用情况的用例所表明的那样），您可以通过在列表中添加无条件限制来保证这一点smtpd_end_of_data_restrictions（如果第二次查找与地址验证过程发生冲突，则可能会对性能产生轻微影响）。

---

‡ 如果不是，您可以在 中实现特殊情况是否适用的决定check_policy_service，这可以让您做出比对发件人进行简单（或正则表达式）查找更复杂的决定，例如，您可以在那里解析 rfc5322.From（标头指示发件人）。唯一的区别是，您不必编写两行文件no-recipient-lookups.pcre，而是必须编写/调整并运行返回结果的策略守护程序reject_unverified_recipient，类似于您的 Milter 当前返回 SMTP 状态代码的方式。