Max SpamAssassin Size problems

[DAve]

Ken A wrote:
> 
> 
> Kash, Howard (Civ, ARL/CISD) wrote:
>>> Why not just set the Max SpamAssassin Size to 50k
>>
>> You'll still truncate images.  I currently have it at 150k and it
>> still truncates images (either large ones or messages with lots of
>> attached images).
>>
>>> or the partial-image-detection rules to 0?
>>
>> This is an option, but you give up some SPAM detection capability.
>> The plugin doesn't specifically test for partial images, but corrupt
>> images in general, which truncated images are a subset of.  Some
>> image spammers have intentionally corrupted the image in such a way
>> that many email clients will still render them readable, but image
>> analysis utilities balk on them.  So messages with corrupt images are
>> given a higher score.
>>
>> And this isn't just about images, supposedly someone is working on a
>> plugin to analyze Word documents for spam content.   It may have the
>> same problem with truncated Word attachments.
>>
> 
> Exactly. So where's the best place to fix this? The most important 
> argument in the "Don't change MailScanner" camp is that you'd be opening 
> a door to DoSing a system, and defeating the purpose of "Max 
> SpamAssassin Size" if you try to pass only complete messages, images or 
> word docs to SA. This is absolutely correct, and must be avoided.
> 
> I agree, but I think this is an issue that needs to be wrestled with 
> more so that SA plugins developers are aware of how MailScanner works 
> and things get worked out the best way possible. We aren't there yet.
> 
> What if you could also pass a flag to SA that said, 'hey, SA, this might 
> be a partial image!'. Then SA could pass that to the plugins that might 
> FP on partial images? Parts of a system need to be aware of how other 
> parts work. ..resisting the urge to quote rodney king. ;-P

I still do not believe this is a problem that MailScanner needs to fix.
The plugin is 'assuming' it will always be handed a complete message 
from all past and future programs using SA, and that the message will 
never be truncated/mangled/poorly constructed for any reason. Whether 
that reason is a software failure, hardware failure, or system 
configuration.

If the plugin needs to know what condition the message is in when it is 
received, I would suggest the SA API change to pass the original message 
size and the passed data size to SA. Then the plugin could make an 
intelligent decision about the data it is inspecting.

In reality, the whole issue could be solved in the plugin README,

"In order to properly check all messages for potential image spams, you 
must configure your <package, tool, process> to pass the entire message 
into SpamAssassin. See the website of your <package, tool, process> for 
information on how to do that."

DAve

-- 
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?

Maybe they forgot who made that choice possible.