On Fri, Aug 20, 2010 at 8:14 AM, <lst_ho...@kwsoft.de> wrote: > Zitat von Stan Hoeppner <s...@hardwarefreak.com>: > > > Robert Fournerat put forth on 8/19/2010 4:46 PM: >> >>> Quoting Noel Jones <njo...@megan.vbhcs.org>: >>> >>> Same here. reject_unknown_client_hostname is too strict, but >>>> reject_unknown_reverse_client_hostname rejects lots of obvious spambots >>>> without resorting to an RBL lookup. The false-positive rate is close >>>> enough to zero that I would not consider removing this restriction. >>>> >>> >>> Call me a BOFH, but I have no sympathy for mail servers >>> that do not pass the FCRDNS test. >>> >> >> Agreed. Given that the majority of consumer broadband providers in the US >> assign rDNS to even all their consumer IP addresses, there's no reason for >> a >> legit mail sending host to not have rDNS. >> >> However, because of the above situation, the existence of rDNS for a mail >> sending host is worth less as a spam check because so many devices have >> rDNS >> today. Using fully qualified regular expressions to check for such >> consumer >> space rDNS is usually much more effective and less error prone. >> > > Since we are using greylisting all need for checking rDNS or DNSBL because > of spam-bots from dynamic IPs is gone anyway. Or main problem are the > "half-legal" spam networks spanning whole AS and operating with proper DNS, > real mailservers and even SPF and DKIM. > > So no, rDNS checking is useless or even harmful in our case. > > Baseline for the OP: Your server, your rules. Check your traffic and see > what spam fighting method is most useful and least error prone in your > special case instead of blindly trust third party experience. >
I don't know if it is blind trust. Some of these people have answered my questions here before with smarts. But I will continue to observe my maillog stats in cacti. I made the change late yesterday and so far the only noticeable blip was a few hundred more virus emails quarantined than on any other recent day. I have to balance this against sometimes urgent situations where someone has been not getting email and is running against some deadline. If we can avoid raising the stress levels and not have it associated with our IT group, this could be a good thing. Normally the problem is that the other site believes they have rDNS set up, but have non-matching values, often due to new mail gateway appliances or services. I'm going to start another thread about greylisting choices. --Donald
