Just in case, make sure the --lint passess with no complaints, e.g: # su vscan -c 'spamassassin --lint'
David B Funk writes, > Cannot tell for sure (I don't use amavisd) but that looks like something > is broken in the way that messages are being passed into the SA engine so > that it no longer 'sees' headers vs body part of the message. > The RFC message format is headers first, then a blank line then body. > So if something is feeding a blank line to SA -first- then the message, > SA will think that the message has no headers and -all- of it is "body". So it seems. I'm not aware of any such compatibility problems between amavisd and SpamAssassin, it is more likely it is a mail submission problem, or there was really such a broken mail that arrived to MTA 'from the wild'. > Is there some way to collect telemetry on what is actually being fed into > the SA engine? Some amavisd option that is equivalent to running spamd > with the '-D' option? The # amavisd debug-sa turns on SpamAssassin logging. If a mail gathered enough spam points it was already captured in a quarantine and can be examined there. An alternative is to specify a 'test sender address', e.g.: @debug_sender_maps = ( ['[EMAIL PROTECTED]'] ); When a mail is seen whose envelope sender address matches the configured one, a temporary file with a message is preserved and can be examined. The log reports the fact, and tells the directory, e.g.: (42432-01) DEBUG_ONESHOT CAUSES EVIDENCE TO BE PRESERVED (42432-01) (!)PRESERVING EVIDENCE in /var/amavis/tmp-am/amavis-20070924T195255-42432 Mark
