442526 - Remote content in e-mails is blocked even if explicitly allowed for a message when "Accept all images" is not selected

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[rsx11m]

This was initially observed by Rod Grisham in the SM Support forum, see http://forums.mozillazine.org/viewtopic.php?t=705155 (no duplicate found).

With bug 216133 and bug 296758, remote images in HTML messages are blocked by default, and the user is presented with an option to either show remote content for this specific message or to allow display of remote images in all messages from a specific user. Further, a global preference exists to either allow all images, only images from the originating server, or no images. This can be overridden on a per-site basis.

Currently (SM 1.1.9; SM 2.0a1pre, 2008062602), when either "Do not load any images" or "Accept images that come from the originating server only" are selected in Edit > Preferences > Privacy & Security > Images, this prohibits remote content to be shown in e-mail messages despite the mail-specific settings allowing it. Thus, clicking "Show Remote Content" or the presence of a white-list entry in the address book only results in showing remote content if also "Accept all images" is selected in the Image Acceptance Policy.

The proposal here would be to separate the policies for Mail & Newsgroups and Browser settings, to avoid overconstraining the privacy settings for messages. This could be based on the originating URI, or depend on in which context the contents are shown:

Originating protocols are http/https(/file?), indicating a web site:
(1) Global preferences allow it = all or same server;
(2) the server for the image is explicitly white-listed.

Originating protocols are mailbox/imap/(s)news, indicating a message:
(1) Global preferences allow remote content;
(2) specific message allows remote content;
(3) sender (From:) is white-listed in address book;
(4) the server for the image is explicitly white-listed.*
    (*this would depend on what is decided on bug 230463)