RE: octet-stream attachment

From: Daniel Stenberg <Daniel.Stenberg_at_sth.frontec.se_at_hypermail-project.org>
Date: Tue, 3 Aug 1999 10:11:04 +0200 (MET DST)
Message-ID: <Pine.GSO.4.10.9908031001240.10859-100000_at_metal.sth.frontec.se>

On Mon, 2 Aug 1999, Tom von Alten wrote:

> It's still misconfigured in that the jpeg should be better identified
> from the sender than "application/octet-stream attachment" (imho - so I
> can inline the images the way I want to).

I understand your wish for this to happen. Yet, should hypermail use the content-type from the mail or should it try to use the extensions to guess what kind of content the files are?

The current method used the content-type only, and since the mail you got said:

> Content-Type: application/octet-stream; name=grab002.JPG

It is not a picture. It is a binary lump of data that isn't even identified as anyting recognizable.

> Content-Transfer-Encoding: base64

It is base64 encoded.

> Content-Disposition: attachment; filename=grab002.JPG

It is _not_ meant to be inlined, as the "attachment" keyword suggests otherwise. Not that hypermail actually cares about that keyword at this moment, if I recall correctly.

Now, since the file will be saved as "grab002.JPG" and then when you click on the link with your browser, the web server will send a content-type to the browser based on the extension so at this point the extension will be used anyhow.

If hypermail used the same extension logics as the web server, it could just as well guess the appropriate content-type already when extracting the attachment. This should probably only be for attachments that come as 'application/octet-stream' and not if identified as something else, as that would in theory enable text files to be named 'foo.jpg' and still be displayed properly.

-- 
             Daniel Stenberg - http://www.fts.frontec.se/~dast
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Received on Tue 03 Aug 1999 10:10:53 AM GMT