Closed Bug 28327 (ImgInMail) Opened 25 years ago Closed 19 years ago

No server hits at HTML mailnews reading - privacy (disable remote content/web-bugs)

Categories

(MailNews Core :: Security, defect, P3)

Product:
MailNews Core
Component:
Security
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: BenB, Assigned: mscott)

References

(Blocks 2 open bugs)

Details

(Keywords: fixed-aviary1.0, helpwanted, privacy, Whiteboard: [need info])

Attachments

(4 files)

Evaluations mail settings..
20.44 KB, image/jpeg
Details
html stripping in Mail.app
151.24 KB, image/jpeg
Details
Information tracked when reading a mail with remote contents.
18.66 KB, text/html
Details
the fix
697 bytes, patch
Details | Diff | Splinter Review 
Spammers may insert and invisible IMG tag into a HTML mail page, which loads an
URL, which contains information about the recipient, e.g. allows to tracking
reading of msgs. This is a privacy issue.

It's especially bad together with bug #22994, but not limited to it.
Should better be implemented as pref (with default=no hits?), as there may be
legal applications in an intranet.
Summary: No server hits for at mailnews reading → No server hits at mailnews reading
What, you mean you don't like receiving a webpage by e-mail! :-(

By blocking images in e-mail (which is what this report is advocating), you will 
lose that ability.  In essense, you will be destroying the browser's 
file/send-page command.

webpages by e-mail should be sent using multipart/related.  Or one should send a 
link and have the user click on the link.
Summary: No server hits at mailnews reading → No server hits at mailnews HTML reading
Summary: No server hits at mailnews HTML reading → No server hits at mailnews HTML reading - privacy
Agreed, "Send page" should include images in the mail - otherwise I loose the
ability to read my mail offline.

I think *any* URL can be abused this way. I doubt it's safe to assume that any
network connection initiated from mail is secure and/or private.
The "HTML" I put in the summary is meant to refer to the type of mail containing 
the URL.  I'm trying to make this bug visible to people searching for issues with 
HTML mail.
Summary: No server hits at mailnews HTML reading - privacy → No server hits at HTML mailnews reading - privacy
I believe that there is widespread support outside of Netscape for preventing 
the mail client from making any network connection whatsoever except to the mail 
server. Another way to picture this is just an automatic way of toggling 
online/offline when switching from browser to mail. For some reason Netscape and 
Mozilla are fiercely resistant to this idea, but I haven't heard anyone outside 
of Netscape voice any opposition.
> Another way to picture this is just an automatic way of toggling 
> online/offline when switching from browser to mail.

No, this is a violation of multitasking. Statisically, mails are the second
largest "out-of-band" source for URLs.

All I want is to disable network traffic (other than to the mail server) caused
by mail reading *itself*.

Otherwise, we can disable URL recognition as well.
That is what I meant, I just left out the *itself* part. I should've been a 
little clearer.
I feel this should ultimately be performed by a bug #7380 type arrangement,
which prompts by default.  The prompts should give a note about spammers, and
would allow the user to remember decisions globally, on a site-by-site,
URL-by-URL, etc. basis.
7380 proposes an extremely complex UI, which will be hard to understand and be 
prone to error.  A usable mail reader should not have modal dialog boxes popping 
up in response to viewing a message.

Configurability is no excuse for poor defaults.

Bug 28612 (META refresh allowed in mail/news) is a related bug.
Status: NEW → ASSIGNED
Target Milestone: M15
Bulk moving all MailNews Security bugs to new Security: General component.  The 
previous Security component for MailNews will be deleted.
Component: Security → Security: General
> I believe that there is widespread support outside of Netscape for preventing 
> the mail client from making any network connection whatsoever except to the 
> mail server.

I'd be interested to know more about this. Could you provide the names of some 
products which do this?
There aren't. I am assuming that Mozilla is trying to be conservative here and 
figures no need to implement features not already done by someone else. If this 
is the case, I would like to make a preemptive comment: I hope Mozilla has not 
been reduced to a project seeking to combine features of other 
packages and offer no innovation of its own.
7380 is an essential feature for power users who don't want the defaults of
novices.  There are no sensible defaults.

The dialogs are there to make it easier for novices to choose which sites they
trust using 7380 - letting the user specify who to trust is the only way to
properly address this.  Sure, dialogs are invasive, I'm open to better ideas.
That is only half a fair comment Jerry, as Mozilla is still behind other
products (eg Nav 4) in some areas.  Hence it is best to catch up before trying
to pass.  In this circumstance, however, the new feature is more important than
many of the old ones.
I think, this is a MUST for final. beta2 nomination.
Keywords: beta2
bulk move to M16. Not an M15 stopper.  If you disagree, pls comment in bug and 
cc: selmer@netscape.com
Target Milestone: M15 → M16
Keywords: nsbeta2
This bug is a subset of bug 36484.
Keywords: beta2
norris, any comments or insights to help here.  A feature request, thoughts for 
PR2.
Whiteboard: [NEED INFO]
I agreeed with jgmyers that webpages need to be sent as multipart/related 
message. This requires a fair amount of work. However, there is no guarantee 
that other mail clients will do the same. Using a pref with default value set to 
"no" seems to be the right way to go. I believe Steve has done the work. Steve?
The work I've done is to block images from selected sites.  As you browse, you 
will encounter offending images that you can right-click on and add to the list 
of sites from which you want images blocked.  Then when you read a mail message 
and it contains an image from that site, the image is not loaded.
Removing the [NEED INFO] for PDT re-eval.
Whiteboard: [NEED INFO]
Blocking images does not at all fix this. An offensive sender, knowing that
images can be blocked, can include an external applet, stylesheet or whatever to
get the server hit.
Putting on [nsbeta2-] radar. Not critical to beta2.  But adding nsbeta3 keyword 
for a fix prior to PR3.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
Depends on: 37983
Changed QA Contact to czhang@netscape.com
QA Contact: lchiang → czhang
As noted earlier, blocking images (and cookies) from a site doesn't help until 
after the fact, and any object that can be loaded from a remote server can act 
as an involuntary return receipt. All that is needed is to throw in a unique 
identifier somewhere like a query string then parse the server logs for it. For 
example, a CSS object, though this can be done to images, HTML files, audio 
files, etc.:

http://server.domain.com/dir/stylesheet.css?UniqueID=victimsusername%40domain.co
m%20isValidEmail

The query string does not in fact run a query, and does not affect the loading 
of the object. But it is logged by the server and thus can easily be examined 
later. This is a great way for spammers to confirm a valid address they've sent 
to, because this way they can ignore the bounced e-mails by falsifying their 
From: headers and still build a database of known good e-mail addresses by 
running web server log reports on the query string. (This all is exactly the 
method reported in bug 22994, just applied more broadly.)

There is only one way to fix this, and that is to provide an option to disable 
all network calls from the mail/news client. The option to disable cookies and 
images on a site-by-site basis is great, but too little too late for someone 
targeted with this type of attack.
The concerns expressed about Mozilla working with Web pages that have been 
mailed are red herrings at best. Mozilla should not emulate Netscape 4.X's 
behavior of only sending the HTML and not the images and associated objects with 
the page. IE sends everything, and Mozilla should too. This also eliminates the 
need to allow any network activity from mail and news except for to mail servers 
specified in the prefs.

I have a feeling that I share the opinion of many readers in that if I want to 
visit a site, I will either go there myself, or click on a link to it.
Whilst sharing sharing the concerns I have two comments:

1) I used to run a genuine, opt-in HTML email newsletter through the Netscape 
Inbox direct program. It was about financial markets and contained references to 
 graphics on the server for two reasons:
a) Graphics that were used every day remained in the browser cache and saved 
unnecessary network traffic and download times
b) a stop-press graphic could alert users to any major change since the mail was 
sent.
You may ask why not go to a web page, but our site statistics showed that there 
were users that liked receiving the information this way - their choice, 
supported by Netscape.
2) Is there evidence that nefarious receipt function is taking place? Does it 
matter - once a spammer has your address, that address has had it anyway and 
will be passed around with no evidence of it working. If this leads to 
non-working addresses being removed so much the better for network traffic and 
mail server administrators of dead accounts.

3) The challenge when addressing issues such as this one is that many, many 
users do not change their preferences so how does the default get set - to block 
these images or not?

The nefarious receipt function has indeed been used by a well known vendor of 
personal finance and income tax software.  They include a tagged URL to a 1x1 
transparent GIF.

The default should be privacy.

The user expectation is that correspondants will not know when they read email, 

unless an explicit "read receipt" is approved.  Thus the default must be either 

full privacy, or "ask the user".


Can this not be fixed with the new content policy hooks?  (I'm not sure if the
DOM can let us figure out that we're loaded in a mail context, if not we can
figure something out.)
Severity: normal → major
Keywords: mail4
Target Milestone: M17 → M18
Thanks for increasing importance of this bug (nsbeta3 and mail4 nomination,
severity major). I'll spend a round of donuts for the Mailnews team, if you fix
this before release :).

> > preventing 
>> I believe that there is widespread support outside of Netscape for preventing
>> the mail client from making any network connection whatsoever except to the 
>> mail server.
> Could you provide the names of some products which do this?

While Jerry propably referred to customers' support, there are indeed a lot of
clients honoring this kind of privacy: plaintext UAs :). (Indeed, I think, some
amount of plaintext mailer users chose these clients because of security and
privacy concerns.)
Hell, I'll pitch in a case of beer to the developer that does this :) Seriously
Whiteboard: [nsbeta2-] → [nsbeta2-][b3 need info]
What info is needed to make a b3 +/- decision?
Whiteboard: [nsbeta2-][b3 need info] → [nsbeta2-]
- per mail triage.  Behavior is the similar to Communicator 4.x.
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
> - per mail triage

No donuts.

> Behavior is the similar to Communicator 4.x.

...which was a privacy thread.
<rant>
I don't think, we will win many users, if our bugs are a superset of those in
4.x.
</rant>


being a bit more constructive: Adding helpwanted and filing bug 49021 for a
(hackish) workaround.
Keywords: helpwanted
Hmm, Microsoft just got harpooned in the New York Times for this exact issue. See
http://www.nytimes.com/cnet/CNET_0_4_2652562_00.html .
What's our exposure? CCing ekrock.

If I understand this correctly, Navigator 4 Mail also had this issue, right? Our 
minimal security goal for RTM is to be *as* secure as Navigator 4. Being more 
secure is of course desirable, but that's an enhancement request, and the time 
for implementing enhancements has long since passed.

This is really a question of Mail security policy, so I'm cc:ing sol. I note 
that someone has already marked this [nsbeta3-]. If Nav4 Mail indeed had the 
same issue, I agree and recommend Future as well.
Yes, this has been this way since HTML mail made its way into Netscape 2.x

