Log in

No account? Create an account


Frustrated by Thunderbird

« previous entry | next entry »
8th Oct 2005 | 12:20

We were sorry to hear earlier this week that Cyrusoft, the publishers of Mulberry, have gone bankrupt. Cyrus Daboo started writing Mulberry at Cambridge (when I was an undergraduate) with close co-operation from the Computing Service and our Mac users. Mulberry was the first really good GUI IMAP client so it's a shame to see it die an unnaturally early death. (More about the early days of Mulberry here.)

For the above reasons we have in the past recommended Mulberry to our users; we can continue to support it for the rest of this academic year, but we need to find something to replace it. To this end I have been playing around with Thunderbird. I have been sadly disappointed. It is buggy, its user interface is clunky, and it encourages users to send their passwords across the net in the clear. The latter in particular is inexcusable for a modern piece of software.

How not to do it

In which Tony goes off on one about how Thunderbird is far too difficult to configure...

When you start Thunderbird for the first time, the first thing you see is a broken "import settings" dialogue which fails to list anywhere to import settings from. Nice start!

Then Thunderbird puts you through a new account setup wizard. On the first pane you can choose from email, rss, or usenet. Having chosen the first you then go to the "identity" pane where you enter your name and email address.

Next is the slightly confusing server information pane. This allows you to choose between POP and IMAP, and type in the host names of the incoming POP/IMAP server and the outgoing SMTP server. The confusion arises from an option that appears if you select POP (which is the default), in which case another option appears which seems to be about whether or not to merge multiple POP feeds into a single INBOX - the description isn't very clear; what is worse is that there is a hrizontal line between the incoming server hostname and this option, and no line between this option and the outgoing server hostname, so the visual cues give you the wrong idea about what this relates to until you flip the POP/IMAP switch.

Note that this pane does not have any security or port number options!

Next is the user names pane in which you type in your user names for the incoming and outgoing servers. The text boxes default to the local part of your email address, which is quite nice. However there are still no security options.

The final pane allows you to give this account a friendly label for the GUI. After this the main window opens and you get asked to type in your password to log into the IMAP server.

At this point I'm pretty suspicious. Surely they can't be so stupid as to send the password in the clear? After all, the IMAP standard requires TLS support. But paranoia means I fire up tcpdump and type in a bogus password. Lo! the password appears in the tcpdump output. I peevishly cancel the login and go looking for the account settings.

The first pane of the preferences dialogue box has a button for configuring how Thunderbird connects to the Internet [sic]. Clicking that reveals that this means proxy configuration, but it doesn't use the correct terminology until you open the subordinate dialogue box. The settings for the actual mail servers are nowhere to be found in the remaining preferences panes. (This is not unprecedented, because Mac OS X Mail also does not include account settings in the preferences dialogue box.) Further digging through the menus reveals that account settings lives in the tools menu.

The primary pane for the account deals with identity information (name, email address, signature, etc.) and, somewhat out of place, the SMTP server. The latter option is in the form of a useless drop-down menu with no direct way to change the detailed settings.

The next pane is for server settings, which is only for the incoming server. This allows you to change the host name, and - mirabile dictu! - the port number. There's a security settings panel which allows you to choose how to use TLS, including the "expose my password" (i.e. "never") and "man-in-the-middle vulnerability" (i.e. "optional") settings. There's also a "secure authentication" tickybox, which like the Internet connection preferences button is clearly a meaningless euphemism for something that the developers think is too technical for users. Googling reveals that it means challenge-response authentication, i.e. CRAM-MD5 - it might also include Kerberos, but since Thunderbird has no documentation I can't easily find out.

So I turn on TLS and continue to look for the SMTP server options. Further down there is a security pane. This reveals itself to be about message encryption, not security in general. Another stupid euphemism. I eventually find the SMTP server options, entirely divorced from the rest of the account settings in a separate sub-tree of the dialogue box. This pane has a just list of one SMTP server host name, which I have to select before clicking the edit button in order to be transferred to a separate dialogue box which - at last - allows me to set the port number and TLS options.

After all that, Thunderbird is finally configured correctly, and indeed it works. However I was put through three panes of the wizard to enter the settings in the first place, which resulted in a dangerously insecure (and broken) configuration, after which I had to dig through four panels of the account settings dialogue box, after going on a wild goose chase through five panels of the preferences dialogue and one in the account settings dialogue.

This is by far the worst MUA configuration user interface I have seen - even Outlook is better. However all of them are bad, because they expose too much complexity to the user and encourage the use of insecure settings.

The right way to do it

In which Tony expounds on secure user interface design...

