orphaned .tmp files in the submission folder

[Ron Smith-4]

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:

#!/bin/sh
############################################################################
#SpamAssassin daemonstartup

spamd -d -x -q -u nobody -x -m 5 -r /var/Communigate/spamdprocessid
#spamd -d -x -q -u nobody -x -m 8 --ident-timeout=15  -r /var/
Communigate/spamdprocessid
#spamd -d -x -Q -m 8 --ident-timeout=15  -r /var/Communigate/
spamdprocessid


My hardware/software setup is as follow:

Mac OS X 10.5.4 client
4 gb ram
spamd with up to 5 children
CommuniGate Pro 5.2.5
SpamAssassin 3.2.5

[sm-7]

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

[Ron Smith-4]

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?

Here's the working line in the scanspam.sh script that calls spamc:

  /var/CommuniGate/spam/spamprep "$myCgate/$QueuePath" "$ReturnPath"  
"$Username" | /usr/bin/spamc -d 127.0.0.1 -t 800 -u "$Username" >>  
"$myCgate/Submitted/$NewFile"


Thanks,

Ron

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

[alexw]

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.

Tschau
Alex

[sm-7]

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