- rhp
I am curious why the goal of Mozilla and Netscape is only to maintain parity 
with NN4 in terms of security. Why not just keep the parity with CSS compliance 
and HTML too?
Thats not the goal. The goal is to always exceed previous products and be 100% 
standards compliant, but if you want to ship a product in any of our lifetimes, 
you come to a point where stuff has to be cut. We are at that point.

- rhp
And security was nominated for weeding out. Can outside contributors make a vote 
of no-confidence in the body responsible for this decision. It is quite 
illuminating about Netscape's prioroties however. AIM must work - 
privacy...screw it.
If you want to be sarcastic and negative, that's your choice. I was just trying 
to provide some information on this issue. 

Sorry I tried to take part in the process.

- rhp
It's not personal. My view is what good is a CSS compliant browser if it chugs 
along spewing personal information and violating my privacy? 

Netscape has never taken security very seriously unless someone turns on the 
light of the media and then Netscape scrambles to look "concerned". I am not 
saying that there are not individuals at the company that are concerned, but 
that the company overall doesn't care until there is some serious negative 
publicity. That is what is wrong here - that security is almost =always= put on 
the back burner for other things that are not even half as important except to 
drooling marketing droids.
PDT should have the following goal:
Prevent Netscape 6 from receiving bad press for things where microsoft has 
already received bad press.

Shaver could you please direct this concern to someone who can affect policy. 
Or commment otherwise? Thank you.
Presumably you can read mail off-line if you are worried about this kind of 
thing. Worked for me in 4.x, that might be a good enough answer for now.

ekrock: doing things the same as 4.x may not be good enough; the world has 
changed. two years ago only the hair-shirt prophets in the wilderness were 
complaining about privacy, now it's a big issue that has attracted lots of 
press and lawsuits.

jerrybaker: you are an idiot if you think we haven't taken security seriously. 
Your hair would curl if you knew some of the potential attacks that have been 
discovered and fixed in Mozilla. It's certainly too bad we didn't get to do a 
privacy enhancement like this, but it's not a true security issue.

Meanwhile, we have a cookie manager and an image blocker (both useful in this 
situation), both of which are significant privacy enhancements over 4.x. As 
long as we don't regress privacy in other areas (and this isn't worse) I'd say 
we're making forward progress.
What's a "hair-shirt prophet"?
perhaps an over-contraction on my part of "hair-shirt wearing, locust-eating 
prophet", i.e. all those biblical dudes who didn't get much respect yet were 
nonetheless proved utterly right in the end.

Maybe I should have gone with "Kassandra" instead.
("Kassandra" with a K is inauthentic spelling of the Trojan seer's name,
although that phrase is a line from the movie "Warlock"!)

Also, jerrybaker shouldn't be faulted for not seeing certain bugs where Mozilla
has sweated security attacks devised by folks like Georgi Gunninski, because
netscape.com chose to make those bugs Netscape-confidential in bugzilla.  I
still think many to most of those bugs should be wide-open, certainly now that
we are past beta2.

/be

/be
Jerry, please don't assume that some overworked Netscape engineers'
de-prioritizing this particular issue, which is obviously a pet peeve issue for
you, reflects anything about Netscape's commitment to security. It's not that we
don't care until exploits hit the press, it's that you only hear about it when
it does hit the press. Anyway, that's why we're open source; if something really
bugs you, either fix it or find someone (not necessarily at Netscape) who's
interested in fixing it.
Kassandra with a "k" is a perfectly fine spelling, used, for example, by 
Richmond Lattimore is his Illiad. (He did go with the latinized Cassandra in 
his translation of Aeschylus's "Agamemnon" published around the same time, 
though.)
Lattimore, eh?  I'm old school (or maybe old-new school), I was raised on 
Cassandra with a C.

Is this bug long enough yet?  More to the point, is anyone going to cough up a 
patch that I can approve?  Who is up to the coding task?

/be
The reason this is a "pet peeve" of mine is because this one issue represents 
one of the largest and possibly most insidious security holes excepting viruses 
or other things that cause physical damage. Being able to tie a user by email 
address to visited Web sites because the Mozilla team doesn't feel it important 
is literally a tragedy. Can we at least get Mozilla to come by default with 
images blocked from all sites known to exercise this behavior?
From what I can tell, the following are =known= to have used Web bugs in email 
marketing campaigns:

Barnes and Noble 
eToys
Cooking.com 
Microsoft 
InfoBeat 
Alright, I'm going to make this bug a little longer: I wish jerrybaker at least
would stop using "the Mozilla Team" to mean netscape.com, a business with scarce
resources it disposes as it sees fit, and (in opposition), the royal "we", at
least himself.

The Mozilla community contains lots of people capable of hacking a fix here.  I
am cc'ing a few.  Complaining about netscape.com is fine; maybe it will change
the PDT's mind.  But producing a patch, or a partial patch even, is better. 
There is no Mozilla Team preventing that.  Why not talk this bug up in the
newsgroups with an appeal to get a patch cobbled together?

A patch to filter HTTP accesses from inline images in HTML mail would be a
start. It shouldn't hardwire evil domain names.  How should it then access a
configurable, possibly shared list of domains?

/be
I do not want to get the two confused, but the lines between what is mozilla.org 
and what is Netscape are =very= blurry (not just in this bug).
The line between security and privacy is very confused in this bug.
> A patch to filter HTTP accesses from inline images in HTML mail would be a
> start

This is what bug 49021 is about.
> The line between security and privacy is very confused in this bug.

Actually not. There are two things going on here. One is that invisibile images 
can be inserted into email sent to me in order to log when I read my mail - this 
is a privacy issue. The second thing is that a cookie can be set with this image 
in order to associate that cookie with an email address - this is a security 
hole.
I'm with Steve: I don't see how setting a cookie is a security issue.  I'd say
it's a privacy risk, and I spend a fair amount of time thinking about this sort
of thing.  (Modulo implementation bugs like buffer overflows in the cookie
handling, but those are risks for all content.)

As far as not allowing external content to be loaded from mail, I don't see why
the content-policy hooks aren't sufficient.  Can't you use them to poke up the
DOM chain and see if you're in a mail message, and then veto any inappropriate
URL load attempt?

Setting cookies is not a security issue. When people browse, they realise the 
context of their browsing. They are on the Web - the Web has cookies. Email 
present a different context. I don't think people would expect that cookies can 
be set by email messages to later be read while browsing the Web (which is the 
effect of this). Sure one could argue that email is in the same context as Web 
browsing since both are the "Internet", but then by that argument so is opening 
Word while online...oh wait.
Help me, jerry, I'm lost.

First you wrote:
> The second thing is that a cookie can be set with this image 
> in order to associate that cookie with an email address - this is a security 
> hole.
and then:
> Setting cookies is not a security issue.

I agree with your second personality, but not your first. =)

It's really easy:
Setting cookies in email: security problem
Setting cookies over Web: Fine

Regardless of Netscape's desire to integrate Web mail with email, email is an 
entirely different context than the Web.
Can you please explain the _security_ (not privacy -- that part is crystal clear
to everyone, I hope) implications for setting a cookie via email?  That part is
totally eluding me, and I consider myself a pretty savvy guy when it comes to
web-related security issues.

(Or, better: don't answer that question, and just write a patch to wield the
content-policy hammer against this particular nail.)



Jerry, you make me laugh.  Who at mozilla.org (not netscape.com now, please 
don't be insulting shaver@zeroknowledge.com, blizzard@redhat.com, 
hecker@collab.net, or brendan@meer.net by insinuating that we are controlled by 
netscape.com) ever was "fiercely resistant" to the right privacy-protecting 
defaults here, or elsewhere?  The mozilla.org folks beholden to netscape.com 
have never uttered a word on this topic.

"Help, help! I'm being repressed!"

This isn't some student protest exercise where talk is the main by-product 
because we're all oppressed by the system.  This is do-the-coding-yourself, 
put-up-or-shut-up open source.  There is no way mozilla.org can or should coerce 
netscape.com into fixing this bug if for whatever reason(s) netscape.com fails 
to see its priority.

How about helping out with implementations of shaver's general content-policy 
interface (bug 37983) instead of making this bug any longer, mmmkay?

/be
I'm glad to provide you with entertainment. If you think that privacy and 
security are funny, then there is probably nothing I can do to change your mind. 
But, THIS IS NOT a put up or shut up system. You, and others, are coding a 
browser for the general public, but you don't want feedback from the general 
public. This is part of the problem that I have been making all this noise 
about.
> THIS IS NOT a put up or shut up system

This part of the world is exactly that. If you want to take on the corporate 
monolith, take it on through its front door, the marketing department and 
customer feedback. Going around the back and shouting at the engineers through 
the open-source door is, in my opinion, somewhat rude.
I'm fine with that then. I will file a bug on Bugzilla to get the Bugzilla bug 
pages to add, "If you do not intend to code a solution to a problem you have 
found, do not report it to us. We are not interested". Is that wording OK?
> I'm glad to provide you with entertainment. If you think that privacy and 
> security are funny, then there is probably nothing I can do to change your 
> mind. 

Get off your high horse, Sir.

> But, THIS IS NOT a put up or shut up system.

No, that's exactly what open source is, and you are not putting up anything but 
noise.  I'm not the type to killfile irrational people, and even a broken clock 
is worth listening to twice a day.  So keep your feedback coming, but maybe in a 
better forum than this bug, eh?  And (for the last time) try to enlist some 
competent hackers to help fix the problem reported by this bug, please.  The 
existing pool of developers are pretty busy with their own priorities, and they 
are not mine to command.

> You, and others, are coding a browser for the general public, but you don't
> want feedback from the general public.

What are you talking about?  We want and get feedback all the time, including 
your vague, windy complaining.  Who says I have to like it, but I'm not stifling 
you, killfiling you, or kicking you out of bugzilla, nor would I or any staffer 
do such a bad thing.

If you think pdt@netscape.com is ignoring you, then why aren't you bothering 
them instead of us who read updates to this bug?

> This is part of the problem that I have been making all this noise about.

Oh brother, here we go again.  Have you no shame?  Stop whining!

/be
It should simply say
"Since you're not paying for this product, no-one is under any obligation to fix 
any problems you report, although we do try to. If you don't agree with our 
priorities, you can fix it yourself or you can try to persuade us (or our 
management) to change our priorities. Just don't get all whiny if you fail."

Over and out. You know where to find me :-).
Jerry, calm down. My guess is that Moz 1.0 (which luckily will be some time 
*after* N6) won't ship with this bug. N6 will propably ship with it, but well...
:).
Removed my vote, please move this discussion to the newsgroup(s) it's not 
helping anything here by driving votes away.

With jefft's permission, I'm reassigning this bug to myself.  Shaver and I are 
working on this bug, bug 18352, and probably bug 46859 in a concerted way that 
may result in patches soon enough to consider for Netscape 6 RTM.

