314728 - Attachment icon show only when "View/Message body as (Original HTML|Simple HTML)"

Status: NEW

(MailNews Core :: MIME, defect)

Description

[Martin Mokrejs]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051101 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051101 SeaMonkey/1.1a

Time to time I receive an email which has an attachment but I don't see the attachment icon shown i mozilla 1.712. It happened I got yet another one and built mozilla-source-2005110105-trunk.tar.bz2 on my linux box.

I figured out changing the "View/Message body as" value from "Plain text" to either "Original HTML" or "Simple HTML" makes the icon appear. While having the "Plain text" set, I see the plaintext message in the message body window. When moving either of the two HTML viewing modes, the "message body" window is without any text.

I will attach the testcase after ripping out private parts of the text.


I cannot judge myself whether this is a "weird" feature or not. Browsing the existing bugs I even can't say if it is a dupe or not, sorry.

What I expect is to see the attachment icon always.

Reproducible: Always

Comment 1

[Martin Mokrejs]

Attachment: testcase

I have overwritten the private data. I have also overwritten the base64 encoded message. Probably some real base64 encoded text should be placed in there to have
the testcase fully working. I hope the structure/layout of the email is the most of interresting message for you.

Comment 2

[Martin Mokrejs]

And, when clicking the original message, the following is shown in my debug seamonkey build. Please note these two:
GetMIMEDescription() returned ""
Ignoring text/html alternative


LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libnullplugin.so returned 946b238
GetMIMEDescription() returned ""
LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libunixprintplugin.so returned 95fa690
GetMIMEDescription() returned ""
###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file xptiInterfaceInfoManager.cpp, line 1937
Break: at file xptiInterfaceInfoManager.cpp, line 1937
LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libnullplugin.so returned 946b238
GetMIMEDescription() returned ""
LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libunixprintplugin.so returned 95fa690
GetMIMEDescription() returned ""
###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file xptiInterfaceInfoManager.cpp, line 1937
Break: at file xptiInterfaceInfoManager.cpp, line 1937
LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libnullplugin.so returned 946b238
GetMIMEDescription() returned ""
LoadPlugin() /usr/local/lib/seamonkey-1.1a/plugins/libunixprintplugin.so returned 95fa690
GetMIMEDescription() returned ""
###!!! ASSERTION: Failed to write xpti manifest!: 'Error', file xptiInterfaceInfoManager.cpp, line 1937
Break: at file xptiInterfaceInfoManager.cpp, line 1937
++DOMWINDOW == 13
WARNING: nsMsgProtocol::SetContentCharset() not implemented, file nsMsgProtocol.cpp, line 628
Considering text/plain alternative
WARNING: nsMsgProtocol::SetContentCharset() not implemented, file nsMsgProtocol.cpp, line 628
Ignoring text/html alternative
Ignoring text/html alternative
WARNING: NS_ENSURE_TRUE(nsDoc) failed, file nsXULElement.cpp, line 2299
--DOMWINDOW == 12

Comment 3

[WADA:World Anti-bad-Duping Agency]

> Content-Type: multipart/alternative;

Since "multipart/alternative;", text/plain part is used when "Plain text" mode, and text/html part is used when "Original/Simple HTML" mode.
This is the trick.

Martin Mokrejs, read "5.1.4. Alternative Subtype" section of RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
http://www.faqs.org/rfcs/rfc2046.html

This bug is probably to be closed as INVALID.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #1)
> I have overwritten the private data. I have also overwritten the base64
> encoded message. Probably some real base64 encoded text should be placed in
> there to have the testcase fully working. 

Um, yeah, that would have been helpful.  Thanks for making the extra work for us, we have nothing better to do.

Do you know what mail client generated that message?

The attachment icon is shown because the message body that was eventually 
used -- that third, base-64 encoded part -- was assigned a filename.  
Probably it's a bug to show a message body as an attachment just because of 
the filename; but that part *also* has   Content-Disposition: attachment   
which should cause it to be shown as an attachment.