The following is based on a couple of simple principles: be as secure as possible by default; and never ask the user something that can be found out automatically.

The account setup wizard needs at least the following information:

  • The user's name

  • The user's email address

  • The incoming server name

  • The outgoing server name

  • The user's password.

  • By default the user's login name is the local part of their email address. There must be an option to edit this, but in many cases that will not be necessary.

When this has been entered, the software probes the servers to automatically find out the rest of the information, including port numbers, TLS settings, and authentication protocols. The algorithm goes like this:

(1) Connect to the IMAP port (143) of the incoming server and check for the STARTTLS capability. If it is available, set the incoming server options to IMAP with TLS required.

(2) If STARTTLS is not available, try the IMAPS port (993) instead. If this works, set the incoming server options to IMAPS.

(3) If either (1) or (2) succeed, do the TLS negotiation and cache the server certificate.

(4) If neither IMAP connection works, perform a similar process with the POP3 (110) and POP3S (995) ports.

Note that IMAP is preferred to POP because it works better if you use multiple MUAs, and because if you try out a POP client and forget to set the keep mail on server option, it will delete everything. However if the user's email provider doesn't give them enough storage space they may wish to override this policy; see below.

(5) Look at what authentication protocols are supported. The order of preference should be (a) Kerberos over TLS or in the clear; (b) password auth over TLS; (c) CRAM-MD5 over TLS or in the clear; (d) password auth in the clear.

CRAM-MD5 has dubious security properties, because it is vulnerable to brute-forcing attacks that password-over-TLS is not, and because the server must have a cleartext-equivalent copy of the users' passwords.

(6) Check that login works, but only if secure authentication is possible. This may require prompting for a password.

(7) Perform a similar process with the outgoing SMTP server. This is slightly more complicated because there are more possibilities. First try the submission port 587; if that doesn't work try the SMTPS port 465; if that doesn't work, try port 25. If secure authentication isn't offered, attempt to send a message from the user to the user (but abort before sending the DATA) to see if the server works as an unauthenticated relay.

I've described this process as being sequential, but in practice the software will want to perform all seven connection attempts concurrently to minimise delays that may be caused by firewalls dropping packets.

When this is complete, present to the user the results of the probe for confirmation or alteration. This will be the usual account settings dialogue box. This should include the following information and controls:

  • incoming server name, editable

  • incoming server port number, editable

  • incoming server protocol, switchable between POP and IMAP

  • incoming server TLS setting (STARTTLS, SSL-on-connect, optional, none)

  • incoming server user name

  • If secure authentication worked, there should be a friendly OK indicator, and an option for the user to view the cached server TLS certificate. If the certificate is not signed by a CA, the software should present it to the user for checking without being asked.

  • If only insecure authentication was offered, there should be a warning note. This should always appear if the user selects either of the dangerous TLS settings (the last two).

  • There should be a note if a working login has not been confirmed.

  • outgoing server name, editable

  • outgoing server port number, editable

  • outgoing server TLS setting

  • outgoing server user name

  • A tickybox to indicate whether authentication is required; if it is not checked the TLS and user name options are greyed out.

  • The outgoing server has a similar OK/unconfirmed flag and security note as the incoming server. If TLS and AUTH were not offered by the server, the security note should say that roaming may not work, but should not be as scary as for cleartext password authentication.

  • Finally, there is a button to trigger test connections using the given settings to confirm that they are working OK, a button to re-do autoconfiguration from scratch, and the usual OK/Cancel pair (though the latter should probably be greyed out for initial configuration!)

(There should probably also be options for client TLS certificate authentication as an alternative to password auth.)

As well as the initial setup, the software must allow for configuration changes caused by alterations to the server or by roaming, and should assist the user in these cases.

If secure authentication was not previously possible but the server now advertises it, the software should check that it works OK then present a dialogue box to the user saying "Secure authentication is now possible, and your settings have been upgraded to use it." with an OK button and a button that takes the user to the account settings dialogue box. The software must be very paranoid about the server's TLS certificate in this case, in order to ensure that this isn't actually a man-in-the-middle attack.

If secure authentication was previously possible but is not advertised on this connection, the software should warn the user that they may be under attack and abort the connection. The other possibility is that the user's email provider has one of those misguided setups that only allow secure connections from the public Internet, so the warning should also advise them to contact their support staff. The software should not encourage the user to turn on the "optional TLS" setting in this situation, and should cause extra work for email providers with bad setups.

If the TLS certificate changes, the user should be warned gently - particularly gently if the CA signatures on the old and new cert are both trusted.

A few final words...

