I'm a little confused as to why this issue isn't considered more
critical within the MIME community. Successfully transmitting the name
of an attachment and correctly noting whether some textual information
is to be treated as an attachment or as part of the message body is
also very important. We have some pretty bad failure modes when this
information is not correctly transmitted.
I agree that the content-disposition proposal should advance at this time.
However, I don't think your reasons for doing this are particularly relevant.
File name information can be useful, but it should not be essential. Something
is very wrong if it is essential.
like several other PC-based mail clients, we use a specially-named
attachment to pass custom rich text, custom attributes and forms
information. When this name isn't preserved, the MIME-based Unix
version can't recognize this information. (Note that we're trying to
get this through gateways, so we're not simply talking MIME to MIME
mailer here and that limits the strategies we can take).
Sounds to me like you need to define a new content-type or types for this. The
gateway can then turn the content-type label into whatever is appropriate on
the other side, and vice versa.
File names are not an appropriate vehicle for carrying type information. They
vary too much, and security considerations sometimes mandate the removal of
file name information.
Also, by default the client will send the text body as both plain text
and within this special attachment (along with the formatting info).
When our client receives the message, it assumes the text of the
message is completely specified in the attachment and discards the
actual body. If a gateway has inserted the attachment into the body,
the attachment is completely lost (I won't go into details about why
this makes sense). Bottom line is the Content-Disposition becomes a
pretty important piece of information.
Sufficiently important that you should be using an existing, well defined
mechanism, I'd say.