557469 - Attachment clip appears then disappears and attachment is not visible (multipart/mixed, but mail-boy-part only, no attachment)

Status: RESOLVED DUPLICATE of bug 479017

(MailNews Core :: Attachments, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

When receiving emails from the equipment, the attachment clip is first displayed, indicating the existence of an attachment.

When the message is selected, the attachment clip disappear and no attachment is shown.

Extracting the email and extracting the attachment with an external email decoder works fine.

Reopening the previously saved email in eml format is still negative.

Safe-mode made no change. 

No errors in Error console.

Reproducible: Always

Steps to Reproduce:
1. Open the attachment filed with the bug
2.
3.
Actual Results:  
No attachment displayed

Expected Results:  
Attachment visible

Comment 1

[[e-mail]]

Attachment: Mail sample with attachment which doesn't display

Comment 2

[Nathan Tuggy (:tuggyne)]

I see this on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 ID:20100317103207.

What mail agent was this sent with? Presumably not Thunderbird.

I'll have to pass this on to someone who knows more about MIME's fiddly bits than I; it may be expected behavior in this case. (In particular, the content-id header on the attachment looks suspicious to me -- if it has a content-id, isn't it supposed to be used as a source for inline pictures or the like?)

Comment 3

[[e-mail]]

The mail is sent by an air conditioning control hardware.

The manufacturer is far from a big company and they probably just checked their mail with an external look...

I have no skills in decoding MIME headers myself. Therefore, I cannot validate it.

The only thing I can think of, is that if others mail agents or mail decoders can cope with a perhaps badly formatted header, why Thunderbird would'nt have the same indulgence ?

Comment 4

[Ludovic Hirlimann [:Usul]]

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=multipart%2Fmixed shows a few related issues.(In reply to comment #2)

> 
> I'll have to pass this on to someone who knows more about MIME's fiddly bits
> than I; it may be expected behavior in this case. (In particular, the
> content-id header on the attachment looks suspicious to me -- if it has a
> content-id, isn't it supposed to be used as a source for inline pictures or the
> like?)

Wada San can you have a look please ?

Comment 5

[WADA:World Anti-bad-Duping Agency]

Mail structure is as follows.
> content-type: multipart/mixed; boundary=--boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9
>
> (Part 1 of multipart/mixed)
> ----boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9
> content-type: multipart/alternative; boundary=--boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
>
>  (Part 1.1 of multipart/alternativa)
>   ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
>   content-type: multipart/related;
>    boundary=--boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7; type="text/html"
>
>    (Part 1.1.1 of multipart/related)
>     ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7
>     content-type: text/html; charset=utf-8
>     content-transfer-encoding: base64
>
>     PGh0bWw+PGJvZHk+PEZPTlQgZmFjZT0iQXJpYWwiIHNpemU9ND4yMi8wMy8yMDEwIDA5OjI2
>     (snip)
>     ZDpQaWMxIj48YnI+PC9ib2R5PjwvaHRtbD4=
>
>    (Part 1.1.2 of multipart/related, embedded image of HTML mail)
>     ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7
>     content-type: image/jpeg
>     content-transfer-encoding: base64
>     content-id: <Pic1>
>
>     iVBORw0KGgoAAAANSUhEUgAAAZAAAAEsCAYAAADtt+XCAAAAAXNSR0IArs4c6QAAAARnQU1B
>     (snip)
>     FnBZ4P8Bd18WeKsyHD8AAAAASUVORK5CYII=
>     ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7--
>
>  (Part 1.2 of multipart/alternativa)
>   ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
>   content-type: text/plain; charset=utf-8
>   content-transfer-encoding: base64
>
>   MjIvMDMvMjAxMCAwOToyNiA6IETDqWJ1dCBhbGFybWUgYmFzc2UgKDI2LDkgJSkgc3VyIGwn
>   dW5pdMOpIHN1cnZlaWxsw6llIEhSIFNhbGxlIFNhdHVybmUgKDEyMCBSZEMp
>   ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc--
>
> (End of Part 1 of multipart/mixed, no other part of multipart/mixed, because close boundary)
> (  mail-body = part of multipart/alternative. No part of attachment in multipart/mixed mail)
> ----boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9--

(1) Because multipart/mixed mail(it's for mail-body part + attachment parts), Tb initially displays attachment icon upon initial download(no additional mail structure analysis mainly for performance reason).
(2) Tb analyzes mail structure upon mail display request.
- No attachment part in main multipart/mixed mail.
- Because multipart/related part in multipart/alternative part(text/html part
  + image/html part for embedded image) is properly structured,
  there is no non-diplayable part due to incorrect/malformed mail structure.
(3) There is no part which is to be displayed in attachment box for Tb.
=> Mail initially has attachment icon, but finally has no attachment icon.

DUP of already opened bug report at B.M.O.

Comment 6

[Ludovic Hirlimann [:Usul]]

Thank you Wada !

Comment 7

[[e-mail]]

I'd like to point out that in this case, as it's not the same for the 479017 bug, 
there is here a real attachment with a real file in it which SHOULD be displayed...

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> there is here a real attachment with a real file in it which SHOULD be
> displayed...

[e-mail](bug opener):

Where can we see mail ATTACHMENT part in your mail sample?
Which part is the "real atacchment" in your mail sample?
Do you understand what multipart/related means?
Was image/jpeg part with content-id: <Pic1> displayed as attachment in attacment box?
(I didn't check whether HTML points the part by <img src="cid:Pic1"> or not.)