I recently released a new version of FiltaQuilla for Thunderbird and SeaMonkey, and one of its cool new features is a custom filter action that runs arbitrary JavaScript. This relies on new backend features, so you’ll need TB 3.1 beta2 or later for this to work.
Mitra recently pinged bug 249191 asking for a filter action that affects remote content. That looked like a good application of a javascript filter action, so I tried it out.
Looking at the underlying code in nsMsgContentPolicy.cpp, there is a message header property “remoteContentPolicy” that can be used to enable showing of remote content for a message. Unfortunately disallowing content appears more complex, as the address book whitelisting appears to override the message header value. But really I think that allowing remote content on a per message basis is probably the more common action need, so let me demo that.
In my documentation for FiltaQuilla, I show a simple basic javascript example of a custom action that affects a message header subject property:
for (let index = 0; index < msgHdrs.length; index++)
{
let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
hdr.subject = "[Hello, world] " + hdr.subject;
}
It’s fairly easy to modify this to set the remoteContentPolicy instead. The result is:
for (let index = 0; index < msgHdrs.length; index++)
{
let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
hdr.setUint32Property("remoteContentPolicy", 2);
}
So if you enter this as a JavaScript custom filter in JunQuilla, you can enable remote content on messages controlled by a filter.
I tested it on a spam message that had “Exxon” in the subject. The resulting filter, including the javascript, looks like this:
I’m sure that defining these filters is beyond the skill of all but a few advanced users, but once the code is written it’s pretty much just cut and paste to get this to work. If I collect a few more examples, I suppose I should create a webpage to show them.
Thanks to jcranmer, Standard8, and bienvenu on IRC channel #maildev for helping to point me to the base code that manages remote content policy.


This is hot! If you don’t already, I’d be sure to mention this in the AMO page as an important feature, as I know folks have been asking for this functionality in Mozilla since we started.
Hey I’m all for “Freedom to choose”
And remote content is a good example.
But how about other kinds of content, specifically Javascript.
Right now, it is impossible to enable JS as content within an email or newsgroup post, but on the the other hand, we can’t stop it in a “content tab” that is; RSS or a mail start page rendering.
That doesn’t seem to be quite fair to me.
Hi Joe,
I’m sure you’re aware of the discussions that went on that disabled javascript access for emails in Thunderbird 3, even if users wanted to override that. As I understand the logic, it was that 1) javascript exploits occur on a regular basis, and need to be fixed in security updates. 2) email is too efficient of a method to distribute such exploits. 3) the vast majority of users that would enable javascript really don’t understand the risks involved.
That is clearly a decision about the target audience of Thunderbird. That is, Thunderbird is targeted to be a basic email application targeting the masses, rather than an engine of innovation targeting sophisticated users. Or perhaps it is a decision that caters to a philosophy that people must be protected from their own stupidity, rather than a freedom at all costs philosophy. Regardless, I had nothing to do with those discussions, and they don’t really have much to do with filters.
I would hope that the decision about javascript would be reconsided at intervals, but with the current aversion to controversial discussions, I doubt that will happen in the foreseeable future.