Warning: the following contains explicit SSL

  • Article

(or, Messaging: Port Probing Demystified)

The "Require SSL" checkbox in the account configuration wizard for POP3/IMAP accounts is an often misunderstood feature.  It's somewhat ironic, then, that the intent of the checkbox is actually to simplify account configuration.

Compare the following two screenshots taken from WM6 Standard and Mozilla Thunderbird.

WM6 Require SSL checkbox

Thunderbird account settings dialog

Notice how much more complexity there is in the Thunderbird dialog.  Now this is not intended to be a dig at Thunderbird.  In fact, as a power user I prefer and appreciate this level of control.  But I realize that my preference doesn't reflect the best user experience for someone who doesn't write email software for a living!

Pop quiz, hotshots:

  1. List the standard and secure ports for POP3, IMAP, and SMTP.
  2. What is the difference between TLS and SSL?  How do you know which your server supports?
  3. What is the difference between "Use secure connection" and "Use secure authentication"?

To expect that the average user would be able to answer any of these questions is ridiculous.  If they are able to provide the server address and username, that is already a huge win in my book.

So in the name of usability, we distilled all this down to a single, easy-to-ignore checkbox.  Users who don't care about security don't need to worry.  More informed/vigilant/paranoid users can enable the secure setting.

Probing the issue

Despite all the settings available in Thunderbird, there are really only three common connection profiles:

  1. Implicit SSL on the secure port (a.k.a. IMAPS/POP3S/SMTPS)
  2. Explicit SSL on the standard port (a.k.a. STARTTLS/STLS)
  3. Unencrypted on the standard port

Rather than ask the user to know or guess which profile matches their particular server configuration, we simply try them all until we find one that works.  We call this port probing.

Let's run through an example port probing scenario where SSL is not supported:

  1. User configures an IMAP4 account and initiates a Send/Receive
  2. Probe attempt 1
    1. Implicit SSL on IMAPS port 993
    2. Connection time out
  3. Probe attempt 2
    1. Explicit SSL on IMAP port 143
    2. Connection successful
    3. Ask server if STARTTLS is supported
    4. Server says "no"
  4. Probe attempt 3
    1. Unencrypted on IMAP port 143
    2. Connection successful (just use the connection from the previous attempt)
    3. Ask server if plaintext authentication is supported
    4. Server says "yes"
    5. Login!

Now that we know which connection method the server supports, we can continue to use that method during subsequent Send/Receive sessions.

One important aspect of this routine is that the more secure connection profiles are tried first.  In the above example, plaintext login was tried only as a last resort.

Questions arise

Q. Isn't port probing slow?

A. Yes, it can be slow since in many cases we are sitting around waiting for the socket connect attempt to time out.  But typically the probing is only done during the first Send/Receive so it is a one time cost.

Q. What if my server doesn't listen on the standard ports?

A. Specify the port number in the hostname (e.g. "imap.aol.com:143 " ).  This works for both incoming and outgoing mail server. 

Protip: Specifying the port number in this manner will influence the port probing logic to favor the specified port number and will generally speed up the connection process!

Port number in hostname 

Q. I'm using WM5 and [scenario] won't work!

A. Unfortunately there were a number of bugs in the port probing implementation in WM5 (see Errata below)

Q. Wait, you never explained what the "Require SSL" checkbox does

A. If the checkbox is checked, the port probing will never try plaintext login over an unencrypted channel.

Errata

The port probing implementation in WM5 was not perfect, though I'd venture to guess that most users never encountered these bugs.  That said, woe unto he whose email administrator did use nonstandard ports or did regard STARTTLS above all others.

If you are having email connectivity issues and you suspect port probing may be to blame, try these troubleshooting techniques:

  1. Add or remove the port number from the hostname
  2. Toggle the "Require SSL" checkbox on or off
  3. Toggle the "Outgoing connection requires authentication" checkbox on or off
  4. (Try different permutations of the above settings)

If you have control over your own mail server, some connectivity issues can be resolved by opening alternative encryption/authentication methods.  For example if your server only uses explicit SSL, try enabling implicit SSL on a different port.