RE: [Declude.JunkMail] Razor

2006-07-24 Thread John Shacklett
Thank you, Sandy. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford
Whiteman
Sent: Friday, 21 July 2006 2:49 AM
To: John Shacklett
Subject: Re: [Declude.JunkMail] Razor

> 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/downloa
d/release/
 
http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re
lease/



---
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.




---
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.



Re: [Declude.JunkMail] Razor

2006-07-20 Thread Sanford Whiteman
> 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.



[Declude.JunkMail] Razor

2006-07-20 Thread John Shacklett
I'd like to break the flow of the current discussion and circle back a
number of posts to ask a question.

I'm not familiar with either Razor or Cloudmark and Bill's mention of that
service caught me unprepared. How does Razor fit into your analysis? Do you
need SA or something similar to invoke Razor or does it come into play more
directly?


--

John 



---
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.