All users were logged out of Bugzilla on October 13th, 2018

Embedded inline image not linking in html properly (mailer of mail sender uses wrong multipart/mixed instead of multipart/related required for MHTML)

RESOLVED INVALID

Status

--
enhancement
RESOLVED INVALID
9 years ago
8 years ago

People

(Reporter: jsh_crw, Unassigned)

Tracking

x86
Windows Vista

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: uri "cid:~" won't link to Content-Id in multipart/mixed (alt) message)

Attachments

(7 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Embedded image with php and made it work on some sites (gmail,yahoo).  At first I thought the script was wrong, but looked up the RFC and it seems standard. If you take the alt out, you'll see the broken image.

Basically, <img src="cid:<imgcid>" alt="" /> in the email html with the attached having a content-id of <imgcid>

Poo... I just realized.  I have it installed portable (via portableapps) on a usb drive, so that might be affecting it.  I'm going to post this anyway, and test later on the hard drive when I get the chance...

Reproducible: Always

Steps to Reproduce:
1. Take contents below and paste into a text file and name it "text.eml"
-- (option: remove the alt tag on the img to see the broken link)
2. open with thunderbird (I just realized that my thunderbird is portable so that might be the problem, but I'm going to post anyway)

*everything below this line
-------------------------------------------------------------------------------
To: someone@somewhere.com
Subject: Testing inline image
Message-ID: <aaf0d96fafd5ab7a56493301e74a13b2-20100104230815BRT@example.com>
Date: Thu, Apr 01 2010 23:08:15 BRT
From: JL <none@nowhere.com>
Subject: Testing inline image
To: Cranium <someone@somewhere.com>
Reply-To: JL <none@nowhere.com>
Mailed-by: example.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT"


--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT
Content-Type: multipart/alternative; boundary="cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT"



--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT
Content-Type: text/plain; charset=ISO-8859-1

- Attached Image Below (in html view):canyousee.png -

--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT
Content-Type: text/html; charset=ISO-8859-1

<html><head></head><body>- Attached Image Below (in html view):canyousee.png -<br />
<img src="cid:canyousee.png-21-20100104230815BRT@example.com" alt="" />
</body></html>

--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT--

--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT
Content-ID: <canyousee.png-21-20100104230815BRT@example.com>
Content-Type: image/png; name="canyousee.png"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="canyousee.png"

iVBORw0KGgoAAAANSUhEUgAAAMgAAAAfCAYAAACiY4IJAAAAAXNSR0IArs4c6QAAAAZiS0dEAN0A
/QAG3FlFIQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9oEAgE7JVaMquoAAAAXdEVYdENv
bW1lbnQAQ3JlYXRlZCBpbiBHSU1Qe9DCiQAACjVJREFUeNrtnHl0FFUWxn+vuqo7JAQiu4IaFsWw
I6gouOCIiCKo6EGWsHiCAVEROAget3HmDKsKjIiICxgVRSADiOiAKEJQWYZ9V0AOoh72BALpqq6+
80dloUk63e0QB0l95+Qk9fqr975337vv3veqOmqP7RVcuHBRIjTXBC5cuA7iwoXrIC5cuA7iwoXr
IC5cuA7iwsUFD/2PaCQQEBZ8GGTR7CDbNgjZx8DwwuV1Fa3bKR7oo9GyjeurLi48qLJ+DnLoVyH9
/gCb15bezB7b646Gi/IVQSxLGNAlwNb1Qq3aMPhZD7d01KhZGwIWHNwP67KCzHsv6I6Ei/K3B5k3
M8jW9ULtK2HBOoOe6R7qJCsMQ1EhXtEgRfHwAA9zsoyQ+7KWBkm716LFJSaNEkwebGuxallxJ6rv
ManvMTl1UhjeN0DjiiatqpuMfyaASOkRa99uoYFu0riiyfGjxbk5J4QmiSYNdJO9u5zPTVOYNs7m
npYWjRIcbfe0tJg+wcaypERt4TRHQu4pYfSIALfWN2noM2meZJJ6p8VXi0LtMP8Dmx7tHVtdE2fS
/iqTsSMDnMwu3qdYuCWhQPvJbGFE/wDNkxx7vzneBuDoYeGJhwM0SXTKX36u5HEIp6PcpVi977D4
7mvh5Zke7k/1RH1fSRNI12HutzpNW2nFeB26KpYuCO3Gi5M99Hm89DYf7x7g87lBhv3Nw+BnQ7nT
J9iMG2XToatiWqaB3y/07Rhg7cqSzdXmNsXML3QMQ4VoOzd1DFceTlu4dFREGJZqs/CjkjlXNVLM
WaWTWEnFxI1mXG7vrPhqUagdXvtY583xNlvXh5b/faqHnumObSPpuBDT7DKNIDs2Oca6+c7Ymrmr
m2LBWp0dZwyy9ht07q4RCMDbrwTD7HNg2S6DrScN+jzutJWZETltGzjS4b4/1cY0JeRQIWOKsyo+
OsIZ3BmTgqxdKVRKgkkfeticbbA522DiBx4SK8P3y4UZk85fqrjs02Cho288brDjjEHmdzod73cm
8SfvBFn4UZA6yTAtU2fjMYOdeQbz1+i0uknxw3bhjTF2zNxocPg3WLrdYNspg/5POTYclRZAacXL
58woskkkHeUuglztNbFt2OU30PXfb4CcE0LLqhaX1oGs/d5iK9qn/9Fp1MIZkCOHhBsutagQD1tP
Rl6R+nWyWLlEGPeOhwf7Oc6waLbNkJ42rdsqZq9w0r+7W1js2iJMnuWhc/fQaLNwls3QVJuU5opF
643zEkFuTjb55QC0v1vRtLXGje2dEz9Nc+z4wI0Wm9YI//pep9l1oQvQbweFtldYJDeAZbu8MXGj
iSAL1+k0bqkVplXX17LClscnwJYcb1Saa9VW5ctBWlU3OXEMVv9iUK1mdJ23beHdiUEWzAqyb7eQ
d6boM8OAnXnFHWS3aeDxqJgnIcDqb4L0vD1Aw6aKxRudyd3tJouNq4Xp83X+cq8zkCnxJqYftuQY
xCeoYvuFZpUtfHGwPdd7Xhxk+edBhvYOkHOiqOzK+vD6HJ2U5hqNK5ohtinxBEaHXX5vTNxoHCSc
vSONQyQd5S7FuqaZY6yVS6JPPcY8bTN2pM2OTVLMmJZV8j1nD0qsuOFWjWtvVOzaIqz6MsiG74Ns
XC00SHFy7fMJ245+Lbqtk8a3BwymZer0f0qjVm3YvweeGWDn5/OR6wjk73tj4UaDcPaONA7yJ/xi
RZk6SOfuTvWT/mpz9HB01snMP/KdPMvDxmMGPwYMNh43ytQIg0Y5KdPbr9q8m7+PSBvuQamiAa97
tfP38sXF+1FwslSvYRE/rgKFKV8Bdm6ObYZUiFd06Krx3Cs689c4Nti2QRARrm7stLV4k84e2xv2
B4iJW5aIpKPcOUi3fhqNWih+/gm6trb4aLrNwf2CZQl5Z4Q9O4WP37J5qF1RaCiIGr44hTcODuyD
Z9PtMjVC+3sUDZsoVvxb+GJekJqXQddeoabp0sO5fv6xAIvnBDmdK5zOFRbNtnlhsB3CAWiQ4kyG
qaNt8s4IP/0oPP9Y9P3of7dF1lKnndxTUrhp1w1QStFrkNNWWucAmRk2vxwQAgHB7xf27Xbs+mBb
x66xcMsSkXSUu016weYr/b5AseO/cPnnoG4WS+ZLsQn89WdSLE/9X/P8kjbaACPHegpPrwrg9wt9
7gywLkvCpGrOMa/X6zhGxhSbl4aEOsQdXRRfLpSotIV7VtKlh8bED5znuy8NCZAxJRiVXWPhRtIU
rb1LKi9NR7nbgwDUqq2Y+63O2Lc9tOugqFodPB6oEO+E3F4DNeauKnqg/483naPMuAqQWBm69dWY
+H7ZvzLWNP9UJbES9EgvbhafT5GxRGfEaA8Nmyq8PvDFQcOmiqfHeEKcAyB1sEb60xpJVSChItzX
W+OVjOj78eEynY4PKJKqOPaqk+wcS495q8hxX5ysk7FE565uipqXORttX5zzXKPXII3M7/TfxS1L
lKajXEaQPwvmzLAZlWaTNlzjmfF6ubdHPc3P3qCv3NvBfYUWyD4ufPaJE/YLnoVc6JPXxR+Dcr9U
np3r39ZJXbCh3oUbQf5v8Hicd6lGT7841otE0rhcbaeuOsXlajuJPPK7OCF7MK7nCvUTlXg0zEpb
l5pqHsnqKHVVDrXUQjSqlxoFHQ3b8jXsoCKpUUXKs8ujrSccx6AhV6h9QOgBgSKBK9XPbgS52L6H
UpGeJKkRHJJU/GzAx7XUUO8jksspZkfNORvxdKGamsgh6Use35R8GKMyOSJDOUQvFF4uUS9QVU3g
sPQLqzVJDeOQ9MHPJny0oIbKICg5nGZBTH2Opp7SOH42kEhPTjKzkJ9AN3JZ5EaQiw2V1RMckSfx
swaw8LOaI/IkldSTMXEKUImBVFEv8ot0COscAD9LS/JYjpBHkByOyfPEc0epWh0N6/I1rOWIDCFJ
DY+5z9HUUxonWyZSWQ0NjbAqlRx53XWQiw0GjYpN5Dy+wUuTmDgAl6jnqKge5qDcSoC9ETaz9ail
5pOsDlNP81NXO4FGtVLvySPrnOuVeGkWc5+jqac0Th4rEU4TT+fCdBEUJltcB3ERHmdkBQb1iaNd
RG4N9R5+1nFAGrM3GMfeYHzIqzoXOk7IqySpYfnRozc58oa7Sb8YYbGdOG4JKYvjFky2xsRxVtYV
/Cpdqa6mkcBDETbx13JCJmBzCBB8tIqo9VzHi+NmTDYXXgflNBpJ50TIlJjriYaTSyYe6uCjDRW4
nVzmuw5yMSJbXqOamoyP6wAdH9dRTU0mR/4ZE6cAJuv5VTpRVY0hkbRSHHM3lUhH4cMghWpqakSt
jobWIRqyZWJRBGMpVdQ4NKrmc9pQQ2XEXE90HJscmUIN9S6nZSlgu5PpzwoJg7M+HygiP4qIlf97
QAl1lMqRc75MLiLJIvKDiIwMo+l6EdmaX99+EXlCSvnHAPmSz9awV0QeOYdTQ0TmikiOiPhFZIOI
9Dynr9HUE5GTz0sUkZMiUrOg7L+EX9mgDP0dNwAAAABJRU5ErkJggg==


--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT--


Actual Results:  
attached image, but not linked in the html properly

Expected Results:  
image shown in html, not in the attachments (or both)

I'm going to leave at normal until someone (or when I get time... it's late here) tests it on a non-portable version.

- It did it with a gif as well, and that didn't work either.
(Reporter)

Comment 1

9 years ago
-- take out the two new lines before the "boundry=" statement that should be on with the previous lines.  They are too big to fit here.
(Reporter)

Comment 2

9 years ago
Created attachment 436630 [details]
Here is the test EML that is pasted in the comments



This is the EML file to test what I mean.  Remove the alt tag in the html to see the broken image.
(Reporter)

Comment 3

9 years ago
Created attachment 436631 [details]
This is the shot of the broken image in html

You can see the broken image in the html (alt removed) and the image is below in the attachments.
(Reporter)

Updated

9 years ago
Attachment #436630 - Attachment mime type: text/plain → message/rfc822
(Reporter)

Updated

9 years ago
Attachment #436630 - Attachment description: Here is the test EML that is pasted in the comments → Here is the test EML that is pasted in the comments message/rfc822
Attachment #436630 - Attachment mime type: message/rfc822 → text/plain
(Reporter)

Comment 4

9 years ago
Comment on attachment 436630 [details]
Here is the test EML that is pasted in the comments



Delivered-To: someone@somewhere.com
To: someone@somewhere.com
Subject: Testing inline image
Message-ID: <aaf0d96fafd5ab7a56493301e74a13b2-20100104230815BRT@example.com>
Date: Thu, Apr 01 2010 23:08:15 BRT
From: JL <none@nowhere.com>
Subject: Testing inline image
To: Cranium <someone@somewhere.com>
Reply-To: JL <none@nowhere.com>
Mailed-by: example.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT"


--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT
Content-Type: multipart/alternative; boundary="cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT"



--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT
Content-Type: text/plain; charset=ISO-8859-1

- Attached Image Below (in html view):canyousee.png -

--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT
Content-Type: text/html; charset=ISO-8859-1

<html><head></head><body>- Attached Image Below (in html view):canyousee.png
-<br />
<img src="cid:canyousee.png-21-20100104230815BRT@example.com" />
</body></html>

--cd5639fdef1dc2ffbbf5007da0b7c23e-alt-20100104230815BRT--

--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT
Content-ID: <canyousee.png-21-20100104230815BRT@example.com>
Content-Type: image/png; name="canyousee.png"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="canyousee.png"

iVBORw0KGgoAAAANSUhEUgAAAMgAAAAfCAYAAACiY4IJAAAAAXNSR0IArs4c6QAAAAZiS0dEAN0A
/QAG3FlFIQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9oEAgE7JVaMquoAAAAXdEVYdENv
bW1lbnQAQ3JlYXRlZCBpbiBHSU1Qe9DCiQAACjVJREFUeNrtnHl0FFUWxn+vuqo7JAQiu4IaFsWw
I6gouOCIiCKo6EGWsHiCAVEROAget3HmDKsKjIiICxgVRSADiOiAKEJQWYZ9V0AOoh72BALpqq6+
80dloUk63e0QB0l95+Qk9fqr975337vv3veqOmqP7RVcuHBRIjTXBC5cuA7iwoXrIC5cuA7iwoXr
IC5cuA7iwsUFD/2PaCQQEBZ8GGTR7CDbNgjZx8DwwuV1Fa3bKR7oo9GyjeurLi48qLJ+DnLoVyH9
/gCb15bezB7b646Gi/IVQSxLGNAlwNb1Qq3aMPhZD7d01KhZGwIWHNwP67KCzHsv6I6Ei/K3B5k3
M8jW9ULtK2HBOoOe6R7qJCsMQ1EhXtEgRfHwAA9zsoyQ+7KWBkm716LFJSaNEkwebGuxallxJ6rv
ManvMTl1UhjeN0DjiiatqpuMfyaASOkRa99uoYFu0riiyfGjxbk5J4QmiSYNdJO9u5zPTVOYNs7m
npYWjRIcbfe0tJg+wcaypERt4TRHQu4pYfSIALfWN2noM2meZJJ6p8VXi0LtMP8Dmx7tHVtdE2fS
/iqTsSMDnMwu3qdYuCWhQPvJbGFE/wDNkxx7vzneBuDoYeGJhwM0SXTKX36u5HEIp6PcpVi977D4
7mvh5Zke7k/1RH1fSRNI12HutzpNW2nFeB26KpYuCO3Gi5M99Hm89DYf7x7g87lBhv3Nw+BnQ7nT
J9iMG2XToatiWqaB3y/07Rhg7cqSzdXmNsXML3QMQ4VoOzd1DFceTlu4dFREGJZqs/CjkjlXNVLM
WaWTWEnFxI1mXG7vrPhqUagdXvtY583xNlvXh5b/faqHnumObSPpuBDT7DKNIDs2Oca6+c7Ymrmr
m2LBWp0dZwyy9ht07q4RCMDbrwTD7HNg2S6DrScN+jzutJWZETltGzjS4b4/1cY0JeRQIWOKsyo+
OsIZ3BmTgqxdKVRKgkkfeticbbA522DiBx4SK8P3y4UZk85fqrjs02Cho288brDjjEHmdzod73cm
8SfvBFn4UZA6yTAtU2fjMYOdeQbz1+i0uknxw3bhjTF2zNxocPg3WLrdYNspg/5POTYclRZAacXL
58woskkkHeUuglztNbFt2OU30PXfb4CcE0LLqhaX1oGs/d5iK9qn/9Fp1MIZkCOHhBsutagQD1tP
Rl6R+nWyWLlEGPeOhwf7Oc6waLbNkJ42rdsqZq9w0r+7W1js2iJMnuWhc/fQaLNwls3QVJuU5opF
643zEkFuTjb55QC0v1vRtLXGje2dEz9Nc+z4wI0Wm9YI//pep9l1oQvQbweFtldYJDeAZbu8MXGj
iSAL1+k0bqkVplXX17LClscnwJYcb1Saa9VW5ctBWlU3OXEMVv9iUK1mdJ23beHdiUEWzAqyb7eQ
d6boM8OAnXnFHWS3aeDxqJgnIcDqb4L0vD1Aw6aKxRudyd3tJouNq4Xp83X+cq8zkCnxJqYftuQY
xCeoYvuFZpUtfHGwPdd7Xhxk+edBhvYOkHOiqOzK+vD6HJ2U5hqNK5ohtinxBEaHXX5vTNxoHCSc
vSONQyQd5S7FuqaZY6yVS6JPPcY8bTN2pM2OTVLMmJZV8j1nD0qsuOFWjWtvVOzaIqz6MsiG74Ns
XC00SHFy7fMJ245+Lbqtk8a3BwymZer0f0qjVm3YvweeGWDn5/OR6wjk73tj4UaDcPaONA7yJ/xi
RZk6SOfuTvWT/mpz9HB01snMP/KdPMvDxmMGPwYMNh43ytQIg0Y5KdPbr9q8m7+PSBvuQamiAa97
tfP38sXF+1FwslSvYRE/rgKFKV8Bdm6ObYZUiFd06Krx3Cs689c4Nti2QRARrm7stLV4k84e2xv2
B4iJW5aIpKPcOUi3fhqNWih+/gm6trb4aLrNwf2CZQl5Z4Q9O4WP37J5qF1RaCiIGr44hTcODuyD
Z9PtMjVC+3sUDZsoVvxb+GJekJqXQddeoabp0sO5fv6xAIvnBDmdK5zOFRbNtnlhsB3CAWiQ4kyG
qaNt8s4IP/0oPP9Y9P3of7dF1lKnndxTUrhp1w1QStFrkNNWWucAmRk2vxwQAgHB7xf27Xbs+mBb
x66xcMsSkXSUu016weYr/b5AseO/cPnnoG4WS+ZLsQn89WdSLE/9X/P8kjbaACPHegpPrwrg9wt9
7gywLkvCpGrOMa/X6zhGxhSbl4aEOsQdXRRfLpSotIV7VtKlh8bED5znuy8NCZAxJRiVXWPhRtIU
rb1LKi9NR7nbgwDUqq2Y+63O2Lc9tOugqFodPB6oEO+E3F4DNeauKnqg/483naPMuAqQWBm69dWY
+H7ZvzLWNP9UJbES9EgvbhafT5GxRGfEaA8Nmyq8PvDFQcOmiqfHeEKcAyB1sEb60xpJVSChItzX
W+OVjOj78eEynY4PKJKqOPaqk+wcS495q8hxX5ysk7FE565uipqXORttX5zzXKPXII3M7/TfxS1L
lKajXEaQPwvmzLAZlWaTNlzjmfF6ubdHPc3P3qCv3NvBfYUWyD4ufPaJE/YLnoVc6JPXxR+Dcr9U
np3r39ZJXbCh3oUbQf5v8Hicd6lGT7841otE0rhcbaeuOsXlajuJPPK7OCF7MK7nCvUTlXg0zEpb
l5pqHsnqKHVVDrXUQjSqlxoFHQ3b8jXsoCKpUUXKs8ujrSccx6AhV6h9QOgBgSKBK9XPbgS52L6H
UpGeJKkRHJJU/GzAx7XUUO8jksspZkfNORvxdKGamsgh6Use35R8GKMyOSJDOUQvFF4uUS9QVU3g
sPQLqzVJDeOQ9MHPJny0oIbKICg5nGZBTH2Opp7SOH42kEhPTjKzkJ9AN3JZ5EaQiw2V1RMckSfx
swaw8LOaI/IkldSTMXEKUImBVFEv8ot0COscAD9LS/JYjpBHkByOyfPEc0epWh0N6/I1rOWIDCFJ
DY+5z9HUUxonWyZSWQ0NjbAqlRx53XWQiw0GjYpN5Dy+wUuTmDgAl6jnqKge5qDcSoC9ETaz9ail
5pOsDlNP81NXO4FGtVLvySPrnOuVeGkWc5+jqac0Th4rEU4TT+fCdBEUJltcB3ERHmdkBQb1iaNd
RG4N9R5+1nFAGrM3GMfeYHzIqzoXOk7IqySpYfnRozc58oa7Sb8YYbGdOG4JKYvjFky2xsRxVtYV
/Cpdqa6mkcBDETbx13JCJmBzCBB8tIqo9VzHi+NmTDYXXgflNBpJ50TIlJjriYaTSyYe6uCjDRW4
nVzmuw5yMSJbXqOamoyP6wAdH9dRTU0mR/4ZE6cAJuv5VTpRVY0hkbRSHHM3lUhH4cMghWpqakSt
jobWIRqyZWJRBGMpVdQ4NKrmc9pQQ2XEXE90HJscmUIN9S6nZSlgu5PpzwoJg7M+HygiP4qIlf97
QAl1lMqRc75MLiLJIvKDiIwMo+l6EdmaX99+EXlCSvnHAPmSz9awV0QeOYdTQ0TmikiOiPhFZIOI
9Dynr9HUE5GTz0sUkZMiUrOg7L+EX9mgDP0dNwAAAABJRU5ErkJggg==


--67e785859ed4af838a2bfc890ab69fb0-mix-20100104230815BRT--
(Reporter)

Updated

9 years ago
Attachment #436630 - Attachment description: Here is the test EML that is pasted in the comments message/rfc822 → Here is the test EML that is pasted in the comments
Attachment #436630 - Attachment mime type: text/plain → message/rfc822
(Reporter)

Comment 5

9 years ago
OK, tested on regular install.  It doesn't show there either.
(Reporter)

Updated

9 years ago
Version: unspecified → 3.0
This looks go to me in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2pre) Gecko/20100401 Lanikai/3.1b2pre.

