User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Thunderbird version 0.8 (20040913) When forwarding an email that contains remote images thunder bird downloads the images from the remote server, displays them in the compose window, and converts them to inline images in the forwarded email. This occurs regardless of whether the setting for blocking the loading of remote images is turned on or not. Reproducible: Always Steps to Reproduce: 1. Receive an email that contains a remote image 2. Forward the email 3. The remote image will load in the compose window and be converted to an inline email within the forwarded email. Actual Results: A remote image is loaded despite the setting to block remote images from being loaded. Expected Results: The remote image should not be loaded. Instead of converting the remote image to an inline image thunderbird should forward the email with the image src referencing the remote URL unless the thunderbird user has changed the settings to allow remote images to be loaded.
This is an email that contains remote images.
This is a forwarded version of the same email, with the remote images converted to inline images by thunderbird.
I see this symptom; images are shown in the compose window. Due to bug 176416, the images will be copied into the message as MIME parts and sent along with it. Under TB, it happens for replies as well as forwards. But under Moz 1.8a4, it happens for forwards but *not* for replies. I'm confused as to whether the behavior is expected: Bug 167131 is about this same problem, and is marked Fixed Bug 206793 is about the *opposite* problem, has a patch, but is left in an unknown state. Bug 206793 comment 6 states that for quoted text -- forwards and replies -- we *should* be blocking images. Workaround: View | Message Body As | Plain Text before reply or forward.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #3) > Under TB, it happens for replies as well as forwards. That has been my experience with TB 0.8 (20040930 branch build) on WinXP. With non-Junk messages: when I reply to a message, the remote images are all loaded in the Compose window. Same thing if I forward the message inline. With Junk messages: when I reply to a message it remains "sanitized" (no images are loaded), but when I forward it inline, the remote images are loaded in the Compose window.
Bug 272810 is, if not duplicate, at least very related to this one.
*** Bug 249075 has been marked as a duplicate of this bug. ***
Before I mark a message as junk, I'll forward it to the spoof or abuse address. Before I mark a message as junk, remote images are not displayed. If I forward a message with blocked remote images, the remote images are displayed in the forwarding message, alerting the spamhaus to the fact that I have a "live" address. Desired resolution: If remote images are blocked, they should stay blocked in the Foreward window when I forward the message.
(In reply to comment #7) > Before I mark a message as junk, I'll forward it to the spoof or abuse > address. I would think you should be forwarding it As Attachment in this case, so that the recipient can see (for instance) the Received headers. Forward As Attachment does not exhibit the symptom of this bug.
(In reply to comment #8) > I would think you should be forwarding it As Attachment in this case, so that > the recipient can see (for instance) the Received headers. Forward As > Attachment does not exhibit the symptom of this bug. True -- however -- I use DSPAM which doesn't like to have mail forwarded as attachment (I realize that it can be configured that way, but that's an extra step). Turning off remote images should block them in any case .. any type of forward.
*** Bug 286611 has been marked as a duplicate of this bug. ***
Moving this to core, since it happens in Moz and TB. I assume the platform/os should be all/all, but nobody with non-Windows systems has yet said so. Bug 206681 is about the Reply case (which appears is TB-specific).
Component: Message Compose Window → MailNews: Composition
OS: Windows XP → Windows 2000
Product: Thunderbird → Core
Summary: Remote images not blocked when forwarding mail → Remote images not blocked when forwarding mail (inline)
Version: unspecified → Trunk
(In reply to comment #11) > Moving this to core, since it happens in Moz and TB. I assume the platform/os > should be all/all, but nobody with non-Windows systems has yet said so. I can confirm this under Linux with Thunderbird 1.0 (20050116) (Debian unstable build).
(In reply to comment #3) > Under TB, it happens for replies as well as forwards. But under Moz 1.8a4, > it happens for forwards but *not* for replies. However, in Moz 1.8b2-0309, replies *do* include images when blocking is turned on -- and I discovered (when testing for bug 288855) that earlier versions of Mozilla blocked (or appeared to block) remote images even when the preference for blocking was turned off! So there was some related but distinct bug that's been fixed, which made it appear that the suite did not exhibit this bug for replies. Updating the summary to reflect this. (In reply to comment #11) > Bug 206681 is about the Reply case (which appears is TB-specific). I was mistaken about this, that bug is not related at all to this problem.
Summary: Remote images not blocked when forwarding mail (inline) → Remote images not blocked when forwarding mail (inline) or replying
*** Bug 294034 has been marked as a duplicate of this bug. ***
Scott, can you take a look at this?
*** Bug 300223 has been marked as a duplicate of this bug. ***
*** Bug 301669 has been marked as a duplicate of this bug. ***
This occurs when replying as well. I'd like to preset certain domains such as incredimail.com to block and allow certain sites such as those from stores I'm subscribed to. Blocking according to address book entries is useless if someone in my address book forwards malicious email to me.
The UI behavior I'd expect is that if images were blocked in the original message, a dialog would appear asking the user if they wanted remote images removed or unblocked before forwarding, with perhaps a cancel button and a note saying that if they instead forwarded the message as an attachment, they could keep the blocked images included without unblocking them.
*** Bug 317495 has been marked as a duplicate of this bug. ***
this is still happening with thunderbird 1.5 rc1 on linux.
*** Bug 328229 has been marked as a duplicate of this bug. ***
just wanted to add that this is related to the web bug (or web-bug or webbug) in order to make sure people looking for this bug will find it.
*** Bug 334693 has been marked as a duplicate of this bug. ***
*** Bug 335132 has been marked as a duplicate of this bug. ***
*** Bug 335641 has been marked as a duplicate of this bug. ***
The profile of this issue has been raised by the recent HP scandal where webbugs and forwarded webbugs were explicitly part of it. Outlook has some protections in place that we should at least meet, if not exceed. http://blogs.zdnet.com/BTL/?p=3671
I've posted a patch in Bug 330443 which also fixes this issue.
This could be fixed by forwarding the references to the remote images as they appear in the original message. But that would leave the recipient loading the remote images if they use an email client other than Thunderbird or if they trust you to use remote images in ways not intended to violate privacy. So I think that instead, it should work like this: * if you forward a message that contains remote images you loaded, the forwarded message should contain the images inline. * if you forward a message that contains remote images you didn't load, the forwarded message should contain neither the image (because that would violate privacy when composing/sending) nor the URL of the image (because that could violate privacy when reading).
(In reply to comment #29) Brilliant! (sorry for the bugspam but that's a very good idea)
(In reply to comment #29) > * if you forward a message that contains remote images you didn't load, the > forwarded message should contain neither the image (because that would > violate privacy when composing/sending) nor the URL of the image (because > that could violate privacy when reading). Stripping the URL does sound like a good idea. I wonder if anything can or should be done for the forward-as-attachment case -- same potential for privacy problems, but harder to implement. As for the rest, since Scott's patch for Bug 330443, this seems to be working well (2b1-1111, 3a1-1031, Win2K), with HTML reply and inline-forward only displaying the images in the compose window if they were displayed in the message window. The images (loaded or not) are automatically given moz-do-not-send=true on both branch and trunk. I thought that was due to the fix for bug 132257, but that bug hasn't been checked into the branch yet (or am I wrong about that?).
Bug 330443 fixed the original issue reported here and that fix landed on the branch.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Resolution: --- → WORKSFORME
Since we know a specific fixing patch we should change this to FIXED. However the fix was for eventual Thunderbird 2, 1.5.0.x is not fixed.
Resolution: WORKSFORME → FIXED
Depends on: 330443
Whiteboard: [sg:want] → [sg:want] fixed by 330443
Scott says the fix is too involved to take safely on the old branch, users will have to upgrade Thunderbird 2 or SeaMonkey 1.1.x
Have we offered Tb2 to those users through automatic update yet?
No, Tbird2 is not even released (it's in beta), there's no automatic update yet. A fixed SeaMonkey has been released, though. Since there appears to be no desire to back-port this fix to the current shipping product it's best to come clean about it. If users know about the problem and care they can switch to SeaMonkey
You need to log in before you can comment on or make changes to this bug.