Closed Bug 172184 Opened 22 years ago Closed 16 years ago

Unblock images for a specific message

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: something_about_dave, Unassigned)

References

Details

Attachments

(1 file)

Currently the option exists to block images for all mail/news messages. This is
great, since most html messages w/ graphics are spam anyway. However, it would
be nice to be able to unblock images when viewing a message, as occasionally
there is the legitimate message with graphics. Right now you can "edit message
as new" and it shows the graphics, but then of course the links don't work.
That's kind of kludgy though -- it would be nice just to be able to unblock.
related to bug 141307
One nice way to do this would be to have a mode of operation where whitelist
addresses (as in the whitelist used for SPAM filtering) allow images to be
loaded in mail & news messages, but all others respect the global setting to
either block or display.
*** Bug 200527 has been marked as a duplicate of this bug. ***
*** Bug 200856 has been marked as a duplicate of this bug. ***
*** Bug 203176 has been marked as a duplicate of this bug. ***
I'd like to see this on a per-folder basis. In my case, I almost never want to
see the images in a mail message, except in one folder, where my subscription to
Dilbert and a few other comics gets filtered to.
Summary: [RFE] Unblock images for a specific message → Unblock images for a specific message
I agree Whole-heartedly with comment #2...  Most emails I receive that contant
remote images are spam, but some mailing lists I'm on also do - & the Junk
filter system knows it, so loading those immages seems appropriate.

Anothing angle on this - one can right click on an image in the email and
block/unblock access to images from that site. Couldn't that be used to get the
same result? Currently it seems that the global option to avoid loading remote
images overrides the per-site listing. Unless I'm mistaken, I'd say that more a
bug than rfe.

sTu.
I agree Whole-heartedly with comment #2...  Most emails I receive that contant
remote images are spam, but some mailing lists I'm on also do - & the Junk
filter system knows it, so loading those immages seems appropriate.

Another angle on this - one can right click on an image in the email and
block/unblock access to images from that site. Couldn't that be used to get the
same result? Currently it seems that the global option to avoid loading remote
images overrides the per-site listing. Unless I'm mistaken, I'd say that more a
bug than rfe.

sTu.
Apologies for the doble post... tried to abort the first, but failed. :|
*** Bug 219119 has been marked as a duplicate of this bug. ***
Apparently my bug was a dupe, sorry...

I don't like comment 2 as much, I would like to be able to do it on-the-fly...
some ideas I had in my bug post:

"I was thinking either a context menu or even better an icon in the status bar
showing some image with a slash thru it that if I click, the slash is removed
and the images shown."
I agree with comment #11 and #2.  I want to be able to click some button to
'show images in this email', and be able to safe-list some senders to allow
images automatically, so that in the case that you receive regular emails with
images you don't have to go through an extra step every time (such as Stefan's
comic strips).
*** Bug 229533 has been marked as a duplicate of this bug. ***
*** Bug 216001 has been marked as a duplicate of this bug. ***
*** Bug 229370 has been marked as a duplicate of this bug. ***
There is now the option to allow sites in the image blocking preference but it
only seemed to work for the browser, and not mail/news. This is a definate bug,
should I change severity from enhancement or file another bug (which I fear
would just get marked dup)
*** Bug 230657 has been marked as a duplicate of this bug. ***
*** Bug 230824 has been marked as a duplicate of this bug. ***
I've attached an image which shows that WinXP SP2 is going to have a feature
which I've been wanting in Mozilla for a long time. And it seems OE has done
this in a simple and cleaver way.

Currently in my Mozilla preferences under Privacy and Security -> Images
I set mozilla to not load remote images in email. This is to protect from
spammers verifying my email address. I'm sure many users do this as well.

However I do receive some newsletters that are written in html from trusted
sources that have many remote images. When those newsletters arrive in my inbox

I am not able to view the remote images in the html, unless I change my
security
setting then load the html email again, which is too much of a hassle.

