Tag Archives: Thunderbird

While working at UVM on their Exchange 2016 deployment, we came across an interesting environmental anomaly (UVM has lots of those). The popular Thunderbird IMAP mail client installer had been customized by someone (*cough*) to handle various local environment quirks in the UW IMAP server deployment. Once of these was the use of a “mailbox path prefix” variable. When UVM migrated to Dovecot IMAP many years back now, this setting became obsolete, but I, er, I mean *someone* never removed this setting from the custom T-bird installer. Surprisingly, it appears that thousands of users in the environment have the IMAP path prefix setting defined. I guess people really loved that custom Thunderbird installer?

Smug satisfaction with the success of *someone’s* mail client installer evaporated quickly when migrating Thunderbird users to Exchange. Why? As it turns out, this setting unexpectedly causes Thunderbird to point to a non-existent mailbox folder, and thus gives the impression that the Exchange migration had resulted in the deletion of all IMAP server folders. Gah!

It took me only an hour or two to figure out how to fix this problem using PowerShell, but I then discovered that it was not really practical to package PowerShell scripts for execution on non-domain-joined computers. Why?

By default, PowerShell does not allow execution of scripts on new non-domain-joined Windows computers. But even if you could work around that problem…

PowerShell will not trust code signatures unless they explicitly were imported into the “Trusted Publishers” branch of the user’s certificate store.

So, PowerShell is not going to be of overly much use to me today, since we want this script to run on-demand in addition to as a logon script. It really would be nice if I could have taken the time to learn C#, C++, Visual Basic, or some other “real” programming language, wouldn’t it? Because now I have to fall back on VBScript again.

Last time… Last time…

The script below will detect the “mail/” IMAP path prefix and delete it if present. It also will set the server polling interval to 10 minutes if set longer than 10 (29 was the default previously, which does not work well with Exchange IMAP). If Thunderbird is running, the user will be prompted to restart their mail client:

Mozilla Thunderbird 13 arrived this week. Guess what? Our customized build process broke again. Now, when you start TB for the first time, you get greeted with the option to create a new email account with one of Thunderbird’s “partners” (in other words, email providers who paid for the honor of being put in the “welcome to Thunderbird” start dialog).

With the assistance of the awesome Ben Coddington (who does not keep a blog, but should so that you can bask in his awesomeness), I was able to track down the place that the new-new account dialog is called, and kill it by switching a preference in the “thunderbird-all.js” file.

Out buddies at MozillaMessaging are at it again… new with Thunderbird 5.0, all of the “jar” files previously present in the Thunderbird installation directory have been collapsed into a single “omni.jar” file, apparently for program load optimization.

This all would be fine with me if the omni.jar were a “normal” zip file, and the previous jars were. Instead, this is an “optimized” jar, that is not recognized by 7-zip as a valid zip archive. It is not clear to me how the jar is “optimized”, or how to re-apply optimizations when modifying the original, nor do I particularly care as load optimization is of little concern to us… we are not operating with 10 year old equipment, for the most part, so who cares?

I have had to work around the problem by using “jar.exe” from the Java JDK. This program extracts and re-creates omni.jar in a way that Thunderbird does not mind. The resultant file size is about the same, too.

Another quirk of the new version is that the default “prefs.js” file, while present in omni.jar, is not copied into the resultant Program Files directory at install time. On a clean install, there is no default prefs.js! I had to populate a new prefs.js into the “core” installer directory, outside of the new “omni.jar”.

Finally, there are no more “localized/nonlocalized” directories in the installer, just that which is within “omni”, and that which is not. So, I put our prefs.js in .coredefaultsprofile (a new directory in the installer zip). Previously it was in .nonlocalizeddefaultsprofile. Likewise, our mailnews.js and ISP Hook “.rdf” files also go in “core” instead of “localized”.

It appears that a Thunderbird 3.1 release (probably 3.1.1) introduced a change that has caused at least one entry in our UVM ISP Hook file to become invalided. Two alert distributed support staff recently reported that the SMTP Server that our installer configures now is set to perform plain-text authentication over an unencrypted channel rather than using STARTTLS.

We know that this setting was correct in the past, and we see that it still is set in our ISP profile… Thunderbird simply is ignoring the setting.

Fortunately, there is a workaround for this setting. We can modify the “mailnews.js” file in the installer to have the default value for “try_ssl” set to “2” instead of the original default of “0”. All I had to do was add a line of “sed” work to our build script:

This “sed” command searches for the phrase try_ssl", 0 and substitutes try_ssl", 2 . After repackaging, we find that the first SMTP server account created after install (which is therefore the default SMTP account) will be set to use “STARTTLS” instead of “clear text”.
I worry about future unannounced retirements of ISP Hook settings.

I had a long look at using the previous “autoconfig” (called “Mission Control Desktop”), and while this approach is powerful, it really requires too much external scripting to be effective as a deployment mechanism (MCD seems more ideally suited to management of systems in a lab environment): https://developer.mozilla.org/En/MCD

So what is the solution? It involves:

One expatriate Windows sys admin and reverse-engineering expert.

A few line of additional shell scripting to our existing build system.

The ability to distinguish capital and lowercase letters.

While explaining the ISP Hook problem to my colleague Ben Coddington, I noticed that the old Account Configuration dialogs (complete with the create “UVM Email Account” option) was still available under TB3, but that the dialog could no longer be activated following a new installation. Ben said “I’ll bet I can fix that”, and proceeded to unpack every “jar” file in the Thunderbird installation directory.

He searched around for strings found in the old config dialog, located the XUL call that brings up the dialog, and then traced this call back to the parent function that initiates account creation for new profiles. In the end we only needed to modify one line of javascript in one JAR to restore the old account dialog. In “%ProgramFiles%Mozilla Thunderbirdchrome”, we unpack “messenger.jar”, and open “.contentmessengermsgMail3PaneWindow.js”, then replace “NewMailAccount(msgWindow, okCallback);” with “MsgAccountWizard(okCallback);”. repack the archive, then drop it into the installer, and we are good to go. Other than that, it is just like using the ISP Hook with TB 2.

There is one other minor change… I also set the following additional default option in the global prefs.js file:

user_pref("mail.winsearch.enable", true);

This defaults Windows Search integration to “on” in the new account setup dialog. It is a cool new feature that everyone should use (in my opinion).

The following is the modified build script I now use to quickly repackage new Thunderbird releases into customized versions. Note that we use the free gnuwin32 version of “sed” to do our javascript modifications (be sure to use the –b (—binary) switch to avoid file munging), and we also need 7-zip (7z.exe) to handle file unpacking and packing: