Postfix reject_unknown_reverse_client_hostname：将默认的unknown_client_reject_code（450）替换为550。为什么/何时不应该？

在与SPAM的日常斗争中，有好几次我一直试图严格执行来自野生Internet连接的客户端的DNS要求。

详细地说，我将在我的smtpd_client_restrictions部分中添加reject_unknown_reverse_client_hostname设置，如下所示：

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

无论如何，我注意到在遇到这种限制时，Postfix的行为非常“柔和”，因为的默认值为unknown_client_reject_code450。因此，邀请客户端继续重试。

在调查550答复时，我在Postfix官方文档中遇到了以下声明：

我绝对不是整个RFC 5321的专家，但是作为一个足够大的人知道RFC 821的人，我真的不明白为什么以550而不是450的响应会在最高SMTP级别上影响我的Postfix实例（违反RFC规范），尤其是考虑到在出现临时错误的情况下，无论明确设置如何，Postfix都会坚持使用450。

那么，有人可以帮助我了解这种替换的问题吗？

PS：与此同时，我以“放松”的限制告终：

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

我将从两个实际答案开始

1. 第一个也是最明显的答案是，在出现临时DNS错误的情况下，临时退回将允许发件人的邮件服务器重试，直到解决DNS错误为止。在这种情况下，永久弹跳会阻止实际的火腿邮件到达您的手中。

2. 第二个答案是，大量垃圾邮件是通过僵尸网络发送的，这些僵尸网络没有任何形式的实际功能程序来发送邮件。他们只会喷一次垃圾，无论该消息是暂时性还是永久性错误，它们都不会尝试重新发送任何消息。因此，通过使用临时错误，您可以永久阻止很大一部分垃圾邮件，但仍然允许火腿再次尝试。（顺便说一下，这就是为什么将灰名单仍然有效并且仍然捕获大量垃圾邮件的原因。）

除了这些之外，还有一个答案更适合该理论和RFC

RFC在4.2.1节中说。那：

判断答复是否适合4yz或5yz类别（见下文）的经验法则是，如果在不更改命令格式或发送方或接收方属性（即，则命令将重复相同的操作，并且接收方不会提出新的实现）。

在反向查找失败的情况下，仅在DNS错误已解决的情况下，消息本身可能会被接受而无需更改消息本身。因此，这应该是暂时的错误。

在邮件不是垃圾邮件的情况下，发送邮件服务器的sysadmin可能会注意到该错误消息，并解决了DNS问题，因此可以在无需用户干预和重新发送邮件的情况下传递邮件。并且，除非发送电子邮件的用户还负责邮件服务器和/或其DNS条目，否则即使他们确实获得了永久退信，他们也将无法执行任何操作-与拼写错误的情况不同地址。

当然，您仍然始终有权以任何理由拒绝任何电子邮件。