[Asrg] Usefulness of wholesale blocking of attachments for SMTP?

  I mail-server I use regularly (Indiana University) has taken, in response to worms and other malware useing .pif. zip, exe, etc attachments to spread their damage, has taken the (IMO) rather drastic step of blocking almost *all* attachments (except for pdf, doc, and a few others), including MacOSX extensions (pbproj and saver) even though there are no viruses currently which try to use OSX extensions (and they wouldn't work either, as Windows would not try to run a xx.saver file as an executable).

I would argue that if one wants to block EXE files - fine - but block them by looking for the base-64 encoded 'TVq' signature of EXE files (the 'MZ' signature when encoded).  The current policy of blocking a great many different attachments, not only makes it more difficult for people who do want to send legitimate attachments (but not too much - I just remove the extension), if adopted on a large-scale (which I doubt it will be), such a "draconian" policy will push mal-ware-writers to move to other ways of sending their worms - Word macro viruses, Excel macro viruses, HTML with mal-ware JS and Java code, or whatever (there's almost always another hole to exploit).

This same mail-server is going to shortly be implementing a system-wide spam filtering solution (probably based on SpamAssasin), which will as a matter of course be scanning all data coming through the relay.  Since all data will be scanned already, scanning for EXE files or other known signatures of malware should not be terribly more computationally intensive.

The solution proposed by 'gep2' would seem to address this, but it seems to me that it would have an incredible computation scaling problem (if filtering on a per-user basis is done on the receiving end), and/or require a global change to the email system (if a sending server would query a receiving server for every email).

Jim

> From: gep2(_at_)terabites(_dot_)com
> Date: Tue, 06 Apr 2004 21:47:13 -0500
> If we're ever going to REALLY get a handle on this problem, I still believe that
> what matters more is:
>
> 1)  putting the quash on unexpected attachments (especially if they are
> executables);  [..]
> 2)  likewise, making support for HTML-burdened E-mail (which can contain all [..]
> I believe that the most significant way to hugely improve both of these
> situations is the ability of the recipient to whitelist individual specific
> senders with SPECIFIC rights to:
> a)  send them attachments (and subapprove based on the class of the
> attachments)
> b)  send them HTML (and POSSIBLY subapprove based on categories of HTML tags
> allowed).