The Case For Email Security

We all know that regular email is insecure; however, it may surprise you to learn just how insecure it really is. For example, did you know that messages you deleted years ago may be on servers halfway around the world? Or that your messages can sometimes be read and modified in transit, even before they reach their destination? Did you know that forging email is very, very easy? Can you trust what you read in an email? Email was not designed with security in mind, and as a result, many different solutions have evolved to plug the multitude of resulting issues.

This article will explain how email works, what the real email security issues are, what mitigations to these are generally in use, and what else you can do to protect your email.

Information security and integrity are essential as we use email to send confidential and sensitive information over this medium every day. While reading this article, imagine how these security problems could affect your business, your personal life, and your identity if they have not already.

How Email Works

This section describes the general mechanisms and paths an email message takes from sender to recipient. This should give you an overview of the different protocols (languages) involved, the different types of servers involved, and the distributed nature of email networks. The examples presented are representative of many standard email solutions but are by no means exhaustive.

Sending an Email Message

Sending an email message is like sending a postal letter. When sending a letter, it is dropped off at a local post office. The local post office looks at the address and determines which regional post office the letter should be forwarded to. Then, the regional post office looks at the address and determines which local post office is closest to the recipient. Finally, the recipient’s local post office delivers the letter to its recipient. Computers are like “post offices,” and the “Simple Mail Transport Protocol” (SMTP) is the “procedure” that an “email post office” uses to figure out where to send the letter next (i.e., the “next hop”). Any program that sends an email message uses SMTP to deliver that message to the next “post office” for “relaying” it to its final destination.

Most people send mail in one of two ways – with a web-based interface like Gmail, Outlook 365, or LuxSci WebMail, or with an “email program” program like Outlook, Thunderbird, iPhone Mail, or Mac Mail.

When sending a message with an email program on a personal computer (or phone or tablet), you have to specify an “SMTP server” so that the email program knows what computer to connect to for sending the message. This SMTP server is like a local post office. The email program talks directly to the server using the protocol (language) known as SMTP. This is like dropping off a letter at the local post office.

When using WebMail, the personal computer communicates with a web server. The “language” the internet connection uses is HTTP – “HyperText Transfer Protocol.” When sending a message with WebMail, the web server takes care to contact an SMTP server and delivers the message to it.

Delivery of email from your SMTP Server to your recipient’s SMTP Server

When an SMTP server receives an email message, it first checks if an account for the message recipient is configured on the server itself. If there is such an account, the server will drop the message in that person’s inbox (or follow other more complex user-defined rules). If there is no local account for that recipient, the server must “relay” the email message to another SMTP server closer to the recipient. This is analogous to how a local post office forwards letters to a regional post office unless it is for someone served by the post office. (Post offices don’t work this way, but this analogy easily explains the concept.) This process is known as “SMTP relaying.”

How does your SMTP Server know where to relay the message?

If the recipient’s email address is “bob@luxsci.net,” the recipient’s domain name is “luxsci.net.” Part of the DNS settings for the recipient’s domain includes a list of SMTP servers that should be able to accept email for this recipient. Multiple servers can be listed and ranked in terms of “priority.” The highest priority SMTP server listed is the recipient’s actual inbound SMTP server; the others are “backup inbound SMTP servers.” These backup servers may merely either queue email for later delivery to the recipient’s actual SMTP server or perform the same real-time delivery actions as the main SMTP server (i.e., they are redundant).

Many scenarios govern an email message’s path from the sender’s to the recipient’s SMTP Server. Some of these include:

1. The sender’s server successfully contacts the recipient’s server and sends the email message directly (black line in the figure).
2. The sender’s server can not contact the recipient’s actual SMTP server (maybe the recipient’s server is busy, down, or has some other connection problem). In this case, the sender’s server tries to contact and deliver the message to the recipient’s first backup server.
3. The sender’s server can not contact the recipient’s actual SMTP server or its first backup server. In this case, the sender’s server tries to contact and deliver the message to the recipient’s second backup server.
4. The sender’s server can not contact any of the recipient’s servers. In this case, it will queue the message and try to send it later. It will keep retrying periodically for several days until it succeeds in sending or gives up.

Any message delivered to the backup servers which queue email could go through the same process of trying to contact the recipient’s main SMTP server or higher priority backup servers. Backup servers may also queue emails for later sending or process the email themselves. (Note that a recipient may have zero or more backup servers, not necessarily two as in this example).