/be
Assignee: jefft → brendan
Status: ASSIGNED → NEW
Setting target milestone to mozilla0.9.  Hoping to get something done much 
sooner, shaver and I welcome help.

/be
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla0.9
What does bug 46859 have to do with this bug? I hope, you don't intend to pop up
dialog for external msgs? Many msgs with web bugs also contain normal (visible)
external images, so an uninformed user would propably allow images to be loaded,
if asked.

How can I help?
Brendan, shaver,
  could you please define the fix you have in mind? I hope it doesn't involve
any new "security warining" type dialog boxes. How do you propose to solve this
problem?

Ben: bug 46859 has nothing to do with the solution to this bug, but it's part of 
the cleanup we think we'll do at the same time as we fix bug 18352.

Boy, you guys must think we fell off a turnip truck.  Shaver and I are 
even more averse to the "add yet another dialog in the naive user's face" 
theory of customization.

Shaver and I currently think we just need to extend the image blocking to block 
images loaded from mail messages, based on a domain name blacklist.  Everyone 
seems to agree that it'll be important to distinguish the mail case from the 
browsing case, so some extension seems required.  How to specify the blacklist? 
Prefs, with UI later comes to mind.

BenB, the first thing you could do to help is comment on this idea.  Also, help 
test the patches developed in the related or coinciding-in-code bugs that we're 
trying to fix.  Thanks,

/be
I still think you need the general case of block all external images since 
blocking from blacked out domains is fine so long as you know they smacked you 
with a webbug, since most user's won't know and by the time they do its too 
late.  I think the point at which to prune this tree is to identify local 
domains not bad domains, if an IMG tag refers to a domain outside the local 
domain list then its blocked otherwise its allowed.

This if you like is much the same as a blacklist, except its a whitelist which 
is much shorter and easier to manage.  It should also be slightly quicker in 
usage.  At the same time I'd use a different broken image icon to help the user 
identify (once they understood what the icon meant of course).

Can the image blocking feature be used to block other kinds of included content
(embeds, applets, iframes, etc)?

Personally, I don't see too much value in customizing the domains from which
image loading is allowed, especially not enough value to have UI for it.

Also, what mstoltz said. I would like to see an opt-in approach, i.e. one that
blocks *all* loading of external resources, even those that don't exist yet
(because somebody might add a feature like external stylesheets to layout and
not think of the "content" loading policy), unless specifically allowed. Because
of that, nsIContentPolicy seems more appropriate to me than the image blocker.

Do you intend to merge the current image blocking code/interfaces and
|nsIContentPolicy|?
I'm in the process of adding a security call,
nsScriptSecurityManager::CheckLoadURI everywhere an URL is loaded by web
content. This seems related. Could the policy be implemented there? This would
(in theory) cover all secondary loads, not just images.

Is there no way to add this is a more central place, e.g. netwerk, or don't we
have enough information (e.g. about the initiator) at this point?
Umm well its considerably more secure to enable such off-network images than to 
disable.  That way if you have an electronic magazine mailed to you with 
legitimate images you can enable it.  
Just my idea, but since I don't know anything about how necko works, take it for 
what it is.

Can Mozilla just be told not to load any requests for external resources that 
originate from a mail window (maybe before the URI even makes it to Necko?)? 
Since JavaScript can be disabled in mail&news separately from the browser, it 
seems to me like the parser knows when it is in a mail or news window and when 
it isn't. Couldn't the parser just be told to ignore requests for external 
resources that originate in a mail (or news?) window?
We could do what jerrybaker describes using CheckLoadURI. This will stop the
load before it ever gets to Necko, if used properly.

that adds an overhead to every CheckURI to check the origin, I looked at that 
it looked very expensive
> That way if you have an electronic magazine mailed to you with legitimate 
> images you can enable it.

Althought that argument is frequently made, I can't see any real justification. 
The user is going to have to download the images whether that occurs when the 
mail is downloaded, or when the images are loaded when the mail is opened. The 
only edge case where a valid argument might be made is when the external link is 
to a dynamic image that conveys some sort of time sensitive information.
> that adds an overhead to every CheckURI to check the origin, I looked at that 
> it looked very expensive

So I take it that the parser does not know when it is parsing mail content vs. 
browser content? If it does, why do you need to check the URI at all? Just 
refuse it flat out.
slucy: we could have a whitelist or a blacklist.  It isn't hard to do both.  We 
could even allow subdomains to be blacklisted from a superdomain that passes the 
whitelist.  If there is no whitelist, only the blacklist applies.  How does this 
sound?

BenB: you wrote "Do you intend to merge the current image blocking 
code/interfaces and |nsIContentPolicy|?"  Yes, although not all at once, and not 
in a way that makes it hard to get a patch fixing this bug into the Netscape 6 
branch.  Note that nsIContentPolicy is interface only, so we need to write new 
code, or morph old code, to implement the new interface.

mstoltz: if you haven't yet, please check out nsIContentPolicy, shaver already 
went to the trouble to add uses of it when loading several kinds of elements.  
See http://lxr.mozilla.org/mozilla/search?string=nsIContentPolicy and let's 
talk.  It seems shaver intentionally added the nsIContentPolicy check after the 
nsIScriptSecurityManager one in places where both are needed, to let security 
mechanism have first crack.  I think that's right -- privacy policy should not 
go through the script security manager.  Thoughts?

Jerry: nsIContentPolicy is used to stop loads in layout code from ever reaching 
Necko.

/be
> I think that's right -- privacy policy should not 
> go through the script security manager.  Thoughts?

It seems to me that you need the privacy check whereever you need the security
check |nsScriptSecurityManager::CheckLoadURI|. So, if you want to keep a privacy
and a security interface, then add a new one, covering both pirvacy and
security, which is called where |nsScriptSecurityManager::CheckLoadURI| is
called now, and its implementation then calls
|nsScriptSecurityManager::CheckLoadURI| and you privacy interface.
Should we move this discussion to bug 18352 or even the newsgroup?
Ben: let's move the design discussion to bug 18352, if not to a newsgroup.  The 
current nsIScriptSecurityManager interface can't express the "shouldLoad" and 
"shouldProcess" results that nsIContentPolicy can, which (if false) lead to no 
failure codes (unlike nsIScriptSecurityManager, which can only fail the check). 
The CheckLoadURI method also doesn't take an enumerated typecode indicating what 
kind of URI load or processing is about to happen.

Mitch: can you update bug 18352 with the places beyond 
http://lxr.mozilla.org/mozilla/ident?i=CheckLoadURI where you intend to add 
calls to the security manager?

/be
agreed on the whitelist and blacklist, I was thinking of other privacy apps 
when considering that, its a well known concept so it shouldn't be difficult to 
get across or produce a UI for.
jerry: I think the point is that some people want images delivered and you 
can't militate for website/email design only give them the best fit, starting 
with a whitelist of local domains implies no other domains would be used to 
deliver images (or other misused tags), and at the same time lets the user opt 
out by adding trusted sites.

and agreed it doesn't belong in script but if there's a ContentPolicy that can 
identify quickly without addrefs that its in email then that seems more than 
reasonable.

And this whole area seems to need a newsgroup/list to itself :-)
slucy: nsScriptSecurityManager::CheckLoadURI doesn't look as cheap as one might 
like, but it will be called no matter what -- at least in any browser where the 
caps/src code is included.  And AddRef costs are the least of CheckLoadURI's 
costs.

I updated bug 18352 with a new comment.

/be
> jerry: I think the point is that some people want images delivered and you 
> can't militate for website/email design only give them the best fit

I can live with that, but can I make a quick point? 

Choice is always good, and taking away user's choice is always bad, under one 
condition - that the choice being taken away somehow causes a loss of usability 
or convenience. As I was saying before, whether a user downloads the images in a 
mail message (because they are all there with multipart/related) or whether they 
have to download them from some remote server when they open the message makes 
no difference to the end user. In fact, the email may be quite a bit faster as 
POP servers are usually not that far up the pipe from the user. I could 
understand hesistating to remove the ability to include remote content if there 
were not another way to add that content, but there is. The only reason that a 
mailer could be upset that they could not use remote content is because their 
mailer won't let them do multipart/related (rare), or because they want to make 
use of this privacy hole.
>I could understand hesistating to remove the ability to include remote content 
>if there were not another way to add that content, but there is. The only 
>reason that a mailer could be upset that they could not use remote content is 
>because their mailer won't let them do multipart/related (rare), or because 
>they want to make use of this privacy hole.

I'm confused, that's dealing with life the way it should be, not the way it 
is.  The user wants to receive, say, an HTML mag in his email and it contains 
images and tagged images and refresh meta tags and god knows what, plugins 
probably as well.  Since the user has no control over the designer of the page, 
and since its unlikely the senders of the mag want to have a different version 
for email or send every damn image to everyone at the time of mailing its 
pretty likely that the images aren't going to be sent.  That's perfectly 
valid.  I can't see how multipart related helps, but perhaps I'm thick :-)

Ok. One more comment :-)

All HTML mail readers that are capable of displaying a Web page in email are 
also capable of displaying multipart/related images, so that knocks down the 
objection that the mailer wants to be 'compatible" with all mail readers in some 
way or another.

Second, the mailer not wanting to send images with the mail (presumably because 
of bandwidth) doesn't hold much water after all. The recipient has to use their 
bandwidth to get the images off of their server anyway, what is the difference 
whether this bandwidth usage occurs at the time of mailing, or at the time of 
reading?

*All future discussion of this should probably be in n.p.m.security.
>what is the difference whether this bandwidth usage occurs at the time of 
>mailing, or at the time of reading?

There's a huge difference.  I get WebMonkey delivered in email, i probably 
don't bother looking at it more than once a month, it gets delivered to say 
5,000 (or 50,000 whatever), people they look at it when they see it, probably 
quite a majority within an hour, but its likely to be some kind of sine wave 
with time zones and the like.  If they send out every image (and advert), then 
their mail server grinds exceeding slow and so on downstream and take a hit 
regardless of when people read the content.  


Is 18352 the one you wanted to add to Brendan? That seems to be about the 
extensions directory.


Posted <news://news.mozilla.org/39DACD11.FD472602@bucksch.org> my reply to
.security.
nsIContentPolicy is about more than just privacy -- it's also for general
browsing prefs, like banner blocking and the like -- but I could see value in
unifying the hooks.  I don't think that we should unify them under the banner of
nsScriptSecurityManager, because people might want to control content policy
without our (unavoidably JS-biased) caps/ implementation, or for reasons other
than security.

(If we're going to discuss the mechanics in another bug, which seems sage, let's
leave poor 18352 alone and use 37983.)

Nominating for rtm.
Keywords: rtm
QA Contact: czhang → junruh
This is a problem in messenger as well as in mail/news.
Messenger == Mailnews!?!

