Closed Bug 239954 Opened 20 years ago Closed 20 years ago

Block loading of remote images lets TD backgrounds through

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: lp, Assigned: mscott)

References

Details

Attachments

(1 file)

An .eml-File demonstrating the bug.
979 bytes, message/rfc822
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040404 Firefox/0.8.0+ (mmoy-O2-GL7-SSE2-crc32-gifalloc)
Build Identifier: Mozilla Thunderbird 0.5+ (20040330) (swalker)

I just noticed today on two separate emails that TD's with the background
attribute loads remote images even if you've set it in preferences not to.
An offending line in the HTML mail looks like so in a Bioware newsletter:

<td width="460" colspan="3"
background="http://nsl.bioware.com/bc12/communitybar.jpg"
style="background-image: url(http://nsl.bioware.com/bc12/communitybar.jpg);
width: 460px; height: 32px; padding: 0 15px 5px 15px;">

Hope it helps :)

Reproducible: Always
Steps to Reproduce:




I'm setting it as Major because spammers could use it for web beacons...
I can confirm this happens with the latest RC build of Thunderbird 0.6. It is
always reproducable by e-mailing yourself with the following HTML in your message:

<p style="background: transparent url(http://anyurl.com/image.gif) repeat-x
scroll 0%; -moz-background-clip: initial; -moz-background-origin: initial;
-moz-background-inline-policy: initial;">This uses the URL for a background
image even when Block Remote images is enabled.</p>
There's the same flaw on the BODY tag of the message.
For example,
<BODY background="http://server.com/image.gif">
gets loaded even though it should be blocked.

same result with something like :

<style type="text/css">
body {
background: url(http://some.site/some.image);
}
</style>
I am noticing the same thing, but this time its the table element who's
background is set, such as in the following:

<table background="http://www.abcxyz.def/image.png">

(thunderbird version 0.6)
I can confirm this bug for Thunderbird 0.7.1.
Obviously, the developers did not consider the (deprecated)
background-attribute of several HTML-elements and the possibilty to define
background images within style sheets respectively within the style-attribute.

As a temorary workaround, I have exclusively allowed these ports for
Thunderbird in my firewall:
SMTP:	25
IMAP4: 143 (using TLS/SSL): 993
POP3:  110 (using TLS/SSL): 995

I have attached an .eml-file which demonstrates the possibility to load
external images by using the background-attribute inside the body-element and
by using the style-attribute.
You can import the .eml-file into Thunderbird by using this extension:
http://www.supportware.net/mozilla/#ext9
Confirm this bug still exists in Thunderbird version 0.7.3 (20040803). 
Background images should be blocked just like <img> images.
*** Bug 250735 has been marked as a duplicate of this bug. ***
Confirming with a recent branch tree from CVS.
When I look at attachment 154152 [details], I see the flowers. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
The bug seems to be resolved with the release of TB 0.8.
At least my demonstation file won't display any background images anymore.
Great work. Thanks a lot.

Yours,
Michael
Thunderbird 0.9+ 20041105

I think this a problem with styles. I have tried to do the same with a
background style:

"background: white url(http://site/picture.gif) fixed no-repeat right bottom"

and removed the explicit background image path. After that the image was not 
attached to the email and it was shown even when image downloading is disabled. 

So there are two problems:
1. Style urls are not blocked.
2. Images referenced in styles are not attached to the message and their urls
are not updated.
Depends on: ImgInMail
Attachment #154152 - Attachment mime type: text/plain → message/rfc822
I no longer see this on TB 1.0
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: