269273 - multipart/mixed messages have attachment icon, but parts are 'inline'

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[Avi Drissman]

Messages with the content type multipart/mixed are marked in the message list as
having an attachment. This is bad. The attachment flag should be reserved for
messages that TB cannot fully display inline.

The sample that's attached comes from Mailman. It wants to append a footer at
the bottom of each message. If the existing content type is text/plain, it can
succeed. If the type isn't (most modern email programs send as
multipart/alternative), then Mailman uses multipart/mixed.

TB is fully capable of displaying the message inline, but flags it as having an
attachment. Having the attachment flag always show on emails that can be fully
displayed inline significantly reduces the usefulness of the flag to me. It
should only be shown if some part of the email could not be shown inline.

Comment 1

[Avi Drissman]

Attachment: Email that shows an attachment icon

Has nothing that the average user would consider an "attachment".

Comment 2

[David :Bienvenu]

we can't tell if the message has an attachment from just the message header, so
this is what we've decided to do...

Comment 3

[Avi Drissman]

OK, but...

Remember how it used to be where emails didn't have the attachment icon, but
once you selected them the icon showed up? Why not, when the message is opened,
update the attachment flag to match the result of a more extensive analysis of
the message when it's opened?

80% of the emails in one folder have that attachment icon. I might as well turn
off the attachment icon column since it's totally useless with this bug.

Comment 4

[David :Bienvenu]

definitely, that would be fine.  We already do that a bit, when we turn off the
attachment icon if the attachment is just a v-card. I'd need to see where we
were setting the attachment icon before, and fix that to clear it if it
shouldn't be set...

Comment 5

[Mike Cowperthwaite]

(In reply to comment #3)
> Why not, when the message is opened, update the attachment flag to match the
> result of a more extensive analysis of the message when it's opened?

Yes, that *would* be fine, BUT...  For the sample message supplied, what exactly 
should be analyzed to determine that the little text/plain footer/sig part is 
*not* an attachment?

I guess it's "unfortunate" that you are inconvenienced by the icon, but in my 
opinion the problem is with MailMan, not with Thunderbird.  I'd say the best 
solution to your particular problem is to fix bug 76702 (which feature is 
supplied by the Mnenhy extension), then filter your MailMan msgs into a folder 
that doesn't show the attachment column.

Comment 6

[Avi Drissman]

> For the sample message supplied, what exactly should be analyzed to determine 
> that the little text/plain footer/sig part is *not* an attachment?

Well, the part that says "Content-Disposition: inline" might help. See RFC 2183.
If the mail explicitly says "this is inline, not an attachment" then I'd assume
we could rely on that part not being an attachment.

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> If the mail explicitly says "this is inline, not an attachment" then
> I'd assume we could rely on that part not being an attachment.

OK, that's a valid point.  Moz does not distinguish well between the two types
-- some 'attachment' parts are always shown inline, some 'inline' parts are not 
shown inline.  See bug 229075 and bug 147461.

Comment 8

[Avi Drissman]

(In reply to comment #7)
> OK, that's a valid point.  Moz does not distinguish well between the two types
> -- some 'attachment' parts are always shown inline, some 'inline' parts are not 
> shown inline.  See bug 229075 and bug 147461.

Interesting; I hadn't seen those bugs.

They're all related, then. Those bugs deal with the proper display of
inline/attached parts, and this one deals with the proper tagging of messages
containing them.

Comment 9

[Mike Cowperthwaite]

See also bug 274156.

Comment 10

[Dan Sandberg]

What's the story with the case below? Thunderbird flags it with a paperclip like
it has an attachment, but doesn't treat the text as an attachment -- it just
shows it in-line.  What's the point of marking it an attachment if the message
doesn't behave in any way as if it had an attachment ( no save attachment
option, no filename, ... )

Seems like a multipart/mixed message with only one section whose content-type is
'text/plain' should not be marked as having an attachment. 

---------------------
... headers ...
Content-Type: multipart/mixed; 
	boundary="----=_Part_5_24634038.1116081844160"

------=_Part_5_24634038.1116081844160
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Text goes here
------=_Part_5_24634038.1116081844160--

Comment 11

[Paul Baclace]

I attached an RTF file (where openoffice is the handler on win2k) and it was
send inline.  The recipient did not know what to do with it and this caused a
critical delay for me.  The message appears with an attachment icon but has no
attachment.

The content type of the attachment is text/plain!  How does Thunderbird
determine the MIME type of a drag and dropped file?  

Specifics: Thunderbird  1.0.2 (20050317)  

Content-Type: multipart/mixed;
--------------020501040704020307040906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

yadda yadda yadda...
--------------020501040704020307040906
Content-Type: text/plain;
 name="prospectus.rtf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="prospectus.rtf"

{\rtf1\ansi\deff0\adeflang1025 [RTF splatter]

Comment 12

[Mike Cowperthwaite]

(In reply to comment #11)
> I attached an RTF file (where openoffice is the handler on win2k) and it was
> send inline.  The recipient did not know what to do with it and this caused a
> critical delay for me.  The message appears with an attachment icon but has no
> attachment.
> 
> The content type of the attachment is text/plain!  How does Thunderbird
> determine the MIME type of a drag and dropped file?  

This bug is actually not about attachments in messages composed by TB, but in 
messages received by TB.
See bug 65794 and bug 66915 about controlling the Content-Disposition for 
attachments while composing; and bug 244618 about the issue of teaching TB which 
MIME type should be used for a particular file extension.

Comment 13

[Steve Tynor]

Attachment: multipart/mixed msg (text/plain and text/html) which displays incorrectly in Thundebird 1.5RC2

Attached is an example mail message mis-displayed by Thunderbird 1.5RC2 - in 1.0.7 (and Outlook), it properly displays the last HTML part; in 1.5RC2, it displays both the text and HTML parts, and also includes an attachment icon which then displays the HTML part.

Comment 14

[WADA:World Anti-bad-Duping Agency]

(In reply to Comment #11 and Comment #13)

name & filename is specified in text attachment part in your cases.
> Content-Type: text/...; name="..."
> Content-Disposition: ...; filename="..."
It's possibly relevant to Bug 182627, because Tb considers a part "attachment" if name/filename is specified, even for mail-body/mail-body-part of text/... type.

Comment 15

[WADA:World Anti-bad-Duping Agency]

This bug's issues may be resolved(or improved) by enhancement in Bug 436555.
> Bug 436555 attachment presentation in received messages needs improvement

Comment 16

[Alfred Kayser]

The first example attached to this bug works as expected: only inline.
The second seems strange at first: both inline and attachment.

The question here is what to do when Content-Disposition has both "inline" and a filename specified. The filename is given so that when it is saved it has the right name.

Displaying that part as inline only would make it difficult (impossible to save it).
Displaying that part as attachment only would violate the "inline" request, but would allow to save the attachment.

See the standard specification: http://www.ietf.org/rfc/rfc1806.txt
for more details.
Specifically:
"the (filename) parameter may be used on any MIME entity, even
   `inline' ones. These will not normally be written to files, but the
   parameter could be used to provide a filename if the receiving user
   should choose to write the part to a file."
So, as soon as the filename is specified there should be a way to allow to save the attachment, even if displayed inline.

So, what TB currently does (since version 1.5 till 21.0a2) is to both as requested by that line.

So, given that the first test case is fixed by other bugs (see above), the other example doesn't need to be fixed.