On Mon, 16 Jan 2006, Mike Sassaman wrote:
> % spamassassin --lint shows no output, so I'm thinking that means no
> problems in my local.cf.
Good, 'spamassassin --lint' should show no outout, it ony barks when
there's something wrong. Now 'spamassassin --lint -D' gives -tons-
of output, but any error messages often get buried in with all the
debugging output.
> % spamassassin < /tmp/test-message.txt on a lowscoring spam (-1.6 according
> to smtp-vilter's headers) get scored a whopping 14.3 by spamassassin! Tests
> hit include HELO_DYNAMIC_IPADDR, BAYES_99, RCVD_IN_SORBS_DUL,
> RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_XBL, RCVD_IN_NJABL_DUL
OK, so that vets your basic spamassassin system. Now the next thing to try
is to take that same test message and feed it to "spamd" via spamc to see
what the daemon thinks about it. Do: '% spamc -R < /tmp/test-message.txt'
that should give a report output that shows the same tests hit. If it
doesn't then that says that there's something about how you're running
"spamd" that is causing problems.
I noticed that in your tests report you show most of the score came from
network type tests. If you start your "spamd" with the "-L" command line
option that will disable all network tests (and seriously reduce your spam
recognising ability). Or if there's something about the way that your
"spamd" starts up so that network tests are disabled, it will have the
same "net"-not result.
> So I think Dave is right - the problem is with the milter, or at least the
> milter / spamassassin communication.
It may be a milter issue but first we need to rule out whether it's a
"spamd" issue (thus the "spamc" tests). IE the flow is sendmail -> milter
-> spamd, spamd results -> milter -> sendmail.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