oh, i meant netscape instant messenger.  sorry for the confusion.
As far as this Mozilla hacker is concerned, the problem with Netscape Instant
Messenger is that it's not open source, not that it has any specific privacy
characteristics.

shaver, AIM is similar to Mailnews in that you get content you didn't choose
yourself. I heard that AIM is a particular bad place for spam. Doesn't it
support HTML, too? If yes, you should protect it just as you protect Mailnews.
But, of course, this would have to be done by Netscape.
Keywords: mozilla1.0
Keywords: mozilla0.9
rtm-, we've already had the discussion and we're not doing this.  Without a 
patch attached, there's no chance anyway.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-][rtm-]
Sorry for the extra mail. Removing mail4 keyword.
Keywords: mail4
Not doing what?
If you mean blocking webbug type junk in email I thought it was underway, if 
you mean AIM that should really have a different bug
Keywords: privacy
Adding nsbeta1 keyword. This should either be fixed or marked Wontfix.
Keywords: nsbeta1
why does it need to be WONTFIX if it's not going to be fixed for a particular 
Netscape beta? In fact, it's not assigned to a Netscape person, which is a 
reasonable indication that a "nsbeta" marking is inappropriate or meaningless.

Clearly Netscape has no interest in this feature (if you're that paranoid you 
can turn off all images) but that doesn't mean it's not a good thing for 
mozilla folk to eventually add finer granularity to the image blocking.
QA > ckritzer
QA Contact: junruh → ckritzer
Servers can also be contected via Javascript (embedded in the mailnews msg)
loading images or automatically submitting forms. This will have to be covered, too.
Bug 60676, which looks like a duplicate of this bug, contains some UI suggestions
*** Bug 60676 has been marked as a duplicate of this bug. ***
Want a security issue on this bug? Try this in an email:

<img src="http://www.yahoo.com/+++ATH0.gif">

When this email is displayed on screens of some modem users, it will disconnect
their modem (should be obvious why). Sounds like denial-of-service to me,
admittedly a pretty minor one. Possible potential for making it e.g. dial a
premium-rate/international number, too, which I haven't tried and may well not
be doable, but if it is possible it could prove profitable via spam.

This is actually a bug in some Rockwell V90 modem firmware, as modems are
supposed to require a 1-second pause between +++ and AT. And even if it *wasn't*
a bug in the modem it would then be a bug in the TCP stack, not Mozilla.
However, even though it isn't a Mozilla bug as such, it is yet one more security
hole which 'allowing email do more or less anything it likes' is bound to provide.

(BTW I don't know what proportion of modems it affects; only tried three, two of
them - both cheap internal modems, one shipped with a Dell computer - were
affected, the other - a USR external - was not. It may not be a major problem,
or it may be.)

Anyway, just for information. Apologies if this is already well-known.

--sam
> Servers can also be contected via Javascript

That's why there is an "Enable JavaScript for Mail and News" preference.

An elaborate UI with per-site control would a be nice thing (I wouldn't think it
worthwhile for just this bug), but an "Enable Remote Content for Mail and News"
preference is essential.

I can't imagine anyone disabling the latter but not the former.


<img src="http://www.yahoo.com/+++ATH0.gif">
has _nothing_ to do w/ this bug, IMO it's a TCP stack bug however if you feel 
that we should do something about it, then you should file a bug in networking: 
http.
Keywords: nsbeta2, nsbeta3, rtm
Whiteboard: [nsbeta3-][nsbeta2-][rtm-]
Wow, chatting a modem with a URL, who'da thunk.

/be
Keywords: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Load-balancing.  Performance first, anyone who wants this and can fix it, please
feel free to take it.

/be
Keywords: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 86627 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I'm not going to get to this in the next milestone.  Help definitely wanted.

/be
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Brendan,
  How do you propose to solve this? It basically means going offline while we
parse and read mail, right?
It's part of the ContentPolicy plan. Obviously that has to be implemented 
first.
*** Bug 96062 has been marked as a duplicate of this bug. ***
It has been implemented in KMail, which is opensource, so one can have a look 
at how it's been done.

See this bugtraq post that mentions the option in KMail:
http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D1%
26start%3D2001-08-19%26fromthread%3D0%26threads%3D0%26mid%3D206015%26end%3D2001-
08-25%26


*** Bug 99616 has been marked as a duplicate of this bug. ***
*** Bug 99904 has been marked as a duplicate of this bug. ***
I still have no time for this -- does anyone?

/be
Keywords: mozilla0.9.2
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Blocks: 104166
See also bug 104802: it might be necessary to disable all plug-ins in the mail 
window (even ones in multipart messages) in addition to not loading images from 
the web.
*** Bug 104802 has been marked as a duplicate of this bug. ***
FYI: This is the HTML mail option in Evolution:

-- in HTML mails --
 ( ) Never load images off the net
 (o) Load images if sender is in addressbook
 ( ) Always load images off the net
'Load images if sender is in address book' could become useless if it interacts
with  the 'Collected Addresses' address book.
"Load images if sender is in address book" isn't very useful anyway.  All a 
spammer would have to do in order to make me load an image is know *one* 
address in my address book and spoof that address.  One easy guess would be the 
victim's own address, and additional guesses could be other addresses on the 
same page the victim's address was found on.
*** Bug 110432 has been marked as a duplicate of this bug. ***
my preference would be to bring the old NN4 button back (bug 55657), so I would
see the html attachment in the attachment plane and could open it as any other
attachment.
Footprint/perf works take precedence.  Reiterating helpwanted.

/be
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 111043 has been marked as a duplicate of this bug. ***
*** Bug 110720 has been marked as a duplicate of this bug. ***
*** Bug 114677 has been marked as a duplicate of this bug. ***
About Comment #31

[Newsletters: Loading graphics from server causes less traffic because graphics
are saved in cache]

One way to resolve this, is that even if you selected an option like "Do not
download images from a remote server while reading email" that can get an option
like "Download all images for this e-mail" with a checkbox "remember this option
for this recipient".
Or simpler, put a button somewhere (and keyboard shortcut) that loads the images
and other network stuff once you've glanced at a mail and decide it's OK.
*** Bug 118473 has been marked as a duplicate of this bug. ***
Dylan_G@bigfoot.com has stepped up (yay!).  Ben, I've taken the liberty of
making you QA Contact (ckritzer is long gone from netscape.com).

/be
Assignee: brendan → Dylan_G
Status: ASSIGNED → NEW
QA Contact: ckritzer → mozilla
Status: NEW → ASSIGNED
> Dylan_G@bigfoot.com has stepped up (yay!)

Great news. I would suggest Mac OS X's Mail.app as an emailer that gets it
right. Cf. attachment, which shows the same message (1) in Mozilla, and (2) in
Mail.app. 

In Mozilla, opening that message (merely by deleting the previous one!) caused
me to confirm my address for the spammer :-( , due to this tag in the HTML
source: <img
src="http://uweb.savingbot.com/chkmailview.php?to=hysterion@mac.com&title=SavingBot_20020125">

 
In Mail.app, you can prevent this by leaving the pref "Download all images,
animations, and other HTML attachments" unchecked. And still the general layout
is rendered with all elements in evidence, including that pesky
"chkmailview.php". (On top of that, also pictured is a button to *bounce*
unwanted mail, but I guess that's another RFE.)

I also agree with comment #146, that a button to override that pref on a
message-by-message basis would be great.
Well, here is my plan (which is being hampered by me being unable to build
Mozilla consistenly currently):  I need to trace down where gekco is involved
and have a pref checked to see if the HTML should be ignored (just use default
rulesets, or some ASCII convert).  Once I familiarize myself with Gecko's core
more, I want to adda  pref for "sandboxed" HTML email (only MIME encoded images
are loaded: nothing else).  So you can default to unsafe, sandboxed, or paranoid.

I just have to find where this code path is :)
An alternative to stripping HTML would be to just stick a new content-policy
object in the chain when this pref is set, and that object can refuse to load
all content with a protocol that isn't the same as the enclosing document.  (I
think that's a _better_ alternative too, for a whole variety of reasons.)

You can look at the image manager's code for an example of content policy
objects and how to deal with them.  We might need to teach the content policy
service a better way to handle dynamic registration of objects -- I can't
remember if I ever got to that --  than category poking, but that's easy.  (I
volunteer, even!)
> I need to trace down where gekco is involved
> and have a pref checked to see if the HTML should be ignored (just use default
> rulesets, or some ASCII convert).

That would be bug 30888, I guess. It wouldn't fix this bug, just provide an
alternative for people already knowing about the problem.
Cool, thanks for the help, Mike :)  I'll start trying to grok that part of the
tree.  Feel free to link the content registration stuff as something this bug
depends on (or tell me which bug I need to link).
Next milestone while I continue to work..
Target Milestone: mozilla0.9.8 → mozilla0.9.9
> > have a pref checked to see if the HTML should be ignored (just use default
> > rulesets, or some ASCII convert).

> That would be bug 30888, I guess. It wouldn't fix this bug, just provide an
> alternative for people already knowing about the problem.

Update: I am working on that. See
<http://bugzilla.mozilla.org/show_bug.cgi?id=69529#c32> for
current state.
Ben, thanks for your work, it's just coincidence that I happen to make a comment :)


Lots of comments in this bug, trying to summarize and some new ideas:

Blocking loading of images is not enough, because any embedded URL (e.g. CSS)
could contain the identification hint.

Blocking ? query strings is not enough, because URLs like
host.com/cgi-bin/SpammerNumberToAddressMapping would still work.

One bug was duped that suggested Mozilla should simply ask before allowing the
request.

Ideally, I think, this bug should be solved in a way similar to the "load images
privacy" privacy feature. I think, in addition to "cookie sites" and "image
sites" we should have "allow html by mail" sites. That would bring up a
confirmation prompt when the email component triggers loading of embedded HTML
content from a site for the first time.

When a mail is displayed, the HTML source is local already. I suggest, when
executing the calls to render that HTML, that call should be extended by an
optional "internal rendering requester" identifier. That identifier should be
passed on (either as a parameter or by a member of some object) to any code
involved in loading embedded objects or rendering the HTML. In our case it would
be an "mailnews" identifier. (When browsing the web, the rendering engine would
be given a "browser" identifier.) That way, the code which is responsible for
fetching would bring up the "new site wants to load content triggered by
mailnews, do you allow?" warning. If the user denies, the HTML mail will be
partially rendered correctly. 

Who knows how we could pass that "internal orignator" bit all the way down?

I don't think that rendering of HTML is an issue here at all, in that HTML
without the server hits is basically, for purposes of this bug, rich text. 
(Excepting scripts and cookie adjustment, but we have ways to turn off script in
mail anyway.)

