Migrating to Mozilla Thunderbird

Dennis Roman Gesker

You probably already know that Mozilla Firefox is a Web browser developed and distributed by the Mozilla Foundation. The release of the browser has been met with a warm reception, and there are reports that it has even made some headway in winning market share away from the dominant Microsoft product, Internet Explorer.

You might not know that the Mozilla Foundation has also released a very fine email software product called Thunderbird. This article will outline some of the positive aspects of this software as well as some pitfalls that should be expected by an organization considering a migration to the Thunderbird email product.

Background

The experiences related here represent those of a mid-sized organization with approximately 150 email users that recently adopted Mozilla Thunderbird as its primary email application.

The organization is virtual and dynamic. Most of the organization's members interact with the firm intermittently and for specific projects. The user base is widely distributed and primarily uses notebook computers. Users are responsible for the purchase and maintenance of their own PCs as well as for selecting their own solution for Internet access, with the requirement of being able to access/exchange messages on the organization's email server. As any systems administrator might guess, when users have this level of independence, the situation can create a combination of configurations that is unwieldy and difficult to support. Also, as is often the case, system support for end users is in short supply.

Server Configuration

The firm is cost-conscious and willing to accept solutions other than those proposed or made available by the largest single software supplier, Microsoft. Instead, the company uses an email solution based on the Debian/GNU Linux distribution using Postfix for SMTP AUTH and Courier for IMAP. SMTP AUTH is authenticated simple mail transport protocol that is useful for this organization because it requires the end users to authenticate before uploading messages for delivery to others inside and outside the organization. IMAP is the Internet mail application protocol that allows the users to retrieve, store, and manage their email in such a way that all messages still reside on the server. All communication with the server uses SSL/TLS or transport layer security.

Seeking a Common Solution

Even though the server side of this mail system setup was standard, the client side was a mish mash. While the majority of the end users use Microsoft Windows and a significant portion also use Microsoft Outlook, the varied combinations presented a considerable support challenge. This situation existed for a number of reasons.

First, there are a many different versions of Microsoft Windows still in use to varying degrees: Windows 98, Windows Me, Windows 2K, and Windows XP. All of these "flavors" may also be at varying patch levels. (As an aside, I find it interesting that the situation of various products at varying levels of development in the Unix world is often portrayed as in intolerable fragmentation, while that situation is acceptable within the product line of a single company. Certainly there is a double standard where Microsoft is concerned. Others have addressed this issue in excruciating detail, so I won't diverge from the main theme of this article other than to point out that this situation significantly contributed to the challenge facing the company.)

Second, most of the users were using some version of Microsoft Outlook. Some used Outlook Express, considered a "light" version of the Microsoft Outlook that ships with the Microsoft Internet Explorer browser package. Microsoft Office package users had versions ranging from Microsoft Outlook 97 to Microsoft Outlook 2003. The "light" version of Outlook, however, seemed to be better than the "full" versions when it came to accessing the IMAP server. Here is an illustration of how the "light" and "full" versions differed in capability with regard to IMAP -- when users employed Outlook Express to send a message, the sent message was stored on the server in a folder named "Sent Items". Users who employed a recent version of the full Outlook package also had their items stored in a folder named "Sent Items", but the messages were stored on the user's local drive rather than on the server.

Third, ISPs seem to take a very wide-ranging approach to setting up a user's PC for use with their networks. These approaches ranged from simply providing a set of instructions (varying in quality), to fully automating (also varying in quality) the setup of a user's PC. Both approaches caused issues. One particular set of ISP instructions recommended deleting/removing any other email account that existed in the user's mail setup. At least one of the automated setup routines didn't bother to ask before removing existing accounts. Users trying to add the firm's email settings had experienced confusion to different extents. In one case, the firm's mail settings were detected and deleted every time the user clicked on the ISP's connect icon! In general, most of these ISPs assumed the users employed some form of Outlook as their email client.

Fourth, there were instances when users were unable to communicate with the company's SMTP server on its traditional port (port 25), because that port was blocked by their ISP. I can only assume that this was in some effort to limit spam circulating on these networks. This port blocking exacerbated the troubles of some users, because it appears that Outlook Express is unable to use SSL/TLS on ports other than port 25. We learned this when we tried to circumvent the port 25 blockage by opening a port for SMTP AUTH traffic on a higher, alternate port number.

Fifth, even though Outlook Express is free as part of the Internet Explorer package, it didn't make sense to try to standardize on a client that was only available on the Microsoft platform. It seemed that for every user running an older version of Microsoft Windows, there was a user who had switched to the Macintosh or Linux platform. An interesting predicament for this project, but I suppose it makes for a nice bell curve.

Sixth, as mentioned above, technical support was under considerable cost pressure and resources simply weren't available to support the wide variation in platforms and software. Alternatively, developing written instructions for every combination and letting users self-support didn't seem practical. From the organization's point of view, there needed to be a balance between remaining "virtual", allowing users independence in selecting their own technology, and having all users heavily and regularly relying on the company for support. It also didn't seem appropriate to the business managers to mandate that users purchase an alternative, despite the fact that some very fine IMAP client software could be obtained relatively cheaply. For instance, the Mulberry IMAP software could have been purchased for the entire organization as it stood at the time for less than $2300.

Mozilla Thunderbird: Magic Bullet?

With one shot, it seemed that we could address all of the main issues that presented obstacles or created confusion. Thunderbird is freely available, fast, stable, and multi-platform with a consistent user interface across platforms. It's capable of using the SMTP AUTH and IMAP protocols over SSL/TLS and can use SMTP AUTH and IMAP protocols on any port for which the client software is configured. That's a lot of positive attributes! Plus, most ISP setup directions and install procedures ignored Mozilla. This was a benefit because once Mozilla was set up; it remained configured regardless of subsequent changes made to Outlook or ISP.

So, was Thunderbird the magic bullet we were looking for? Almost. Despite all of Thunderbird's well-implemented and positive attributes, there were some issues that had the potential to force an organizational roll back. The most significant issues were all related to incompatibilities with Microsoft products. The bug report id numbers in Mozilla's bug tracking system that presented the most difficulties were:

1. Files sent as attachments from within Microsoft applications arrived at the recipient as "tmp" files. Bug number 273849.

2. Inability to open messages previously saved to the desktop by Microsoft Outlook ("eml" files) by double-clicking on the message (which is to say that the Thunderbird didn't register the eml extension). Bug number 26201.

3. Opening messages previously saved to the local drive either by Thunderbird or Microsoft Outlook from within Thunderbird (File... Open Saved Message...) opened the saved message but did not allow access to the attachment if one existed. Bug number 239685.

4. Mozilla Thunderbird is unable to open/process ms-tnef files that appear to the end users usually as winmail.dat files. Bug number 77811.

We addressed these issues with mixed results. Our first problem (bug 273849) was corrected very quickly after the 1.0 release of Mozilla Thunderbird. Instead of using the release posted on the main product page for Mozilla, we used one of the nightly builds, specifically version 1.0 (20041224) or rather stated the build released on 2004-Dec-24. Problem solved.

The second problem (bug 26201) was a bit of a surprise for us and affected only a few users, although they were affected significantly. A handful of our users had numerous (hundreds) "eml" files saved into directories on their local hard drives that spanned many years. This was a surprise because of the server's use of IMAP. The assumption (poorly made) was that users were managing their messages and that all messages were stored on the server. These users were using the POP protocol that had been running previously on the server and saving their email messages as "eml" files from within Outlook. This bug presented itself when a user would double-click on a saved "eml" file and Outlook Express, rather than Thunderbird would launch..

Our third (bug 239685) issue is closely related to our second issue. There is a workaround in Thunderbird whereby a user can open an "eml" file by choosing "File" and selecting "Open Saved Message". The file does indeed open, but the message is often incorrectly formatted and the user is unable to retrieve any attachment that was stored with the message. Apparently, there are many issues surrounding "eml" files (see bug 29286). Considering the speed with which Mozilla foundation applications seem to evolve, however, it's probably a safe guess that work is continuing with regard in this area.

Presently, we plan to migrate these particular users back to Outlook Express if these issues (bug 26201 and 239685) are not resolved on Mozilla's next release. Unfortunately, these users are also in the group of users whose ISP's block port 25. Because Outlook Express has difficultly with SSL/TLS on ports other than 25, we will likely have to create yet another AUTH SMTP port on a high port number that doesn't require the user to employ SSL/TLS. This would be a disappointing setback because it is a regress not only of our new found uniformity but also of security.

Finally, our fourth problem (bug 77811) that is pressuring a downgrade is Thunderbird's inability to deal with ms-tnef encoding. Ms-tnef is the Microsoft alternative to mime encoding, see:

http://support.microsoft.com/default.aspx?scid=kb;en-us;241538

MS-TNEF Encoding Solutions

To solve ms-tnef encoding incompatibilities, an organization can either install software on the client that will assist in decoding ms-tnef files or install software on the server that will translate the ms-tnef encoded files to standard mime. The best approach is to use both methods.

At the server level, there are two alternatives that do a very fine job of translating this ms-tnef encoding. Both alternatives are scripts written in Perl. In both cases, email is filtered through these scripts either directly or indirectly. The first script is tnefclean.pl:

http://www.dread.net/~striker/tnefclean

xfilter "/usr/local/bin/tnefclean.pl -f"

The second script that can be used to re-encode ms-tnef files is tnef2multipart.pl; see:

http://www.advosys.ca/papers/filter-misc/tnef2multipart.pl

http://mailtools.anomy.net/sanitizer.html

# aptitude update
# aptitude install sanitizer

1. Create a configuration file for the sanitizer program.

2. Add a rule to the configuration file to filter winmail.dat files through the tnef2multipart.pl script.

3. Make a symbolic link to the script.

4. Add an xfilter entry to the maildroprc file.

The rule for the anomy sanitizer configuration indicated at the beginning of the tnef2multipart.pl script is:

file_list_1 = (?i)(winmail.dat)
file_list_1_policy = accept:drop:drop:drop
file_list_1_scanner = 0:::/usr/local/bin/tnef2multipart.pl %FILENAME

# ln -s /usr/share/sanitizer/contrib/tnef2multipart.pl \
  /usr/local/bin/tnef2multipart.pl

xfilter "/usr/bin/sanitizer /etc/sanitizer/sanitizer.cfg"

I imagine that there is some resistance to including support for ms-tnef encoding because bug number 7811 has been listed in the Mozilla bug database tracking system since July of 2002. This is truly in contrast to the typically quick fashion of how the Mozilla Foundation addresses and resolves most bug issues.

Conclusion

Mozilla Thunderbird is a very strong product. It's a fine solution for any firm looking to unify its user base onto a common email client. It has many fine attributes. For example, it is freely available, fast, stable, and multi-platform with a consistent user interface across platforms. It's capable of using the SMTP AUTH and IMAP protocols over SSL/TLS, and can use SMTP AUTH and IMAP on any port to which the software is assigned and/or configured.

However, Mozilla Thunderbird does have some pretty sharp shortcomings related to compatibility with Microsoft products. These shortcomings go well beyond the typical end-user response of "It doesn't work the way my old software worked."

If the workarounds presented in this article are sufficient, or these issues are addressed directly by the application's developers, Mozilla Thunderbird should be considered as an alternative to almost any existing email client. Migrating to this product might even be considered, along with its Mozilla Firefox Browser cousin, as a first step for organizations looking to migrate off the Microsoft operating system and application platform.

The benefits of migrating from a myriad of email client software to Mozilla Thunderbird for this organization, which operates technologically in a loose and virtual fashion, clearly outweigh the rough edges of this quickly evolving software package.

Resources

Courier -- http:// http://www.courier-mta.org

Debian/GNU Linux -- http://www.debian.org

Fentun -- http://www.fentun.com

Maildir -- http://www.courier-mta.org/mbox-vs-maildir/

Maildrop -- http://www.courier-mta.org

Microsoft Windows -- http://www.microsoft.com

Mozilla Foundation -- http://www.mozilla.org

Mozilla's bug tracking system -- http://bugzilla.mozilla.org

Postfix -- http://www.postfix.org

SSL/TLS -- http://www.openssl.org

Wmparser -- http://www.magicwinmail.net/wmparser/download.php

Dennis Roman Gesker is presently employed as the Manager -- Special Projects for a mid-sized telecommunications contracting firm. He holds an MBA and a Masters in the Management of Information Systems from Katz GSB at The University of Pittsburgh. Dennis can be reached by email at: dennis@gesker.com.