S/MIME is a long-established method of sending encrypted, signed email, based on public Internet standards. We regularly come across requirements for S/MIME, particularly from regulated industries such as banking, health, and finance. S/MIME often is required when communicating between businesses and government agencies, for example.

Another secure mail standard, PGP (amusingly named as “Pretty Good Privacy”), is used more for secure person-to-person communications. It’s less popular now because the consumer versions of popular web-based email clients such as Gmail and Outlook/Hotmail aren’t able to display encrypted mail. That’s one reason much person-to-person communication that requires privacy has moved to platforms such as WhatsApp (and many others) that offer native, end-to-end encryption.

Both PGP and S/MIME require a mail client that can use keys and certificates. Many desktop and mobile clients, including Apple Mail, Microsoft Outlook, and Mozilla Thunderbird fit the bill, as do business versions of some web clients such as Microsoft Office 365. Setting up the keys takes work, but many organizations still consider it worthwhile, despite recent vulnerability disclosures requiring remedies to block loading of remote content.

S/MIME has been around since 1995 and gone through several revisions; the current version is covered by RFC 5751. It requires exchange of public keys, a non-trivial task that often requires the support of an IT team or similar resource. This is where commercial solutions from companies such as SparkPost partners Virtru and Echoworkx come in, making security easier for person-to-person business mailing (see our SparkPost/Echoworkx how-to for more information).

That said, let’s dig into plain old S/MIME a bit deeper and see what we can do with it.

Why should I care?

The short version:

• Encryption gives you message privacy.

• Signing gives you authentication (of the sender), non-repudiation of origin, and message integrity checks.

• S/MIME works differently than DKIM and DMARC and can coexist with them.

Privacy
If your messages contain nothing personal, private, or legally important, then you probably won’t need to think about S/MIME. Modern email delivery systems such as SparkPost already use “opportunistic TLS” to secure the message transport from sending server to recipient server.

The “opportunistic” part does mean however that if the sending server can’t negotiate a secure connection, we’ll send the mail in plain text. This isn’t suitable if you want to force the message to be secure all the way. You can take a peek at which mailbox providers claim TLS support and which actually do. Assuming the recipient’s server does support TLS, your message is secured like this:

TLS secures the conversations between mail servers (which it’s why it’s called Transport Layer Security). MIME (including S/MIME) is concerned with message content and its treatment, and can be thought of as being part of the “Presentation layer”.

S/MIME secures the message content all the way (“end to end”) from the message origin to the recipient mail client, encapsulating the message body.

S/MIME encrypts the message body with the recipient’s public key. The body cannot be decoded without the recipient’s private key—not by any “person in the middle” such as your ISP, SparkPost, or the recipient’s mail server.

The private key is never disclosed; it’s kept in sole possession of the recipient. The encrypted message travels over the Internet to the receiving mail server. When it lands in the recipient’s inbox, it is (usually automatically) decrypted with their private key and becomes readable.

A few S/MIME gotchas to be aware of:

S/MIME encryption has a side-effect of preventing server-based incoming message scanning for malware because the message payload is in encrypted form and therefore unidentifiable.

Note that the message headers (From:, To:, Subject: etc) are not encrypted, so the subject-line content needs to be created with that in mind.

Signing – authentication
S/MIME also provides the recipient the ability to check that the identity of the message sender is who they say they are.

The sender’s email has a certificate attached, which, rather like the certificate on a secure website, can be traced back to an issuing authority. There’s a full description of the signing process here.

We’ll take the approach of signing the mail first, and then encrypting it, so the process looks like this.

Non-repudiation
Another useful benefit of signing to the recipient is non-repudiation of origin. Consider a situation where an email message is used to approve a contract. The recipient gets the contract in a message from the sender. If the sender later tries to say, “Nope, I never sent that message to you”, then the received message shows that the sender’s certificate was in fact used.

Message integrity
The signing process creates a fingerprint of the plain source message (known as a message digest), encrypts the digest using the sender’s private key, and includes it in the delivered message. The recipient’s mail client can tell if the message body is tampered with.