I guess I don't understand why you need to pass in a magic token when we have
the URL for both the containing document and the desired URL coming in already
to your content policy object.  Back In The Day, we talked about a window-type
parameter for the content policy hooks, but I seem to recall us deciding it
wasn't worth the trouble, given that you already had the URL of the containing
document.

Now, it looks from quick LXR diving that we no longer call the content-policy
hooks for external style sheet references, and I'm not sure what the path is
like for site icons, but these are small bugs to be resolved once the big pieces
are in place.
> I don't think that rendering of HTML is an issue here at all, in that HTML
> without the server hits is basically, for purposes of this bug, rich text. 

Right, I was referring to text only rendering.


> (Excepting scripts and cookie adjustment, but we have ways to turn off script in
> mail anyway.)

Right, and for cookies I wouldn't introduce a new settings category, but use the
same cookie management we already have.


> I guess I don't understand why you need to pass in a magic token when we have
> the URL for both the containing document and the desired URL coming in already
> to your content policy object.  Back In The Day, we talked about a window-type
> parameter for the content policy hooks, but I seem to recall us deciding it
> wasn't worth the trouble, given that you already had the URL of the containing
> document.

I didn't knew that, if we have the containing URL available everywhere, that's
great, and we can make the decision (whether this request falls into the
mailnews category or not) based on that's URL protocol.


> Now, it looks from quick LXR diving that we no longer call the content-policy
> hooks for external style sheet references, and I'm not sure what the path is
> like for site icons, but these are small bugs to be resolved once the big pieces
> are in place.

Sounds good.

Does somebody object to a new category
  "sites allowed to load html embedded content 
   triggered by mailnews"
in addition to images sites and cookie sites?


If this suggestion gets accepted, is the implementation identical with the
following?

- duplicate "image sites" preferences code, and adjust it

- find the right place to catch any protocol request,
    (maybe it helps to find out where the test is implemented that
     checks whether the request falls into the "image site" category)
  and check whether the following condition is true:
    is containing document's URL (as seen in content policy)
    protocol in [imap, pop3, news, localmail]
    and
    (
      user allows any mailnews triggered content loading
      or
      user allows "mailnews triggered fetching" from requested site 
       {if unknown prompt user}
    )

  Re the target network protocol, I'd not make a difference between
  protocols, and not even allow file://,
  because that could confuse users when an email shows them their
  local system configuration files in an IFRAME etc.
In a perfect world, one message would not even be able to load content from a
different message.  A message should be able to load content from the same
message (using multipart/related)

Checking stylesheets and javascript files would probably help solving at least
part of bug 53968

(where's the related bugs field...)
Blocks: 108004
Blocks: 31907
I am making progress on bug 108153, which is another workaround for this bug.
Adding CC.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Keywords: mozilla1.0+
Keywords: mozilla1.0
Is this bug truly blocked by bug 37983?

Dylan, how's it going for 1.0?

/be
Ok, here's where I'm at.

I know roughly where mailnews decides to parse, thanks to the patch where it
completely disables HTML.  At that point I need to put in a decision (based on a
user pref) whether our policy on parsing the HTML in the email is NO REMOTE or
REMOTE ALLOWED.

Mike S. sent me a description:
"- you need to implement nsIContentPolicy and register your 
implementation (http://off.net/~shaver/content-policy.html has some 
tips, and I think it's still largely correct).

- your content policy implementation needs to make its shouldLoad 
decision based on the prefs you mention"

From there it's a matter of testing.  So the big hurdle is wether or not I can
quickly write the code which makes the load decision.  I can make a whitelist of
allowed protocols for each path and parse the decision on based on that, but the
actual description isn't clear enough to me (with my level of exprience with
Mozilla).  I was going to spend next week going over the bits I can do easily first.

> I know roughly where mailnews decides to parse, thanks to the patch where it
> completely disables HTML.  At that point I need to put in a decision (based on a
> user pref) whether our policy on parsing the HTML in the email is NO REMOTE or
> REMOTE ALLOWED.

If you mean my patch for bug 30888, that is not the normal HTML parsing.
Normally, libmime just parses MIME stuff and writes HTML content directly
(unchecked) into the result stream. That result stream is rendered in the msg
pane, leaving it up to Gecko to sort it all out.
I have a suggestion on how this feature could be implemented.
Basicly, you just implement a set of preferences similar to the existing prefs
under privacy-images with the folowing items:
a set of radio buttons that read 
1.Do not load any external content for emails
2.Do not load external content for emails except when the user accepts the server
3.Accept all external content for emails

Option 1 would never load external content
Option 2 would basicly pop up a box everytime a HTML email with external content
was loaded and say "do you wish to block this external content" and it would add
the domain name to a blacklist that could be edited with some kind of blocker
Option 3 would always show external content

As to what option to make the default, I dont know.

I'd prefer an additional choice of "Always ask".
Probably for the 1000th time, but I'm going to add it to this way too long
comment list anyway. I recently switched to Mozilla for e-mail and really don't
want to change back, but this issue forces me to do so.

In my opinion there's no way to separate good HTML mail from bad. Instead of
thinking out and planning for very complex and flexible solutions, why not
simply add a preference that disables *any* HTML rendering of email by default
(by displaying the text alternate or HTML source). And provide an option to show
a selected/opened message with HTML rendering on.

This would be easy to implement, can default to current behaviour, solves the
issue for me (and others) while better ways to restrict HTML rendering can be
implemented.

Please don't get mad at me for repeating what others have said already, but I
didn't read any objections to a solution like this. This feature would also be
usefull for other situations which would not be handled by restricting
connections or certain HTML tags.

On the subject of using third party software to block connections made by the
mailreader: My firewall can't distinguish if the connection is comming from the
browser component or the mail component because the executable is 'Mozilla.exe'
in both cases. This also has reverse affect allowing the browser component to
connect to my POP server.
bvr: I want html rendering but no server hits (other than my mail server to
download the mail) to read mail (privacy, spam prevention). That's what this bug
is about. It's not a problem of html mail but of html mail with links to
external resources.
> why not simply add a preference that disables *any* HTML rendering of email by
default

I said it above already, but some people obviously missed it: That's what bug
30888 implements. Patch is waiting for review.
Sorry that this won't be in 1.0, but it's actually a lot harder than I thought
it'd be to fix :)  I'm learning XPCOM based around what Mike Shaver's told me of
how to tackle it, but I'm finding that the other examples of the nsISupports
through the code (for other security things) are inconsistent at best (some have
bitrotted away, the entire security setup needs a review by someone who knows
more about it).

If you know anything or can help, please pitch in.
*** Bug 135298 has been marked as a duplicate of this bug. ***
FYI: bug 108153 and bug 30888 (which both provide a workaround for this bug)
have been check into the trunk (not the 1.0 branch yet). See
<http://bugzilla.mozilla.org/show_bug.cgi?id=30888#c169>.
*** Bug 138151 has been marked as a duplicate of this bug. ***
Blocks: 138249
*** Bug 139743 has been marked as a duplicate of this bug. ***
*** Bug 141012 has been marked as a duplicate of this bug. ***
*** Bug 141559 has been marked as a duplicate of this bug. ***
*** Bug 141774 has been marked as a duplicate of this bug. ***
I think a whitelist/blacklist is unlikely to be too useful to the average user
without associated button(s) to allow/block image load for a given message.
I'm of the opinion that the blacklist should default to *, too - but that would
require something to confront the user and explain, and I'm not sure that's a
good thing.

The idea of just going "offline" is all well and good... for POP3 mail. A bit of
a pain for IMAP.

I'd be inclined to suggest blocking all images by default, with an icon/button
to enable image loading for (1)this message (2) all messages From: this sender
and adding a prefs dialog option to change the default from block all to allow
all. Perhaps (dreaming, here) even block all except x (intranet, etc) as per
whitelist/blacklist suggestions in this thread.

The question is, can this be made user-friendly enough? I think it _has_ to be
implemented one way or another. I read the Postmaster account from Mozilla, and
the amount of bugged spam is nothing short of astonishing.
If we are reading IMAP mail we already know the server's name, and the same with 
POP. Is it really that hard to disallow the initiation of any network activity 
whatsoever from within a mail message EXCEPT to the mail server?
The solution is as follows:
  The HTTP getremote functionality checks if it's being called from an HTML
document (which succeeds, although things like referrer are striped from file://
base docs), or from mail (which will be blocked by default; else allow if pref
is set to allow remote content in email).

I've been too busy with RL happenings (most importantly finding work) to sit
down and figure out how to modify the content policy handlers.  Once that's done
it's a small amount of work for a UI dialog in prefs and testing.
*** Bug 144781 has been marked as a duplicate of this bug. ***
Spammers are making major use of this loophole.  I strongly urge that outgoing
network activity based on the act of reading email require explicit user
authorization.
Bryce: If you select View -> Message Body As -> Simple HTML, then there're no
server hits.
Alex, and where exactly is that option?
I'm using RC2, and see nothing like that.
It's in the nightlies. But that setting doesn't stick between sessions.
Alex, "View as Simple HTML" is nice, but not nearly good enough. On some
messages neither "as Simple HTML", nor "as plain text" show me anything at all,
while the message is still entirely self-contained and can be viewed properly
w/o any server hits! In other words, I do want "complex" HTML, I just want it to
only use the content that's already available in the message itself.
Mikhail: As Torgeir mentioned, the option is in the nightlies, which you can
download here: http://ftp.mozilla.org/pub/mozilla/nightly/latest/

Torgeir: At least with 2002051604 (on Win2k), the setting seems to be persistent
for me :-/.

Aleksey: I'm not proposing that "Simple HTML" is the solution to this bug,
merely a workaround until it's fully completed :). 
I'd like "complex html", as long as all the content & images are contained
within the message.  It's also critical that it be easy to say "this one's fine
--- let it load images".

The issue is broader than HTML.  I'd like Mozilla to promise me that reading
email is a fully private activity, resulting in no network activity.  Any
activity (return receipts, url loading, etc) should require my permission.

 -BN

I'd also like to be able to mark spam as read without reading it, but that's a
seperate matter.
Can't this get put at a much lower level within the codebase?  If the rule is
that mailnews can only talk to it's mailserver, can't a block be put at the
network layer?

In one swell foop, you'd block (or catch) all the cases with potential privacy
violations.  There are lots of ways to violate privacy based on rich email. 
Cookies for example ( Bug #22994 ), or images ( Bug #144781 ).  With a network
layer block, you don't have to think of all of them in advance.
"<i>can't a block be put at the network layer?</i>"

It can.  That's precisely what I want to have, and am working on, for the patch.
 However, the XPCOM stuff which lets you define the methods for doing the
boolean decision about if something is OK to load or not from context info (in
this case, the context is loading from mail/news area) is a bit beyond my
current abilities, plus I've been going through a job situation -- thus the
slowness of my patch to come out.

Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
*** Bug 148386 has been marked as a duplicate of this bug. ***
*** Bug 148859 has been marked as a duplicate of this bug. ***
*** Bug 151017 has been marked as a duplicate of this bug. ***
Spammers are sending out things like the following.  The image, of course, is
too small to be seen.  I deleted the spam domain and my email address from the
snippet below.

<p>Hi, did you receive my previous email message?</p>
<p>I sent it 2 weeks ago, but I&nbsp;still didn't get an answer, please check in
your old email.</p>
<p>Anyway, I'll send you another copy tomorrow or the day after, you don't need
to reply to this email.</p>
<p><img src="http://[SPAM DOMAIN DELETED]/w.cgi?email=[MY EMAIL DELETED]"
border="0"></p>
<p>Regards,</p>
<p>John Laplace</p>

waldemar: So, for that, you just turn off images in MailNews, eh?

(see also bug 97055)

And, I realize that bug 97055 only covers a subset of this bug, but it helps.
Waldemar: what is your point in comment 197? That's what started this bug.
Blocks: 158464
*** Bug 159151 has been marked as a duplicate of this bug. ***
Alias: ImgInMail
Looks like we will miss the target milestone.

pi
Could someone please remove supradave@earthlink.net from the maillist to this
bug.  I haven't wanted to submit a bug about it, but I keep getting mail about
it and I don't know about or how to fix it.

Thanks,
Dave
sincere apologies for spam, but just so everyone knows that Dave's had a reply...

Dave - you're getting mail about this bug because you've voted for it.  Go to
the bugzilla page, and in the page footer, you'll see a link that says "My
votes". Follow that link, uncheck the box next to this bug, and click the
"change votes" button.
Blocks: majorbugs
FYI: even with "cookies off in mail&news" cookies are enabled...:(

set Mozilla to "dont accept cookies" in Mozilla Mail
set Mozilla to "dont show remote images" in Mozilla Mail
set Mozilla to show "original HTML"
now send a mail to browserspyhtmlmail@gemal.dk
read the reply mail that comes back

now check your cookies in the Cookie manager. A cookie from gemal.dk is now
present! that bug 168258
*** Bug 168174 has been marked as a duplicate of this bug. ***
I removed myself from this bug but it keeps emailing me... Re-adding myself and
removing myself again...
*** Bug 176165 has been marked as a duplicate of this bug. ***
According to http://www.msnbc.com/news/829223.asp?0si=- next Outlook will have
this feature enabled by default.
With the additions of "do not load remote images in mail & newsgroups" and
"enable plugins for mail & newsgroups" (bug 147877), and "disable cookies in
mail & newsgroups" -- what else is there to be fixed before we close this bug?

The only thing I can think of is defaulting with these settings to be secure,
and maybe adding them to a global section of the security tab in mail/news
preferences.  Comments?
dylang, I think comment #5 pretty much sums it up. It's one thing to block
images, plugins, and cookies, but quite another to block all network activity
originating from an email message. That would be far more secure.

For example, what about frames or iframes? What if a spammer includes a
stylesheet that points to a CGI? What about prefetching? What about shortcut
icons? And the list goes on. :-)

I think a block at the network layer *does* make sense...
I suppose as long as the correct combination of those preferences can absolutely
guarantee that no network activity will be initiated by reading a mail message,
then it's all covered. If, however, there is any way to trigger network activity
without explicit user input, then this has not been fixed in a satisfactory manner.
Jerry, as has been pointed out previously, they cannot. And even if they could
it would be good to have a main switch on the network level.
FYI: As the summary indicates, this bug has always been intended by me (the
reporter) to include *any* possibility of network activity, not just images. See
commment 25.
I'd like to make a radical, and possibly impractical, suggestion. If you're
considering a network-level switch to fix this bug, why not fully separate
MailNews's network-level status? There are certainly times of slow connection
when I'd want my browser online but my mailNews offline - then I can browse,
delete, etc. my mail at local speeds but still get online data in the browser. 

[Of course, that solution would require a real, working offline mail client.
Bugs like <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=67172">67172</a>
would become more pressing]
Impractical, yes :)
The optimal solution I've alsayws wanted in a hook in network code.  Right now
Mozilla, at the network level, will not fill out the HTTP request structure the
same way if it's in the mail/news area (because we don't want to leak the
specific message, etc, to a remote server via referrer).  Extending this to
simply ignore all network activity if origin is mail/news shouldn't be too hard,
it's just that I haven't had time to fully go through all the code (there is a
lot :-/) to make sure that such an idea wouldn't lead to new bugs elsewhere.

The offline solution isn't applicable to people using IMAP (myself, others),
because IMAP has to be online to look at new messages if you don't have your
brower set to autodownload messages (the default).  I look at my mailbox from
many locations, and value the online features :)
If somehow the Mail/News reader would be running NOT as Mozilla.exe it would be
possible to solve this whole problem with a firewall or IP filter by disabling
all outgoing communication (or making different rules for it). However, as
comment 168 says, currently it is not possible to distinguish between the
Mozilla Mail/News reader and the browser (both identified as application
Mozilla.exe).
Wouldn't it be easier to do this as a preliminary solution?
I know that under Windooze it would certainly solve my problem. Under Linux
however, I did not find such a personal firewall/IP filter, which can do IP
filtering by application.
Did this make it in 1.0.1?  If not target should be updated.
*** Bug 181338 has been marked as a duplicate of this bug. ***
Isn't this a preference now?  In Privacy > Images preferences, I see a
preference that prevents remote images from loading in Mail/News.  This build is
2002123108 on Win XP Home SP1.
Brant: Not exactly. CSS files, for example, could act as a unique identifier
(see also comment #29). 

PS Be sure to add yourself to the CC list on bugs, otherwise might might not
receive any of the responses ;).
Re: comment #220

Also, ideally we would want to allow loading images that are included in the
message itself, and only prohibit loading *external* images (while the current
preference, as I understand, would prohibit any kind of images).

And see also comment #210.
Aleksey: I think the current pref already does that. That's what "remote" is
there for in "Do not load remote images in Mail & Newsgroups", right? :-)
I've just made the bug #187984, that is like to be a duplicate of this one.
I think that loading remote contents without the user being informed about
privacy risks is really a bad privacy issue. A warning similar to the one that
appear posting form data would be apreciated. A bettere idea, allowing the user
to select if any remote contents should be loaded or not.

Try the http://www.readnotify.com/, that sell a service of mail tracking, that
use remote contents loading to collect a lot of informations about the mail and
the recipients.
Isn't it a very nasty service? :)


*** Bug 187984 has been marked as a duplicate of this bug. ***
*** Bug 188235 has been marked as a duplicate of this bug. ***
bringing over some comment from sfraser's duplicate bug:

sfraser writes:

Currently, viewing a mail message can fire off remote loads for images
(controllable via a pref), iframe contents, style sheets, and other stuff. Not
only is this a security issue, it's also a privacy issue: spammers can use
weblogs, or FTP images requests, to gain information on when a mail message was
viewed, and from what IP address. Image requests may even reveal your email
addresss (depending on pref settings).

I think mail needs an option, defaulting to _on_, to turn off loading of all
remote content in mail. Only display what is contained in the mail message, and
nothing more.

clearing the target milestone.

dylang, is this still on your radar?
Target Milestone: mozilla1.0.1 → ---
Would this cheap short term solution work: If we flag the message as spam (by
our spam detection code) then when the user try to display it, only display as
plain text? Should be pretty cheap to add that. I think Seth mentioned to me the
other day that he wants to disable images for messages that are marked as spam
as well. 
If this bug is to be fixed even when JavaScript is enabled in mail messages, it
depends on bug 65224.
I agree with Simon's suggestion. Give the user an option to not access non-local
content, of any kind, without explict permission. I don't think that
spam-detection is sufficient. Mozilla can put a box in the message header area
that the user can click in order to load the non-local content. This will make
it easy for the user to determine if the message is spam.
Note that for this purpose, "local" must include mail on the IMAP server
configured for the account.
That's true. Local perhaps should mean "under the user's control". A remote
mounted home directory, for example.

In addition to #227 from Seth Spitzer:
I agree to it's suggestion, I think it would be necessary to add such a feature.

I could imagine that this feature could work like the "Cookie Manager" with same
options: either ask at every mail which wants to load remote content or define
locations that will be allowed to load remote content from. Of cause allowing or
denying loading all remote content should be possible as well.
There is an a partof a message sent my by the Readnotify service:
<IMG
SRC="http://www.dvvorzk66t4nx8.ReadNotify.com/nocache.pl/dvvorzk66t4nx9/footer0.gif"
border=0 height=1 width=1 alt="">

<iframe width=1 height=1
src="http://www.dvvorzk66t4nxo.ReadNotify.com/iframe.asp?dvvorzk66t4nxp=2"
frameborder=0 STYLE="width: 0; height: 0px; border:0px"></iframe><table height=1
width=1 border=0><tr><td
background="gopher://gopher.dvvorzk66t4nxy.ReadNotify.com/gb.dvvorzk66t4nxz.gif"></td></tr></table>

as you can see, they try to load many types contents using different protocols
(also the gopher)
The mail tag-id are embedded in may part of the url (also in the server address...)
Now, I'm going to post an attachment with informations collected about that mail
by the read notify service .

Original informations included also a map of the recipient possible location,
detected using the IP used for loading remote contents.
tv@beamnet.de wrote me:
> Just for the sake of couriosity: Do you know what happends when you
> select the various "view/message body" options?
> This might be of interest to other people subscribed to the bug, too,
> but I thought I'd ask privately to not generate too much noise.
This is a VERY interesting question.
If you select plain/text or simple HTML remote contents of the message sent me
using Readnotify service (containing remote img iframe and table's BG) are not
loaded at all.
I'm sure about that because I opened a tracked mail and the tracking system was
not aware of that.
I guess that also other type of remote contents (using any HTML tag that allow
it and any protocol) should not be loaded.

Yep, Simple HTML (aka Sanitized HTML) and Plain Text are designed to strip away
all references to remote content.
I've been using Simple HTML, and it seems to do the trick. It would just be nice
to have a convenient way to tell it to load all of the email's content. I could
go up to the menu and enable full HTML, but then I have to remember to switch
back when I'm done. Maybe a button in the headers.
Heh, I guess that's one reason for this article -- being able to read the
original mail and all the local content in the original format without fear of
triggering remote load. 
midori@paipai.net -- we don't need examples of why this bug is bad.  The fix to
this bug is fairly logical.  Go look at bug 83038.  (On a side note: the fix for
that bug originally was a blacklist of bad protocols instead of a whitelist of
allowed, remote referrer protocols, and thus needs to be revistited by someone
to be updated in a new bug)  The fix is to simply to stick a new content-policy
object in the chain when this pref is set, and that object can refuse to load
all content with a protocol that isn't the same as the enclosing document (as
Mike Shaver said in comment 151).

