Possible config option to skip filename/filettype checks for the message body?

[Julian Field]

On 09/06/2009 19:52, PSI Mailbag wrote:
> On 22/05/2009 04:43, Julian Field wrote:
>    
>> Just use a ruleset on "Allow Filenames" and "Allow Filetypes", with
>>      
> "."
>    
>> as the value for messages you don't want to check. That will allow any
>> filename containing any character.
>>
>> On 20/05/2009 05:07, PSI Mailbag wrote:
>>      
>>> Hey Jules + List,
>>>
>>>    What do you guys/gals think about a config option to bypass the
>>> filename/filetype checks on the message body? Very frequently, I get
>>> messages being blocked because "file" (and even when used in the
>>>        
> mime
>    
>>> only option) detects regular chatter as being a file that shouldn't
>>>        
> be
>    
>>> sent:
>>>        
> <snip>
>
>    
>>>    In my mind I see a config option that would allow you to bypass
>>>        
> the
>    
>>> "file" results from the content extracted from the message body
>>> (msg-*.txt), while still allowing it to properly run against regular
>>> attachments.
>>>        
>
>
> Hey Jules, can we revisit this? It's true that your suggested config
> would work in this case, but it would also disable all file/content
> checking in the process (which kind of defeats the purpose). Even if
> "Allow Filenames" was set to \.txt$, the attachment is still removed as
> it matches the content type, and a lot of the definitions in file's
> magic file are poorly built (such as "Candidate" at the start of a file
> for certain Quicktime files, etc).
>    
In which case try using the MIME Types version of it instead, as that 
uses a different set of signatures, some of which are a lot better (eg. 
the text/plain one).
> Is there another config suggestion that I can use without fully
> disabling all filename/filetype checks? Since MS extracts the message
> body for AV processing, I figured an ideal solution was to be able to
> flag message body's as not being scanned for filetype checks to prevent
> the false positives, while still allowing regular attachments to be
> scanned and filtered.
>    
That's actually a lot harder than you would think. It is very difficult 
for me to work out what is the body of the message and what is an 
attachment from the output data structure of the MIME explosion code 
which is in MIME-tools. The way mail apps tend to do it is look for the 
text/plain and text/html parts, which can be easily subverted into 
making them actually hide attachments in them.

Sorry, your best bet I think is still to allow text/plain and text/html 
in filetype.rules.conf and work from there.

Obviously someone else may have a better idea... :)
> Thanks,
> -Joshua
>
>    

Jules

-- 
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store
Follow me at twitter.com/JulesFM

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
PGP public key: http://www.jules.fm/julesfm.asc


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.