[Top] [All Lists]

Re: MIME's "Content-Disposition" Header

1995-01-18 10:20:03
Pete Resnick <presnick(_at_)qualcomm(_dot_)com> writes:

On 1/17/95 at 5:41 PM, Olle Jarnefors wrote:
I suggest we here include words to the effect that the filename
specified must not be regarded as containing an initial part
specifying an absolute or relative path through a hierarchical
file system. If this is required, the following security
concerns may be dropped:

          o+ Creating or overwriting system files (e.g.,

          o+ Placing executable files into any command search path
            (e.g., "~/bin/more").

          o+ Sending the file to a pipe (e.g., "| sh").

Certainly the third case (with the pipe) is not clearly addressed by simply
making a statement regarding not using any path information, and there are
lots of other cases (like CON etc in DOS) that aren't affected.

That's true. Unix has a very general file concept. Maybe we
could catch the pipe case by stating that the Filename parameter
is to be regarded as the name of a _disk_ file?

I have nothing against explicitness in the Security section. The
case of CON, CON.GIF etc. in MS-DOS all being redirected to the
user's screen (which often can redefine certain keys on the
keyboard by means of ANSI.SYS escape sequences) should also be

I propose that a new
parameter, Portable-Filename, is introduced. Its values would
have a restricted syntax. It could be used together with the
Filename parameter like in this example:

I actually think this is a bad idea. Generating the portable filename is
going to require one of two things to happen: (a) The sending client is
going to have to use some algorithm to generate a portable filename to use
if the real filename doesn't work on the machine, or (b) the user will have
to choose the filename. Choice (b) is usually considered too burdensome, so
the MUA is going to try to come up with a portable name on its own.

I wrote "_could_ be used together with the Filename parameter".
In no way should it be mandatory to include a Portable-Filename
parameter. If the sender doesn't provide such a filename,
his/her UA is under no obligation to construct a portable
filename from the Filename parameter value.

that, I don't see why you'd want to put that kind of functionality into the
client to perform when it is always the recipient who has to determine its
own limitations.

I agree that figuring out artificially restricted portable
filenames would be burdensome for most users. I think, though,
that this functionality would be useful for some more advanced
users. A concrete example of why is included in my previous
response to Patrik Faltstrom.

A recipient is much more likely to come up with a useful
name for its purposes (given any full filename by the client) than a client
will be able to make that decision for the recipient. For instance, if I
sent from my Macintosh:

Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="Pete's Favorite Flower"

Neither a UNIX client nor a DOS client is going to be terribly happy, but a
UNIX client might decide that it can use the descriptive:


whereas a DOS client might have to settle for "PETESFAV.GIF".

This as an example where automatic transformation of the given
filename will work reasonably well. This is often the case when
the receiver's system is about as powerful as the sender's as
regards filename syntax (modern Unix versus Macintosh).

My own example is this:

: Suppose the incoming message contains three body parts with the
: filename parameters
:    runefont-table-75.gif
:    runefont-table-300.gif
:    runefont-examples.gif
: A MS-DOS UA will probably transform these to
: At least this is what MS-Kermit does in a similar situation.
: These MS-DOS filenames are not very descriptive and, worse,
: which filename corresponds to which of the body parts is wholly
: dependent on the _order_ in which the body parts are saved.
: A _careful_ sender could provide much better portable filenames,
: such as
:    RUNET75.GIF
:    RUNET300.GIF

It shows a situation where any automatic transformation will
give miserable results. Of course the receiver's UA may ask
him/her about filenames to use in that case, but the receivers
may be many and less sophisticated than the sender, the message
may be the result of much work and the sender therefore willing
to compose it in a careful way.

I don't see how a strictly optional Portable-Filename parameter
could hurt anyone.

Other systems
might make different decisions about the best filename given what the
sender sent. If instead the client decides on a portable name, the UNIX box
might decide "I can't use the real name, so I best use the portable one."
Then, of course, if the UNIX recipient has any brains at all, it might also
decide, "Gee, all GIF files on my system have to end with lowercase '.gif',
and this one ends in '.GIF'. I guess I should add that."

You describe a lousy implementation for a Unix system. A warning
to naive implementers not blindly to use the Portable-Filename
when the local system supports long filenames can of course be
included in the specification.

It seems to me that if you want to make decisions about a good filename for
a recipient, the recipient should be the one deciding, not the sender.
Especially since most recipients have some smarts about such things anyway.

Yes, normally the receiving UA should show the filename in the
message, whether it takes the Filename or the Portable-Filename,
to the user, giving him/her a chance to provide a better
filename, before saving the body part.

One tangential comment which has nothing to do particulary with the
substance of the draft, but just an answer to Olle's curiosity about this:

Actually, in the bitmap case on certain systems, you might be able to click
on the icon and pop up an information box with lots of information, you
could drag the icon in a file manager like interface to file the attachment
in a different directory or to copy it into a new message, you could click
the icon to start up a helper application to view the attachment, etc. And
being an icon, it takes up very little space on the user's screen compared
to including all of the desired information in inline text.

Yes, I realize GUIs can be made much more user-friendly than text
terminal interfaces. I wouldn't mind including a fuller
description of an icon-based implementation in the draft, so the
current opposite impression is avoided.

Olle Jarnefors, Royal Institute of Technology, Stockholm