It would be great if we had a button/link similar to that in OE so that for a
specific email I can have the images that were blocked loaded. There isn't a
need to have Mozilla remember that I clicked the show images link. For example
if I click to view another email then click back to the email with remote
images, it's okay for me to have to click the button/link to have the images
load again. I state this because I assume it's easier to implement when nothing

has to be remembered.

From an evangelistic point of view, wouldn't it be great if this enhancement
landed before WinXP SP2, so that MozillaMail was never without a feature that
OE
has. :-)
seems like this is a popular feature request. since it has some GUI changes, I
propose it's a good Alpha blocker.
Flags: blocking1.7a?
*** Bug 232038 has been marked as a duplicate of this bug. ***
need to find someone to work on this if we are going to get it...
Flags: blocking1.7a? → blocking1.7a-
If the feature of a whitelist for remote image loading was added. Would/should
it be based on the email address or the server address of the images?
(In reply to comment #23)
> If the feature of a whitelist for remote image loading was added. Would/should
> it be based on the email address or the server address of the images?

I would think just "not Junk flagged" would do it.
i'd prefer that new mozilla mail features don't get tied to mozilla's junk mail
feature or at least not exclusively.  i use my own spam filtering (bogofilter)
but would still like to take advantage of image blocking and selective unblocking.
> (In reply to comment #23)
> I would think just "not Junk flagged" would do it.

I disagree.  One of the main goals of image blocking is to prevent web bugs via
image.  (BTW, I think style sheets may still get requested...this may be a
separate bug)  Using the junkmail filter would make this blocking measure
"leaky."  It only takes one http request to infect your email address, so I
would also prefer that this not be tied into the junk flag.

> (In reply to comment #22)
I think that allowing whitelisting based both sender's email and on image host
server have their uses and both should be included in this feature.
we can white list everything under the sun. However, I think it's better to have
a button to unblock the images for a specific message, without having to keep
track of it. If mozilla has 5 white/black lists thats too much stuff for users
to keep track of.

If we do go the white list route. I think it's only sensible to whitelist via
server because email addresses can be spoofed but servers cannot.
A great feature that I have seen somewhere is that if the "From" address is in
your address book then images are "whitelisted" which is a great feature.  If we
would like to go a little further, a flag inside the Address book that says
images will be accepted or not. 

Either way, I believe having a "Show Graphics/Unblock images/Load HTML" button
would be essential. 
image blocking without a button for "show this message without blocked images"
seems like a half-implemented feature.  whitelisting seems like a second-order
enhancement request kind of issue, like icing on the cake.  please don't hold
off on implementing an unblock button until whitelisting can be added.
whitelisting should really be treated as a separate issue entirely.
i agree with allyn
*** Bug 237334 has been marked as a duplicate of this bug. ***
*** Bug 238287 has been marked as a duplicate of this bug. ***
100% agreement with Comment #28: allow images if sender is in the address book
(an option in the address book entry to allow/disallow image loads is a nice
addition), and also have a button to show/hide images for the current message. 
The button shouldn't affect the global setting; it doesn't need to persist at all.

Actually, I'd like to extend this a bit, and have the option also affect the
View/Message Body As setting.  I'd like that to be globally set to "Simple
HTML", but for the same set of conditions for which I'd show images I'd like to
see "Original HTML".
Another few small issues with image handling in emails:

 - There is no visible indication of the image when it's blocked. Shouldn't just
the standard web browser handling be used (i.e. show a border round the image
and a small icon).

 - Cannot right-click and get the properties of the image.

I agree with comment 29, I would see an unblock images button as the first prioirty.

The attachement of the OE screenshot shows a good implentation. Tell the user
when there are blocked images, and offer to unblock.

In regards to whitelisting ..

Comment 27 makes a good point, about not using 'From' addresses, and not having
loads of whitelists.

When first investigating image blocking I immediately assumed the Image Manager
in mozilla would be deal with emails. Is this not the best place, as it would
avoid duplication?
I agree in first implementing an unblock button which allows users to enable
HTTP (and so on) traffic to the remote server. If the activates the feature all
data communication is blocked and can be enabled for each eMail seperatelly. 

A kind of Whitelist (e.g. enable HTML in eMail from Server xyz) is in my opinion
still necessary but mayby at lower priority. I get about 10% HTML eMails from my
total eMail (excluding junk) it would be kind of anoying over time when I have
to enable the "pictures" all the time manually. 
For the whitlist I can see the following options:

- Server Based (new whitlist): Causes an extra list to maintain by the user.
eMails send by big ISP e.g. mylist.com, yahoo etc can only be treeted the same
way. I think this is too unflexible. (I hope I have understood this idea right)

- eMail based: causes a hughe whitelist, however I can identify my HTML senders
pretty good and there aren´t this much. Personally I would prefer this method.

- Address book based: Probably my favorite one. The Adressbook is also used as a
first filter for junki mail detection as far as I´m informed. I have only
"trusted" adresses in my address book so these should be able to send me HTML
formats. This would also make an additional whitelist redundant. 
(In reply to comment #19)

This is the approach I am in favor of.  YahooMail (circa June 2004) has the
ability to enable this exact feature.  All email can have HTML images disabled,
with a link that may be clicked to enable them for just the one being viewed.

My preferred mode of operation with Mozilla (1.7rc3) is to leave email images
enabled, but to set the "View" -> "Message Body As" to "Plain Text".  Whenever I
get an email which I can see from the text mode version is probably safe to look
at, I switch "View" -> "Message Body As" to "Simple HTML" or "Original HTML",
depending upon just how much trust I have in the sender and/or content.

"Simple HTML" omits images, but honors many font settings, giving a sense of the
layout, while "Original HTML" shows pages in all their glory, with images (since
I leave those enabled).  Unfortunately, after doing this for a message, I must
remember to turn it off again, since otherwise it remain enabled for the next
message I look at.

While viewing a message, it would be great if were possible to switch to
"Original HTML" for just that viewing of that message without affecting
subsequent messages.  The default for all messages might be a Preferences
setting, which could be overridden on a message-by-message basis,
Bug 216133 is about the same issue in Thunderbird. Perhaps this helps?
I think there are 2 usual situations facing users here: (1) either that they
have disabled external image loading in mail completely but want to enable it
for this message or this sender, or (2) that they have disabled external image
loading but the email sender is using external images - perhaps because a third
party is sending their mail for them.

In case (1) the ideal would be to display a button or right-click context menu
item to load the images just this once. Offering the user anything more
sophisticated would require that they re-enable image loading and this becomes
case (2).

In case (2) the ideal would be to offer the user two choices:

(A) Load all the external images in this message just this once (perhaps
excluding any sites blacklisted in the "manage image permissions" dialog, unless
all the images came from blacklisted sites)

(B) Enable image loading from this external site or sites. You would need to
manage the possibility that an already-blacklisted external site is amongst them
- I would hate to inadvertently un-blacklist doubleclick.net for example. If a
single site is involved, the site name should ideally be displayed in the
context menu item or button -- e.g. the right-click menu offers "Allow image
loading from virgin-atlantic.com"].

The images should then load immediately once the preferences have been changed.
Don't make the user refresh the page.


Although at first sight these may seem complicated, what I'm suggesting is not
hard to implement and the user would see something much simpler and more
convenient than today: just press the button or right click to make all the
images appear, either just this once or forever. You might implement this as a
pull down button rather like the one on the print, forward and save buttons.

Alan
Perhaps some ability to check for and block beacons as well would be a
worthwhile addition.  
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Just wondering, since I don't use the suite and this bug hasn't been touched in a long time: is this still an issue? It's been in Thunderbird for a while now, and I'm just wondering.
As this feature has been added to the Mozilla Suite in the form of the continuation project SeaMonkey, shouldn't this be marked FIXED?
The backend for this was introduced by bug 216133 with the Thunderbird fix, a frontend provided with the phishing detection in bug 296758, thus this bug here should be resolved as either FIXED or WFM (problem resolved via other bugs).
->WFM
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: