Open
Bug 404321
Opened 18 years ago
Updated 3 years ago
File contents which were in plain text are displayed as image/bmp
Categories
(MailNews Core :: Attachments, defect)
MailNews Core
Attachments
Tracking
(Not tracked)
NEW
People
(Reporter: kiranmadival, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.6 and thunderbird-2.0.0.9
We have a plain text file with name t.sdf, which has the file content starts with "BM". When we send this file as an attachment in the seamonkey-1.1.6 and thunderbird-2.0.0.9 on RHEL, the file is treated and displayed as (Content-Type: image/bmp) image/bmp file, even though the file is being plain text file. But this problem does not occur on Novell's Evolution 2.0.2 email client.
Use the following steps to reproduce..
Created a file, "t.sdf" with the following content.
$ cat t.sdf
bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0|
$
And created a file, "t1.sdf" (File contents are in the Upper case)
$ cat t1.sdf
BMRSERVICE________ ABW MITT ABS RNA MV |RW|31.07.2007 |24:00 | 0| 9363| -3| 0|
$
When we sent a mail with "t.sdf" as an attachment, E-mail client displayed the content type as text/plain.
--------------070601060306090405080508
Content-Type: text/plain;
name="t.sdf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="t.sdf"
bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0|
--------------070601060306090405080508--
When we sent a mail with "t1.sdf" as an attachment, E-mail client displayed the content type as image/bmp.
--------------070805000704070809060102
Content-Type: image/bmp;
name="t1.sdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="t1.sdf"
Qk1SU0VSVklDRV9fX19fX19fIEFCVyBNSVRUIEFCUyBSTkEgTVYgfFJXfDMxLjA3LjIwMDcg
fDI0OjAwIHwgMHwgOTM2M3wgLTN8IDB8Cg==
--------------070805000704070809060102--
Also we also see that if the file content start with text "GIF8" the file being treated as "image/gif"
$ cat g.sdf
GIF8
$
and below how it is displayed by the Email Client.
--------------060903070806030108010203
Content-Type: image/gif;
name="g.sdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="g.sdf"
R0lGOAo=
--------------060903070806030108010203
Reproducible: Always
Steps to Reproduce:
Following steps to reproduce..
Created a file, "t.sdf" with the following content.
$ cat t.sdf
bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0|
$
Created a file, "t1.sdf" (File contents are in the Upper case)
$ cat t1.sdf
BMRSERVICE________ ABW MITT ABS RNA MV |RW|31.07.2007 |24:00 | 0| 9363| -3| 0|
$
When we sent a mail with "t.sdf" as an attachment, E-mail client displayed the content type as text/plain.
--------------070601060306090405080508
Content-Type: text/plain;
name="t.sdf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="t.sdf"
bmrservice________ abw mitt abs rna mv |rw|31.07.2007 |24:00 | 0| 9363| -3| 0|
--------------070601060306090405080508--
When we sent a mail with "t1.sdf" as an attachment, E-mail client displayed the content type as image/bmp.
--------------070805000704070809060102
Content-Type: image/bmp;
name="t1.sdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="t1.sdf"
Qk1SU0VSVklDRV9fX19fX19fIEFCVyBNSVRUIEFCUyBSTkEgTVYgfFJXfDMxLjA3LjIwMDcg
fDI0OjAwIHwgMHwgOTM2M3wgLTN8IDB8Cg==
--------------070805000704070809060102--
Also we also see that if the file content start with "GIF8"
the file being treated as "image/gif"
$ cat g.sdf
GIF8
$
and below how it is displayed by the Email Client
--------------060903070806030108010203
Content-Type: image/gif;
name="g.sdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="g.sdf"
R0lGOAo=
--------------060903070806030108010203
Actual Results:
When the file contents were in plain text. The file content is treated and displayed as image/bmp file.
Expected Results:
When the file contents were in plain text. The file contents must be treated and displayed as text/plain file.
This problem does not occur on Novell's Evolution 2.0.2 email client.
Comment 1•18 years ago
|
||
The problem happens at message composition/send time, not when the message is displayed, right?
I am experiencing this problem when the message is displayed in the mail client window.
I have a filename with the extension sdf, and the file content starts with BM (all in Capital letters)and send this file as an attachment, Email client window displayed this as a Image. Why this is displayed as a image when the file contents are in plain text.
When I looked at the below module "/modules/libpr0n/src/imgLoader.cpp" and the function name is imgLoader::GetMimeTypeFromContent()
"
/* Is it a GIF? */
if (aLength >= 4 && !nsCRT::strncmp(aContents, "GIF8", 4)) {
aContentType.Assign(NS_LITERAL_CSTRING("image/gif"));
.....
else if (aLength >= 2 && !nsCRT::strncmp(aContents, "BM", 2)) {
aContentType.Assign(NS_LITERAL_CSTRING("image/bmp"));
"
The above piece of code checks for "BM" and sets the content type as "image/bmp".
Why this has been done this way?. If I want to display the attachment as
as plain text, what needs to be done?
Let me know if you need more information on this.
I am experiencing this problem when the message is displayed in the mail client window.
I have a filename with the extension sdf, and the file content starts with BM (all in Capital letters)and send this file as an attachment, Email client window displayed this as a Image. Why this is displayed as a image when the file contents are in plain text.
When I looked at the below module "/modules/libpr0n/src/imgLoader.cpp" and the function name is imgLoader::GetMimeTypeFromContent()
"
/* Is it a GIF? */
if (aLength >= 4 && !nsCRT::strncmp(aContents, "GIF8", 4)) {
aContentType.Assign(NS_LITERAL_CSTRING("image/gif"));
.....
else if (aLength >= 2 && !nsCRT::strncmp(aContents, "BM", 2)) {
aContentType.Assign(NS_LITERAL_CSTRING("image/bmp"));
"
The above piece of code checks for "BM" and sets the content type as "image/bmp".
Why this has been done this way?. If I want to display the attachment as
as plain text, what needs to be done?
Let me know if you need more information on this.
Comment 4•18 years ago
|
||
Phenomenon was easily reproduced by: (lates-trunk 2007/11/18 build is used)
(1) Preparation
- No mime-type definition for file extension of ".1234"
(When MS Win, HKEY_CLASSES_ROOT\.1234 doesn't exits in registry)
- aaa-01.1234 : 4096 bytes of "A" (no CR/no LF)
aaa-02.1234 : "BM" + 4096 bytes of "A" (== "BM" + aaa-01.1234)
aaa-03.1234 : 4096 bytes of 0x19
aaa-04.1234 : "GIF8" + 4096 bytes of 0x19 (== "GIF8" + aaa-03.1234)
(2) Compose a mail, attach above 3 files, send later.
Following headers were created by Tb.
> --------------000708080703050804060301
> Content-Type: text/plain; name="aaa-01.1234"
> Content-Transfer-Encoding: base64 (<= this is because no CR/LF/CRLF)
> --------------000708080703050804060301
> Content-Type: image/bmp; name="aaa-02.1234"
> Content-Transfer-Encoding: base64
> --------------000708080703050804060301
> Content-Type: application/octet-stream; name="aaa-03.1234"
> Content-Transfer-Encoding: base64
> --------------000708080703050804060301
> Content-Type: image/gif; name="aaa-04.1234"
> Content-Transfer-Encoding: base64
Above is current implementation of fall back when unknown mime-type, as you see in program source.
Simplest workaround is to register ".sdf" & "text/plain" to system table for file-extension=>mime-type translation. When MS Win, it is HKEY_CLASSES_ROOT\.sdf. Sorry but I don't know about Linux.
(Why application who generates ".sdf" file doesn't register it to system?)
(Server application, and your client machine does only read of the files?)
Second workaround is to register ".sdf" & "text/plain" to mimeTypes.rdf of Tb.
(A) Create entry for ".sdf"&"text/plain" in mimeTypes.rdf by Seamonkey's "Helper Applicasions", and copy back entries to Tb's mimeTypes.rdf.
(This may be done by Firefox's latest-trunk, but I don't know well about it)
(B) Create entry for ".sdf"&"text/plain" in mimeTypes.rdf via dialog by Tb.
(B-1) Create a dummy received mail with attachment of ".sdf" and dummy mime-type
(say "application/x-unknown")
(B-2) Open the mail, and double click the attachment, and choose action(s).
This forces creation on mimeTypes.rdf entry.
(B-3) Terminate Tb, and edit mimeTypes.rdf, and replace "application/x-unknown"
by "text/plain".
(B-4) Restart Tb
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•18 years ago
|
||
Oh sorry, you are fortunately using Seamonkey.
Workaround is very very simple when Seamonkey.
- Add ".sdf" & "text/plain" via Preference/"Helper Applications".
Updated•17 years ago
|
Assignee: mail → nobody
Component: MailNews: Main Mail Window → ImageLib
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: imagelib
Hardware: PC → All
Version: unspecified → Trunk
Comment 6•14 years ago
|
||
An alternative to GetMimeTypeFromContent should be used by mail clients. It's really only useful for discovering what type of image a particular thing that we highly suspect of being an image (i.e., a thing specified from within an <img> tag) is; using it as a general-purpose file(1) alternative is a bad idea.
Component: ImageLib → Attachments
Product: Core → MailNews Core
QA Contact: imagelib → attachments
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•