On 02/02/2012 17:35, Ned Slider wrote:
On 02/02/12 15:44, Giles Coochey wrote:
On 2012-02-02 15:39, Ned Slider wrote:
I would recommend removing reject_unknown_client from your smtpd_sender_restrictions.
I would not recommend that, I would recommend you fix your DNS. If you have a lot of mail throughput perhaps run a caching-DNS server or proxy to improve performance and reduce timeouts.
What makes you think it's his DNS that is/was broken?
I didn't take much notice to the overall context of the error. The sender's DNS is broken, the sender may be the same organisation as the receiver.
But yes, a caching name server is almost obligatory for anyone running a mail server.
Agreed.
There is a reason the default rejection code is 450 and that is because temporary failures in DNS lookups are not uncommon, otherwise it would be a permanent rejection. IMHO this setting is more likely to delay legitimate mail with temporary DNS issues, as is the case here, than it is to block spam. There are more reliable indicators of spam that are less likely to cause FPs than relying on a rDNS lookup.
There are times when you might want to just receive anything on port 25, missing rDNS is a good indication of a bot. I don't use absolute rules myself for accepting or rejecting emails on my gateways, but rather a score based system.
However, the sender will have a large number of deferred messages in their queue if we assume that the missing rDNS is a global problem and their users will eventually be receiving warning messages and later bounces for a good proportion of emails they send. I don't see any reason to go out of my way to workaround their problem.