If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

block/unblock loading of remote content based on filters

NEW
Unassigned

Status

MailNews Core
Filters
--
enhancement
13 years ago
3 years ago

People

(Reporter: Andy, Unassigned)

Tracking

1.0 Branch

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

Using much the same UI as for designing filters, it'd be nice to prevent 
automatic loading of graphics and other external linkage, based on customisable 
rules.

An example would be

Sender            is|isn't             in my address book --
                                                           |
                                             Collected Addresses

|*| block loading of external references




Or even based on labelling

Label         is|isn't         1|2|3|4|5|0 none***


| | block lading of external references



This would be a godsend to those that hate having their email addresses tracked 
with inbuilt HTML, while leaving the legitamate mailings and whatnot intact. 

*** If the "allow arbitrary number of labels is implemented (I sure hope so) 
then this could possibly need rethinking for large amounts of labels. Although, 
I'd hazard a bet that most people would never go above 20 - 30 labels...

Reproducible: Always
Steps to Reproduce:

Comment 1

13 years ago
Dupe of bug 172184?
Component: Preferences → Filters
Product: Thunderbird → MailNews
Summary: not a bug: feature request → block/unblock loading of remote content based on filters
Version: unspecified → 1.0 Branch
(Reporter)

Comment 2

13 years ago
Possibly. It's the same situation being discussed, but a different method for
implementing it. The comments for that bug all seem to be centered around a
"click if you want to see it" kind of scenario.
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01".

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

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

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

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

Comment 4

12 years ago
Confirming, as this is a sensible suggestion in my point of view and it is still
not present in TB1.5b1 AKAIK.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: mscott → nobody
QA Contact: filters
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core

Comment 5

7 years ago
I'd like to add my voice to this (OLD) request - its especially useful because

1: emails from mailing lists often use unusual addresses e.g. notification+m5wbsb2a@facebookmail.com 

2: You can't add the "Display remote content" to entries that are in remote directories (especially Mac OSX) (this was reported as a bug, but I can't find it now).

Both these cases could easily be handled by filters IF (and only if) the filter allows overriding the "Don't Load remote content "default. 

- Mitra

Comment 6

7 years ago
Mitra's ping inspired me to write this blog post:

http://mesquilla.com/2010/05/20/javascript-custom-filter-action-in-new-filtaquilla/

that demos how a javascript custom filter action in my FiltaQuilla extension can be used to enable display of remote content policy.

Comment 7

6 years ago
Bug #370165 is a specific case of this which would be solved by the same solution - i.e. action in Filters.

Comment 8

5 years ago
Allowing this in Filters would also solve the problem of emails from specific constructed addresses - such as Facebook Notifications - which you don't want to put in the Address Book or it causes other problems - see Bug #784069

Comment 9

5 years ago
There is a general philosophy issue here on new filter actions and search terms that needs to be discussed at some point.

As you can see from FiltaQuilla, it is possible to add so many possible filter actions and search terms that the existing drop-down lists of actions and searches becomes unwieldy and confusing to people who want the more common actions and searches. So my own feeling on this is that there is a progression on possible implementations:

Least commonly needed: use a javascript search term or filter action
Less commonly needed: include as an explicit item in an extension
Commonly needed: include in core.

I showed in the reference from comment 6 how this current request is easily doable, so the issue now is whether the request is needed enough to raise to the level of core. IMHO the proper way to determine this is to first write a simple extension that adds it, then demonstrate that that extension is heavily used.

Comment 10

5 years ago
Except that 
a) this is a really common request - there are at least half a dozen related bug reports that would be solved by a filter action.  
b) ALL Mac OSX users need this, because of bug #482616 as we can't set it on individual addresses.
c) most people don't figure out how to use extensions
d) extensions break - I run alpha or beta releases and extensions are often disabled because of incompatability, once its in the core it tends to stay operational. 
e) once the geeks get the solution (extension / preference) they tend to ignore the bug, and the Muggles never get a solution and just see it as a bug. 

For example ... now I've figured out that there is a preference 
mailnews.message_display.disable_remote_image 
that can be set to false so that it never asks me about remote content, I'm probably going to ignore this.

Comment 11

3 years ago
I support this feature request wholeheartily. It is very tedious clicking "Show Remote Content" or "Always load remote content from xxxx@xxx.xx" every time.

Background:
For example a telco company uses a different address for every newsletter they send. I.e.:
-donotreply@news.telstra.com
-telstraemailbill_noreply8@online.telstra.com
-telstraemailbill_noreply6@online.telstra.com
-telstraemailbill_noreply5@online.telstra.com

I wish to set a filter "@*.telstra.com", so that any mail I get from telstra automatically loads the remote content.

Otherwise called a whitelist, filter or such, whichever meets the naming conventions used in Thunderbird.

It will still satisfy privacy advocates as the request is on the basis of opt-out of privacy protection. All non-whitelisted

It will also prevent the address book getting clogged with addresses the user never intends to use, as the whitelist/filter will be separate to the address book.

Comment 12

3 years ago
Aside comment to my previous post:
The KB talks about to use the Config editor to create a mail.trusteddomains setting (http://kb.mozillazine.org/Privacy_basics_%28Thunderbird%29)

It pretty much sounds like the functionality this feature request is looking for, except:
- it doesn't seem to work
- it has no UI
- it does not support wildcards, subdomains

Comment 13

3 years ago
Just open Options | Privacy and go and whitelist telstra.com (assuming the pics also reside on their domains)

Comment 14

3 years ago
Thank you! I realised it has been added since the latest few updates of Thunderbird. I was using a slightly older version.

I think the implemented functionality satisfies the feature request.
You need to log in before you can comment on or make changes to this bug.