After talking to dveditz, we might want to consider blocking inline images in mail by default, leveraging our remote image blocker bar to allow users to reload the message with the inline images. This would be tied to whatever trusted address policy we have for bypassing the blocked inline image check. Might be tricky to implement this. our remote image blocker is tied to thunderbird's content policy manager which detects the attempt to load the remote image. That code isn't invoked at all for an inline image.
Does it block also the pictures (xxx.jpg) shown in line in the mail? With the .wmf bug found (and corrected but there may be others), I fear to open this pictures even if the mail seems to come from one of my children : the From: line may be faked. If I choose in my viewing preferences to show only in "text only" format (not html) and without attachment in line, are all the image blocked and not loaded? Do I have a simple way to show the images on request? e.g. "Bug 172184 Unblock images for a specific message"
I'd like to see this capability, too. Consider the bugs around image processing libraries and crafted images, and/or all the image spam that I'd rather not see. I don't know how to do it but found that these images usually have an address like 'cid:number'. This could probably be detected during MIME processing. Also, if I could disable HTML display completely so that I'm shown the HTML source of an HTML message, that would solve the problem, too.
I have discovered that if I block remote images in my preferences they are blocked (of course) but if I push the "forward" button the previously blocked images appear : I think this is a bug in the "policy manager" and a breach of security see .wmf bug and virus!
> but if I push the "forward" button the previously blocked images appear That is not this bug, that's bug 263345 (fixed by bug 330443, should be fixed in the Thunderbird 2 beta 1 just released).
we made great strides with remote images but didn't get to inline images which don't go through the content policy logic. Let's work on that in the next release.
Target Milestone: Thunderbird2.0 → Thunderbird 3
Hello everybody. In the bug 547568 I show some details of the message body and the strategy they use: one identified image section and a html section linking the image source via the "cid:" of the image section. This trick makes Thunderbird not to dectect and shows porn images in messages.
are there other bugs related to this?
Component: General → Security
Target Milestone: Thunderbird 3 → ---
Not that I know of.
I believe we already have this feature; set the pref "mailnews.display.disallow_mime_handlers" to 2 (or greater), and it will block images whether they're inline or not. See here: <https://dxr.mozilla.org/comm-central/source/mailnews/mime/src/mimei.cpp#289>. To be fair, this isn't the most user-friendly, since you have to 1) set a hidden pref, and 2) go to View -> Message Body As every time you want to switch to seeing images (and then remember to turn it back off!), but the mailnews part works already, and we could simply enhance the usability here if we thought this was valuable. One possibility would be to have messages marked as junk automatically use simple HTML without images.
(In reply to Jim Porter (:squib) from comment #16) > One possibility would be to have messages marked as junk automatically use > simple HTML without images. I belive we already do that.
Well, we don't for messages in the Junk folder from Gmail. I don't use Thunderbird junk filters, so I'm not sure exactly how they work. Maybe all we need to do is treat all messages in a Junk folder as junk by default?
(In reply to Jim Porter (:squib) from comment #18) > Well, we don't for messages in the Junk folder from Gmail. I don't use > Thunderbird junk filters, so I'm not sure exactly how they work. Maybe all > we need to do is treat all messages in a Junk folder as junk by default? bug 1273818 is an idea along those lines
From a user perspective, the important thing is an obvious way to set a don't-display-images bit in the entire client by default while still rendering the balance of the HTML - right now the only way to satisfy the first objective is to render all messages as text, and there's no way to render the HTML on a per-message basis. A clear path to a whitelist manager would also be excellent. I point all interested parties to my unexpected behavior description in the (duplicate) https://bugzilla.mozilla.org/show_bug.cgi?id=1314417 that got me invited to this thread. (I'm a web developer of long and comparatively impressive standing who's a tourist around these parts.) One does not want to be minding his own business in the local coffeeshop, or his open-bay office, or in his living room with his kids, only to discover that some jackhat has dumped uninvited porn stills into his inbox by leveraging the client's RFC 2111 compliance.
Please block inline images that contain bytes within the html.
You need to log in before you can comment on or make changes to this bug.