The cert plays no role in negotiating the TLS connection with the server, it's strictly for authentication purposes. The server determines the cipher suite to be used for the TLS connection. It is the lowest common denominator supported by both, Thunderbird, and the server.

Why the server chooses the cipher suite it does, I don't know. Since you do seem to have access to the server logs, you can probably find out.

Did you change any TLS preferences in Thunderbird via about.config?

You may also look at the Thunderbird error console if that gives any clues. Ctrl-Shift-J

Also, take a look at this support topic. https://support.mozilla.org/en-US/questions/1116781

Thanks for your reply.

The server's TLS cipher list was ALL:+RC4:@STRENGTH:!aNULL.

I didn't think about the config editor until after posting this question. All the security.ssl3.* preferences, which appear to be the supported ciphers, were defaulted to true.

The piece that I wasn't aware of was "lowest common denominator". The first cipher in the preferences security.ssl3.* list was security.ssl3.dhe_rsa_aes_128_sha. The maillog above shows that is the cipher that the mail server settled on.

I found a link, https://www.privacy-handbuch.de/handbuch_31k.htm (Google translate helps) that suggested settings for Thunderbirds security preferences. I made the suggested changes, but that didn't work with my mail server. That's something I can investigate.

Then I saw your post. The "lowest common denominator" part seems to be the key. I should be working on the mail server configuration, not Thunderbird, changing the mail server's postfix smptd settings to require the better ciphers. The email clients would be (forced into) using a more secure connection without the users having to configure them.

Thanks, Bill

Thinking about it, the term "lowest common denominator" probably is somewhat misleading.

I think this describes it more accurately: In TLS the client sends a list of supported cipher suites, ordered from most preferred to least preferred. The server also has a list of supported cipher suites ordered by preference, and selects its most preferred cipher suite that the client also supports.

The answer to my original question is:

 bring up the 'Thunderbird Preferences' window,
 click on the 'Config Editor' button
 accept the risk
 search on security.ssl3.
 the first preference in the list is:
    security.ssl3.dhe_rsa_aes_128_sha ( a 128-bit cipher)
 set it to false
 the second preference in the list is:
   security.ssl3.dhe_rsa_aes_256_sha (a 256-bit cipher)

with that change in settings, the email server negotiated a TLS connection using the second preference which is a 256-bit cipher.

That is the simplest answer to my question.

It may be advisable to continue setting preferences for ciphers to false until the set suggested in the www.privacy-handbuch.de link above are arrived at. security.ssl3.dhe_rsa_aes_256_sha was not in that list.

Since I was looking for a more secure cipher, this would probably be a better answer to my question.

Since I didn't understand the negotiation between the email server and Thunderbird in setting up a TLS connection, I was looking to fix the poor selection of cipher by configuring Thunderbird.

Since I manage the postfix email server, It appears that better choice is to configure postfix's main.cf to "harden the SSL connection". I will restore Thunderbird to its original configuration and try the postfix settings specified in https://bettercrypto.org/static/applied-crypto-hardening.pdf.

Thanks for your help is getting me to this understanding.

Bill