Rather than making fun of or scream "stupid", why don't we keep
developing and arguing for standard based 'solutions':
You mean like RFC 2046?
The recommended action for an implementation that receives an
"application/octet-stream" entity is to simply offer to put the data
in a file, with any Content-Transfer-Encoding undone, or perhaps to
use it as input to a user-specified process.
Gee, I sure am glad that the vendor of this software followed the standard
and offered to save this body part to a file.
(note that it says "user-specified process" as opposed to the insecure
default action so graciously provided by the vendor)
RFC 2046 also says (section 9):
Implementors should pay special attention to the
security implications of any media types that can cause the remote
execution of any actions in the recipient's environment. In such
cases, the discussion of the "application/postscript" type may serve
as a model for considering other media types with remote execution
capabilities.
and the section on application/postscript does indeed describe risks that
are similar to those in visual basic.
Perhaps unfortunately, RFC 2046 doesn't come right out and say
"DON'T EXECUTE CONTENT IN EMAIL MESSAGES".
Then again, it doesn't say DON'T CUT YOUR CUSTOMER'S ARM OFF either.
not that it would matter if it did...
Keith