On 02/03/2012 06:35 AM, 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 think this will allow the mail through - but when I look at my logs just in the last week we have over 5400 rejects due to unknown client and only 24 of these are from this client - all the rest are junk.
My confusion is that a reverse lookup of the IP gives me the clients domain (dropping the mail(x) subdomain) thus I assumed it was the helo domain name - which does not have rDNS - that was causing the reject - maybe it was just a timing error. Also, as I run bind - it may be a cache error and I need to leave it for 24+ hours
Final question for the list - does anyone use "reject_unknown_client" - it has given me the most grief with legitimate clients that have poorly administered domains.
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.
we already run bind - the problem should not be temp timeouts. The domain with the problem is not under my control.
What makes you think it's his DNS that is/was broken?
But yes, a caching name server is almost obligatory for anyone running a mail server.
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.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos