Others have had good much more complete followups, but a couple of things
that went unmentioned:
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.,
"/etc/passwd").
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. I have to
concur with Ned that the security considerations must be left in, whether
or not the comment about pathnames is added.
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:
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=Futhark-A-fonttable-300.gif;
portable-filename=FUTHARKA.GIF
Content-Description: A table showing all glyphs of the main
runic font Futhark A, in 300 dpi resolution.
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. Given
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. 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:
"pete-s-favorite-flower.gif"
whereas a DOS client might have to settle for "PETESFAV.GIF". 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."
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.
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:
The MUA might instead
present the user of a bitmap terminal with an iconic
representation of the attachments, or, on character
terminals, with a list of attachments from which the user
could select for viewing or storage.
Of the two implementations outlined here the one for the more
primitive equipment, character terminal, sounds the more useful
to me! Instead of a bunch of icons on the bitmap terminal --
probably with only the word GIF in them, in the best case with a
dot pattern perhaps hinting on the main features of the image --
I can on the character terminal expect a list of the attachments
offered for viewing, probably showing the first line of the
Content-Description header, possibly also the suggested filename
and the approximate file size. In the character terminal case I
can thus expect to get more information on which to base a
decision to view or save an attachment or leave it.
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. All in all,
there's a lot that can be done with icon-like attachments. But again, this
is tangential to the substance of the draft. (BTW: Personally, I'm with Ned
on leaving the concrete examples in there; it makes it easier to visualize
what the heck the author had in mind when you are going to implement
something.)
pr
--
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
QUALCOMM Incorporated
Home:(217)337-1905 / Fax: (217)337-1980