Max SpamAssassin Size problems

Anthony Peacock a.peacock at chime.ucl.ac.uk
Thu Aug 24 10:26:41 IST 2006


Hi Julian,

Julian Field wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> 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. 

And if the script kiddies find out they might start using this to cause 
problems.

> The problem with rewinding to the previous boundary is that you may end 
> up not giving SpamAssassin _anything_ to work with.

True.  But for those of us not using the various image plugins, that is 
no different from the current situation.  It is only those people using 
the image plugins that this causes problems with at the moment.

> 
> 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 vote for the third option.  It keeps the idea of limiting the amount 
of data that SA gets, whilst still giving the plugins chance to get a 
complete gif image.  At the end of the day if the people using the 
plugins keep getting truncated images, they can always raise the Max Msg 
  Size config parameter.

> 
> 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.

Agreed!

-- 
Anthony Peacock
CHIME, Royal Free & University College Medical School
WWW:    http://www.chime.ucl.ac.uk/~rmhiajp/
"If you have an apple and I have  an apple and we  exchange apples
then you and I will still each have  one apple. But  if you have an
idea and I have an idea and we exchange these ideas, then each of us
will have two ideas." -- George Bernard Shaw


More information about the MailScanner mailing list