Bug 263345 (reply-images)

Remote images not blocked when forwarding mail (inline) or replying

RESOLVED FIXED

Status

defect
RESOLVED FIXED
15 years ago
11 years ago

People

(Reporter: ben, Assigned: mscott)

Tracking

({fixed1.8.1.1, privacy})

Dependency tree / graph
Bug Flags:
blocking1.7.13 -
blocking-aviary1.0.8 -
blocking-thunderbird2 -
blocking1.8.0.12 -
wanted1.8.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want] fixed by 330443)

Attachments

(2 attachments)

Reporter

Description

15 years ago
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.
Reporter

Comment 1

15 years ago
This is an email that contains remote images.
Reporter

Comment 2

15 years ago
This is a forwarded version of the same email, with the remote images converted
to inline images by thunderbird.

Comment 3

15 years ago
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

Comment 4

15 years ago
(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. 

Comment 5

15 years ago
Bug 272810 is, if not duplicate, at least very related to this one.

Comment 6

15 years ago
*** Bug 249075 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
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.

Comment 8

15 years ago
(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.

Comment 9

15 years ago
(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
Reporter

Comment 12

14 years ago
(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.
Keywords: privacy
Summary: Remote images not blocked when forwarding mail (inline) → Remote images not blocked when forwarding mail (inline) or replying
Flags: blocking-aviary1.1?

Updated

14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
*** Bug 294034 has been marked as a duplicate of this bug. ***
Scott, can you take a look at this? 

Comment 16

14 years ago
*** Bug 300223 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking-aviary1.0.6?
*** Bug 301669 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Depends on: 303752

Updated

14 years ago
Flags: blocking-aviary1.5+

Comment 18

14 years ago
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.

Comment 19

14 years ago
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. ***
Flags: blocking1.7.13-
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8-

Comment 21

14 years ago
this is still happening with thunderbird 1.5 rc1 on linux.

Comment 22

13 years ago
*** Bug 328229 has been marked as a duplicate of this bug. ***

Comment 23

13 years ago
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.

Comment 24

13 years ago
*** Bug 334693 has been marked as a duplicate of this bug. ***
Alias: reply-images
Flags: blocking1.8.0.4?
Flags: blocking-thunderbird2?
*** Bug 335132 has been marked as a duplicate of this bug. ***
*** Bug 335641 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.0.5?
Whiteboard: [sg:want]

Updated

13 years ago
OS: Windows 2000 → All
Hardware: PC → All
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
Assignee

Comment 28

13 years ago
I've posted a patch in Bug 330443 which also fixes this issue.

Comment 29

13 years ago
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).

Comment 30

13 years ago
(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?).
Assignee

Comment 32

13 years ago
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.
Flags: wanted1.8.0.x+
Flags: blocking1.8.0.11?
Keywords: fixed1.8.1.1
Resolution: WORKSFORME → FIXED
Depends on: 330443
Whiteboard: [sg:want] → [sg:want] fixed by 330443
Duplicate of this bug: 371482
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
Flags: wanted1.8.0.x-
Flags: wanted1.8.0.x+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12-
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
Product: Core → MailNews Core
Duplicate of this bug: 451840
You need to log in before you can comment on or make changes to this bug.