Have you tried safe mode? (see https://support.mozillamessaging.com/en-US/kb/Safe+Mode for more information)
(Reporter)

Comment 7

9 years ago
Tried in safe mode also... are you seeing the pic in the attachments (under a line that says something like "canyousee.png") or in with the html where it's supposed to be?  I have no problem with it loading the image, but it's not in the html as in accordance with RFC 2111 or maybe RFC 2932... they look the same to me.
(Reporter)

Comment 8

9 years ago
Created attachment 436698 [details]
Image not showing above the text in html

I changed the html to show the image above the text to distinguish from the attachments.
(Reporter)

Comment 9

9 years ago
Ludovic, I didn't read the full comment.  I'm downloading Lanikai now to test...

OK, I tested in Lanikai and have the same results for Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2pre) Gecko/20100302 Lanikai/3.1b1 .. hmm, you have beta 2, where did you download it?

OK, tested on Shredder, but can't find Lanikai 3.1b2.  This one I think is more current.  Here it is:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4pre) Gecko/20100331 Shredder/3.2a1pre
(Reporter)

Comment 10

9 years ago
Created attachment 436739 [details]
views in gmail, showing proper handling

The top one was forwarded from Thunderbird.  The content ID was dropped, so the image is a standard attachment.  The bottom one is the original and you can see that it's not the same as an attachment.  It's shown in the html where it's supposed to be.

