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 at centos.org > http://lists.centos.org/mailman/listinfo/centos