Hi Ron,
At 05:28 17-07-2008, Ron Smith wrote:
spamassassin --lint has always returned no issues with the rules.
spamassassin -D --lint returns a 304 line log file which I can provide
if requested. Other than the failure with Net::Ident (which refuses to
install under CPAN because it fails the make test), there is nothing
there that seems to be an issue.
spamassassin --lint tests the command line spamassassin and not
spamd. Your problem is not with the spamd configuration or the rules.
But if what you say is true of spamc being responsible for the actual
file creation and placement in the submission folder, then it would
appear to be a spamc issue entirely. Or the interaction between the
scanspam.sh script in the CommuniGate folder which
spamc does not create files. It takes the file as input and sends
the contents to spamd. According to your script, a
"$myCgate/Submitted/$NewFile" is appended to as the output of the
spamc command. That must be the orphaned files you were talking about.
I'm assuming that the spamc is probably failing, sending the .tmp file
back to the Submitted folder and CommuniGate is then reprocessing the
message and sending it back to scanspam.sh and so again to spamc.
It's your script that does that and no spamc. spamprep may be
creating files as well. As I don't use these scripts, I cannot tell
what is happening.
Now to figure out why spamc is failing on these messages.
If there is any failure, it should be logged to "$myCgate/Submitted/$NewFile".
Question though: does spamc return any email back to the submitted
folder with extra .tmp suffixes at any time or for any reason?
spamc does not return any emails. It will return the results from
spamd. spamc does not create any .tmp files. You can see the actual
output by piping an email through spamc. It's most likely spamprep
which is creating the orphaned .tmp files.
Regards,
-sm
