orphaned .tmp files in the submission folder - SpamAssassin

This is a discussion on orphaned .tmp files in the submission folder - SpamAssassin ; Hello again. I have not received any feedback from anyone. I would
really appreciate any help.
I'm using spamc/spamd with CommuniGate Pro. When spamd puts the file
in the submission folder it USUALLY gets a .sub extension applied
within a ...

orphaned .tmp files in the submission folder

Hello again. I have not received any feedback from anyone. I would
really appreciate any help.

I'm using spamc/spamd with CommuniGate Pro. When spamd puts the file
in the submission folder it USUALLY gets a .sub extension applied
within a minute or two. However I am seeing orphaned files that are
both non-spam and spam that just get left as .tmp files. Many times
these files have multiple .tmp extensions (up to 9 or 10 of them) as
though spamd just coughed and started over.

Currently I'm examining these files and deleting the spam and using a
drag and drop renaming utility to manually submit (add the .sub
extensions) these files a couple of times a day.

Why is this happening and what settings changes will stop it? I've
tried more spamd children and less spamd children. I've turned
autowhitelisting off and on. I've checked all the mysql spamassassin
database files and they are in working order.

Here's the Startup.sh script that CommuniGate pro runs with variations
of the spamd command that I've tried:

Re: orphaned .tmp files in the submission folder

At 17:34 16-07-2008, Ron Smith wrote:
>I'm using spamc/spamd with CommuniGate Pro. When spamd puts the file
>in the submission folder it USUALLY gets a .sub extension applied
>within a minute or two. However I am seeing orphaned files that are
>both non-spam and spam that just get left as .tmp files. Many times
>these files have multiple .tmp extensions (up to 9 or 10 of them) as
>though spamd just coughed and started over.

spamd does not put files in folders. spamc sends the contents of the
file to spamd. The contents are evaluated and the results are
returned back to spamc.

You can enable debugging in spamd to see what is happening at that
end. Find out what process is creating those .tmp files. The
process should usually do the cleaning up.

The probability of getting feedback is higher if you provide
technical information such as log entries which demonstrate what is
going on. If it's a spamd configuration problem, you can get the
debug output by following http://wiki.apache.org/spamassassin/HowToDebug

Regards,
-sm

Re: orphaned .tmp files in the submission folder

Thanks, SM.

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.

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

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.

Now to figure out why spamc is failing on these messages.

Question though: does spamc return any email back to the submitted
folder with extra .tmp suffixes at any time or for any reason?

On Jul 17, 2008, at 3:39 AM, SM wrote:
> At 17:34 16-07-2008, Ron Smith wrote:
>> I'm using spamc/spamd with CommuniGate Pro. When spamd puts the file
>> in the submission folder it USUALLY gets a .sub extension applied
>> within a minute or two. However I am seeing orphaned files that are
>> both non-spam and spam that just get left as .tmp files. Many times
>> these files have multiple .tmp extensions (up to 9 or 10 of them) as
>> though spamd just coughed and started over.
>
> spamd does not put files in folders. spamc sends the contents of
> the file to spamd. The contents are evaluated and the results are
> returned back to spamc.
>
> You can enable debugging in spamd to see what is happening at that
> end. Find out what process is creating those .tmp files. The
> process should usually do the cleaning up.
>
> The probability of getting feedback is higher if you provide
> technical information such as log entries which demonstrate what is
> going on. If it's a spamd configuration problem, you can get the
> debug output by following http://wiki.apache.org/spamassassin/HowToDebug
>
> Regards,
> -sm

Re: orphaned .tmp files in the submission folder

Ron Smith schrieb am 17.07.2008 14:28:
> 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.
>
> Now to figure out why spamc is failing on these messages.
>
> Question though: does spamc return any email back to the submitted
> folder with extra .tmp suffixes at any time or for any reason?

Spamc is only a filter that gets a message from standard input and
passes it (with SpamAssassin headers added) back to standard output.
Additionally, it gives a scan success/failure return code.

Spamc is not reading messages from files nor bouncing messages. It is
simply adding a few headers to the given message, so that other programs
can detect what SpamAssassin thinks of the spamminess of a message.

The caller of spamc is responsible for reading a message from a file or
a mail queue and for writing the updated message back to where it should
go. So I suggest you move your question to a Communigate support list,
since it seems that there is a problem with the calling of spamc, not
with spamc itself.