I have previously considered that perhaps there should be a standard protocol for email software autoconfiguration, such as specially formatted records in the DNS that contain all the necessary information, so that all users would have to do is type in their email address. However, although SRV records can already solve most of this problem, they are not quite enough because although they tell you the host name and port number, they don't tell you about the higher-level security settings. So such a protocol is not entirely trivial; it also has the problem that it would be redundant wrt the in-band feature negotiation of IMAP and SMTP which might cause objections to the idea on architectural grounds. So the above approach of intelligent autoconfiguration is pretty close to ideal; perhaps you could make it even slicker by guessing the IMAP and SMTP server names based on the user's email address, instead of hoping that the SRV idea gets standardized.

Update: see also the expired Internet-Draft http://www.watersprings.org/pub/id/draft-hall-email-srv-02.txt

| Leave a comment | Share

Comments {7}


from: mair_aw
date: 8th Oct 2005 15:04 (UTC)

lj-cut! :-)

Reply | Thread

Ben Hutchings

from: womble2
date: 8th Oct 2005 15:13 (UTC)

Sounds good to me. Now how about implementing it?

Reply | Thread

Tony Finch

from: fanf
date: 9th Oct 2005 09:57 (UTC)

That's what the lazyweb is for!

Reply | Parent | Thread

The Uitlander

from: uitlander
date: 8th Oct 2005 15:30 (UTC)

Well, I'm a long term Thuderbird user, having migrated across from Netscape which I'd been suing since maybe 1995 in assorted different versions - so most of the setup was familair to me, and it has become a lot better than what you used to get with Netscape. FWIW I usually create a dud account using the wizard, and then go and sort out the settings I really want using the preferences dialog as I know exactly what needs to go where in that and I'd prefer not to have the wizard-style obfuscation thank you very much.

Reply | Thread

glitterboy - the dark lord of washing

from: glitterboy1
date: 8th Oct 2005 21:35 (UTC)

I was sorry to hear about Cyrusoft and Mulberry, too.

So you have two main objections (bugginess and/or UI apart) to Thunderbird and others: complexity of configuration, and encouragement of insecure access?

How serious a concern is the latter, in the context of MUAs for use with hermes? If new hermes accounts can no longer use plaintext access, and it will be phased out for all accounts by next July (i.e. before you'll be forced to withdraw Mulberry), then MUAs' behaviour in encouraging plaintext access will most certainly cause confusion and frustration, but not actually an increased security risk? i.e. pragmatically speaking, the problem is back to being one of complexity, not security?

As for complexity, what scope might there be (at least in the PWF environment) for the automated creation and personalisation of Thunderbird's prefs.js within a user's profile? It should be feasible for other MUAs, too.

With regard to obtaining settings from a server, I'm vaguely aware of Eudora's ability to use ACAP to obtain its initial configuration settings. (And you can further assist the user with 'x-eudora-option' tags.) I've never tried this, but it sounds vaguely interesting. Is this an option?

Ahem. Ignore me, this is far too serious. Time to go and do a meme....

Reply | Thread

Tony Finch

from: fanf
date: 9th Oct 2005 09:57 (UTC)

Good questions.

Yes, Thunderbird's encouragement of insecure access is not a serious ongoing problem for the reasons you state, but it does make users expose their passwords at least once, the first time they run Thunderbird and before they realise they need to do the fiddly advanced configuration thing. It might be possible for us to avoid this (depending on Thunderbird's behaviour) using the logindisabled flag pointed out by Mike. We can do this globally once all insecure access has been disabled, but until then it will have to be for connections from outside the University or not at all. (Confession: I have not yet caused it to be discussed...)

WRT the PWF, I haven't investigated how to pre-configure Thunderbird sanely (though perhaps my colleagues have). That will help a little, but most of our IMAP users run MUAs on their own desktops, not on machines managed by us.

In the past we were interested in ACAP to provide address book portability, especially between desktop MUAs and webmail and Pine etc. However ACAP hasn't taken off - only a few products support it (including Mulberry - whoops!) so it's not really worth spending time on.

Of course, if you create a new protocol for simple MUA configuration, the protocol can require sensible default behaviour from the servers and clients, so a lot of the complexity dealt with by my autodetection algorithm goes away, so the protocol simplifies itself. And you still need the autodetection code for email service providers that don't implement the new simple configuration protocol.

Reply | Parent | Thread


from: sion_a
date: 9th Oct 2005 18:36 (UTC)

My experiences as a thunderbird user earlier this year left me distinctly underwhelmed by it. Mind you, the competition didn't fare terribly well either.

Reply | Thread