Perhaps you might say, “I thought DKIM gives me message integrity checks!” Well yes, DKIM provides message body and message header integrity checks – anti-tampering guarantees. However, DKIM failure (or absence) will not usually cause the incoming message to be marked as completely invalid, …unless a DMARC policy of `p=reject` is in play (more on DMARC here). DKIM is one factor of many used by the ISP for reliable assignment of reputation to a domain and is, of course, an essential part of your messaging stack.

Your mail client will show you prominently if an S/MIME message fails signature checks:

Summary: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME is a presentation-layer capability that can work between two email end-users (with valid certificates/keys) without any action by the email admin. S/MIME provides encryption and signing and is personal to each user.

S/MIME is tied to the full sending address (local part and domain part), so, for example, alice@bigcorp.com and bob@bigcorp.com would need to have different certificates. In contrast, DKIM validates the email is coming from the signing domain. DKIM is a whole subject in itself; this article is a good place to start.

DKIM and DMARC setup is done by your email admin (working on the mail server and DNS records). Once set up, they are active for domains, rather than individual users.

How does this relate to SparkPost?

Mail systems for person-to-person messaging, such as Microsoft Exchange Server, have long supported S/MIME.

If you are using SparkPost to send to specific recipients with mail-clients that can read S/MIME, then it could make sense to S/MIME sign your messages. S/MIME signing adds further assurance that the message is actually coming from you (or your system), and has not been tampered with, which may be valuable in some use-cases. All you need for that is your own key and some free software that we’ll demonstrate in part 2 of this article.

Using S/MIME encryption is a separate choice to make. You’ll need the public key for each of your recipients. Obtaining this could be as easy as having them send you (or your app) a signed email. We’ll explore a practical tool for sending S/MIME signed and encrypted mail through SparkPost in a follow-up post.

Which clients support S/MIME?

Consumer Gmail
The ordinary Gmail web client displays incoming mail signatures (see below), but it’s not set up to hold your private key to read encrypted messages. Even if that were possible via third-party plugins, uploading your private key is not a great idea from a security standpoint.

I couldn’t get Yahoo! Mail to decode signatures in messages at all.

The consumer version of Microsoft Outlook/Hotmail accounts alert you to the presence of an S/MIME signature, but don’t give you full access to view or check the certificate.

Hosted business mail
For organizations with hosted mail, Microsoft Office 365 and G Suite Enterprise have S/MIME support.

Outlook mail clients
Client-based Microsoft Outlook (e.g. 2010 for Windows) works:

Clicking on the icons gives you more information:

On Outlook 2010 / Windows, the certificate store is accessed via File / Options / Trust Center / Trust Center Settings / Email Security / Import / Export.

Thunderbird – cross-platform and free
If you’re looking for a free client, Mozilla Thunderbird fits the bill. It’s available on PC, Mac, and Linux, and supports S/MIME across all of these. Here’s how a message looks on Mac. The “sealed envelope” icon indicates the message is signed, and the padlock indicates it was encrypted.

Clicking on the envelope/padlock displays info about the message:

Thunderbird has its own key store, accessed in similar ways on each platform:
Mac via Preferences / Advanced / Certificates / Manage Certificates
PC: menu (“hamburger” top right), Advanced / Certificates / Manage Certificates
Linux: menu (“hamburger” top right), Preferences / Advanced / Manage Certificates

Mac Mail
Mac Mail also supports S/MIME. It relies on your Mac keychain to hold your keys.

iOS Mail
Firstly, import your email account’s certificate like this, then you can view S/MIME signed and encrypted emails. They don’t really look any different on the viewing screen.

Android
Some devices and apps support S/MIME; there’s a lot of variety out there. Samsung has a guide.

Finally…

That’s our quick overview of the practical uses of S/MIME. If you want to get your own mail certificates, there’s a list of providers here. I found Comodo works well (free for non-commercial use – open this in Firefox, not Chrome).

In part 2, we’ll explore how to apply S/MIME signing and encryption to messages that you deliver via SparkPost.

Further reading
Microsoft has a good introductory article on S/MIME here.

For more info on the EFAIL vulnerability and how it’s been addressed, this is the definitive site. Other easy-to-follow explanations are here and here.