Max SpamAssassin Size problems

[Julian Field]

-----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. 
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
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

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


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

wj8DBQFE7Wj2EfZZRxQVtlQRAnS8AKCMru7YT5pnn4wS8k6l3boD9uaa3ACfYthV
MQjQuJctKtXA2Jyu/dO7UUo=
=nu50
-----END PGP SIGNATURE-----

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