Jay G. Scott wrote: > Sorry. Haven't been able to work on this for several weeks. > (I'm the OP.) > > The machine runs RH linux (5.4, IIRC) installed via kickstart, using > a "stock" configuration -- no special efforts to include > any perl packages. So it's just a basic configurtion, > perl-wise. > > However, it turns out that there is a CPAN mirror inside > our firewall (nice of them to tell me about it -- which, > in fact, they didn't; I found it by snooping around). > Someone did send me a list of the dependencies they > knew about (which aren't in the INSTALL file), but, > that's __supposed__ to be moot, if this CPAN mirror is > all that it should be. We shall see -- though, right now, > I don't know when we shall see, since I'm still called > away to do this other thing. After all the time > I spent chasing dependencies it seems like I ought > to be able to find time to test out this mirror, but....
If it's a reasonably complete CPAN mirror you should be able to do a CPAN install of SA. SA's direct dependencies have dependency chains that get a bit bulky if you're trying to trace by hand; I don't recall doing so outside a packaging system with open Internet access for more than a decade and SA has gotten quite a bit more complex since then. (I remember needing a custom patch to do URI lookups in DNSBLs for quite a few years.) Keep in mind that once you've started down this path you should NOT try to install anything else with Perl dependencies from packages; always install from CPAN - or you'll end up with a real mess of mismatched modules. > About the only thing we can get past the "air gap" > (not a true air gap, but it's the shortest way to > describe it) is email. Management has all these > grandfathered requirements about stuff they must > have _and_ stuff I can't do (e.g.,no RBLs) _and_ > (so it seems to me) a real problem with certain > kinds of spam (read blue pills), so, bottom line > is, I'm reinventing a lot of wheels. Don't get > me started. *eyeroll* "Here. We need you to build a house, but you're not allowed to use your hands." Not using DNSBLs will seriously drop the accuracy over time. If you can get much feedback somewhere consisting of complete unaltered messages, you can use Bayes to help even out the hit and miss from the pure pattern-matching. You might also see if you can sneak in a local BIND/DNS-server-of-choice install and set up a local DNSBL for both IPs and URIs. You'll need an ongoing source of missed spams to extract data from. You'll miss a lot but over time you can accumulate enough information to start blocking things more effectively. I've written a crude web UI to feed data in to a database and a minimal tool to export it to DNS; you can download a tarball or check out from SVN at https://secure.deepnet.cx/trac/dnsbl. -kgd
