I was able to get the ability to send e-mails & stop the timeout by changing the outgoing server settings back to "None" for connection security from SSL/TLS & the port changed back. Can I still have some type of security for the outgoing e-mail without triggering problems like this?

You are asking the wrong people. Ask you ISP why they do not support modern SSL/TLS used.

Given Thunderbird has inherited the changes made to Firefox. We only support TLS. (SLL is fundamentally broken and deprecated by the folk that decide these things.). Additionally there are only 2048 it cypher key supported along with only certain cyphers.

A good way to know if you can use SSL/TLS with a server is to put it into this web site. https://www.htbridge.com/ssl/

It will test the mail server and tell you if it is actually secure.

Thanks. I called my ISP and they said some e-mail clients cause problems with SSL conection security. The website you mentioned gave wi.rr.com an F grade, so it looks like they don't support that. Other authentication options I can use in Thurderbird are: "Encrypted password", "Kerberos/GSSAPI", "NTLM", and "OAuth2". The ISP reccomended I stay with "Password, transmitted insecurley", though, as encryption can cause problems with attatchments on some e-mails.

Any reccomendations on if I shoud keep trying for more security on the outgoing server, or does Thunderbord take care of this somewhat?

I'd also like to change form POP to IMAP, so I'll backup my messages and make the port switch. Is that the usual way to transition to IMAP on Thunderbird since the Server Settings-Server Type field is listed as "POP Server" without a drop-down box to change it to anything else?

Apart from Matt's advice, I think you need to understand that SSL/TLS doesn't encrypt message content. These tools are aimed principally at protecting the login and password; all the message content is generally passed as clear text.

If you want end-to-end encrytption, either both parties need to set up to use S/MIME or GPG, or you put your sensitive material into a separate document, encrypt that and send it as an attachment. Word and other Office documents can be "locked" with a password, or you can compress the document and protect it with a password. A good zip utility should let you password protect a compressed file.

If you go down the S/MIME or GPG route, both you and your correspondents will need to enable it (that may mean using an add-on e.g. Enigmail), generating key pairs, and exchanging your public keys.

POP and IMAP are two separate email protocols, and internally, I suspect that like virtually all email clients, Thunderbird will use two completely independent email client libraries.

When you set up an account, you select which protocol to use, and the appropriate client module is engaged. This in turn affects the organisation of data storage and which settings are offered. You can't switch between POP and IMAP behaviour by simply revising port settings.

Set up the account again, but this time select IMAP. When this new account is up and running in Thunderbird, transfer messages from the old POP-connected account into the new IMAP-connected account, and then delete the POP-connected account. It is generally unhelpful to run POP and IMAP variants of the same email account side by side.

We're hampered by the terminology here. Thunderbird refers to "accounts" but they are not the same as the "email account" offered by your provider. From one point of view, the email account (as offered by your provider) is a somewhat ideal and intangible conceptual entity. It exists even without you making use of it or even accessing it.

But one "email account" can have multiple practical manifestations. You could have it set up in various computers or other devices using POP, IMAP or even via a web interface. They are all ways of making use of the email account. In Thunderbird, an "account" is essentially a connection configuration that lets Thunderbird negotiate with a server to gain access to the messages it receives and to send new messages. You could in theory set up one email account as several separate accounts in Thunderbird, using a mix of POP and IMAP, along with accompanying SMTP "accounts" used to send messages. It isn't practically useful to do this, but I'm trying to make the point that "account" in an email client isn't quite the same as the "email account" offered by your provider. Indeed, in Thunderbird, "account" embraces POP, IMAP, SMTP, NNTP, RSS and various Instant Messaging ("chat") protocols.

SSL/TLS doesn't encrypt message content. These tools are aimed principally at protecting the login and password; all the message content is generally passed as clear text.

I think the wording is a little confusing. TLS encrypts data in flight. That includes login and password as well as message content. It does not protect data at rest, e.g. messages stored on ones computer or the provider's server. End-to-end encryption is needed to protect data at rest as you already explained above.

My understanding is that TLS/SSL encrypts the link between client and server, so that's between Thunderbird and the SMTP server. If you can provide a link to any authoritive description that says it works otherwise I would read that with interest.

An email client communicates with the next server in line; it doesn't, as far as I know, make any connection to the recipient's incoming IMAP/POP server. So the encryption, regardless of what part of the message it applies to, stops after the SMTP server, which is why I describe it as not being there to protect content.

ISTR using a packet sniffer on an SSL-connected email transaction and being surprised at seeing message content in plain text.

My understanding is that TLS/SSL encrypts the link between client and server, so that's between Thunderbird and the SMTP server.

Correct.

An email client communicates with the next server in line;

Yes, an email client communicates with the next SMTP server in line.

it doesn't, as far as I know, make any connection to the recipient's incoming IMAP/POP server.

Not with an IMAP/POP server anyway. If at all, then with a SMTP server.

So the encryption, regardless of what part of the message it applies to, stops after the SMTP server, which is why I describe it as not being there to protect content.

Not necessarily. A decent email provider would also encrypt SMTP-to-SMTP server communication. However, there is no guarantee for it.

ISTR using a packet sniffer on an SSL-connected email transaction and being surprised at seeing message content in plain text.

Then something went terribly wrong.