Remote images inside iframes (or nested iframes) bypass mail's remote content blocker. Assuming remote content white listing by address book is turned off, send yourself a message with the following body: <iframe src="http://espn.com"/> When you read the message in Thunderbird 1.5.x and Thunderbird 2.x you should see the remote images load.

Note: 1.5.0.x and 2.x always load the remote images. Trunk builds block remote images because the patch landed for Bug 330443 is aggressive about denying the load in the case of unexpected errors. However, it's too aggressive as it also blocks remote content for RSS articles (Bug 359402). And it doesn't show the blocked remote content bar in the message pane.

In the case of an iframe, aRequestingLocation is going to be the src of the iframe and not the mail url for the message we are showing in the message pane. We care about the mail url because we use that to differentiate between RSS articles and messages (we allow remote images in RSS feeds). I added a routine to get the uri for the message pane and use it as the requesting location if it exists. This makes the thunderbird 2 branch build block remote images in iframes for non RSS articles. It makes the trunk builds show the remote content bar for non rss articles (the content was already getting blocked on the trunk). It also fixes 359402 for the trunk because we can now tell the difference between rss articles and messages again since we pass in the mailnews url to MailShouldLoad.

We may end up having to adjust this later to make it less restrictive since with this patch we're going to end up denying remote content in non mailnews chrome windows. But I'd rather us be over agressive right now and adjust as things come up. This is now fixed on the trunk and I will land it on the 1.8.1 branch along with 330443.

This needs to be fixed on 1.8.1 now that bug 330443 landed there to prevent bug 359402, right?

this patch landed along with Bug 330443 on the 1.8.1.1 branch for thunderbird and will be in beta 1.