Max SpamAssassin Size problems

Julian Field MailScanner at
Thu Aug 24 09:53:09 IST 2006

Hash: SHA1

Anthony Peacock wrote:
> Hi,
> Julian Field wrote:
>> 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.

- -- 
Julian Field
Buy the MailScanner book at

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654

Version: PGP Desktop 9.5.0 (Build 1112)
Comment: (pgp-secured)
Charset: ISO-8859-1


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
For all your IT requirements visit

More information about the MailScanner mailing list