filename checks = wrong filename report

[Sylvain Phaneuf]

>>> Scott Silva <ssilva at sgvwater.com> 10/07/2008 00:00 >>>

> And this would be feasible in the body text of a text/plain message 
> section? (which is ultimately what the report is)
> 
> At that point they could just send the exploit in a message body and not 
> bother with a file in the first place.
> 
>> ooohoheresmyreallyscarrrylongfilenamethatcouldbufferoverflowyourpcandletmerunwhateverIwantonit.exe 
>> 
>> 
>> 
>> See, nothing happened, did it? Even if it was thousands of characters 
>> long, it would be no different, because it's in the body text.
> How about when that longscaryfilename..... gets sent to syslog. That is 
> another reason to sanitize the names.
> 
> Julian didn't set it that way to be easier, or to mess with users. He has 
> listed all the reasons in the past, I just can't remember them all.

Sorry, I had not realised this had been discussed in the past. I can't keep up with the MailScanner list people!

I will try to search the archives... 

I see the point about 150 characters limit, but the filename I see in my log is 
CNU0701SF00084(Sent200807041022)2.mail.pdf
and it is 42 characters long.  This attachment was not > 150 characters and yet it's name was sanitized. That's what is really confusing. The sanitizing hides the real fact that caused it to be blocked: it contains multiple extensions. Could the length of the filename trigger a different report that when an attachment has multiple extensions?

Sylvain