16964 - protecting email address from spammers

Status: VERIFIED FIXED

(MailNews Core :: Security, enhancement, P3)

Description

[ron ralston]

I use Communicator 4.7 as both my browser and email tool.  This turns out
to be an extremely bad idea because of the ability of the browser to provide my
email address to any web server which requests it.

After having clicked on a couple of innocent looking mp3 links which turned out
to be porno sites, my inbox is now regularly loaded with porno spam which no
amount of inbox filtering seems to be able to eliminate.

I strongly suggest that an option button be provided under "preferences", "mail
& newsgroups", "identity" which could block the browser from transmitting the
information to a web server unless authorized to do so.  Such an option button
should probably offer the choices of "send my email address whenever asked and
don't bother to tell me", "tell me that the server has asked for my email
address and ask my permission to send it", and "never send it and don't bother
to tell me".  I'd select the last option myself.

If Communicator already has some mechanism which provides this functionality and
I'm just not aware of it, I'd appreciate knowing what it is.

Thanks

Comment 1

[jefft]

Ron, thanks much for suggestion. I'll look into the problem. Accepting...

Comment 2

[Sean Richardson]

Not sure about *web* servers, but NN 4.7 does have a preference under
"Advanced" that may be relevant: "Send my e-mail address as anonymous
FTP password". The same preference exists in the current build of Mozilla,
although whether it does anything yet or not is an open question.

I wouldn't put it beyond the bait-and-switch artists to send one of their gifs
with an <IMG SRC="ftp://... URL.

Some legit public FTP sites do want your e-mail address as the "password",
so there is always the problem of, after switching the preference off,
needing to turn it on to do a download, and then forgetting to turn it off
again.

Addressing this in a separate RFE, bug 17661.

Comment 3

[Phil Peterson]

Ron, it would be helpful to know what technology you believe was used to obtain
your email address. We don't send the email address to a web server.

The only way I can imagine doing this is with the cookie trick: a malicious
spammer sends you email with an HTTP link which, when you click on it, deposits
a unique cookie onto your machine. Since they already know your email address,
they can now tell that you've read their message, and direct web-based
advertising at you.

Is this what happened, or are you describing a different attack?

Comment 4

[jefft]

M14... I don't have a reproducible case.

Comment 5

[jefft]

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

Comment 6

[Phil Peterson]

Not holding B1 for this. If the problem is as I described earlier, then what we
need is a way to disable cookies only for incoming mail/news messages. Norris or
morse?

Comment 7

[Stephen P. Morse]

This is a well-known problem.  An ad site (read this as "doubleclick") sets a 
cookie when you browse the web.  Later you read spam e-mail.  The e-mail is html 
and it has a link to an image on doubleclick.  Doubleclick then gets to read and 
modify the cookie that it previously set.  Furthermore, the link to the image 
can be customized for each recipient that the mail is sent to so that it 
contains a query string with the recipients e-mail address (they know your e-mal 
address since they sent you this spam).  So now double-click can plop your 
e-mail address into its cookie.  The next time you browse to a 
double-click-partnered site, they will know your e-mail address.

We already have protection against this.  The solution that we advocated was to 
set the dont-accept-foreign-cookies pref to true.  That will block images in 
e-mail from setting cookies.  However if the ad site had previously set a 
cookie, that cookie will be read and transmitted back to the site when you read 
your e-mail.  So this solved only part of the problem in 4.7

As a result of that firedrill, I implemented the foreign-cookie pref in 
seamonkey so that it blocks both the setting and getting of cookies.  So we have 
full protection in seamonkey whereas we have only partial protection in 4.7.

From my perspective, you can probably close out this bug as fixed, based on my 
implementation of the foreign-cookie pref in seamonkey.

Comment 8

[jefft]

Marking it as fixed as suggested by morse. morse has implemented a way to
disable setting & getting cookies.

Comment 9

[Greg Sabino Mullane]

>The next time you browse to a double-click-partnered site, 
>they will know your e-mail address.

Small correction: Double-click will know it, but there is no general 
method for site X to get it, even if they have a doubleclick 
banner. Not that doubleclick will have any hesitation about 
selling their database, of course. :(

Comment 10

[Stephen P. Morse]

If you have the no-foreign-cookie pref set, then neither doubleclick nor its 
partners can associate your e-mail address with a tag that was planted when you 
browsed to the site.  If you disagree, give me a scenario.

Comment 11

[leger]

Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.

Comment 12

[John Unruh]

Verified fixed as suggested by morse.