SpamAssasin : problems with some emails...

same here

I cannot figure out what's wrong in spamd conf, sockets or perl module Mail::SpamAssassin, but "spam acl error" occurs at least once per hour, letting obvious spam mails to go through filter with No-Score.

spamd -D --lint gave no errors, maybe acl is malformed, so those particular mails break the process.

At the same time of error SpamAssassin writes a file in /tmp, which is new for us.

If anyone can bring light here it will be very appreciated.

Thanks in advance for your time,

BTW
Perl Version is 5.8.8, SpamAssassin 3.2.4, Mail::SpamAssassin 3.002004 (holdback)

 

I see the same messages. I don't consider it real ipmortant (for me) - Over the past five days I've seen that exactly five times (at various times on various days) and we have hundreds of thousands of messages go through over the course of that time. So it's pretty rare.

Unfortunately I don't have the source messages to check them out at this time.

Mike

 

our problem was quickly solved by cpanel support tech staff. SpamAssassin was not configurated properly at

Code:

/etc/cpspamd.conf

As occasionally mail load processing was high, spamd childs refused to work, giving that "acl spam condition" error.
Try to increase connections per child and/or number of childs accordingly to your server performance (check SpamAssassin documentation)

 

I'm sure it was not properly created, I have noticed it too.

 

Was this problem (from 6/9/08) ever solved? I did a manual upgrade last night to cPanel 11.23.3-S25971 (stable). Ever since then, I've been getting these errors -- about one per minute at their peak.

I've got spamd's maximum children set at 25 now, and maximum processes per child at 35, so I don't think that could be the problem.

It's got to be something that's changed between v11.18 and v11.23. But what?

rac

 

Same problem here...

 

I recommend having our technical analysts take a look at this for you: http://tickets.cpanel.net/submit

 

i can't at the moment, i am not allowed to open access to 3rd parties unless its a catastrophic situation.

is there something that can help me debug the problem by myself?

 

Anyone solved this problem please?

 

I must laugh at that. At the same time, I feel bad for you. I undestand things beyond your control because maybe you do not control the policy in your company. It's ashame though that they would state that things couldn't be opened up to the people who you pay to provide you with support. yikes.

Of course I've been down similar roads before so I can sympathize with you.

Mike

 

I don't see this happen very often, but I do see that it happened with an inbound message on a server I manage this morning. So I opened a ticket iwth Cpanel to see if they could take a look at it - just to help those of you out who can't open a ticket iwth Cpanel.

Not sure what they will find out though.

Info in exim_mainlog shows:
2008-07-14 01:08:44 1KIGI4-00007j-M7 spam acl condition: cannot parse spamd output
2008-07-14 01:08:44 1KIGI4-00007j-M7 H=nf-out-0910.google.com [64.233.182.189] Warning: ACL "warn" statement skipped: condition test deferred
2008-07-14 01:08:44 1KIGI4-00007j-M7 H=nf-out-0910.google.com [64.233.182.189] Warning: "SpamAssassin as gemoon detected message as NOT spam ()"
2008-07-14 01:08:49 1KIGI4-00007j-M7 <= some_email_address@gmail.com H=nf-out-0910.google.com [64.233.182.189] P=esmtp S=10910940 id=4548bc380807132207y647d7f79u385445c46e63147@mail.gmail.com T="some subject"
2008-07-14 01:08:49 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1KIGI4-00007j-M7
2008-07-14 01:08:50 1KIGI4-00007j-M7 => someuser <someaddress@somedomain.com> R=virtual_user T=virtual_userdelivery
2008-07-14 01:08:50 1KIGI4-00007j-M7 Completed

mike

 

As you stated, its beyond my control

So far, my tests show that with a recent spamassassin update, the return status from spamd is not recognized by Exim's ACL, thus the no score () in the error message.

Probably the ACL is outdated and doesn't cover all the different return codes from spamd.

 

It's been mostly resolved in my case. My ISP filed a ticket with CPanel and the result, after a few days of trying other things, was a perl reinstall, I am told.

I'm still seeing an occasional spamd failure (one in the past 24 hours) but nothing like before, when it was several times per hour.

 

Then we have the same problem since these errors aren't very frequent here either.

The problem is that /tmp is fill up with spamassassin temporary files and the logs are filling up by the end of the week.

 

Well, you can always delete the tmp files periodically and take care of that problem. I'm surprised you're having problems with the logs if the failures are infrequent. I went back and checked, and at the peak I was getting one failure per minute, and the logs faithfully recorded every one without problems. Of course, I do enjoy seeing a nice zero-byte paniclog file as much as anybody.

 

thats not a real solution, its obvious that Exim ACLs or Spamassassin have a bug that causes this, the cPanel developers should find and fix the problem.

 

Anyone managed to resolve this problem?

 

I think i solved it, found the bug and fixed it. I'll wait for a day and if i don't find any more temp files from crashed spamd processes then i'll explain how i fixed it, otherwise... i messed up :D

Still, things are looking good, haven't had a spamd process die in over 12 hours now...

 

Here is how to fix the problem:

1) stop exim/clam/spamd, while we do our updates
service exim stop

2) clean temporary directories (very important step)
rm -rf /home/.cpan/*
rm -rf /home/.cpcpan/*
rm -rf /var/lib/spamassassin/*
rm -rf /tmp/.spamassassin*

3) delete existing SA in order to force it to recompile
rm -rf /usr/local/bin/spamassassin
rm -rf /usr/bin/spamassassin

4) re-do perl libs and recompile SA
/scripts/installspam

5) restart everything
service exim start


PS:
the clue here is the path /var/lib/spamassassin/ which most people don't know it exists, and its why those with the bug can't get it fixed even if they reinstall SA, that directory must be deleted.

PS2:
edit your /etc/cpspamd.conf and make sure you have sensible values, like maxconnperchild should be at least 200 (i use 500 or 2000 depending on the server), max children to at least 3 (i use 5 or 10).

PS3:
now leave the system running for a while and check back on it by looking for the dump files under /tmp with: ls -la /tmp |grep -v sess

PS4:
use the above at your own risk, if it kills your dog, steals your bank accounts, i can't be held responsible :D