"Jeff Chan" jeffc@surbl.org wrote
Hi Joe, While it's nice that you want to build SURBLs into jwSpamSpy, we somewhat prefer that message processing be done in mail servers instead of mail clients particularly in order to minimize name server hits.
Hi Jeff,
I appreciate those concerns, but I have tried to address them in my client design as much as possible, to minimize any impact on SURBL compared to a server-based approach:
1) I only use SURBL if I can't verify an email as ham or spam using any other methods, such as sender whitelists, local domain blacklists, SBL records, ratware signatures, etc. jwSpamSpy is capable of detecting and tracking most of the pill / porn / warez domains etc. without having to resort to SURBL -- after all is the engine that provides a lot of the SURBL data :-)
2) I keep an extensive local whitelist of domains (several 1000s) which are never externally queried
3) I perform local DNS caching, which will eliminate a lot of duplicate queries on the wire
4) After that I go through the DNS server of the provider which will cache data; the client never directly connects to multi.surbl.org.
5) By default my filter checks for new mail every 10 minutes, less than the 15 minute TTL on SURBL. It's quasi-realtime. Therefore there should be no major time lag between delivery to the ISP mailserver and the SURBL query issued by the client, which I think was your main concern with a client-based approach. My mail polling interval is conveniently shorter than the SURBL TTL :-)
Having said that, my long-term plan is to also to offer a server-based solution that could run on Linux and other platforms. The existing client already supports multiple pop accounts on the same box, which obviously all go through the same DNS caching, etc. as they would on a server-based version.
Joe