Spamassassin size limits being ignored?

[santrix]

Hi,

In my spamassassin options (under Exim Configuration Editor) I have

Maximum size a message can be before it will not be scanned by SpamAssassin = 200

I know this figure is large, but I was just watching "top" while having a cup of coffee and the CPU load went nuts due to spamd and then clamd - spamd was running inder one of my user accounts, so I thought I would check out exim_mainlog to see what all the fuss was over...

This is what I found:

2009-09-03 10:31:38 1Mj8eu-0003tP-14 H=smtpauth11.prod.mesa1. bingojim.net [44.44.44.44] Warning: "SpamAssassin as woohoo1 detected message as NOT spam (-2.6)"
2009-09-03 10:31:43 1Mj8eu-0003tP-14 <= [email protected] H=smtpauth11.prod.mesa1.bingojim.net [44.44.44.44] P=smtp S=1715979 [email protected]
2009-09-03 10:31:43 1Mj8eu-0003tP-14 => catchall <[email protected]> R=virtual_user T=virtual_userdelivery
2009-09-03 10:31:43 1Mj8eu-0003tP-14 Completed

So, a message arrived and was spam free... but look at the S=1715979... the message was over 1.5Megs, so why would spamd be run against it?

Steve

p.s. the ip addresses and hostnames altered to protect the innocent!

 

[MattCurry]

Spamassasin

Hello,


I do apologize for your issue, and I have looked into it. However, it looks like the best course of action in this case would be to submit a ticket. I would also restart spamd just to make sure first. Please let me know if you have any other questions.

Thank you,
Matthew Curry

 

[santrix]

For anyone who is reading, the boys at Cpanel reinstalled exim/spamd, and found a few bits of perl weren't all there, but this didn't change the behaviour. In the end, another cpanel support told me that this is just normal behaviour.

i.e. messages that are over the size quota are always tagged as "not spam" and delivered. You won't/should never find anything tagged as spam which is over the quota.

 

[santrix]

Sorry to bump this one, but there is still something not right about the way WHM is doing things.

I just created a largish (15Mb) email from my gmail account, and sent it into my account on my WHM box...

Watching top, I saw spamd fire up under my user account, and hog 90% CPU for a few seconds while the message came in... Why?

If WHM is supposed to NOT spam scan messages bigger than 100k (as set in WHM) then why is spamassassin spamd still obviously scanning the incoming message?

Steve

 

[cPanelDavidG]

For anyone who is reading, the boys at Cpanel reinstalled exim/spamd, and found a few bits of perl weren't all there, but this didn't change the behaviour. In the end, another cpanel support told me that this is just normal behaviour.

i.e. messages that are over the size quota are always tagged as "not spam" and delivered. You won't/should never find anything tagged as spam which is over the quota.

Hmm, can you provide me with your ticket ID number for that ticket? I'd like to follow up internally about the behavior described in this thread.

 

[santrix]

Thanks David.

For everyone else's info, this issue was re-investigated at a lower network level and it was found that Google and Yahoo (and perhaps others) were not issuing a SIZE command during the initial SMTP calls, therefore making it impossible for exim to determine if the message was too big to push through spamassassin.

The end results is that where an incoming message arrived with no associated SIZE command, that it will get scanned by spamassassin regardless of it's size - with obvious consequences in terms of un-necessary CPU overhead while large messages are scanned.

Once more thing has occurred to me in the week or so following this investigation, which may actually be quite serious.

Supposing a spammer decided to fix his sending MTA so that it deliberately passed an inflated value for the SIZE parameter during the SMTP connection. Doing so, might he not in effect force exim to bypass spamassassin for that message altogether (with WHM telling exim to bypass SA for anything over, say 100kb), despite the message being below the 'ignore' threshold?

Steve

 

[santrix]

Again folks, sorry for bumping this, but...

I am no specialist in exim, so forgive if this question sems naive, but my understanding is that in order for the message to be scanned by spamassassin (either correctly or incorrectly, based on it's size), the message must first be received (not accepted) by exim.

Wouldn't it be possible at this stage to determine the message's actual size, and then act appropriately, rather than just relying on the SIZE command?

It appears to me that the SIZE command is of more use in rejecting the message at the initial handshake, to save eating up bandwidth - however in our case, the message must have been received in order to be passed through SA, so isn't relying on the SIZE command questionable at best?

Steve

 

[santrix]

Actually, this time no apology for bumping this thread again... this problem is still there. It MUST be affecting other users of WHM...

Just to recap, I am getting entries like this:

2010-03-08 21:57:46 1Nokx9-0002UO-VA spam acl condition: cannot parse spamd output
2010-03-08 21:57:46 1Nokx9-0002UO-VA H=omp234.mail.ukl.yahoo.com [87.248.110.204] Warning: "SpamAssassin as xxxxxx detected message as NOT spam ()"
2010-03-08 21:57:46 1Nokx9-0002UO-VA <= [email protected] H=omp234.mail.ukl.yahoo.com [87.248.110.204] P=smtp S=7764184 [email protected]
2010-03-08 21:57:58 1Nokx9-0002UO-VA => [email protected] <[email protected]> R=lookuphost T=remote_smtp H=mx1.bt.mail.yahoo.com [195.50.106.143]
2010-03-08 21:57:58 1Nokx9-0002UO-VA Completed

in /var/log/exim_mainlog

Note the size (S=7764184) of the message - and the fact that Spamassassin tried to scan it!!! This is causing huge CPU spikes.

This was previously investigated by Cpanel support who found that the SIZE value exchanged during the SMTP connection from some sources (yahoo being a major culprit) was either not there, or invalid. This is causing SA to scan huge messages (much bigger than the 100k limit set in WHM).

Isn't it possible for the message to be accepted and then "sized" locally before exim decides whether to put it through SA? After all, the logs clearly show that the message size has been calculated correctly somewhere along the line... This seems like such a bad situation.