Postfix reject_unknown_reverse_client_hostname: replace default unknown_client_reject_code (450) to 550. Why/When I should not?

In the daily battle against SPAM, there have been several times when I've been tempted to heavily enforce DNS requirements from clients connecting from the wild Internet.

In detail, I would have added the reject_unknown_reverse_client_hostname setting within my smtpd_client_restrictions section, as in:

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 

Anyway, I noted that when hitting such restriction, Postfix behaviour is quite "soft" as the default value for the unknown_client_reject_code is 450. Hence, client is invited to keep retrying.

While investigating for a 550 response, I met following statement, on the official Postfix documentation:

I'm absolutely not an expert about the whole RFC 5321, but as someone old enough to know RFC 821, I really don't see why, a 550 response instead of a 450, could impact my Postfix instance at the maximum SMTP level (breaking RFC compliance), expecially considering that in case of temporary errors, Postfix will stick with a 450 regardless of the explicit setting.

So, can someone help me understanding what's the problem with such a replacement?

P.S.: in the meantime, I ended with a "relaxed" restriction:

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 

Solution 1:

I'll start with two practical answers

1. The first and most obvious answer is that in a case where there's a temporary DNS error, a temporary bounce will allow the sender's mailserver to try again until the DNS error is fixed. In this case, a permanent bounce will block actual ham mail from reaching you.

2. The second answer is that a great deal of spam is sent via botnet boxes that do not have any form of actual functional programs to send the mail. They will spray their junk once only, and won't try to re-send any messages whether said message gets a temporary or permanent error. So by using a temporary error, you are blocking a large percentage of the spam for good, but you're still allowing ham to try again. (This, by the way, is why greylisting still works and still catches a lot of spam.)

In addition to these ones, there are also an answer that bears more to the theory and the RFC

The RFC says in section 4.2.1. that:

A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation).

In the case of a reverse lookup failure, it would be possible for the message to be acceptable without any change in the message itself, provided only that the DNS error is fixed. Therefore, this should be a temporary error.

In a case where the message is not spam, the sending mailserver sysadmin may notice the error message and get the DNS problem fixed, so that the message can be delivered without the user having to intervene and re-send the message. And unless the user sending the email is also in charge of the mailserver and/or its DNS entries, even if they do get a permanent bounce directly, they won't be able to do anything with it - unlike e.g. the case of a misspelled address.

Of course, you are still always within your rights to reject any email for any reason.