It's all a matter of sitting down and figuring out exactly where (and a bit how)
to implement nsIContentPolicy and shouldLoad.  Having been through 3 jobs in the
past 9 months hasn't sped up that part of my approach to this bug.
*** Bug 189806 has been marked as a duplicate of this bug. ***
Mail triage team: need info.
Whiteboard: [need info]
*** Bug 175258 has been marked as a duplicate of this bug. ***
So.....,

What's the official word on this bug?   Is there a work around? 

I read the rest of the comments and there doesn't seem to be any.

Telling, that this bug is over 3 years old now.  Bet if outlook implemented this
tomorrow, it would be in mozmail by the end of the week :)

Anyway,  I think giving the user the option to not load any remote items is a
very important privacy feature.  Suspect that not having this feature is
contributing to the growing amount of spam I am receiving.

Giving the high dup count and votes, I suspect a lot of people agree.
In mailnews, go View -> Message Body as -> Simple HTML
Problem solved.
cool, thanks.

Two things...

(i)  Maybe the View->"Message body as" option can be placed under
Edit->Preferences->"Mail and News" somewhere; maybe under the "Message Display"
property sheet.

(ii) Why is this bug still open?
> (ii) Why is this bug still open?

The "simple HTML" feature is _very_ far from what this bug requests. I want to
be able to view _full_ HTML mail, with images, CSS, etc - but only when those
images and CSS are included in the email and are not on a remote server. The
"simple HTML" feature restricts _way_ too much.
(i) It must be easy to change. In prefs it would be too far away.
>Telling, that this bug is over 3 years old now.  Bet if outlook implemented this
>tomorrow, it would be in mozmail by the end of the week :)

Evolution has implemented it, though.

>>Telling, that this bug is over 3 years old now.  Bet if outlook implemented this 
>>tomorrow, it would be in mozmail by the end of the week :) 
 
>Evolution has implemented it, though. 
 
And KMail 
*** Bug 204438 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
something that thunderbird and the trunk will want for 1.5 alpha.

taking from dylang@thock.com, send me mail if have a patch started, and want
this back.
Assignee: dylang → sspitzer
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla1.5alpha
Will thunderbird run as a separate process? If it will, then it would be a
pretty easy WORKAROUND to use a personal firewall to block all connections from
the process other than to mailservers.  Still, hope to see this soon!
Re: #254: This is why I currently use Mozilla for browsing only, and a 
different software (Netscape 4.x, actually) as a mail client. The mail client 
is configured to assume I use a proxy, and the provided proxy address is 
nonexistent. This way, all HTML connections resulting from mail-reading simply 
fail.
Tip: you could also use a second mozilla profile to do the same thing. Simply
start mozilla with a command-line flag to select the correct profile for mail or
www access. Easily incoporated into a toolbar link / shortcut / script or
whatever your platform uses.

IMHO, this is 99% fixed with the "enable plugins for mailnews" and "load remote
images in mailnews" options.
Tal, Craig: Thanks for the workarounds. Craig's I think will mean that clicking
on a link in an email won't work as it should; I'd hate that.
How to enable bug 108153's workaround, as far as I can tell: posted to said bug.
Implemented Already!!?
Has anyone here ever heard of the open source project called SquirrelMail?  It
is an IMAP web-based mail client.  It is coded in PHP and usually runs on Apache
with modPHP installed.  Anyways, see http://www.squirrelmail.org/

The reason I bring this up is that the developers of SquirrelMail opted to (by
default) block all images from a foreign server!  Yes, all of them.  There is
actually a plugin that allows the administrator of the webmail to re-instate the
ability to see these "unsafe images."  The plugin is called "unsafe image rules."

Deep link: http://www.squirrelmail.org/plugin_view.php?id=98

FOR THE WHOLE RESAON why anyone should care about this bug, or why the
SquirrelMail people chose not to allow (by default) the viewing of any image
from a foreign server, SEE THIS LINK!
http://www.squirrelmail.org/wiki/en_US/UnsafeImages

Okay, so there is a precedence for completely blocking every image in an e-mail
that didn't come inside the e-mail!  There is also a precedence for allowing a
user to selectively reinstate the normal image view of HTML mail.

You would probably guess that most users were pretty disappointed when these
"usafe images" were being blocked.  But for some of us who *do* receive a lot of
SPAM, I actually preferred viewing my mail with the SquirrelMail interface until
I came across something I needed to see from a legitamate source.  Having the
unsafe image RULES (via the plugin) makes this feature votable for Mozilla Mail!
 Or, "I wish Mozilla Mail did this, too."
*** Bug 210403 has been marked as a duplicate of this bug. ***
sliding out
Target Milestone: mozilla1.5alpha → mozilla1.5beta
*** Bug 212752 has been marked as a duplicate of this bug. ***
*** Bug 214046 has been marked as a duplicate of this bug. ***
IMHO the inevitable flexible solution is: Unique allowed-domains lists
and proxy-setups for each email account.  Within one process using one
profile, you configure the browser's proxy, optionally override by a
global default email proxy and allowed-domains, and optionally override
proxy setup and allowed-domains on each email account.

The allowed-domains is a domain list field similar to no-proxy-for but
with a separate boolean to turn on or off use of this field.

To access all domains from an email account: set the boolean false.
To block all: set true (use list), but with empty list: none allowed.
Behind a firewall, set true and list your own local domains as
allowed (allow access by HTML-email to images, css, plugins...
within your own network).

I don't know the state of the javaScript-able proxy function in Moz,
but provided such a user-configurable JS proxy function had access
to whether the browser or an email account (and which email account)
was triggering this particular DNS-to-IP resolution, then a user can
code up the above effects (defer to different proxies appropriately,
and enforce separate allowed-domain lists).

That JS-proxy would be a minimum start giving much power long before
any GUI need be conceived for this, similar in spirit to user prefs
that don't have a GUI yet.  Care needs to be taken so any IP caching
is also separated or multi-layered, so previous browser hits don't
"enable" HTML-email hits to the same site by skipping the JS-proxy
based enforcement by virtue of already-cached (or simply provide
option to disable IP-cache use from all HTML-email).

Don't you think it's easier to say, "the mail window wants to initiate a network
request that didn't result from a user click -- is the request to the mail
server? If not, block the request. Done."
I doubt that an allowed domain list is the solution for email problems, though
it's ok for browser cookie settings. What makes me think this? Occasionally
we're receiving Junk mails from one of our own domains. While browsing I'm
actively requesting a certain domains content, reading mail makes me read what
somebody else wants me to read. 
Allowed domain lists would be valid for known accounts *and* signed mails only,
being somewhat more complicated than [reb at cypress-dot-com]s suggestion. 
Olaf
Olaf,

(I'd hope that) The domain whitelist is for outbound targets, not for appearant
E-Mail originators (as these can be forged, of course).
I don't get that much spam that refers to images on my own webserver.

Cheers

Thomas
sorry, missed that. However, related to past comments, I'll second comment 247
for this bug: Show everything that is enclosed with the respective mail and
prohibit any contact to any server outside, e.g. show full images and
stylesheets as long as they are attached to the mail (plugins give another
problem with that, but that has already been solved in one of the last years... :-)

But then, viewing mails plain text only has saved me from reading dozens of
viagra spams, so I currently don't really miss this feature :-)

Olaf
I for one could really do with a domain whitelist, as I get automated emails
that refer to images on our intranet webserver (and not having the images makes
for a useless email).
*** Bug 218627 has been marked as a duplicate of this bug. ***
My comments as to the best way to handle this, although they could easily spill 
into seperate bugs:

Make privacy the default. External objects do not load without user interaction.
Allow selective loading, possibly via right click "Allow object to load."
Allow full loading, either via right click, Load External Objects, or via chrome
similar to the junk mail indication in thunderbird.
Provide seperate toggles for previewing and opening a message, perhaps make
privacy default for the preview pane, and default to allowing external objects
when opening in a window.
Provide sender and site whitelists and blacklists that take precidence
regardless of the global privacy settings

*** Bug 229038 has been marked as a duplicate of this bug. ***
I joined the mozilla bugzilla group just for this one option.  And then I found
it!  In 1.5 it is under [Preferences... -> Privacy_&_Security -> Images ->
Do_not_load_remote_images_in_Mail_&_Newsgroup_messages].

I expected it to be under [Preferences... -> Mail_&_Newsgroups] or in the Server
Settings in [Mail_&_Newsgroups_Account_Settings...].  Just an observation, not a
complaint.

Happy happy happy happy,

Steve

PS:  When does this bug get closed out?
When it is possible to make Mozilla NEVER talk to any server except by explicit
user action (e.g., clicking on a link). As it is images don't load, but you can
do all kinds of other stuff instead.
FYI, current versions of Pegasus Mail also block images by default.  His 
solution was to pop up a message saying "This web page has images, do you want 
to load them?" or something like that, with the option to either load or not 
load by default, and the option to disable the popup.  If you choose to disable 
image loading, right-clicking on any message gives you the option to "Show 
Pictures (HTML)".
What about remote style sheets, flash, javascript, java applets, or anything
else for that matter?
Any network connexion outside should be avoided inside a message.

This shous include stylesheets and urls inside stylesheets.

This could be implemented by filtering out urls outside the message own url.

Mozilla-mail access mailboxes via urls like :
mailbox://nobody@Local%20Folders/folder/message
imap://user:password@imap.serveur.net/folder/message

Or disallow any other protocols than mailbox: or imap: inside a mail message.
With 26 dupes, this bug needs a clearer summary. I'm appending "(disable remote
content/web-bugs)", but feel free to change that to something easier to search.

BTW, starting with WinXP SP2, this feature will included in Outlook Express.
See http://www.pcmag.com/image_popup/0,3003,s=1841&iid=62601,00.asp

Prog.
Summary: No server hits at HTML mailnews reading - privacy → No server hits at HTML mailnews reading - privacy (disable remote content/web-bugs)
*** Bug 232843 has been marked as a duplicate of this bug. ***
Perhaps this has been addressed in the 278 comments before mine...

I am happy with the 'blocking of remote images in Mail' feature, but now I want
to be able to UNBLOCK images in some emails. I don't see any easy way of doing
that, other than allowing all remote images, then viewing the message, then
blocking again.

I would like to be able to permanently allow remote images in emails when the
images are on certain servers. So in the Browser, I can BLOCK images from some
servers. In Mail, I want to be able to ALLOW images from some servers, with the
default being to deny.

This would keep me safe from random spammers, but would allow me to view my HTML
newsletters etc, once I had configured everything correctly.
Asking for blocking in 1.8a because this is a major privacy concern.

