Created attachment 763654 [details] sample email with inline image User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130512193848 Steps to reproduce: I received an email, apparently sent using Microsoft CDO for Windows 2000 (according to the X-Mailer header). The email is in html and contains inline images referenced with <img> elements with src set as as a filename, and the attachment (which has a correct Content-Type of image/png) has the same filename as a 'name' in the Content-Type header, and as a 'filename' in the Content-Disposition header. I had them send a simple email from the same system and saved it to an .eml file, and edited the email addresses, hostnames, and ip addresses out...hopefully it is still useful to figure out this problem. The relevant parts : <IMG id="Picture 1" src="d0176599-66b6-4266-b625-1b33c4b206ee.png" width=396 height=223> and Content-Type: image/png; charset="utf-8"; name="d0176599-66b6-4266-b625-1b33c4b206ee.png" Content-Transfer-Encoding: base64 Content-ID: <121dbd5e-15af-4ff5-9355-42e54bcba13f> Content-Disposition: inline; filename="d0176599-66b6-4266-b625-1b33c4b206ee.png" Actual results: broken image is displayed in the message and the file is shown as an attachment Expected results: While I am reliably informed that this style of referencing attachments is not according to the standard, I would expect Thunderbird to accommodate this, especially since it is almost certainly quite trivial and doing so will make the use of Thunderbird in the enterprise somewhat less painful.
I assume using the name (found in content-type) instead of cid:... when referencing img src from HTML is really non-standard, and probably non-standard enough to *not* accommodate for it in TB. We really can't iron out all the problems caused by non-standards-compliant mailers, especially now that TB is maintained by volunteer community.
I think it is non-standard, but if TB wants to get any traction inside organisations using FOSS with Microsoft Exchange/etc, then I think it should be considered seriously. It's easy to just claim 'non-standard', and it's a valid argument, but it surely would be much easier for TB to support this (and then have more and more people not use Microsoft tools) than to get Microsoft to use standard methods. FYI, in this case, I am a s/w engineer inside Intel's Open-source Technology Centre (OTC) and Microsoft Exchange/Outlook are the most-used mailers outside OTC, so many wide-audience messages are not rendered correctly by TB. This makes it impossible to recommend TB even to people inside OTC (where it is likely most readily accepted). Can I assume that supporting the above method doesn't actually break any standard compliance? If so, I personally think it is worth the effort (though it isn't *my* effort, admittedly).