On Fri, Jul 29, 2005 at 02:23:44PM -0500, Jem Berkes wrote: > I've posted it here. I've been testing it with 2.1.6-alpha > http://www.sysdesign.ca/archive/mod_dnsbl_lookup-0.90.tar.gz
Cool. I'd split dnsbl_zones into ipv4_dnsbl_zones and ipv6_dnsbl_zones and have the DnsblZones directive work like; DnsblIPv4Zones DnsblIPv6Zones or similar. IPv6 RBL's do exist, and are incompatible with IPv4 ones, so it's worth having the support early-on. dnsbl_lookup_query() takes an IP address argument as a string, but it would probably be a lot better to take it as an apr_sockaddr_t, since that's an IP version agnostic format, and is generally the way an Apache module would have the address available to it. Passing it around in binary format also helps you avoid using sscanf and the associated reentrancy problems on many platforms. The implementation is neat, but it could also do with efficiency being in mind, IME (I help run a very large RBL) rbl lookups tend to be a big source of latency during request/mail handling and it's worth making the effort to go a bit further :) Although the dnsbl_lookup_query() function's output is comprehensive, perhaps more useful and efficient would be to supply a framework for allowing modules to check DNSBL's in a boolean manner. As-is the code scans every registered RBL, even if one flags an address as listed. That's super in-efficient for the majority case, and there's no application level caching, which tends to be a must for most implementations (even if it is only per-request, like Exim's or sendmail's implementations for example). Part of the lack of boolean-checking reveals another problem, how are other modules supposed to know what constitutes a positive for a particular RBL? It hardly makes sense for them to have to supply another directive to find this out. This is a non-trivial problem, but if you're going to have an RBL implementation it needs to be tackled somewhere, though I can't think of any easy configuration syntax that wouldn't have mod_rewrite-like complexity. Though maybe something like; DnsBlackList chainname IPv4 rbl.mail-abuse.org any DnsBlackList chainname IPv4 rbl-plus.hea.net 127.0.0.7 DnsBlackList chainname IPv6 rbl-6.hea.net ::1 would work. Then a boolean function, looking something like; dnsbl_lookup_chain("chainname", apr_sockaddr_t* address) could return DNSBL_LISTED if the address resolves at all in the mail-abuse.org list, if it's 127.0.0.7 in the hea.net one, or if it's an IPv6 address if it's ::1 in the rbl-6 one, you get the idea. Also that way it can return as soon as it finds any listing for that chain, without checking the rest. Multiple chain's mean multiple modules can use it. or that different chains can be used in different contexts and so on. Although even this complicated syntax doesn't allow for configurations like "Deny only if listed in at least two RBL's", which are suprisingly common amongst the paranoid mail administration community. And another one is that sometimes RBL's are used a whitelists, for example some people use rfc-ignorant.org lists as a whitelist so that they can know not to try callbacks [read http://www.cus.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/paper.pdf] Maybe the closest thing the Apache framework to supporting this level of complexity is SetEnvIf. Building complex allow/deny conditions is hard, and this all requires a solid think. But all that said. it's interesting stuff, and I can think of a few ways in which I'd like these kind of complex configurations, and am certainly willing to help. > The README file should describe everything. This is a module providing an > optional utility function intended for (but not limited to) mod_smtpd. The > function allows the user to query DNS based blocklist databases, both DNSBL > and RHSBL style, for arbitrary data. This can be used for all kinds of > filtering and anti-spam use, including score systems such as spamassassin. There's also http://www.blars.org/mod_access_rbl.html, for reference, but its job is different. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]