Sign and Encrypt Messages
Back in Signatures, I explained how to add a signature to the end of each message with your contact information, a quote, or other content. But a message can also have a digital signature, a (normally invisible) string of characters that confirms to the recipient that the message truly comes from the address it appears to come from, and that the message contents haven’t been altered in transit.
In addition, Mail can encrypt messages, scrambling their contents so that only someone with the necessary key (presumably, the recipient) can view their contents, thereby ensuring private communications.
In this chapter I discuss if and when you should use digital signatures and encryption, how they work behind the scenes, and how to go about signing and encrypting messages in Mail.
Learn When and Why to Sign or Encrypt Messages
Let me start with the essential question of whether, or under what circumstances, you should even think about signing or encrypting messages. It’s not something everyone needs to do, and if you never need to do it, you need not bother reading the rest of this chapter. But the need could arise at some point—and even if you don’t need to sign or encrypt, you may find that there are some benefits to doing so.
Most of us are accustomed to thinking of email as being private. One person sends a message and someone else receives it; as long as no one is looking over either person’s shoulder or snooping on their computers when they’re not around, we presume that whatever was in that message is known only to the sender and recipient.
Indeed, that’s how things work most of the time, just as with paper letters: Most of the time no one except the intended recipient opens a letter to see what’s inside. But mail theft, tampering, accidents, and honest mistakes do occur. It sometimes happens that a person who shouldn’t see what’s inside an envelope, does. And when the contents of that envelope are highly confidential, sensitive, or valuable, someone else reading your mail can become a serious problem indeed.
Email is no different. It should be private, but it isn’t always. Each message exists not only on the computers of the sender and recipient, but also (at least temporarily) on each party’s mail server. In addition, a message may pass through any number of intermediate servers and routers, and may be backed up along the way in the data centers of one or more ISPs. In any of these places, a message could be read by an employee of the ISP, and it could be intercepted in transit by a hacker—or a government agency—during its journey from sender to recipient.
(“Doesn’t SSL encrypt my messages?” you may ask. SSL secures a message only between Mail and the incoming or outgoing mail server, but doesn’t prevent someone from reading that message while it’s on a mail server, or during other legs of the delivery process.)
Because so many millions of email messages are exchanged every day, the probability that any particular message you send or receive will be read by someone who shouldn’t see it is incredibly small—but not zero. So, consider what would happen in one of these situations if the wrong person read email you sent:
You need to email your accountant detailed information about your income, expenses, and taxes.
You need to provide someone with your credit card number, social security number, or other sensitive information by email.
You’re an executive at a major computer company and you want to discuss top-secret plans for a new product with your advertising agency—but not risk leaking the information to the press.
You need to discuss a sensitive medical condition with your doctor by email, but you worry that you could lose your job if your employer finds out about it.
You’re a journalist in a politically sensitive region, and you need to file a story that the local government might find objectionable.
You’re in a country with major human rights abuses, and you want to tell your story to the world without the authorities finding out.
Get the idea? A lot could be at stake: money, a job, or even a life. In these cases and countless others, you might need a guarantee—not just a presumption—of privacy, and encrypting email is the only way both parties can be reasonably certain that no one else will read their mail.
Of course, in addition to legitimate uses, encrypted email could be used to plan crimes, conceal information from law enforcement agencies, and so on. But the point I want to get across is that ordinary people, in ordinary situations, may from time to time feel that the level of security they get from ordinary, unencrypted email isn’t adequate.
That gives you an idea of why encryption may be important, but what about digital signatures? Signing a message (with or without encryption) lets the recipient confirm that the message originated from the person whose email address is on it, and that the message wasn’t altered in transit. Given the huge volume of spam and the increasing incidence of fraudulent email, it’s common to get messages with a forged From address. A digital signature can solve this problem by letting recipients know that the person who appeared to send the message really did, and that no hacker has surreptitiously inserted ads or malware, or changed the meaning of a legitimate message.
In an ideal world, every email message would be signed and encrypted. Doing so would eliminate a great deal of fraud, spam, identity theft, and other societal ills. Unfortunately, the world is not ideal. It’s not practical to sign and encrypt everything, because some email clients (and most webmail systems, including Gmail) don’t support encryption, and even clients that do often require either special software or complicated setup steps for both sender and recipient. However, if and when the need arises, you’ll be happy to know that Mail has signing and encryption capabilities, and you can use them with only a modest amount of configuration.
Mail’s built-in encryption method, which is free to use but a pain to set up, is called S/MIME; I discuss it next. You can also use a third-party encryption tool in Mail, such as the commercial PGP (Pretty Good Privacy) or the free, open-source, PGP-compatible GnuPG (Gnu Privacy Guard). I talk about the latter in Use GnuPG for Mail.
Use S/MIME Encryption
Mail’s interface never uses this term, but the underlying mechanism it employs for signing and encrypting mail is called S/MIME (Secure/Multipurpose Internet Mail Extensions). It’s an industry standard that most other desktop email clients understand, regardless of which operating system they use. (Apple also includes S/MIME support in iOS—see Sign and Encrypt Messages in iOS. Unfortunately, many other mobile email clients don’t speak S/MIME.)
S/MIME uses a form of public-key cryptography. That means each user has a pair of keys: a public one, normally used to encrypt messages, and a private one, normally used to decrypt messages. So, I can share my public key freely, and anyone can use it to encrypt messages they send to me. However, those messages can be decrypted only using my private key, which I don’t share with anyone. Similarly, as long as I have someone’s public key, I can encrypt a message to that person, but I can’t decrypt that message, or any other message someone has encrypted using that public key.
A key (public or private) is nothing more than a long string of random-looking characters. Keys are normally wrapped in containers called certificates, which also include identifying information about the key’s owner and a digital signature from the certificate authority (the person or company who issued the certificate); the signature lets users verify that the certificate hasn’t been tampered with.
So, to get a pair of encryption keys, you must obtain a certificate, which will contain both your public key and your private key (I explain how in a moment). Mail uses macOS’s system-wide keychain to store certificates—both yours (including both the public and the private key) and those of your correspondents (containing only their public keys). Because Mail communicates with your keychain in the background, just as it does with your account passwords, you normally don’t see or interact with certificates directly.
When you sign a message using S/MIME, Mail does several things:
It calculates a hash—that is, it performs a mathematical operation on the contents of the message to come up with a unique value. If even a single character in the message were different, the message would have a different hash.
It encrypts the hash using your private key so that it can’t be tampered with. The encrypted hash is called a digest.
It includes the digest, along with a certificate containing your public key, inside the message (although this extra content isn’t visible to you, the sender).
The combination of the digest and your certificate enables the recipient’s email program to verify that the message contents haven’t changed during transit, and that your address as the sender hasn’t been forged.
Also notice something interesting about this process. By signing a message I send to you, I also send you my public key—which you can then use to encrypt messages you send to me. So, if two people want to encrypt messages to each other, the easiest way to do so is to first exchange signed—but not encrypted—messages to exchange public keys. (Don’t worry—I explain every step of this process just ahead.)
Encrypting a message is a similar process, except that Mail can encrypt a message only if you already have the recipient’s public key in your keychain. Assuming you do, Mail uses that key to encrypt your outgoing message and sends it (without the original cleartext version, of course) along with your public key certificate.
Get a Personal Certificate
If you want to sign outgoing messages, or if you want other people to be able to send you encrypted messages, the first thing you must do is obtain an S/MIME certificate. These come in a variety of forms from a variety of sources. If you work for a large organization, your IT department may be able to issue you a certificate. Most individuals, however, go directly to any of several companies called certificate authorities to obtain a certificate.
If you don’t mind paying a good bit of money and going to some bother, you can work through an involved process of proving your identity to a certificate authority and receiving a certificate that includes your name and other identifying information. However, there’s a quicker and easier way to go, with only a modest trade-off: a personal certificate. A personal certificate can be used to encrypt messages just as effectively as any other certificate, but the catch is that the certificate authority certifies only that the email address on the certificate is the same address that was used to request it; the certificate doesn’t include your name or any other personal information. If that’s good enough for you (and it probably is), you can bypass a lot of the hassle and expense usually associated with obtaining a certificate.
Several companies offer personal certificates at reasonable prices, but I know of one—Instant SSL (a reseller for Comodo, the world’s second-largest certificate authority) that gives them away for free, so what I describe here is how to get and install an InstantSSL certificate.
Follow these steps:
In your favorite web browser, visit Instant SSL.
Locate and click the Get Now button.
In the form that appears, fill in your name, email address, and country of residence. The Key Size (bits) pop-up menu should say 2048 (High Grade), the default setting. Select any of the remaining checkboxes as desired, choose and enter a revocation password (a password you create that allows you to revoke the certificate, if necessary, in the future), and click Next.
Watch your Inbox for a message saying that your certificate is ready to be picked up—normally this takes minutes (or less). (If the message doesn’t arrive within a half hour or so, make sure it’s not in your Junk mailbox.) In this message, click the Click & Install Comodo Email Certificate button.
Your default browser should open and download the certificate. Depending on your settings, it may import the certificate automatically; if not, double-click the certificate file in your Downloads folder. Keychain Access opens; if you’re asked which keychain to put the certificate in, choose Login. (If you see a message saying “Error: -26276,” just ignore it and click OK. The error message is wrong.)
You must now tell your Mac to consider your certificate to be “trusted” (which isn’t automatic, since you didn’t go through a lengthy and expensive verification process to get it).
Open Keychain Access if it isn’t already open, select Login in the Keychains list, select My Certificates in the Category list, and double-click the newly added certificate with your email address to open it in a new window. Click the triangle next to Trust and then choose Always Trust from the “When using this certificate” pop-up menu.
Close the window, enter your password when prompted, and click Update Settings.
Quit Keychain Access and close your browser window.
Quit and reopen Mail.
You’re now ready to sign messages.
Sign or Encrypt a Message
The buttons you use to sign and encrypt messages are located in the header area of new message windows (Figure 29), but they appear there only after you’ve installed an S/MIME certificate. The starburst-shaped one on the right 
is used for signing messages, and the padlock-shaped one on the left 
is used for encrypting them.
Sign a Message
To sign a message, follow these steps:
Compose and address a new message as you normally would, making sure to choose the email address that goes with your certificate from the From pop-up menu.
Select the digital signature
button; the X on the button label is replaced with a checkmark 
on a blue background.Click Send.
If this is the first time you’ve used your certificate to sign or encrypt an email message, you may be prompted to confirm that Mail may use the certificate in your keychain. If so, click Allow or (my recommendation) click Always Allow to grant Mail access to the certificate.
That’s it! Mail appends your digital signature and sends the message.
How your signature appears on the recipient’s end varies from one email client to another, but I explain how Mail handles signed messages shortly, in Read Signed or Encrypted Mail.
Encrypt a Message
Before you can encrypt a message, you must have the recipient’s public key—which means having the person’s certificate in your keychain. You can check on this by launching Keychain Access (you can find it in /Applications/Utilities), selecting Login in the Keychains list, and selecting Certificates (not My Certificates) in the Category list. If the person’s name or email address appears in the list, you should be good to go. If not, ask the person to send you a signed (but not encrypted) message. When you receive it, Mail adds the person’s certificate to your keychain.
That done, follow these steps:
Compose and address a new message as you normally would.
Select the encryption
button; when it’s selected, the padlock icon changes to a closed state 
and turns white with a blue background.The encryption button is usable only when an address field (To, Cc, or Bcc) contains an email address for which there’s a matching certificate in your keychain. If you know you have a person’s certificate but the button isn’t enabled, open Keychain Access, double-click the person’s name in the Certificate list to see that you’re using the same email address that the certificate was issued under (since a person can have more than one email address), and that the certificate hasn’t expired. If either of these problems exists, ask the person to send you a new, signed message from the proper email address, or send the message to the listed address.
Optional, but highly recommended: also sign the message by clicking the digital signature
button, changing it to the selected state.Click Send.
If this is the first time you’ve used your certificate to sign or encrypt a message, you’re prompted to confirm that Mail may use the certificate in your keychain. Click Allow or (my recommendation) Always Allow to grant Mail access to the certificate.
Mail sends the encrypted (and optionally signed) message—that’s all there is to it. (Read on to find out what happens on the other end.)
A few words of caution, however: Although encrypting a message guarantees that it’s scrambled all the way from your computer to the recipient’s, once it has been downloaded and decrypted on the other end, your message could potentially be read by anyone with access to that computer. So, the safe use of encryption requires both parties to take appropriate measures to protect the decrypted text. Also, bear in mind that S/MIME leaves all the message metadata (the name and email addresses of sender and recipient, the subject, the date and time, and so on) unencrypted, and even that information can reveal information you wouldn’t want someone else to have.
Read Signed or Encrypted Mail
Each email client has its own way of handling incoming signed or encrypted messages—and a few can’t handle them at all. Although I can’t explain what the experience is like for every client, I want to describe how Mail works with such messages.
Mail indicates, in the message header, whether an incoming message was signed, encrypted, or both (Figure 30). Other than that, however, reading encrypted messages should be entirely transparent unless something goes wrong—more on this in a moment.
When you receive a signed but unencrypted message like this one message, Mail automatically adds the sender’s certificate to your keychain. If you want to view the certificate info from within Mail, click the checkmark 
icon in the header; a dialog appears with the relevant information (Figure 31).
icon in the message header to show the certificate, just like this.In general, that’s all you need to know—you need not jump through any additional hoops to decrypt messages or verify senders. If a message arrives that Mail is unable to decrypt (for example, because your private key doesn’t match the public key the sender used), a banner appears at the top of the message that says “Unable to decrypt message.” Click the Show Details button to see (often sketchy and unhelpful) information about why Mail couldn’t decrypt it.
Use GnuPG for Mail
Symantec’s Desktop Email Encryption software, formerly known as PGP (Pretty Good Privacy) after the technology it’s based on, can also encrypt and sign messages using public-key cryptography. Unlike the S/MIME system built into Mail, PGP uses centralized computers called keyservers to hold public keys. That means you need not bother with the process of sending your correspondent a signed message to deliver your public key before they can send you an encrypted message; their software can find your public key on the keyserver automatically and transparently.
It’s a great system, but for two tiny catches. First, you must pay for the software (prices vary according to the license type and duration you choose, but the least-expensive price for a single license is about $100). And second, both sender and recipient must have the necessary software to support PGP—it’s not interoperable with S/MIME.
An alternative to PGP is GnuPG (GNU Privacy Guard, also abbreviated GPG). It uses public keyservers, just as PGP does—and because it uses OpenPGP, the same underlying standard as PGP, GnuPG users can exchange encrypted messages with PGP users. A Mail plugin called GPG Mail adds the necessary hooks to Mail; it’s part of a larger package of tools called GPG Suite, which also includes GPG Keychain for creating and managing your public and private keys and MacGPG, the engine that powers all the GnuPG components.
GPG Mail is far easier to set up than S/MIME, and you need not go to an external certificate authority to get your public and private keys. The software is largely self-explanatory, but you can find detailed instructions on the GPGTools Support site.
With GPG Mail installed, you can use the controls it adds to Mail’s windows to send messages using either OpenPGP or, if you also have it configured on your Mac, S/MIME. In fact, when replying to a message, GPG Mail is smart enough to use whichever encryption method the sender used. If you’re corresponding with recipients who can use either system, the default is to use OpenPGP, but if you change a hidden setting, GPG Mail uses S/MIME unless you tell it otherwise.
Sign and Encrypt Messages in iOS
iOS Mail supports S/MIME in much the same way macOS Mail does. Unfortunately, even in the best cases, S/MIME is rather complicated for the average user—and iOS has the most confusing, opaque implementation of S/MIME I’ve ever seen.
Relatively few people need to use S/MIME on an iOS device, and those who do won’t find it anywhere near as convenient as on a Mac. So, fair warning: If you’re not sure this is something you’ll need to do, you’ll be happier skipping all these steps! (And, if you have problems that this chapter doesn’t cover, I’m sorry to say I’m unable to offer further troubleshooting help. There are so many variables that just getting S/MIME to work correctly for every iOS device could be its own book.)
Set Up S/MIME in iOS
First, you’ll need to turn on S/MIME for each account you want to use it with and get your own certificate onto your iOS device so you can sign outgoing messages. (Unfortunately, I haven’t been able to retrieve new certificates directly from providers like InstantSSL on my iOS devices, so part of this process assumes you already have a certificate on your Mac, as described in Get a Personal Certificate.)
You must turn S/MIME support on, for any given account, to be able to see whether an incoming message received by that account was signed; to add a sender’s certificate to your iOS keychain; or to sign or encrypt outgoing messages. Turning S/MIME on, without changing any other settings, causes no harm and may be helpful, so I suggest that you go ahead and do so for each account. Here’s how to do it:
On your Mac, where you’ve already installed a personal certificate (see Get a Personal Certificate), open Keychain Access (which is located in
/Applications/Utilities). Select login in the Keychains list, select My Certificates in the Category list, and locate the certificate named after your email address on the right. Click the disclosure triangle next to the certificate, and then select the private key underneath.Choose File > Export Items, leave the name set to its default (
Certificates.p12) and the File Format set to its default (Personal Information Exchange (.p12)), choose a location (such as your Desktop), and click Save.You’ll be prompted to enter and confirm a password. Do so—seriously, do not leave the passwords blank!—and click OK. Then enter your login password (the one for your user account on your Mac) and click Allow (or Always Allow, if you prefer).
Locate the certificate file you saved in the last step and email it to yourself as an attachment.
On your iOS device, open the email message from the previous step.
If necessary, tap the attachment to download it. Then tap it again to open it. If you’re prompted to choose a device, tap iPhone—not Apple Watch.
On the Install Profile screen that appears, tap Install; if your iOS device uses a passcode, you’ll be prompted to enter it. Then tap Install on the screen that says “This profile is not signed,” and tap Install once again when prompted. Enter the certificate’s password (which you created in Step 2) and tap Next.
Tap Done.
Go to Settings > Accounts & Passwords > Account Name > Account > Advanced (or, for iCloud accounts, Settings > Accounts & Passwords > iCloud > Mail > Advanced).
At the bottom of this view, tap the switch next to S/MIME to turn S/MIME support on for that account (if it isn’t on already); when on, you see the Sign and Encrypt by Default options covered below. To exit the account settings, be sure to back up one screen and tap Done to save any changes you’ve made.
To add certificates for other accounts, repeat Steps 1–9 as necessary. You must also repeat these steps on each of your iOS devices; the certificates don’t sync via iCloud.
So far, you’ve enabled S/MIME for one or more accounts and added your own certificate(s). So if all you want to do is sign outgoing messages, you’re all set—move on to Work with S/MIME, next. However, if you also want to encrypt messages sent to someone else, you’ll need that person’s public key; we’ll get to that shortly, in Turn On Encryption.
Work with S/MIME in iOS
Now that your iOS device is set up to use S/MIME, you might imagine that you can simply turn digital signatures and encryption on or off for each message, as you can in macOS. It’s not quite that simple—but at least it’s possible.
For reasons I truly can’t comprehend, you have to turn signing on or off for an entire account, in the Settings app; that setting then persists for all messages you send until you go back and turn it off. Furthermore, Mail gives you no visual indication of whether signing is turned on, so you could easily end up sending signed messages when you don’t want to, and vice versa. It’s silly, and it’s wrong, but that’s the way it is.
Encryption is a bit more user-friendly. You can use the Settings app to tell Mail to encrypt all messages from a given account by default (which simply leaves messages unencrypted when sent to recipients for whom you don’t have a public key), but if you leave that setting off, you can still tap an icon in Mail to turn encryption on for any individual message to a recipient for which you do have a public key.
Turn On Signing
To turn on signing for an account, go to Settings > Accounts & Passwords > Account Name > Account > Advanced (or, for iCloud, Settings > Accounts & Passwords > iCloud > Mail > Advanced; for Exchange, Settings > Accounts & Passwords > Account Name > Mail > Advanced Settings). Tap Sign, turn it on, and tap the certificate you want to use (which should correspond to your the default email address for that account). Then go back two screens and tap Done.
In theory, every message you send from that account will be signed, but if you have multiple accounts or addresses, it’s easy to confuse Mail—so do yourself a favor and check two more things:
Make sure the default From address for the account also matches the certificate’s address. (I know, that doesn’t seem like it should be necessary, but in my tests, signing and encryption failed if it wasn’t the case.) To do this, go to Settings > Accounts & Passwords > Account Name > Email (or, for iCloud, Settings > Accounts & Passwords > iCloud > Mail > Email) and select the address matching the certificate.
When composing a message, make sure the From address for that particular message is the same as the address on the certificate (which must also be the default From address for that account, per the previous bullet item)—an alias to that address won’t work. If not, tap the Cc/Bcc, From line; tap the From address; and then tap the correct address in the list.
And now your outgoing messages from that account should be signed! Be sure to go back and turn signing off when you want messages to stop being signed.
Turn On Encryption
If you really want to, you can turn Encryption on in Settings for all new messages (assuming you have the recipient’s public key). Just as you did for signing, go to Settings > Accounts & Passwords > Account Name > Account > Advanced (or, for iCloud, Settings > Mail, Contacts, Calendars > iCloud > Mail > Advanced; for Exchange, Settings > Accounts & Passwords > Account Name > Mail > Advanced Settings). Tap Encrypt by Default, turn it on, and tap the certificate you want to use. Go back two screens and tap Done.
But there’s generally no need to do this, because you can turn on encryption individually for any given message with just a tap. So I suggest leaving this setting off.
As I mentioned above, there’s another element, which is that to encrypt a message to someone, you need that person’s public key. So, whether Encrypt by Default is turned on or not, Mail won’t encrypt outgoing messages unless the recipient’s public key has been added to your iOS device’s keychain. (And, oddly, that’s true even if you’re trying to send encrypted messages to yourself, and you’ve already added your own certificate to your device.) The easiest way to get it is to ask the other person to send you a signed (but not encrypted) message. Unlike Mail in macOS, Mail in iOS doesn’t grab certificates automatically from signed messages you receive. To do this manually, tap the sender’s name in the header of the signed message (marked with a small seal icon 
), tap View Certificate, tap Install, and then tap Done. Repeat with any future signed messages you receive from other correspondents.
When you address an outgoing message—with the right From address selected—Mail tells you whether it can encrypt the message:
If the sender’s name is in blue and a blue open lock
icon appears when you tap in the To field, you have a public key for that person and you can send encrypted email. Tap the lock to change it to the closed state 
(with the text Encrypted at the top), and when you send the message, it’ll be encrypted.If Mail can’t encrypt the message—usually because you haven’t installed the recipient’s public key—the address is in red with an open lock
icon, and the text Unable to Encrypt appears at the top.
Read Signed and Encrypted Messages
As long as S/MIME is turned on for the account where you receive an incoming message, you don’t have to do anything special—you’ll know a message is signed if there’s a badge 
next to the sender’s name, and you’ll know it’s encrypted if there’s a lock next to the sender’s name. (Messages that are both signed and encrypted have only the lock icon.) You can tap the badge or lock and then tap View Certificate to read its details if you’re interested, but no other steps are required.
About the EFAIL Vulnerability
Just as the fourth edition of this book was about to hit the virtual shelves, my Twitter feed started blowing up with Urgent! Breathless! Warnings! about a newly discovered vulnerability that affected email messages encrypted with S/MIME or OpenPGP. My first thought was, oh, great, my book needs revising before it’s even out. But after investigating the problem, I discovered that it wasn’t nearly as dire as it was first made out to be. Meanwhile, in the months since then, changes have occurred that have rendered the problem mostly moot.
The Problem
A team of European researchers found a vulnerability that they dubbed EFAIL. That site summarizes the issue; their complete technical paper (PDF) is here. The very short version of the problem is that there is a technique that an attacker could potentially have used to cause Mail (or another email client) to send the decrypted contents of an encrypted message to outside parties. This technique exploited a combination of weaknesses in two encryption standards, design flaws in certain modern email clients, and less-than-ideal default settings. It worked only when you received and opened a message that contained a hidden copy of encrypted email you’d already sent or received—meaning you were almost certainly being targeted directly. And it affected both S/MIME and OpenPGP.
This exploit required that the attacker already have copies of encrypted messages sent to or from you. (There are numerous ways these could be obtained, but all of them require the extra, and sometimes quite challenging, step of first hacking into your email in some way.) Once that’s done, the attacker would take the encrypted contents of one or more of these messages and hide it in a new, specially crafted, encrypted message sent to one of the original senders or recipients (and, presumably, made to look as though it comes from a trusted source). When the victim opened this message, their email client decrypted it and sent the attacker the plaintext contents of the encrypted message(s) hidden within. So, this didn’t give the attacker the ability to freely read all your encrypted email, only those specific messages sent to you or the other party in the email transaction in this sneaky way.
Why You Don’t Have to Worry
For starters, this problem had the potential to affect only people who encrypted their email—and if you weren’t one of them, there’s nothing to see here. More importantly, though, I saw no evidence that this exploit was ever used in the wild. And even if it did get out into the wild, an attacker couldn’t have used this on you without first obtaining the existing encrypted email messages from your account that they wanted the contents of. That’s a nontrivial extra step.
In any case, the potential threat didn’t last long On June 4, 2018, GPG Suite was updated to version 2018.02, with mitigations for EFAIL. (It’s been updated several more times since then, with further fixes.) Apple also made initial changes in macOS 10.13.5 to partially addresses S/MIME vulnerabilities, and included additional fixes in 10.14 Mojave. So, as long as your system software and/or GPG Suite are up to date, you should be fine.
However, even with the above fixes, there’s a remote chance someone could use a variant on this technique to read encrypted messages sent to or from you. You can immunize yourself against the most likely forms of this attack simply by preventing Mail from downloading remote images without your express permission.
To do this on a Mac:
Go to Mail > Preferences > Viewing.
Uncheck “Load remote content in messages.”
Close the Preferences window.
On an iOS device, do this:
Go to Settings > Mail.
Turn “Load Remote Images” off.
And that’s it.