> Do you need SA or something similar to invoke Razor or does it come > into play more directly?
As I was mentioning in my exchange with Bill, the Razor client portion is distributed as a few Perl apps (separate ones for checking, reporting, whitelisting, etc.) with numerous supporting .pm modules; the heavy-lifting is done in the .pms, which can also be called directly. As a clearly Perl-centric suite, it fits naturally into SpamAssassin, where it is, by far, most often deployed; SA users are assumed to be using Razor, or are told to do so before complaining about their catch rates! Under Unix variants, the apps such as razor-check can also be forked on their own, and wrapper scripts can be written to return results to a variety of calling MTAs. Unfortunately, it is not at all easy to get razor-check to work on Windows Perl interpreters; I think I'm one of the few to have gotten it working at all, but its reliability is still questionable (i.e. it frequently times out, though it does return correct results whenever it connects). I think this has to do with Perl's socket support, which is not equivalent on Windows and *nix (even though a vast number of other Perl areas work just as well on either platform). So the only reliable way that I know of to run Razor on Windows is to use one of the "compiled" (really, more like "assembled") spamassassin.exe binaries that have the socket issues fixed up and Razor support inside. These exes, however, are necessarily bloated with Perl runtimes and the whole SpamAssassin enchilada, which means you are talking _major_ scan times per fork, even with all other SA tests turned off except for the Razor interface. Spamassassin.exe is simply a wrapped-up executable assembly of spamassassin.pl, and will not execute any faster than the .pl (it's just easier to roll out). Spamassassin.pl/.exe is the a standalone version of SA -- where a new spamassassin process is forked for every incoming mail -- which is not the way it should be run, even on Unix, though it appears to be even worse on Windows. Rather, SA should be launched via spamd, the client-server daemon, since that eliminates the huge overhead of Perl startup and module and rulebase loads; spamd is the only way to scale SA (okay, there are also third-party filtering daemons that support SA as well as other scanners, and replicate spamd's preloading functionality, but that's a whole other topic and completely on the *nix side). SPAMC32, a free Declude external test whose URL is in my sig, is a Windows client for spamd that was designed especially for Declude integration. It requires that you have a spamd running somewhere, and if you're going to need Razor support in your spamd, that somewhere is going to have to be a *nix box, as far as I know. OTOH, you could certainly demo Razor's accuracy by forking a bulky spamassassin.exe only against a corpus of false negatives. There are also a couple of (to my mind) dubious, low-adoption open-source SMTP proxies that claim to integrate Razor without SpamAssassin, but those are unproven in my book, and are likely too competitive to be appropriate on this list if they even work... but those might be another way to at least preview accuracy. HTH. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