Note: a sender’s and recipient’s email systems may have arbitrarily complex server configurations actually handling the delivery process and performing operations such as: backups, filtering, forwarding, queueing, etc. Any number of servers may be involved and and number of copies or backups of messages may be made.

Once the email message arrives at the recipient’s SMTP Server and is finally delivered to the recipient’s inbox, the recipient may pick up the message and read it whenever they choose (as discussed below).

Each server receiving your message adds its “Received” stamp to the message headers. This stamp identifies what server received the message, at what time, and from what other server. This information allows the recipient to trace a message’s entire journey.

The takeaway from this discussion so far is that:

1. Most email servers communicate with each other using SMTP.
2. It’s impossible to tell how long it will take an email message to get from sender to recipient. You don’t know how busy the servers are, how much traffic there is on the internet, what machines are down for maintenance, etc.
3. Messages may sit in queues on any number of servers for any amount of time. Some of these servers may belong to third parties (i.e., they may not be under the purview of either the sender or the recipient).
4. Recipients can determine the internet address and name of the computer from which you send your messages, even if a spammer spoofs your email. (See Tracing the Origins of an Email Address and Hiding It)

Retrieving Email From an SMTP Server

When an email message is received, it sits in a file (or database) in an email server. You must access this content if you wish to view this email message. Any computer wishing to access the email must speak one of the email server’s languages. With some exceptions (like MS Exchange, ActiveSync, and direct use of databases), there are only two main languages that email servers understand (for email retrieval, as opposed to email sending, for which they use SMTP). One is called the “Internet Message Access Protocol” (IMAP). The other is called the “Post Office Protocol” (POP). (We will not discuss the details here, but you may be interested in Understanding Email Services for information about them.)

As a recipient, you can generally retrieve your email using a web-based interface known as “WebMail” or an “email program” program, such as Microsoft Outlook, running on your personal computer or device. The programs will talk directly to your email server and speak IMAP, POP, or something similar. With WebMail, your computer will talk to a WebMail server using a web connection (speaking HTTP); the WebMail server will, in turn, talk to your email server using POP or IMAP or something similar (like a direct database connection).

The Lack of Email Security

Email is inherently insecure. In the following sections, we will see just how insecure it is. At this stage, it is essential to point out the insecurity in the email delivery pathway just discussed:

