Herb Martin wrote:
40-50 a day (over 9 days) for low volume mail server. Another
server was primary MX until yesterday, and now I am picking off
much of the junk before it even gets to SpamD.
Ouch, that's a lot.
It was so prevalent when I first switch this Exim server to primary
that my thinking was that it was my mistake, then a problem with
having upgraded SpamD (I am running an aggressive pre-release),
then a problem that might be Cygwin specific, or finally network
related.
Hmm, you're running this under Cygwin? I wonder if the OP is, too...
I understand that -- but is the reset/failure to complete the
SpamD check also cached? That is, if stanza #1 spam check
gets reset without finishing, will the stana #2 use the
cached failure? (versus retry in stanza #2.)
I believe not -- based on my logs -- and I hope not. So with
5 spamd stanzas in the exim config, it seems to only 'miss'
once (maybe twice) per message before running the check...
A quick check of the source reveals that error conditions are not
cached, so that would explain the behavoir you're seeing in your logs.
For the devs, this is how Exim parses spamd's output. You guys see
anything odd about this?
if( sscanf(CS spamd_buffer,
"SPAMD/%s 0 EX_OK\r\nContent-length: %*u\r\n\r\n%lf/%lf\r\n%n",
spamd_version,&spamd_score,&spamd_threshold,
&spamd_report_offset) != 3 ) {
/* try to fall back to pre-2.50 spamd output */
if( sscanf(CS spamd_buffer,
"SPAMD/%s 0 EX_OK\r\nSpam: %*s ; %lf / %lf\r\n\r\n%n",
spamd_version,&spamd_score,&spamd_threshold,
&spamd_report_offset) != 3 ) {
log_write(0, LOG_MAIN|LOG_PANIC,
"spam acl condition: cannot parse spamd output");
return DEFER;
};
};
- S