I guess the content-id being dropped would be another bug altogether, but one step at a time for me.
(In reply to comment #9)
> Ludovic, I didn't read the full comment.  I'm downloading Lanikai now to
> test...
> 
> OK, I tested in Lanikai and have the same results for Mozilla/5.0 (Windows; U;
> Windows NT 6.0; en-US; rv:1.9.2.2pre) Gecko/20100302 Lanikai/3.1b1 .. hmm, you
> have beta 2, where did you download it?

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/

It's called thunderbird but launches as lanikai :-)

So we are seeing the same thing.

(In reply to comment #10)
> Created an attachment (id=436739) [details]
> views in gmail, showing proper handling

Sorry but I fail to notice the difference between the gmail view and Tb's. Gmail's image is below some text saying attached image Tb is too. The only thing different is the line. Is that line the bug you are reporting ?
(Reporter)

Comment 12

9 years ago
> It's called thunderbird but launches as lanikai :-)

I thought you were seeing something different, that's why I was wondering where it was.

> 
> Sorry but I fail to notice the difference between the gmail view and Tb's.
> Gmail's image is below some text saying attached image Tb is too. The only
> thing different is the line. Is that line the bug you are reporting ?

The line is the difference between an image in the HTML and an image as an attachment.  I'm fine that it's an attachment, but you can't link it in the html with the cid like it's supposed to do (see RFC 2932).  This is a bug.  You can link images on the internet (when you allow them), but can't link images in the mail that are already loaded.  You can track people with outside images, but not with a loaded image, so in a since they are safer.  That doesn't count if someone finds a way in through an image, but that would compromise attachments to so it's irrelevant since the image is shown below.

I can make a more dynamic page to show images as background and other things as well, but the point should already be made.  If you want a more dynamic example, I'll make one...
(In reply to comment #0)
> Expected Results:  
> image shown in html, not in the attachments (or both)
(Bug summary)
> Embedded inline image not linking in html properly

Where can we see "Embedded inline image properly linked to HTML" in the attached mail? Where can we see text/html part and image/xxx part with content-id: which are placed in same multipart/RELATED part?

Bug of mailer or mail system which mail sender uses.

(In reply to comment #10)
> views in gmail, showing proper handling

As Gmail doesn't put "--- canyousee.png ---------------" after display of text/html part before inline display of image/png part, and as there is no text after "- Attached Image Below (in html view):canyousee.png -", and there is no other part between text/html part and image/png part, and as the image/png part can be displayed in inline, rendering result becomes same as display of next when the image/png part is displayed in inline.
> content-type: multipart/related
>   content-type: text/html
>     - Attached Image Below (in html view):canyousee.png<br>
>     <img src="cid:canyousee.png-21-20100104230815BRT@example.com">
>   content-type: image/png;     
>     content-id: <canyousee.png-21-20100104230815BRT@example.com>

If this bug report is not enhancement request for quirks, INVALID.
If request is quirks of similar treatment of text/html and image/xxx with content-id: in multipart/mixed to treatment in multipart/related, sverity should be enhancement. Is such quirks mandatory feature?
(Reporter)

Comment 14

9 years ago
> Where can we see "Embedded inline image properly linked to HTML" in the
> attached mail? Where can we see text/html part and image/xxx part with
> content-id: which are placed in same multipart/RELATED part?

Oops, I guess is was RFC 2111 that I was referring too:
http://www.faqs.org/rfcs/rfc2111.html

Yes, I should put text above and below the image, but the eml attachment in this bug has the html part and the image in the multipart.  I'm not sure what more you want unless you want me to create one that has the image between text so that you can see the difference.  In the text part there is no image, because it's text, but that's not what is showing (as you can see if you remove the alt tag to see a broken image).

> As Gmail doesn't put "--- canyousee.png ---------------" after display of
> text/html part before inline display of image/png part, and as there is no text
> after "- Attached Image Below (in html view):canyousee.png -", and there is no
> other part between text/html part and image/png part, and as the image/png part
> can be displayed in inline, rendering result becomes same as display of next
> when the image/png part is displayed in inline.
> > content-type: multipart/related
> >   content-type: text/html
> >     - Attached Image Below (in html view):canyousee.png<br>
> >     <img src="cid:canyousee.png-21-20100104230815BRT@example.com">
> >   content-type: image/png;     
> >     content-id: <canyousee.png-21-20100104230815BRT@example.com>
> 
> If this bug report is not enhancement request for quirks, INVALID.
> If request is quirks of similar treatment of text/html and image/xxx with
> content-id: in multipart/mixed to treatment in multipart/related, sverity
> should be enhancement. Is such quirks mandatory feature?

The cid is valid for per rfc 2111 and references the images as a part of the image with a valid content-id.  Upon reading the rfc more they state:

   Conforming
   implementations can choose to, but are not required to, take
   advantage of the content-id's uniqueness and interpret a "cid" URL to
   refer to any body part within the message store.

So, no it's not required.  My bad.  Required or not (though not part of this bug) the mail program shouldn't strip the content-id so that when forwarded it can still be seen properly in other mailers.  Granted that's not require either (I don't think).  I will change to enhancement...
Severity: normal → enhancement
(Reporter)

Comment 15

9 years ago
Created attachment 439827 [details]
EML with text above and below image (see the next jpg for example)
(Reporter)

Comment 16

9 years ago
Created attachment 439828 [details]
Image from G-mail and thunderbird showing eml with text above and below image
(Reporter)

Comment 17

9 years ago
I hope the last two attachments show more clearly what I was trying to explain.  Gmail shows the attachment in the HTML (and actually doesn't show in attachments) when the content-id is used properly, while Thunderbird shows just the attachment below and the alternate text in the HTML.

I have already moved to enhancement, since the RFC did say it was not required.  I hope that will handle most concerns about this bug.
(Reporter)

Comment 18

9 years ago
An example of a website that sends images in the HTML with the content ID would be blogtv.com and not many others.  Because they use "=" to break their HTML up though, gmail handles it incorrectly (I guess they didn't test on gmail), but shows mine correctly. Windows Mail, Yahoo, and hotmail show mine and the blogtv emails correctly.
(Reporter)

Comment 19

9 years ago
Created attachment 439835 [details]
This is the EML in windows mail. They show the image in the HTML and as an attachment.
(In reply to comment #16)

I also think it's better to keep Content-Id: header. Confirming.
Can you change bug summary to appropriate one to avoid misunderstandig of issue and for ease of search?

> Image from G-mail and thunderbird showing eml with text above and below image

I could see Gmail's display(as if multipart/related). Sorry for my misinterpretation of display result by Gmail. Gmail doesn't look to limit search scope of cid: to multipart/related only.
- rfc 2111 defines syntax of cid:, but doesn't define search scope of cid.
- cid: url is reffered by rfc 2387(for multipart/related) only.
- Currently, cid: is used and interpreted only when text/html or similar one.
So, I thought normal interpretation is that seach scope of cid: is limted to multipart/related only. Gmail stretches RFC?

(In reply to comment #19)
> This is the EML in windows mail. They show the image in the HTML and as an
> attachment.

MHTML was implemented by MS, and MS's browser/mailer probably fully supports MHTML. For mailer of MS, html mail is probably a kind of MHTML too, and probably doesn't limit search scope to multipart/related only.
Mozilla family supports a part of MHTML only in html mail(<img src="cid:...")> by mail&news only. Full MHTML support by Mozilla family is already requested.
Gmail possibly supports MHTML, and possibly applies MHTML rules to mail data stream.

If cid: url is likified in text/plain or is supported by <a> tag, and if display of content pointed by cid: is supported, it's very convenient way of attachment display. In this case, there is no reason to limit search scope to multipart/related only, because no rfc says that cid: url can be used only in mutipart/related.
What do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 21

9 years ago
Sorry about the name... Let me know if this one fits more:

  uri "cid:~" won't link to Content-Id in multipart/mixed (alt) message

Thank you for your time with this.  I couldn't find the reason for not working (since it worked in other mail programs), and now I know.

Ok, the problem was simply the multipart/related section.  The RFC did indicate that it needed to be of a multipart/related form to use the CID properly.  The multipart/alternative, should be used as a sub-part to the multipart/related... So basically, all I had to change was multipart/mixed to multipart/related, and that solved the problem.

Thank you.

I feel like I've run into this problem before for some reason.  Only now it's documented that I can't read the RFC's fully.  There are so damned many of them...
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: uri "cid:~" won't link to Content-Id in multipart/mixed (alt) message
(In reply to comment #21)
>   uri "cid:~" won't link to Content-Id in multipart/mixed (alt) message

Your understanding is same as mine.
Note: RFC 2392(Obsoletes: 2111) uses term of cid-url, so I wrote cid: url.

> The RFC did indicate that it needed to be of a multipart/related form to use the CID properly.

But, no RFC says that cid-url shouldn't work in other than multipart/related :-)

We need to check RFC of MHTML to investigate "CID in multipart/mixed" issue. We are better to open separate bug for "CID in multipart/mixed" issue, if analisys of the issue will be required.

> WORKSFORME

Do you think "loss of Content-ID: of image/xxx part upon inline formard" is not problem any more? Do you think problem is misuse of multipart/mixed in mail which should be multipart/related by mailer which mail sender uses?

If so, close as INVALID, please.
WOKSFORME at B.M.O is for "Tb's flaw in code really existed, and was fixed by unkown patch".
FYI.
> http://www.faqs.org/rfcs/rfc2557.html
> RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
> 7.  Use of the Content-Type "multipart/related"
>  If a message contains one or more MIME body parts containing URIs and
>  also contains as separate body parts, resources, to which these URIs
>  (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole
>  set of body parts (referring body parts and referred-to body parts)
>  SHOULD be sent within a multipart/related structure as defined in [REL].
>(snip)
> [REL] specifies that a type parameter is mandatory in a "Content-
>    Type:  multipart/related" header, (snip)

Closing as INVALID.
Resolution: WORKSFORME → INVALID
Summary: Embedded inline image not linking in html properly → Embedded inline image not linking in html properly (mailer of mail sender uses wrong multipart/mixed instead of multipart/related required for MHTML)
(Reporter)

Comment 24

9 years ago
(In reply to comment #23)

Not disagreeing with closing, but the specification you show does say "should" and not "must".  I was content with this being closed, but still concerned that others will fall into the same.  All other mail clients I tested the EML on handled it normally even though multipart/related wasn't specified.  From now on, I will use multipart/related, but others will be confused as to why Mozilla doesn't handle what everyone else handles normally even though it may be incorrect.
(Reporter)

Comment 25

9 years ago
(In reply to comment #22)
> If so, close as INVALID, please.
> WOKSFORME at B.M.O is for "Tb's flaw in code really existed, and was fixed by
> unkown patch".

Thank you for changing to INVALID.

As far as comment #24, I meant to ask a question.

Should Thunderbird handle url-cid normally outside of multipart/related since it appears that most other mail applications seemed to handle it normally?  

Since this I've also tested in Outlook and it handles it as though it's multipart/related even though the message is multipart/mixed.  I have yet to find another mail application outside of Thunderbird that doesn't handle the url-cid as though it was in multipart/related when only multipart/mixed was specified.
(In reply to comment #25)
> As far as comment #24, I meant to ask a question.
> Should Thunderbird handle url-cid normally outside of multipart/related since
> it appears that most other mail applications seemed to handle it normally?  

I don't think "should", but I surely think "is better to do".

(a) Although RFC 2557(MHTML) says "should be placed in a same multipart/related part", Windows Mail, Gmail, and probably Outlook, searches for part with Content-Id: in multipart/mixed. It indicates that they strech MHTML RFC. Quirks for comaptible behaviour with other mailers is also an important thing, if critical RFC violation is not involved in it.
(b) As I wrote in comment #22, no RFC says that cid-url must not/should not work in other than multipart/related, although MHTML RFC says "should be placed in multipart/related"(as you say, not "MUST").
(c) As I wrote in comment #20, if MHTML RFC is slightly streched by Tb, user's convenience can be enhanced.

I think Outlook's behaviour is reasonable if MHTML RFC is slightly streached by Tb.
  - Search Content-ID: even if multipart/mixed.
    (How about multipart/alternative?)
  - When multipart/mixed, the part is displayed in attachment pane,
    because the part with the Content-ID: is really placed in multipart/mixed.

I think "strech of MHTML RFC by Tb like some other mailers and Gmail" is never mandatory. But, if other people will open bug for the enhancement, I'll surely vote to it, and will ask David Bienvenue about correctness of the enhancement request.
(Reporter)

Comment 27

9 years ago
(In reply to comment #26)

I agree that it would enhance user's convenience and that it might be better to do.  Do you think that I should reopen this bug (and leave as enhancement) since I probably closed it prematurely due to this?

> I think Outlook's behaviour is reasonable if MHTML RFC is slightly streached by
> Tb.
>   - Search Content-ID: even if multipart/mixed.
>     (How about multipart/alternative?)

According to the RFC, multipart/alternative are all the same content, with the more advance at the bottom.  I believe it states somewhere that they should (or may) all have the same content-id since only one will be used at a time.  I think if the multipart/alternative is part of a multipart/related, the content-id could be placed for the entire multipart/alternative as a group instead of on individual items (though both might happen).

>   - When multipart/mixed, the part is displayed in attachment pane,
>     because the part with the Content-ID: is really placed in multipart/mixed.
> 
> I think "strech of MHTML RFC by Tb like some other mailers and Gmail" is never
> mandatory. But, if other people will open bug for the enhancement, I'll surely
> vote to it, and will ask David Bienvenue about correctness of the enhancement
> request.

OK, let me know if I should reopen, or you can do so if you feel it should be.


On a similar subject:

The messages sent by blogtv have multipart/mixed with two parts one a multipart/alternative for the html/plain content and another multipart/mixed for the images.  When I changed the main to multipart/related, the cid-url didn't work.  When I changed both main and sub to multipart/related, the cid-url didn't work.  When I removed the sub and had mulipart/related with the multipart/alternative and the images all as part of the multipart/related, it worked perfectly.

Maybe this is a different bug, but should a multipart/related that is a part of another multipart/related work normally?

This is a example of the structure blogtv.com uses in their email (that doesn't work in Tb):

  Content-Type: multipart/mixed; boundary=boundry-example-mix1

  --boundry-example-mix1
  Content-Type: multipart/alternative; boundary=boundry-example2

  --boundry-example-alt
  Content-Type: text/plain; charset=us-ascii

  ...plain text...
  ...another image...

  --boundry-example-alt
  Content-Type: text/html; charset=us-ascii

  ...<IMG SRC="cid:imageloc@somewhere" alt="plain text">...
  ...<IMG SRC="cid:imageloc2@somewhere" alt="another image">...

  --boundry-example-alt--

  --boundry-example-mix1
  Content-Type: multipart/mixed; boundary=boundry-example-mix2
  
  --boundry-example-mix2
  Content-Type: image/gif
  Content-ID: <imageloc@somewhere>

  [image content]

  --boundry-example-mix2
  Content-Type: image/gif
  Content-ID: <imageloc2@somewhere>

  [image content]

  --boundry-example-mix2--

  --boundry-example-mix1--

Changing the main part to related, didn't work:

  Content-Type: multipart/related; boundary=boundry-example-rel1

  --boundry-example-rel1
  Content-Type: multipart/alternative; boundary=boundry-example2

  --boundry-example-alt
  Content-Type: text/plain; charset=us-ascii

  ...plain text...
  ...another image...

  --boundry-example-alt
  Content-Type: text/html; charset=us-ascii

  ...<IMG SRC="cid:imageloc@somewhere" alt="plain text">...
  ...<IMG SRC="cid:imageloc2@somewhere" alt="another image">...

  --boundry-example-alt--

  --boundry-example-rel1
  Content-Type: multipart/mixed; boundary=boundry-example-mix2
  
  --boundry-example-mix2
  Content-Type: image/gif
  Content-ID: <imageloc@somewhere>

  [image content]

  --boundry-example-mix2
  Content-Type: image/gif
  Content-ID: <imageloc2@somewhere>

  [image content]

  --boundry-example-mix2--

  --boundry-example-rel1--

Nor did changing both (which I think probably should have):

  Content-Type: multipart/related; boundary=boundry-example-rel1

  --boundry-example-rel1
  Content-Type: multipart/alternative; boundary=boundry-example2

  --boundry-example-alt
  Content-Type: text/plain; charset=us-ascii

  ...plain text...
  ...another image...

  --boundry-example-alt
  Content-Type: text/html; charset=us-ascii

  ...<IMG SRC="cid:imageloc@somewhere" alt="plain text">...
  ...<IMG SRC="cid:imageloc2@somewhere" alt="another image">...

  --boundry-example-alt--

  --boundry-example-rel1
  Content-Type: multipart/related; boundary=boundry-example-rel2
  
  --boundry-example-rel2
  Content-Type: image/gif
  Content-ID: <imageloc@somewhere>

  [image content]

  --boundry-example-rel2
  Content-Type: image/gif
  Content-ID: <imageloc2@somewhere>

  [image content]

  --boundry-example-rel2--

  --boundry-example-rel1--

Removing the sub multipart/related did work though:

  Content-Type: multipart/related; boundary=boundry-example-rel1

  --boundry-example-rel1
  Content-Type: multipart/alternative; boundary=boundry-example2

  --boundry-example-alt
  Content-Type: text/plain; charset=us-ascii

  ...plain text...
  ...another image...

  --boundry-example-alt
  Content-Type: text/html; charset=us-ascii

  ...<IMG SRC="cid:imageloc@somewhere" alt="plain text">...
  ...<IMG SRC="cid:imageloc2@somewhere" alt="another image">...

  --boundry-example-alt--

  --boundry-example-rel1
  Content-Type: image/gif
  Content-ID: <imageloc@somewhere>

  [image content]

  --boundry-example-rel1
  Content-Type: image/gif
  Content-ID: <imageloc2@somewhere>

  [image content]

  --boundry-example-rel1--
You need to log in before you can comment on or make changes to this bug.