BETA: Max SpamAssassin Size for sendmail and Postfix

[Alex Broens]

On 9/11/2006 6:08 PM, Julian Field wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Alex Broens wrote:
>> Julian,
>>
>> On 9/10/2006 8:58 PM, Julian Field wrote:
>>> I have added the new logic to the Max SpamAssassin Size configuration 
>>> option, with just about all the extra features everyone wanted in here.
>>>
>>> # SpamAssassin is not very fast when scanning huge messages, so messages
>>> # bigger than this value will be truncated to this length for 
>>> SpamAssassin
>>> # testing. The original message will not be affected by this. This value
>>> # is a good compromise as very few spam messages are bigger than this.
>>> #
>>> # Now for the options:
>>> # 1) <length of data in bytes>
>>> # 2) <length of data in bytes> truncate
>>> # 3) <length of data in bytes> continue <extra bytes allowed>
>> <snipped>
>>
>>> I have only added the logic to the sendmail and Postfix versions so 
>>> far, as I want to be sure it works before I give it out to everyone.
>>>
>>> It's on www.mailscanner.info as usual.
>>>
>>> *Please* can you test this out for me. If you think I have gone over 
>>> the top, and just produced a system that no-one can work out how to 
>>> use, then please do tell me and I will remove bits of it again. 
>>> Personally I think it will only be used by 1% of users at most, which 
>>> leads me to think I should remove the whole thing and go back to 
>>> something much simpler again.
>>
>> As you state above "spamassassin is not very fast...."  which I'd 
>> think makes it a natural to set a max size of the raw msg to be parsed 
>> by SA which avoids rocket science.
>>
>> the truncate and/or continue with bytes may not always work for spam 
>> and may add to the load by scanning unnecessary large HAM and it seems 
>> to me its a trial & error method till one gets the spam_du_jour caught 
>> in a jungle of sizes, multiparts, etc, etc.
>>
>>> Your thoughts?
>> Though & wish: apply the VERY simple spamc method: "max msg size" and 
>> save lots of cpu time and potential FPs avoiding scanning even chuncks 
>> of oversized msgs.
>> (incidentaly scanning chuncks breaks some plugins, full & rawbody 
>> rules, etc)
> I really do not like the spamc method. All the spammers have to do is 
> make the message a bit bigger and they complete evade SpamAssassin 
> altogether. Bad news in my book.

Julian,

same would apply to MS if a spammer sends 50k of gibberish at the 
begining of a msg plus his URL payload at the endo of the message and 
you're telling MS to scan the first 40k.

so what do you do in both cases? increase the size.. but the CPU and 
time savings you achieve from avoiding scans of many large msgs is 
superior than the pain of a theoretically missed missed spam.

and what about broken rules?
Many ppl use meta rules which scan a full or raw body... and if you stop 
in the middle of the message, the rules become useless.

And third party plugins? (not only OCR)

IF you'd add the option to use the "spamc method" it would be VERY 
appreciated.

thanks

Alex