pi
Flags: blocking1.8a?
No, given that bug 108153 (Simple HTML mode) is implemented, it isn't. One
reason why I fixed that bug was that I wanted to fix this one (28327), and IMHO
it did. That fix protects you not just from tracking, but also from the vast
majority of potential security exploits and automatic viruses.
I wonder if it's still valid at all, and if so, only in very few edge cases.
Before you flame me, note that I am the original reporter of the bug. ;-)
(In reply to comment #281)
> No, given that bug 108153 (Simple HTML mode) is implemented, it isn't.

Simple HTML mode is not enough: a user might like to see HTML messages as
intended by the author, but not trigger web bugs.

If this feature is implemented, messages in which all the content is attached to
the email using cid: URLs would display properly AND web bugs would be stopped.
Using the Simple HTML feature means you can do only one of these at a time.
I agree with comment 282, simple HTML is a very nice feature (And I use it), 
but since Outlook has functionality for not giving away emailadresses (not 
downloading pictures, etc from remote locataions) one can expect a lot of 
companies to embed them in the message.

In some cases I want the simple HTML (especially in the case of suspected 
SPAM), but most of the time I just want to be sure that my emailadress isn't 
given away, while I read the email with the layout as intended by the sender.

My point is that these two issues (simple HMTL and No server hits) resolves 
two completely different problems. Simple HTML blocks content that doesn't 
generate a server hits and is required for proper displaying of the message.
(In reply to comment #280)
I support pi as long as it doesn't get too long :-)

> Asking for blocking in 1.8a because this is a major privacy concern.
... and security. I am talking about iframes. What about 1.7? Too late?

The scenario in bug 64066 comment 31 already has happened! (which is a browser
bug, so I was sent here)

> spammer might just start attaching .au or .wav files to emails for this purpose?

Please see:
bug 191460 comment 24 and bug 191460 comment 84 - Virusmail executes embedded
virus. (netsky.p@MM, W32/KLEZ.H@mm) (This is partly solved for Windows by bug
239160 and a MIME patch but the iframe problem still exists)

bug 213280 - denial-of-service-attack using iframe & telnet-urls
This bug is not a security concern. It only blocks fetches to the *Internet*, it
should not block fetches to msg parts, because e.g. inline image loads should
continue to work. So, if there is a security problem, you can always exploit it
by attaching the exploiting doc and refering to it with an appropriate URL -
indeed, the worm described in bug 191460 does just that -, and this bug (28327)
won't stop it by design. "Sanitzed HTML" did.
*** Bug 230274 has been marked as a duplicate of this bug. ***
I think the best solution was mentioned in Comment #150:

Put mails in a sandbox and don't allow them to access anything
outside of themself.

For special cases there could be exceptions like
Mails from foo@bar.com may access urls matching http://www.deadbeef.com/*
...
Flags: blocking1.8a? → blocking1.8a-
*** Bug 244593 has been marked as a duplicate of this bug. ***
I think fixing this will be easier and cleaner (at this point) for tbird.

tbird has it's own content policy, see
http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMsgContentPolicy.cpp

in the tbird ui, mscott has:

privacy
  [ ] block loading of remote images in mail messages

in 1.7 (so I assume trunk, too), we have:

privacy and security
  images
    image accept policy
      [ ] do not load remote images in Mail & Newsgroup messages
  
so for tbird, maybe this will be acceptable:

1)  keep the pref name the same (mailnews.message_display.disable_remote_image)
2)  but change the UI to be "block loading of remote content in mail messages"
or "block loading of remote files in mail messages"
3) fix nsMsgContentPolicy::ShouldLoad() and maybe do:

-else if (aContentType == nsIContentPolicy::TYPE_IMAGE)
+else

(or we might want this check for remote content before the check for plugins, as
"don't load remote content" might take precendence over plugin content handling)

note, I'm not sure if that will address the "don't load remote css problem" or
the "don't load any iframes" problem.  (see bug #243306)

the reason, besides UI, why this is easier in tbird is we won't break browser as
we have a separate policy in a separate app.

let me attach the text of my conversation with bz for some background.
Status: NEW → ASSIGNED
here's a conversation I had about this with bz.

<bz> So as far as blocking everything
<bz> I'm looking at nsMsgContentPolicy::ShouldLoad
<bz> It's a matter of replacing the line
<bz>   124   else if (aContentType == nsIContentPolicy::TYPE_IMAGE)
<bz> With the line
<bz>   124 else
<bz> I suspect that should be sufficient...


<sspitzer> I'll look into that frame thing. 
<sspitzer> as remote iframes should be loaded in mail either. 
<bz> yeah
<bz> Agreed.
<bz> Iframes are TYPE_SUBDOCUMENT
<bz> on trunk
<bz> and SUBDOCUMENT on branch
<sspitzer> you mean, add an else check for:  nsIContentPolicy::TYPE_SUBDOCUMENT
(like we have for nsIContentPolicy::TYPE_IMAGE) 
<bz> yeah
<bz> Note that that won't block stylesheets...
<sspitzer> don't we already block those? 
<bz> I would think we would want to apply the image pref to all content
regardless of type
<bz> Not that I'm aware of.
<sspitzer> I think I was thinking of (Link:
http://bugzilla.mozilla.org/show_bug.cgi?id=184948)http://bugzilla.mozilla.org/show_bug.cgi?id=184948

<sspitzer> what's the right way to block all remote content? 
<sspitzer> or is that not possible? 
<bz> well...
<bz> just don't do a type check?
<bz> Run the code that checks the scheme no matter what type the thing is?
Target Milestone: mozilla1.5beta → mozilla1.8beta
Here you can find a list of web bugs :
http://www.freedom-to-tinker.com/archives/000610.html
*** Bug 256839 has been marked as a duplicate of this bug. ***
Even Outlook Express has fixed that issue in their latest release:

Screenshot: http://microcephale.free.fr/priv/OEprivacy.PNG

It is kinda trivial to block images AND other external content. Without blocking
other content, the image blocking feature is totally and utterly useless.
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Flags: blocking1.8a4?
restoring aviary1.0 nomination, only project leaders can set blocking status.
Flags: blocking-aviary1.0+ → blocking-aviary1.0?
taking
Assignee: sspitzer → mscott
Status: ASSIGNED → NEW
*** Bug 248853 has been marked as a duplicate of this bug. ***
*** Bug 248857 has been marked as a duplicate of this bug. ***
*** Bug 259091 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a4? → blocking1.8a4-
Flags: blocking-aviary1.0? → blocking-aviary1.0+
*** Bug 260962 has been marked as a duplicate of this bug. ***
Attached patch the fix — — Splinter Review 
this may be too agressive. Testing will let us know for sure.

I may also change the string text to refer to remote content instead of remote
images in the UI.
> this may be too agressive. Testing will let us know for sure.

Doesn't it affect Thunderbird RSS reader?
It generate e-mails with iframe loading the remote article.

(In reply to comment #301)
> > this may be too agressive. Testing will let us know for sure.
> 
> Doesn't it affect Thunderbird RSS reader?
> It generate e-mails with iframe loading the remote article.

Yes, this bug by design will break these messages, and I see no way around it.
IMHO, the RSS reader should be changed in some way (need to figure out how).
No this change has no effect on Thunderbird's built in RSS reader. Things will
still load fine for RSS folders.
Flags: blocking1.8a1-
*** Bug 261520 has been marked as a duplicate of this bug. ***
I checked this into the branch and the trunk last week and so far I haven't
gotten any complaints about it being too aggressive yet. 

I may end up changing the string we show in the UI down the line but I'm not
going to keep this bug open just for that issue. Also need to do some further
testing to see if the remote style sheet code calls through the content policy
manager...
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
This is not blocking iframes on the trunk (2004101505), but is working for
thunderbird (20041009). I double-checked that the patch here was checked into
the trunk, why wouldn't it work there?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I should also note that it looks like nsMsgContentPolicy is explicitly blocking
ftp, http, and https only. Not gopher (found "in the wild", see comment 234) or
any other scheme that might be supported by us or the OS.

A scheme that opened a new window, like an external app or one of the news
protocols, wouldn't be useful as a commercial web-bug, but a one-off snoop
attack where you don't care if the recipient knows that you know could still
succeed.
*** Bug 264828 has been marked as a duplicate of this bug. ***
*** Bug 265296 has been marked as a duplicate of this bug. ***
*** Bug 266462 has been marked as a duplicate of this bug. ***
(In reply to comment #305)
> I may end up changing the string we show in the UI down the line but I'm not
> going to keep this bug open just for that issue.

Bug 266503 opened for the UI update.


> Also need to do some further testing to see if the remote style sheet code
> calls through the content policy manager...

Apparently it does not; I've tested, and remote style sheets (via <link>) are 
still loaded with TB version 0.8+ (20041028), Win2K.  However, as noted in 
comment 306, the <iframe> tag is being blocked with TB; but not for 
MailNews 1.8a5-1019.

How is it that the patch was checked into the trunk with neither review nor 
superreview?
*** Bug 260039 has been marked as a duplicate of this bug. ***
This is possibly the subject of Secunia advisory SA13086:

"Mozilla 1.7.3 / Thunderbird 0.8 Valid Email Address Enumeration Weakness"
http://secunia.com/advisories/13086/

Adding blurb to help catch duplicate filings.
(In reply to comment #311)
> Apparently it does not; I've tested, and remote style sheets (via <link>) are
> still loaded with TB version 0.8+ (20041028), Win2K.

I can't confirm this for TB 0.9final, Win2K. The remote stylesheet is not loaded
before clicking on the "Show Images" button (ensured via Ethereal).
(In reply to comment #315)
> I can't confirm this for TB 0.9final, Win2K. The remote stylesheet is not
> loaded before clicking on the "Show Images" button (ensured via Ethereal).

In TB 0.9, I see that also.
Product: MailNews → Core
Blocks: 239954
If it was good enough to block aviary 1.0, it is good enough for 1.1.
Flags: blocking-aviary1.1?
Blocks: 278176
bug 274866 made the pref to block images in mailnewd (for seamonkey) to block
all remote content, the same way as thunderbird does it.
(In reply to comment #318)
> bug 274866 made the pref to block images in mailnewd (for seamonkey) to block
> all remote content, the same way as thunderbird does it.

I reopened this because of the suite. If that's being handled elsewhere then
this can get re-closed.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
It would be useful if someone explained how to use it. Is there UI for this? If
not it won't be available to most users.

pi
Just set the good old pref to not show images in mailnews. (like i tried to say
in comment 318 (there are too many comments here))
Bug 287672 is about fixing the wording of the pref panel text.
Flags: blocking-aviary1.1?
No longer blocks: majorbugs
(In reply to comment #319)
> (In reply to comment #318)
> > bug 274866 made the pref to block images in mailnewd (for seamonkey) to block
> > all remote content, the same way as thunderbird does it.
> 
> I reopened this because of the suite. If that's being handled elsewhere then
> this can get re-closed.
Was this handled elsewhere? I didn't see it anywhere, yet this was closed. Thanks.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: