Spamassassin unreliable

software development

#1

Half the time when I start spamassasin from my procmail filter, it aborts. The verbose procmail log says:

procmail: Program failure (-11) of "/usr/bin/spamassassin"
procmail: Rescue of unfiltered data succeeded.

Then the resulting header has no X-spam-Status line. Has anyone else had this problem? How do you make spamassassin work every time?


#2

I am having a similar problem. Spamassassin processes some mail, but a lot of it fails. It leaves a core file in my home directory. This happens with both DreamHost’s spamassassin and my own locally installed version 3.1.7. I wish I knew how to reproduce the problem so I could debug it, but as it is it seems to be random.


#3

Well I’m seeing that error return -11 when procmail sees the failure. Can you grep the sources and find out what -11 means?
I googled one other mention of a -11 exit code from spamassasin but that guy says the problem went away when he switched to using spamc/spamd. spamc is there on /usr/bin, so I tried it. When I run it that way there is no error, but there are no x-spam lines added to my header either. It is as if spamd is not installed and WE cannot install our own demons here. Dreamhost is looking into it, I’m 70 hours into my last support request and a week or so since my first on this subject.


#4

I’m also getting this with spamassassin 3.1.7 which I just installed (I’ve been with dreamhost for 1 week). It happens with about 50% of emails for me. I don’t think it is caused by emails intended to crash spamassassin as it happens with several legitimate emails I received also and if I run spamassassin manually on any of the spam it chokes on, everything works fine.

BTW, -11 is SIGSEGV, so this is a seg fault.

I tried running this using the procmail test procedure described at http://partmaps.org/era/procmail/mini-faq.html#debugging under "Help, I get this error message … ", “Troubleshooting tips” on a message which crashed spamassassin and it did NOT crash. So something funny is going on.

Hopefully dreamhost can figure this out soon, because their “junk filter” version of spamassassin lets a LOT of spam through.


#5

I think I’ve found the answer! Can anyone verify that spamassassin crashes when run from spaceymail-mx1 and does NOT crash when run from spaceymail-mx2? I grepped through my inbox and spam folder, and cannot find any cases where a mail from mx1 has any X-Spam headers in it, and 100% of mail from mx2 does have X-Spam headers in it.

So, this explains the ~50% error rate - something is wrong with spacemail-mx1! I am submitting a ticket about this.


#6

I would agree with your discovery. It seems that messages received on spaceymail-mx2 all have X-Spam headers, while only some from spaceymail-mx1 do. Keep us updated on the status of the ticket! Hopefully they can figure this out.


#7

Got a response back that they are looking into it & think they know the cause & will get back to me. Much more promising than the previous response.


#8

They’ve taken care of the problem (reinstalled perl) and now it seems to be working 100% of the time.