From: Daniel Stenberg (Daniel.Stenberg@sth.frontec.se)
Date: Tue Aug 03 1999 - 03:11:04 CDT
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