So, other than, ummm, no_dns_for_from and round_the_world, are there any other DNS related tests?
Muskoka.com 115 Manitoba Street Bracebridge, Ontario P1L 2B6 (705)645-6097 Muskoka.com is pleased to announce New High Speed Services please visit http://www.muskoka.com/services.htm for more information > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > William Stearns > Sent: Friday, March 28, 2003 3:20 PM > To: Ed Kasky > Cc: ML-spamassassin-talk; William Stearns > Subject: Re: [SAtalk] spamd/spamc performance > > > Good afternoon, Ed, > > On Fri, 28 Mar 2003, Ed Kasky wrote: > > > I am running SA 2.43 on a Redhat 7.2 machine (500 mhz with 512 > mb ram) I > > run spamc/spamd with no special switches - just invoke spamc > through procmail. > > > > Spamd takes between 10 and 12 seconds to process messages from > 3-10k in size. > > > > Is this considered to be acceptable performance or are there > things I can > > do to speed it up at all?? > > The DNS checks can take quite a while if the remotge DNS server > simply doesn't respond. One thing to do if you're starting up spamd with > the redhat init script is to touch and add this line to > /etc/syscondig/spamd > > OPTIONS="-d -c -a --local" > > and restart spamassassin with > /etc/init.d/spamassassin restart > > This will skip _all_ the network based checks, including razor, > pyzor, etc., but will speed up the processing noticeably. > If that helps, you may want to look at simply disabling, or > reducing the timeout for, the checks that take the longest. > Cheers, > - Bill > > ------------------------------------------------------------------ > --------- > "...exploiting this vulnerability would cause the RPC service to > fail, with the attendant loss of any RPC-based services the server > offers, as well as potential loss of some COM functions. > ...Although Windows NT 4.0 is affected by this vulnerability, > Microsoft is unable to provide a patch for this vulnerability for > Windows NT 4.0. The architectural limitations of Windows NT 4.0 do not > support the changes that would be required to remove this vulnerability. > Windows NT 4.0 users are strongly encouraged to employ the workaround > discussed in the FAQ below, which is to protect the NT 4.0 system with a > firewall that blocks Port 135." > > -- http://www.microsoft.com/technet/security/bulletin/MS03-010.asp?frame=true "Microsoft is betting that customers using 7-year-old Windows NT 4 Server--35 percent of the total--are ripe for an upgrade." -- http://news.com.com/2100-1012-994437.html -------------------------------------------------------------------------- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org Linux articles at: http://www.opensourcedigest.com -------------------------------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