• WebMail: If the connection to the WebMail server is “insecure” (i.e., the address is http:// and NOT https://), then all information, including the username and password, is not encrypted as it passes between the WebMail server and your computer.
• SMTP: SMTP does not encrypt messages (unless the servers in question support SMTP TLS). Communications between SMTP servers may send messages in plain text for any eavesdropper to see. For example, if your email server requests your username and password to “log in” to the SMTP server to relay messages to other servers, these may be sent in plain text and subject to eavesdropping. Finally, messages sent via SMTP include information about which computer they were sent from and what email program was used. This information, available to all recipients, may be a privacy concern.
• POP and IMAP: The POP and IMAP protocols require you to send your username and password to log in; these credentials are not encrypted (unless you use an SSL-secured connection). So, your messages and credentials can be read by any eavesdropper listening to the flow of information between your personal computer and your email service provider’s computer.
• BACKUPS: Email messages are stored in plain, unencrypted text on SMTP servers. Data backups on these servers may be made anytime, and administrators can read any data on these machines. The email messages you send may be saved unexpectedly and indefinitely and read by unknown persons.

These are just a few of the security problems inherent in email. In the next section, we will talk about communications security problems in general. Later on, we will see how these problems are commonly solved.

Security Threats to Your Email Communications

This section describes many of the common email security problems:

Eavesdropping

The internet is a big place with a lot of people on it. It is easy for someone who has access to the computers or networks through which your information is traveling to capture and read this information. Like someone in the next room listening in on a phone conversation, people using computers “near” the path an email takes through the internet can potentially read and copy messages.

Identity Theft

If someone can obtain the username and password that you use to access your email servers, they can read emails and send false email messages as you. Very often, these credentials can be obtained by eavesdropping on SMTP, POP, IMAP, or Webmail connections, by reading email messages in which you include this information, or through other means.

Invasion of Privacy

If you are very concerned about your privacy, you should consider the possibility of “unprotected backups.” You may also be concerned about letting recipients know the IP address of your computer. This information may tell in what city you are located or even find your address in some cases! This is not usually an issue with WebMail, POP, or IMAP but is an issue with the transport of email, securely or insecurely, from any email client over SMTP.

Message Modification

Anyone who has system administrator permission on any of the SMTP servers that the message visits can not only read your message, but they can delete or change the message before it continues to its destination. The recipient cannot tell if the email message has been altered! If the message were merely deleted, they wouldn’t even know it had been sent.

False Messages

It is very easy to construct messages that appear to be sent by someone else. Many viruses take advantage of this situation to propagate themselves. In general, it is tough to be sure that the apparent sender of a message is the actual sender- the sender’s name could have been easily fabricated. See “Who Stole My Email Address?”

Message Replay

Just as a message can be modified, messages can be saved, modified, and re-sent later! You could receive a valid original message, but subsequent faked messages could appear valid. This has significant implications for automated systems that ingest email and perform automated actions based on their contents.

Unprotected Backups

Messages are usually stored in plain text on SMTP Servers. Thus, backups of these servers’ disks usually contain plain text copies of your messages. As backups may be kept for years and can be read by anyone with access to them, your messages could still be exposed in insecure places even after you think that all copies have been “deleted.”

Repudiation

Because regular email messages can be forged, there is no way to prove that someone sent a particular message. This means that even if someone DID send a message, they could successfully deny it. This has implications for using email for contracts, business communications, electronic commerce, etc. See DKIM: Fight Spam and Forged Email by Signing your Messages.

Symmetric and Asymmetric Encryption in a Nutshell

To understand how we can mitigate the email security problems described above, a basic knowledge of the two main types of encryption will be advantageous. This section presents these concepts in a simple, straightforward form.

Symmetric Encryption

In symmetric encryption, you and your friend share a “secret” key. Using this key, you can encrypt a message into “cyphertext.” Cyphertext looks like a random sequence of characters and is meaningless to anyone unless they also have the secret key. Then, they can decrypt the cyphertext back into the original message and read it.

Using symmetric key encryption, eavesdropping and unwanted backups of messages are no longer a problem. It also becomes more challenging for someone to modify messages in transit in a meaningful way. An example of a popular method used for symmetric encryption is AES-256.

The problem with symmetric key encryption is that the secret key needs to be shared. Unless meeting in person, how do you securely communicate this key? What if you want to send a secure message to someone on the other side of the world? How do you quickly get them the secret key in a way that eavesdroppers can’t detect?

Message Digests/Authentication Codes

A “Message Digest” or “Message Authentication Code” is a straightforward concept. The message passes through an algorithm that creates a relatively short sequence of characters (maybe 128 or 256). This sequence of characters is a “fingerprint” of the message. Any change in the message would produce a significantly different fingerprint. There is no way to reverse engineer the original message from its fingerprint. It is almost impossible to find two messages that yield the same fingerprint (just like trying to find two strangers with the same fingerprint). An excellent modern function for this process is “SHA256“.

Message Digests are quick ways to check to see if a message has been altered. If you have a digest of the original message and compare it with a digest of the message you just received and they match, then you know that the message is unaltered.

Asymmetric Encryption

In asymmetric encryption, also known as “public key” encryption, each person has TWO keys. Any cyphertext created using one of the keys can ONLY be decrypted using the other key. For example, say you have keys “K1” and “K2.” If you encrypt your message with K1, then ONLY K2 can be used to decrypt it. Similarly, if you encrypt using K2, ONLY K1 can be used to decrypt it. This is distinct from symmetric key encryption, where only one key performs both functions on the same message.

For a detailed explanation and example of asymmetric encryption, see: How does Secure Socket Layer (SSL or TLS) Work?

In asymmetric key encryption, the two keys that each person possesses are commonly named the “private” and “public” keys because the “public” one is published or given out freely to anyone who wants a copy, and the “private” one is kept secret. The security of asymmetric key encryption depends on whether the private key is kept secret.

Asymmetric key encryption allows you to do many clever things:

• Send an Encrypted Message: To send a secure message to someone, all you have to do is encrypt it with their public key! Only the intended recipient with the matching private key can decrypt and read the message. This solves the problem of eavesdropping and the problem of sending secret keys that is inherent in symmetric key encryption. Instant email security.
• Prove You Sent a Message: To prove to someone that you sent a message, you can encrypt the message (or just a piece of it) with your private key. Then, anyone can decrypt it with your public key and read the contents. The fact that your public key decrypts the message proves that only you could have sent it (or someone with your private key).
• Sign a Message: A message signature proves that you sent the message AND allows the recipient to determine if the message was altered in transit. This is done by using your private key to encrypt a message digest at the time of sending. The recipient can decrypt this digest and compare it to a digest of the received message. If they match, the message is unaltered and was sent by you.
• Encrypted, Signed Messages: The most secure form of communication is first to add a signature and then encrypt the message plus the signature with the recipient’s public key. This combines all of the benefits of all techniques: security against eavesdropping and unexpected storage, proof of sender, and proof of message integrity.

Email Security via TLS

The easiest thing you can do to improve your email security is to use an email provider that supports “Transport Layer Security” (SSL/TLS) for their Webmail, POP, IMAP, and SMTP servers.

TLS uses a combination of asymmetric and symmetric key encryption mechanisms. If you connect to a server using TLS, the following things happen (roughly — see a full discussion):

1. The server uses its private key to prove that it is the server you are trying to connect to. This lets you know that you are not connecting to a “man in the middle” trying to intercept your communications.
2. You send the server your public key.
3. The server generates a “secret key” and sends it to you encrypted using your public key.
4. You and the server then communicate using symmetric key encryption using this shared secret key. (Symmetric key encryption is faster than asymmetric key encryption).

The benefits of TLS are twofold:

1. You can determine if you are connecting to the right server, and
2. You and the server can communicate securely.

If you get any warning messages when connecting to a server using TLS, you should think twice about ignoring them. While your provider may have a small technical problem causing the warning, they also indicate that communications are being intercepted. These warnings usually indicate one of the following:

1. The server’s SSL “certificate” (i.e., the public/private key pair) has expired.
2. Some of the information in the certificate doesn’t match your expectations. E.g., the certificate was issued for a different server name than the one you are trying to connect to. (You could be inadvertently connecting to the wrong server.)
3. An untrusted agency issued the certificate.
4. There is a “man in the middle” eavesdropping on your connection.

SSL/TLS certificates are (generally) issued by third-party agencies. These third-party companies do a “background check” on companies that request certificates and only issue certificates if the companies have a right to them. The certificate can include the company’s name, issuing company’s name, and the name of the server to which it is issued. When you connect to an SSL server, you can verify this embedded information and the fact that it was issued by a third-party company that you trust. If the certificate is valid, you can have a high degree of confidence that the server you are connecting to is the one you want to reach.

See: Everything You Wanted to Know about SSL Certificates for more details.

Using TLS ensures that communications between your personal computer and your email service provider’s servers will be encrypted. The message contents, usernames, and passwords will be hidden from eavesdroppers but only hidden from eavesdroppers between you and your service provider!

TLS services do not protect messages once they arrive at the SMTP server or when they leave an SMTP server and head to their destinations (unless your provider can and is using SMTP TLS to talk to the recipient’s SMTP server). So, it doesn’t generally protect the message contents, but it completely protects usernames and passwords from detection. This is important because it prevents identity theft, forged messages, etc.

TLS is very easy to use. It usually only involves clicking a few checkboxes in the configuration of your email client. It is transparent to your recipients – you can use TLS for these services even if your recipients can not or do not. These measures protect you and your password. We strongly encourage using TLS for email communications (and any communications over the internet) whenever possible.

Email Privacy with Anonymous SMTP

In previous sections, we wrote that when you send email via any email client (not usually WebMail, though some provider’s WebMail also does this), your computer’s internet IP address is included in the message for all recipients to see. Depending on your Internet Service Provider, this information may be used to determine your location! This could be a serious issue for people very concerned about their privacy. Other information like the email program you use is also visible to the recipient.

Anonymous SMTP services, or re-mailers, provide a good way of keeping all of the functionality of SMTP that you require while giving you back your privacy. These services typically receive your message via (Authenticated) SMTP (ideally, they would also support SMTP over TLS, as described above) and then “scrub” the message, removing all information about the computer’s address, the email program, and any other non-standard information. These services then re-email your scrubbed message to the intended recipients.

The result is that the recipients get the message just as they would have without the “Anonymous” service, except that they can only track the message back to your Anonymous SMTP server. They know who you are, based on your email address and your message content, but they have no way of knowing where you are or what email program you are using.

Most anonymous SMTP services log all information they scrub out of messages and track all activity. So, while your recipients do not know where you are, your email service provider does. This type of service prevents any real benefit to people who send unsolicited or forged emails. Their service provider can quickly respond to complaints or abuse, identify the sender, terminate the account, and bring legal measures to bear.

It provides a level of privacy that is functionally equivalent to sending through a WebMail interface.

LuxSci offers Anonymous SMTP services to all clients who have SMTP Relaying services. This service is also compatible with LuxSci’s SMTP over TLS services and only requires changing the port you use to connect to LuxSci’s SMTP servers.

Email Security via Asymmetric Key Encryption (PGP and S/MIME)

While TLS protects your password and message contents to some extent, it does not solve any other problems we have discussed: repudiation, encryption, unwanted backups, message modification, etc. This is because TLS only protects the message path as it is transmitted between you and your server and (maybe) between servers. It does not protect messages stored on disk or transmitted between servers that do not both support TLS.

The ultimate solution is to use asymmetric key encryption to provide message signatures and encryption. This completely solves the issues of:

• Eavesdropping (everything is always encrypted)
• Message modification (message digests are used)
• Message replay (you can include a timestamp in the signature)
• Repudiation (signatures allow proof of who sent the message)
• Unprotected backups (everything is always encrypted)

Asymmetric key encryption should be used with SSL so that your username and password (and message headers such as the subject) are also protected. Why? These credentials are not part of the message body and thus would not be encrypted along with the message.

Fortunately (or unfortunately), there are two widely used forms of asymmetric key encryption for email: S/MIME and PGP (see how to set PGP up). Both allow you to add signatures or encryption to your messages. PGP is compatible with standard email clients. S/MIME is built into most email programs, but you must obtain a S/MIME certificate from a third-party company or LuxSci.

Interoperability Problems

PGP and S/MIME solve many email security problems, but they also create another: interoperability. One interoperability issue is that PGP and S/MIME are entirely incompatible. If you are using PGP and your friend is using S/MIME, you will not be able to send each other secure messages.

That said, PGP has been an internet standard (OpenPGP – RFC 2440) since 1997. PGP-encrypted email accounts for a significant fraction of the current encrypted email traffic on the internet. So, using PGP will make you compatible with many people. However, S/MIME is easier to use. It is installed in most email programs and the distribution and management of certificates is often easier than with PGP. Some email clients, such as Microsoft Outlook, can be configured to use BOTH PGP and S/MIME so that you can correspond securely using whatever method is necessary.

See also: How to install S/MIME and PGP Encryption Certificates into Major Email Clients

The other interoperability issue involves exchanging keys. You need to know the public key of the recipient to send them an encrypted message. The public key is also needed to prove that a message was signed or unaltered. So it is necessary to trade public keys before secure communication can begin. There are various ways to trade keys (including email). PGP offers “key servers” from which your correspondents’ keys can be downloaded to make the process easier. However, not everyone has their PGP keys listed on a key server, let alone the same key server. Even more challenging is that not everyone uses PGP. The key exchange issue is still an impediment to sending secure messages — especially if you have to send them quickly.

Keys are usually communicated ahead of time or key management is taken care of by a secure email service provider.

Email Security Compatible with Everyone: “Secure Message Pickup”

Secure Message Pickup Encryption uses a trusted “encryption middleman” to provide almost the same level of email security offered by asymmetric key encryption but with universal compatibility. Here is how it works:

1. The sender connects to the middleman’s SMTP or WebMail portal on a secure TLS connection.
2. The middleman validates the sender.
3. The sender creates a message.
4. The message sender chooses some method for verifying the recipient’s identity. This could be via a password, a question and answer, a login to a portal, etc.
5. The middleman encrypts the message (e.g., using AES256) and stores it on his server.
6. The middleman sends a plain text message to the recipient with only a secure link to the middleman’s web portal and a unique message password that is part of the encryption key. The middleman then ‘forgets’ this password so that he cannot decrypt the message until he gets the password back from the recipient.
7. The recipient connects to the middleman’s web portal over a secure TLS connection and logs in.
8. The middleman decrypts the message and presents it to the recipient.

The encryption middleman handles all the dirty work; it doesn’t matter if the sender uses PGP and the recipient uses S/MIME. In fact, it doesn’t matter if either uses encryption at all! All that the sender and recipient need is a web browser and regular email service. The middleman takes care of everything else.

How does it solve the security problems we mentioned earlier?

1. Eavesdropping: No one can eavesdrop on the message because the sender and recipient connect to the middleman on a secure TLS connection.
2. Identity Theft: No one can steal the sender’s login or the recipient’s verification information because both the sender and the recipient use TLS connections.
3. Invasion of Privacy: The recipient knows nothing about the sender’s computer, email client, or location. She only knows that he used the middleman.
4. Message Modification: No one can modify the message because it never leaves the middleman’s server and is encrypted and signed while residing there.
5. False Messages: The message is only accessed on the middleman’s server, so no one else can pretend to send it.
6. Message Replay: No one can re-send the message because it never leaves the middleman’s server.
7. Unprotected Backups: The message is encrypted when stored, so it is secure even in backups.
8. Repudiation: The recipient knows that the sender sent the message because the middleman validated him, and digital signatures are used.

In addition, the middleman can keep a log of who accesses the message and at what times. Thus the sender can audit the message to see who has viewed it.

Notice that the message is secure and anonymous. It is encrypted and stored on the middleman’s servers, so it is not subject to the security of intermediate relaying servers. Only the middleman can encrypt and decrypt the message, and only authorized recipients can access the message. The recipient knows nothing about the sender’s computer, only that he used the middleman. As long as the middleman is trustworthy, the message is entirely secure, completely anonymous, and completely compatible.

LuxSci’s SecureLine service provides complete “Escrow” encryption as a form of Secure Message Pickup and options for PGP, S/MIME, and TLS.

SMTP TLS

There is a growing trend for SMTP Servers to support “opportunistic TLS.” If both the sending server and the recipient server support opportunistic TLS, they will automatically negotiate a secure TLS-encrypted connection and transport your email message. This has the effect of securing server-to-server delivery of email across the internet. This is great, except:

1. Some email providers do not yet support Opportunistic TLS (see who)
2. The email will be transmitted insecurely if it is not supported or the security setup fails.

An alternative to opportunistic TLS supported by LuxSci as part of SecureLine is “Forced TLS.” With Forced TLS,

1. Email going to a recipient whose servers support opportunistic TLS will be delivered via TLS or not delivered at all until TLS is working.
2. Email that is going to a recipient whose server does NOT support opportunistic TLS will automatically “fall back” to the use of some other form of encryption (e.g., Secure Message Pickup).

When TLS is “good enough” for you, it is ideal, as it is the easiest form of encryption to use. It is “business as usual,” which everyone likes. So, if TLS is good enough, use TLS with recipients who support it and use other means with those that do not.

Conclusion

Email is, in general, Completely Insecure! The primary email security issues include:

1. Eavesdropping
2. Identity Theft
3. Invasion of Privacy
4. Message Modification
5. False Messages
6. Message Replay
7. Unprotected Backups
8. Repudiation

Ways to Protect Your Emails

TLS: It is easy to use TLS to secure the communications between your computers and the email service provider. This works no matter who your recipients are. TLS improves email security in these ways:

1. It establishes that you are contacting your service provider’s computers and not someone else’s
2. It encrypts the username and password you use to log in to these servers. This mitigates identity theft and other issues.
3. It protects your message from eavesdroppers between your computer and your SMTP server.

Anonymity: If you have access to an Anonymous SMTP server, you have an easy way to increase your internet privacy. Anonymous SMTP provides:

1. IP address privacy so that message recipients cannot determine your computer’s internet address (and thus your location).
2. Email client privacy so that the recipients cannot determine what email client is used.
3. A means to strip out any other non-standard “email header” data that may be lurking in your outbound messages.

PGP and S/MIME: PGP and S/MIME keys use asymmetric key encryption to protect the contents of your messages throughout their complete journeys. They improve email security by:

1. Protection against eavesdropping and unwanted backups
2. Message Digests to detect whether messages have been altered in transit
3. Signatures to prove sender authenticity

We highly recommend the use of TLS for email communications. Unfortunately, PGP and S/MIME are not being used as extensively as they should be. More companies are using TLS and secure message pickup to encrypt communications. The impediment of setting up, enforcing usage, and training employees on PGP and S/MIME is more challenging than the benefit of use. The cost savings gained by using secure messaging are challenging to quantify, especially as most companies assume that they don’t (or won’t) have significant problems in this arena. These assumptions are changing as the threat of security issues is growing. Technologies such as S/MIME and PGP are gaining more traction with the general public.

Secure Message Pickup encryption avoids the impediments of PGP and S/MIME encryption while providing complete email security, anonymity, and other features. This has no learning curve because it can be easily integrated into an existing email system. Anyone concerned about security but doesn’t know how to set it up can use Secure Message Pickup as quickly as they use WebMail. In addition, it can communicate securely with anyone with an internet connection and regular email.

Forced TLS provides a means of communication with recipients whose email servers also support TLS. If the added benefits of having the message always encrypted, even at rest, are not requirements, Forced TLS is a good option.

Unlike computer break-ins and other security problems, problems with email security are tough to detect. You cannot tell if someone is reading your email or modifying messages subtly until it is too late (see How Do You Know If Someone has Read your Email Message?). You cannot quantify the cost of email and information security problems until it is too late.