I suppose that there is some chance of random mayhem if you
launch the right file in the wrong Ap. But how much chance?
This is the type of question security folks will ask and
then answer. Depending on your level of paranoia, even a remote
chance may be unacceptable. Personally, it does not concern
me.
If the file is an attack, the attack will be against the Ap that
goes with its file extent, which will be the Ap that goes with
its MIME subtype if that is set precisely.
application/octet-stream is application/no-further-info.
That is to say _the MIME header_ gives you no further information
about what kind of application this file belongs to. This cannot
plausibly be interpreted as "don't believe anything that the file
name suggests."
I believe Keith's comments were more directed to the wrong
choice of app based upon heuristics. For example, the ".doc" extension
is very ambiguous. It is possible that launching the wrong app on
the file may cause problems. Of course, one still has to ask
how much of a security problem that really is.
It should be the norm that the receiver of a message is prompted
before invoking an application on a particular attachment. However,
some MUAs may not, and a heuristic approach just adds another level
of uncertainty in security.
I believe Keith's response to messages about the topic on the
comp.mail.mime group was to just bring up some potential security
issues (even if very slight) and clarify some points about the MIME
standard and content-types.
I don't really understand why MHonArc _needs to know_ that this
particular application/octet-stream file belongs to FrameMaker.
It depends on what the user of MHonArc would like to see. For
example, if a Frame->HTML filter was hooked into mhonarc, the
user may want to have Frame attachments automatically converted
to HTML so a reader of the archived message does not need to have
Frame to read the document.
However, this desired behaviour should not entice to add potential
security, and/or data conversion, problems. If a content-type
is application/octet-stream, then the data should be treated as such.
This is the safe thing to do: force a manual application of
Frame against the foreign file. Don't let it be automatically
applied.
The application/octet-stream is the safer way to go.
But the security feature is the manual confirmation before
anything is done with the file. It has very little to do with
whether you are guessing that the file extent has told you the
right Ap or the MIME header has told you the right Ap. Manual
execution of the Ap that you guess from the filename is safer
than automatic execution of the Ap selected by noting the MIME
header.
Exactly. The issue is, with respect to MHonArc, is that an
application/octet-stream file gets a ".bin" extension. Therefore, when
a Web browser gets the data, the server would have sent the
content-type of application/octet-stream. Browsers automatically will
attempt to save the data to disk instead of giving the user the choice
of launching FrameMaker (if the data is really a Frame document).
Therefore, the user will have to go though some extra steps to
bring up the data into Frame instead of giving the convenient
choice from the Web browser.
If senders want to make it more convienent to receivers of their
messages, the senders should insure they have proper content-types
for their data so people do not have to play guessing games, or
be inconvienced, when try to read the data. MUA developers
should not have to burden themselves becuase people, or misbehaved
software, mistypes data.
--ewh
