The acronyms most commonly used are TLS (Transport Layer Security) and SSL (Secure Sockets Layer). As those names suggest, they are concerned with encrypting a network transaction, such as the transfer of a message from one machine to the next.
TLS should be distinguished from PGP (Pretty Good Privacy) and S/MIME, which are methods for encrypting the contents of a message but not the transport.
If you are authenticating with a plain text password, then using TLS is a good idea. For it keeps your password private, even if somebody is sniffing network packets. However, it does not guarantee the privacy of your message contents. For the message may go through several hops to get to its destination, and your use of TLS/SSL has only encrypted the network data over the first hop.
If you are a spy, or a counter spy, and need the contents of your message to be secure, you should use PGP or S/MIME or a similar method. These protect what you wrote. However, they do not protect the password you may have sent for plain text authentication.
It is possible to use both TLS and PGP. However, this web page is mainly concerned with TLS.
The use of encryption depends on establishing some kind of trust between the client and the server to which it is connected. Otherwise there is a possibility of what is called the "Man in the Middle" attack.
The standards for TLS encryption with Email depend on the use of X.509 certificates to establish the trust relationship. An X.509 is a digitally signed encryption document, that can in turn be used to verify the signature on some other digitally signed documents.
The chain of trust begins with a CA, or a Certification Authority. The CA signs various X.509 certificates. If you have a copy of the CA certificate, then you can use that to verify the validity of these digital signature.
The Computer Science Department (cs.niu.edu) has chosen to become its own certification authority. It has thus created its own CA certificate. In order to be able to use TLS with the computer science servers, you may need to first install that certificate on your system. If you are using Netscape messenger, you should install it there. If you are using other email software, you should install with Internet Explorer, which adds to the Windows trusted certificate repository.
Installing the CA certificate is harmless, in the following sense:
Once you have installed the department CA certificate, go into its property settings, and set the property to allow it to be used for signing server certificates. This should be sufficient to allow TLS secured connections to our mail servers and to our web server.
If you are uncertain about whether to allow that degree of trust, you should discuss your concerns with the system administrator.
With both Netscape messenger and Outlook Express, it is not too difficult to work your way through the mail setup menus to turn on the use of an encrypted connection (or secure connection).
Outlook express, and recent Netscape versions (6 or later) can also be set to use encrypted transport for their POP3 connections.
I have no experience with Eudora. I hear that it can be a little tricky.
Older versions of Pegasus are not capable of using encrypted transport. Since it uses CRAM-MD5 authentication, this is less of a problem. You can also setup Pegasus to use APOP for POP3 authentication. Before you do that, arrange with the system administrator, to setup an APOP password and a CRAM-MD5 password.
Newer Pegasus versions can use encrytped mail transport. However, it does not use the CA certificate verify the connection. Instead, it remembers the fingerprint of the server certificate used, and will warn you if that changes. We change our server certificates about once per year (December or January).
The X.509 certificates are used for public key encryption. The X.509 contains the public key. The owner of the certificate also has an associated private key.
The private key is used to sign transactions. The public key is used to verify the validity of the signature. This verification of signatures becomes the basis for trust.
The CA certificate is self-signed. Trust in the CA certificate has to come from elsewhere.
The CA has signed a server certificate for each server. The name of the server is part of that server certificate.
Your mail client request the server certificate, and the server supplies this. Your client uses the CA certificate to verify the server certificate. Your client also checks that the server name in that server certificate matches the name of the server it believes it is connected to. This establishes that the server certificate was issued to the indicated server.
The client and server now use public key encryption while negotiating what conventional encryption method to use. The server signs these negotiations with its server key, and the client verifies the signature using the server certificate. This step establishes that the client is communicating with the correct server, and is the protection against a "Man in the Middle attack".
The mail is now sent, with all data in the transaction encrypted by the negotiated conventional encryption method. If you are using SMTP authentication, that is handled in the encrypted session.