[Mimedefang] filter_multipart stripping forwarded messages from KMail

[Kelson Vibber]

At 04:42 PM 10/28/2003, Kenneth Porter wrote:
>Given the vulnerability of our favorite broken email client, I'd say the right
>fix here is to change KMail's behavior. Otherwise the next virus writer can
>just spoof a KMail message hoping to sneak a .com file past a lenient filter.

So you're saying that Outlook will prefer Content-Description over 
Content-Disposition/filename and Content-Type/name?

If that's the case, then absolutely, no change should be made to 
re_match.  On the other hand, if Content-Description is only a backup in 
the event that no filename is defined elsewhere, then it ought to be as 
safe as having the phrase format.exe appear in the body of the message - as 
long as a filename is defined in one of those accepted fields.

I'm not suggesting that re_match should never check Content-Description, or 
that it should skip it if it finds signs of KMail in the headers.  I'm 
suggesting that - assuming no client (or at least no highly-used, extremely 
vulnerable client) will use Content-Description for the filename if one of 
the other two fields is defined - re_match should only check it if those 
two fields are blank, invalid, or not present.

Keep in mind that this behavior is not something that can currently be 
changed in KMail's settings.  The workaround has to be done for each 
attachment.  To change the default description or make it configurable, a 
patch or bug report will have to be submitted and accepted.  And getting it 
accepted assumes that the KDE folks interpret this as a KMail bug and not a 
MIMEDefang bug.


Kelson Vibber
SpeedGate Communications <www.speed.net>