Closed Bug 1367141 Opened 8 years ago Closed 8 years ago

MAPI email created externally - embedded file-based images create blocked content warning after upgrade to 52.1.1

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ivan, Unassigned)

References

Details

Attachments

(1 file)

Example email
27.26 KB, text/html
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce: Upgraded to 52.1.1 Changed preference mail.compose.attach_http_images to 'true', as instructed. Restarted Thunderbird, even restarted my computer. Checked the preference - still set to 'true'. Actual results: We have been using small SOCMAPI.EXE to create MAPI emails from our custom Helpdesk software in Thunderbird for years. Our application creates the MAPI email and attaches one or several images to it (mostly JPG or PNG saved previously to our server). After the upgrade, the images are not shown, Thunderbird is blocking them, I have to enable them one-by-one. Which is a lot of work, especially with many attached images. Expected results: Images should be shown as in prior 52.1.1 releases, there should be no need to enable them one-by-one.
Hmm, what exactly does your MAPI program create? I have the impression that the description isn't really accurate since *attached* images should work as before. What has changed are *embedded* images. So does your software create a HTML e-mail with embedded images with references to files "saved previously to our server", so something like: <img src="file:// ... ">? Can you attach a sample e-mail? We've changed the Thunderbird editor so that images based on files are no longer displayed. To allow users to include them, there is an unblocking mechanism in place now. Once I see the sample e-mail, I can make some suggestions. Maybe you could convert the images to data: URLs?
Reading your description again, maybe you could reference the images via http: URLs from your server instead of file: URLs, so <img src="http://intranet. ...">. Then the mail.compose.attach_http_images would take effect and attach the images. Or maybe I misunderstood your report and there is a problem with attachments.
Attached file Example email —
Hi, You are correct. We are talking about the embedded linked images. Attached is the saved email. Here is the actual email body: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <body>DMI,<br /><br />What&nbsp;is&nbsp;the&nbsp;reasoning&nbsp;for&nbsp;not&nbsp;having&nbsp;the&nbsp;"Print"&nbsp;button&nbsp;available&nbsp;on&nbsp;the&nbsp;WWA&nbsp;when&nbsp;accessing&nbsp;it&nbsp;through&nbsp;the&nbsp;Rescheduling&nbsp;module?<br /><br />Please&nbsp;refer&nbsp;to&nbsp;the&nbsp;screenshots&nbsp;below.<br /><br /><img src='file:///\\HAL\C\DMI\FAQX\LINKS\109996\_SIDNEY_DEWAY_001.JPG' alt='linked image' /><br /><br /><img src='file:///\\HAL\C\DMI\FAQX\LINKS\109996\_SIDNEY_DEWAY_002.JPG' alt='linked image' /><br /><br /><img src='file:///\\HAL\C\DMI\FAQX\LINKS\109996\_SIDNEY_DEWAY_003.JPG' alt='linked image' /><br /><br />Ivan<br /> </body> </html> Thanks,
Yes, that won't work any more. You need to convert the images to data: URLs or use http: URLs, which should not be so hard since you're running your own servers. Please understand why we changed this: file: URLs in messages were a possible attack vector to extract files from victims.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Summary: MAPI email created externally - images not attached after upgrade to 52.1.1 → MAPI email created externally - embedded file-based images create blocked content warning after upgrade to 52.1.1
Hmmm. That makes things much more complicated for us, loyal Thunderbird users. I understand the reasoning why you changed this, but I do not understand what have you had actually accomplished - if you allow me to show the pictures anyhow - by unblocking each one ... one by one... We just have to remember now to do that and spend additional minutes clicking on each picture 'unblock'. Which we usually forget and send the Helpdesk emails without the pictures. Is there any way we can return to the previous behaviour - or at least allow us to unblock ALL pictures with one click? Thanks,
(In reply to Ivan from comment #6) > I understand the reasoning why you changed this, but I do not understand > what have you had actually accomplished - if you allow me to show the > pictures anyhow - by unblocking each one ... one by one... The attack vector was to get the user to paste HTML containing hidden file-references, not just images. So now the user must explicitly unblock those references. > We just have to remember now to do that and spend additional minutes > clicking on each picture 'unblock'. Which we usually forget and send the > Helpdesk emails without the pictures. I understand the problem. In the bug where we changed the behaviour, we discussed up to comment #420, so not a decision we took lightly. There was a heap of stuff affected, templates, add-ons, etc. However, your MAPI application is a new twist. > Is there any way we can return to the previous behaviour - or at least allow > us to unblock ALL pictures with one click? I don't think we will allow an "unblock all". But I don't quite understand your situation. You have a proprietary helpdesk system. What stops you modifying that software and creating data: URLs instead of file: URLs? That's one function call when you prepare the HTML e-mail.
In fact, in C#, which I found as example, it's two lines: Byte[] bytes = File.ReadAllBytes("path"); String file = Convert.ToBase64String(bytes); So then you put: <img src="data:image/jpeg;filename=xxx.jpg;base64, ...">
OK, I will try to play with this over the weekend. Btw - we use Alaska XBase++, I am not sure about the above mentioned conversion function equivalent availability. I need to do some research and testing. Thanks.
See Also: → 1367716
Please note the discussion in bug 1367716. There people create messages via the command line. They asked for a solution to unblock file-based images. If we do that, we might consider unblocking images in MAPI-created messages as well, although that's a lot harder to do.
Yes, that would be perfect - it would solve our issue. But what does this mean - are you planning to allow it in the future builds of Thunderbird? Or is it just on the wishful Christmas list? Thanks, Ivan
See how the other bug goes. Automatically converting images in messages produced from the command line is a few lines of code (I'd think). Passing the information along from MAPI is a different thing. If we do it, it will be in a future release of TB 52.x, so not ready for weeks/months. If you fix your own software, you can be up and running in a few days. Without looking into it, it might also be possible to do this as and add-on which you could also deploy immediately.
Yes, if you can provide add-on, that would be highly appreciated. But it is your call. Thanks anyhow. Ivan
Hmm, it wouldn't look so good for one of the TB developers to provide an add-on to reduce security, would it?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: