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

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Ben Holt]

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.

Comment 1

[Ben Holt]

Attachment: The original email, including remote images

This is an email that contains remote images.

Comment 2

[Ben Holt]

Attachment: Forwarded copy of the same email

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

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[wintogreen]

(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

[Kalin Kozhuharov]

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

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Steve Kelem]

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

[Mike Cowperthwaite]

(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

[Darrell Esau]

(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. 

Comment 10

[Mike Cowperthwaite]

*** Bug 286611 has been marked as a duplicate of this bug. ***

Comment 11

[Mike Cowperthwaite]

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).

Comment 12

[Ben Holt]

(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).

Comment 13

[Mike Cowperthwaite]

(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.

Comment 14

[Daniel Veditz [:dveditz]]

*** Bug 294034 has been marked as a duplicate of this bug. ***

Comment 15

[Asa Dotzler [:asa]]

Scott, can you take a look at this? 

Comment 16

[Jesse Ruderman]

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

Comment 17

[Mike Cowperthwaite]

*** Bug 301669 has been marked as a duplicate of this bug. ***

Comment 18

[Jeff Flowers]

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

[Tom Metro]

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.

Comment 20

[Daniel Veditz [:dveditz]]

*** Bug 317495 has been marked as a duplicate of this bug. ***

Comment 21

[k b]

this is still happening with thunderbird 1.5 rc1 on linux.

Comment 22

[zug_treno]

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

Comment 23

[webograph]

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

[Jerry Baker]

*** Bug 334693 has been marked as a duplicate of this bug. ***

Comment 25

[Daniel Veditz [:dveditz]]

*** Bug 335132 has been marked as a duplicate of this bug. ***

Comment 26

[Daniel Veditz [:dveditz]]

*** Bug 335641 has been marked as a duplicate of this bug. ***

Comment 27

[Daniel Veditz [:dveditz]]

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

Comment 28

[Scott MacGregor]

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

Comment 29

[Jesse Ruderman]

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

[Mattias]

(In reply to comment #29)

Brilliant! (sorry for the bugspam but that's a very good idea)

Comment 31

[Mike Cowperthwaite]

(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?).

Comment 32

[Scott MacGregor]

Bug 330443 fixed the original issue reported here and that fix landed on the branch.

Comment 33

[Daniel Veditz [:dveditz]]

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.

Comment 35

[Daniel Veditz [:dveditz]]

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

Comment 36

[Boris Zbarsky [:bzbarsky]]

Have we offered Tb2 to those users through automatic update yet?

Comment 37

[Daniel Veditz [:dveditz]]

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

Comment 39

[Dr B W Darvell]

Gosh - this is old! But the problem is still present in 91.3: blocked content is loaded in a forwarded message, violating the "to protect your privacy" policy. This seems to me to be very unfortunate, since if spam is being reported vital information has been conveyed to the spammers.
Clearly this does not derves the RESOLVED FIXED status.