Max SpamAssassin Size problems

[Scott Silva]

Julian Field spake the following on 8/24/2006 1:53 AM:
> 
> 
> Anthony Peacock wrote:
>>> Hi,
>>>
>>> Julian Field wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>
>>>>
>>>> Kash, Howard (Civ, ARL/CISD) wrote:
>>>>>> Instead of the closest following MIME boundary, how about the 
>>>>>> closest following blank line (or line that only contains 
>>>>>> whitespace). Would
>>>>> that
>>>>>> be okay?
>>>>> That sounds like an OK fix for the images.  The plugins don't care 
>>>>> about
>>>>> the closing MIME boundary, they just need the full base64 encoding
>>>>> present, which, as far as I know, shouldn't contain any blank lines.
>>>>> The only issue I can think of is if you hit the "Max SpamAssassin Size"
>>>>> limit in the middle of the MIME header.  Then your next blank line 
>>>>> would
>>>>> be between the header and the contents and you're left with a header 
>>>>> but
>>>>> no contents.  That would probably still trigger a corrupt image rule,
>>>>> but should be pretty rare.
>>>>>
>>>>> SA does have a MIME_MISSING_BOUNDRY rule, but it has a default score of
>>>>> zero in at least the 3.1 releases.
>>>> Sounds survivable. After the limit I will keep going until I hit the 
>>>> first line that only contains white space.
>>>>
>>>> All done. Will be in the next beta.
>>>> *Please* test this functionality after I release this beta.
>>> I have been watching this discussion with a growing uneasiness.  I 
>>> could be wrong but doesn't this behaviour open up the system to 
>>> problems with huge image files...
>>>
>>> I understand that lots of people are concerned about these gif only 
>>> spams, and that a lot of effort is going into creating the SA plugns 
>>> that OCR them, etc (I am on the sa-users list as well :-)), but I 
>>> think this change creates a means to bypass the max size setting, and 
>>> could lead to the very problems that that setting was meant to prevent.
>>>
>>> The Max Msg Size setting is there so that we can tune how our systems 
>>> work, preventing them being brought their knees by SA trying to scan 
>>> huge emails.  It feels like the new scheme is saying to the admin, 
>>> well you can set a max msg size but we will ignore that if the msg has 
>>> an image at that point.
>>>
>>> By changing the code as you describe there is now nothing to stop a 
>>> malicious sender creating an email with a huge JPG file which then 
>>> gets sent complete to SA, a few raw body rules later SA starts taking 
>>> forever to scan emails.  Receive many of these and the mail server 
>>> begins to crawl.
>>>
>>> Wouldn't it be better to roll the massage back to the starting MIME 
>>> boundary?  This way a broken gif image is not passed to SA so the 
>>> plugins don't complain, but all messages are smaller than the max 
>>> message size set by the admin.
>>>
>>> I may misunderstand how this works, so I am waiting to be corrected :-)
>>>
> Yes, you are absolutely correct. Non-spam may well include huge images. 
> The problem with rewinding to the previous boundary is that you may end 
> up not giving SpamAssassin _anything_ to work with.
> 
> So it's up for a vote:
> 
> do I chop half way through an image?
> do I chop at the end of an image?
> do I carry on for a max of 100 lines of Base64 data or until the end of 
> an image, which is earlier?
> 
> I have no intention of making the 100 configurable, it will be 
> impossible for 99.9% of users to know what to set it to.
> 
I think the third option is a good compromise. It gives a little bit of wiggle
room for the smaller images, but stops the possible overflow.
-- 

MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!