174043 - Attachments are not detected on incoming messages.

Status: RESOLVED DUPLICATE of bug 101719

(MailNews Core :: Attachments, defect)

Description

[John Malmberg]

Mail messages with Viruses attached or that had the Virus replaced with a
harmless attachment do not get displayed as having an attachment.

The only way to see this is to use the view source.

Mozilla 1.1

Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.1)
Gecko/20020828

Comment 1

[John Malmberg]

Attachment: Sample e-mail with an attachment

This is a sample of an e-mail that has had the VIRUS replaced with a harmless
text file.

I am getting the same results with ones that appear to contain a live virus,
but for obvious reasons, I am not posting one of those.

Comment 2

[Colin Blake]

I don't see the attachment on the email attachment either. This is with
Netscape7, so changing OS to Linux. Also confirming.

Comment 3

[Jo Hermans]

The problem is that Mozilla is showing the first attachment (text/html) which 
contains an *empty* frame. The second attachment (TEXT/PLAIN) with the real
human-readable message is ignored, probably because the MIME-type is not in
lowercase (it's case-sensitive, see bug 59619). There's also a thirth TEXT/PLAIN
attachment in this mail !

What should Mozilla be showing ? When you prefer HTML-mails, you get an empty
window. When you prefer plain text, you won't find any attachment b/c of bug
59619. And even if you did, you still have 2 choices ! Luckily, the good one
(second attachment) has an 'inline' parameter, which might serve as an indicator
that at least this one should be shown. But even if we did this, it would still
be complicated.

Comment 4

[WADA:World Anti-bad-Duping Agency]

To Comment #1 From John Malmberg

attachment 102638 [details] is multipart/alternative mail case.
This is processed by Bug 130119.
> Option to choose what part of multipart/alternative message to display

Comment 5

[Mike Cowperthwaite]

(In reply to comment #3)
> The problem is that Mozilla is showing the first attachment (text/html) which 
> contains an *empty* frame. 

Actually, it's probably the *third* attachment, which is also empty but 
text/plain -- the spec for multipart/alternative, which Mozilla follows, is to 
show the last item in the message which the client *can* display.

Duping this to another bug about virus-reports in mult/alt messages, but I think 
that one should be resolved Invalid.  As WADA points out, bug 130119 is the 
enhancement request for a more comprehensive way of selecting the displayed 
part.

*** This bug has been marked as a duplicate of 101719 ***