後綴reject_unknown_reverse_client_hostname：將預設的unknown_client_reject_code（450）替換為550。為什麼/什麼時候不應該？
在與垃圾郵件的日常戰鬥中，有好幾次我都受到誘惑，對從狂野 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
我將從兩個實際的答案開始
- 第一個也是最明顯的答案是，在出現臨時 DNS 錯誤的情況下，臨時退回將允許發件人的郵件伺服器重試，直到 DNS 錯誤得到修復。在這種情況下，永久退回郵件將阻止實際的火腿郵件到達您的手中。
- 第二個答案是大量垃圾郵件是通過殭屍網路發送的，這些殭屍網路沒有任何形式的實際功能程序來發送郵件。他們只會噴一次他們的垃圾郵件，並且不會嘗試重新發送任何消息，無論所述消息是臨時錯誤還是永久錯誤。因此，通過使用臨時錯誤，您可以永久阻止大部分垃圾郵件，但您仍然允許 ham 重試。（順便說一句，這就是為什麼灰名單仍然有效並且仍然會擷取大量垃圾郵件的原因。）
除了這些之外，還有一個更符合理論和 RFC 的答案
RFC 在第 4.2.1 節中說。那：
確定回復是否屬於 4yz 或 5yz 類別（見下文）的經驗法則是，如果在不改變命令形式或發送方或接收方的屬性（即，該命令以相同的方式重複，並且接收方沒有提出新的實現）。
在反向查找失敗的情況下，只要修復了 DNS 錯誤，就可以接受消息，而無需對消息本身進行任何更改。因此，這應該是一個臨時錯誤。
在郵件不是垃圾郵件的情況下，發送郵件伺服器的系統管理員可能會注意到錯誤消息並修復 DNS 問題，從而無需使用者干預並重新發送郵件即可投遞郵件。除非發送電子郵件的使用者同時負責郵件伺服器和/或其 DNS 條目，即使他們確實直接獲得了永久退回郵件，他們也無法對它做任何事情 - 不像例如拼寫錯誤的情況地址。
當然，您始終有權以任何理由拒絕任何電子郵件。