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]
