I've got an idea for faster rDNS lookups. Before I present the solution. Here is the problem...
...basically, rDNS checks are "expensive". They sometimes take a few seconds when done in real time and depend on the timeliness and of other people's DNS servers. This 1-5 (or more) seconds may not seem like a big deal... but if this can be more instantaneous, it increases the volume of messages a server-side spam filter can handle. (every little bit counts) Anyone doubt me? Well... my point is valid for the same reason that it is typically MUCH faster to check again a DNSBL (like SURBL) than it is to convert domains found within the e-mail to IP addresses and then check these again SpamHaus's RBL. Both of these are good techniques... but DNSBL checking where each domain doesn't have to be resolved to an IP address is much faster. For the very same reasons... again... rDNS checks are a bit "expensive". But consider that a given IP's rDNS doesn't change that much (on average). Therefore, it would be a huge time and resource saver to specially program a DNS server to receive rDNS queries in RBL-like format, to do the rDNS lookup on the IP address passed in the RBL-like query, and then to return results much like an RBL would... "Null" for having an rDNS, and "127.0.0.x" if the IP does NOT have rDNS. This way, the mail server is "tricked" into thinking that this is just another RBL. You might ask, "where is the time savings if the DNS server has to fetch the rDNS all the same?" Here is the clincher... because, as I mentioned, rDNS settings don't change often, therefore, PERHAPS.... the DNS server could be configured or programmed to cache BOTH positive and negative results for 24 hours (or whatever the config file requests... maybe even DAYS). This way, although the 1st rDNS query would still be expensive, subsequent queries would be lightening fast. Also, since rDNS should (ideally) never be enough of a factor by itself to mark a message as spam, then, therefore, a rare mishap on someone's legit mail server wouldn't block mail if all else is well. (And those few who have no problem blocking soly on rDNS... they'd not mind such extremely rare FPs anyways) Therefore, the negative caching would have virtually no effect on temporary mistakes made by other mail admins... and this is in contrast to the damage that might be done if a regular DNSBL's records were cached for too long and a FP comes along that was quickly and already "fixed" but then still "stuck" as blacklisted on a server due to such caching. Also, before anyone mentions TTL values providing caching anyways... consider that you typically get not long or zero caching of negative results. This feature I describe would be VERY beneficial because MANY spam filters which have to option to do RBL lookups could benefit. They could just remove their regular rDNS feature and then do the lookup I described and use the RBL-based return in the same way that they previously used the rDNS for. Does anyone know of a publicly available RBL that already does this? Anyone interested in creating such a service? (I don't think I have the expertise to do this.) Thanks for your help!! Rob McEwen PowerView Systems
