[Mimedefang] non-virus executables

[David F. Skoll]

On Wed, 9 Oct 2002, Les Mikesell wrote:

> Could we change the MIME type to application-octet-stream
> on questionable parts - or at least something mailers won't ever
> launch?

Many (most? all?) Windoze MUA's ignore the MIME type.  They go by the
filename (.exe --> executable and to h*ll with the MIME type), or even
(!) by the file contents (MZ --> x86 executable signature and to h*ll
with the MIME type).

I even attempted to register a MIME type with the IANA.  The type was
"vnd-roaringpenguin/defanged" and I specified that MUAs MUST NOT do
anything with this MIME type except offer to save it to a file.  My
application was rejected precisely because MUA's often ignore the MIME
type, so the safety is illusory.

Here, FYI, is the reply from IANA.

Regards,

David.

While this is an interesting idea, I believe what you have here
violates section 2.2.1 of RFC 2048. In particular, MIME types are
required to specify a an actual media format. What you're doing here
is using a a media type to specify handling of an object; the actual
content can be almost anything.

Additionally, I'm very concerned that this does not in fact solve the
problem you think it does. The unfortunate fact of the matter is that
some implementations, in violation of the relevant standards, are
perfectly happy to open anything no matter what the content-type is,
and if they don't recognize the content-type they look at the filename
and/or the content itself to figure out what to do.

One way out of this would be to define this as a content-disposition
rather than a content-type. The problem with doing this is that
content-disposition support isn't as easily extended in existing
clients. OTOH, as I just pointed out, client changes will be needed
for this to work no matter what.

Another way to approach the problem would be to actually modify the
content in addition to relabelling it. If you added a wrapper around
the content that requires a specific plugin to remove you
simultaneously do two things:

(1) Prevent the content from being executed directly.
(2) Eliminate the conflict with section 2.2.1 since you now have defined a
    true media format and not a relabelling of arbitrary content.
(3) It provides you with a means of communicating what was found to be
    wrong with the content to recipiet.

In case it isn't obvious, the way this would work is that you'd use a
type handler that tells the user there's a problem and offers to
proceed if the user insists on doing so.

Just to be complete, yet another way to do this would be to define a
new multipart subtype that would contain two parts, one describing the
problem and the other containing the suspect content. Given the
default handling of unknown multipart subtypes is to treat them as
multipart/mixed I don't think this is a viable approach, however.