With Message Body as plain, the plain text part used for display does not 
have a filename (and no Content-Disposition either, so defaulting to 
'inline'), and so not detected as an attachment.

Note that if you turn off 'Display Attachment Inline' you also won't see any message body, when the HTML case is selected.  This is bug 182627; and a 
comment at that bug mentions that an icon is shown in the attachment panel for the message body.  Attachment panel implies paperclip icon.

Comment 5

[Martin Mokrejs]

It seems with the old testcases I can now see the paper clip icon regardless the "Original HTML/Simple HTML/Plain text" values. Tested with current cvs HEAD build.

Comment 6

[Phil Lacy]

with patch for Bug 551698 applied. view attmts inline off. view as plain text no attachment appears. view as html the attachment appears but the attachment is also the message body not the 2nd part which is text/html. 

So we have with view original html selected:

part text/plain  not visible
part text/html   not visible
part text/html 
     content-disp appachment
                visible. and is in an attachment.

in mp/alt I believe we pick up the last part, rightly or wrongly I don't know. In above I guess the structure id's it as an alternative and not related or mixed. Not sure of intention or expectations with this structure.

Comment 7

[Volker B.]

This behaviour is currently exploited by PHISHING MAILS which are shipping a malicious HTML page as base64 attachment which is not visible to the user. 

The upfront HTML contains a link to the malicious  hidden HTML: 
<a href="cid:aW5nLWRpYmEuaHRtbA$21637796$654271@ing-diba">hier</a> 

Problems:
1. As default view is "original HTML" the user is not aware of a hidden HTML attachment.
2. The attached HTML is not displayed below the original upfront HTML (like attached pictures / sent as attachments).

I strongly suggest to increase the importance of this bug due to security concerns.

Find attached a demo phishing for described behaviour.

Comment 8

[Volker B.]

Attachment: ING-DiBa Telefon-PIN aktualisierung - anonymous.eml

demo phishing mail to visualize the problem

Comment 9

[Joshua Cranmer [:jcranmer]]

(In reply to Volker B. from comment #7)
> This behaviour is currently exploited by PHISHING MAILS which are shipping a
> malicious HTML page as base64 attachment which is not visible to the user. 

The test case you cite appears to be a different issue, relating to multipart/related and cid: links.

[Although the bug there is we probably shouldn't be trying to work with cid: links as navigation targets.]

It's not clear in any case that not hiding the attachment (due to its use in a multipart/related as a cid: reference) would mitigate any risks.

Comment 10

[Volker B.]

> It's not clear in any case that not hiding the attachment (due to its use in
> a multipart/related as a cid: reference) would mitigate any risks.

1. Meanwhile users are sensitized to mails carrying attachments. "do not open it".
2. When hovering over a link you are shown the link target in the status bar, enabling users to identify a malicious target before clicking it. The CID-link is very uncommmon and cannot be identified as potentially dangerous (it links to your own email/mailbox). 

There is no way to see the decoded HTML in Thunderbird (seeing the link to russia phishing server) - you need to manually extract the encoded attachment and have it decoded - or even open the attachment/HTML and look at the code in a browser. Furthermore, the target link for used forms (the send button) is not shown in the status bar in Firefox/Chrome (contrary to regular links).

If pictures sent as attachments are displayed below the mail body in the preview, why not the attached HTML in the same way? 

If mails containing pictures sent as attachments are shown with an attachment icon, why do mails with HTML attachments lack the attachment icon?

Maybe this bug report is the wrong place for all these issues, I trust someone can handle this from here and see this is treated more user-friendly in the future?

Comment 11

[Volker B.]

Attachment: new phishing mail using CID link (Sparda-Bank Telefon-Banking )

Comment 12

[Yuki]

Attachment icon show only when "View/Message body as (Original HTML|Simple HTML)"