223421 - Messages with images whose URLs contain the email address should be marked as Junk

Status: RESOLVED EXPIRED

(MailNews Core :: Filters, defect)

Description

[lev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

MailNews/Thunderbird sometimes fails to filter a junk message, even with
adaptive filters enabled, which causes it to display all the remote images in
that message as though the message was a "valid" one. This causes an HTTP
request to the remote server, and if the image URL includes the recepient's
email address, the address is "confirmed" working, resulting in more spam being
sent to the account.

There is no legitimate reason why an image URL in a message should contain the
email address of the recepient. Such a message is either spam, or an invasion of
privacy.

I suggest allowing users to auto-mark these messages as Junk, or at least to
"sterilize" the URLs by removing the email address from it.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note that we already disallow loading remote images in mailnews...

Comment 2

[lev]

Yes, but turning them off altogether is a far less user friendly option. I would
think that the goal is to show benign images as normal, while not displaying, or
at least sterilizing the ones that will open you up for future spamming.

Comment 3

[Hermann Schwab]

... "sterilize" the URLs by removing the email address from it

That´s only "half the rent", as germans say.
I´m sometimes looking at the HTML source of my spam, offline, and I had only one
with my email address in the image URL. Also rare is a webbug, 1x1 pixel.
But there are more often images with very long random looking URLS, and I
suspect that my mail address is encoded there. They could even encode my address
in a really short way: Assign numbers to the biggest providers, and they can
encode [e-mail] to hhschwab123 and encode that with an simple xor to
something like sth8fhrti74, and if I wouldn´t suspect this I´ll never know that
this was my address.
So fixing this bug gives false security to people, thinking: if my address is
seen, the image is blocked, if it isn´t blocked automatically, I can view it.
There is absolutely no way to protect your email address other than disallowing
remote connects.
The only option I see is allowing images from the originating server of a
whitelist of your buddys.
<paranoid mode: extreme> what happen´s, if this images url gets redirected?
</paranoid>
Imho this bug only makes sense to block images allowed by a whitelist, but I´m
not so paranoid to think my whitelist should be overriden by a computer.
O.K, I´m so paranoid to not accept HTML mail, people can attach, or send links.
Sanitizing by excluding some HTML tags is fine, but this fix wouldn´t improve
privacy, as only the dumbest of the spammers are using this trick.
Propagating this as an enhancement of security will give some people a false
impression of being secure.

Comment 4

[Matti]

Just popped in while searching for another bug which allows loading of images
even with image loading turned off :(
I often see crafted image urls but searching for the email wouldn't help at all
since a spammer is able to mask it as he wishes...
Of course it's easy to do it like
http://www.spammer.com/[e-mail]
but it's also easy like
http://www.spammer.com/pic_your..email.com.jpg
or even
http://www.spammer.com/pic_email.com..your.jpg
or (also quite often) just insert an ID and do a DB-Lookup afterwards.....
That would be less than a drop of water on lava unfortunately... turn off
loading of images completely, that will help the most!

Matt

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.