OpenBSD’s Guide to Netiquette

The OpenBSD’s mailing list page netiquette section is excellent. It is a distillation of how to communicate online, i.e.:

  • Plain text, 72 characters per line [or simplest formatting available]
  • Do your homework before writing
  • Include a useful subject line [or headline]
  • Trim your signature
  • Stay on topic
  • Include important information
  • Respect differences in opinion and philosophy

Using only plain text is extreme outside of email. But, the idea that formatting should not get in the way of content is good. Know what you are talking about. Help others to understand. Give them all the relevant information. Trim out anything that does not move the discussion forward or is confusing. Treat everyone with respect.

It’s good advice for any kind of communication and for life. It’s relevant to writing an email, a newsletter, a blog post, an article or anything else you may do.

Inbox Zero and the Search for the Perfect Email Client | Ars Technica

“Are you the sort of person who needs to read and file every email they get? Or do you delight in seeing an email client icon proudly warning of hundreds or even thousands of unread items? For some, keeping one’s email inbox with no unread items is more than just a good idea: it’s a way of life, indicating control over the 21st century and its notion of productivity. For others, it’s a manifestation of an obsessively compulsive mind. The two camps, and the mindsets behind them, have been a frequent topic of conversation here in the Ars Orbiting HQ. And rather than just argue with each other on Slack, we decided to collate our thoughts about the whole ‘inbox zero’ idea and how, for those who adhere to it, that happens.”

—”Inbox zero and the search for the perfect email client.” arstechnica.com. May 13, 2018.

There is no perfect email client. You have two choices.

1. Let things sit in your inbox and deal with new email as it comes in.

2. Configure filters, file and delete email, so you don’t have email collecting in your inbox.

There is a right answer. The ability to manage email is a basic 21st century skill. Maybe artificial intelligence and your email client will one day do it for you, but currently, it is a skill you just need to learn.

You Give Up a Lot of Privacy Just Opening Emails. Here’s How to Stop It | WIRED

“[Email tracking] tech is pretty simple. Tracking clients embed a line of code in the body of an email—usually in a 1×1 pixel image, so tiny it’s invisible, but also in elements like hyperlinks and custom fonts. When a recipient opens the email, the tracking client recognizes that pixel has been downloaded, as well as where and on what device. Newsletter services, marketers, and advertisers have used the technique for years, to collect data about their open rates; major tech companies like Facebook and Twitter followed suit in their ongoing quest to profile and predict our behavior online…

…To prevent third-parties from leaking your email, meanwhile, Princeton’s Englehart says “the only surefire solution right now is to block images by default.” That is, turn on image-blocking in your email client, so you can’t receive any images at all.”

—Brian Merchant. “How Email Open Tracking Quietly Took Over The Web.” Wired. December 11, 2017.

As discussed in my post A Text Only World there is no surefire way to stop this kind of tracking. Even if you use text only email, which isn’t a bad idea, you will still be tracked if you follow links and so forth. But, sticking with text over HTML is often a more secure and less convenient option.

A Text-Only World

“Security-conscious users must demand that their email providers offer a plain-text option. Unfortunately, such options are few and far between, but they are a key to stemming the webmail insecurity epidemic.

Mail providers that refuse to do so should be avoided, just like back alleys that are bad places to conduct business. Those online back alleys may look eye-pleasing, with ads, images and animations, but they are not safe.”

—Sergey Bratus and Anna Shubina. “The Only Safe Email is Text-Only Email.” The Conversation. September 10, 2017.

Taking the position that “the only safe email is text-only email” is problematic for two main reasons:

  1. Security is a process, and nothing is “safe”.
  2. Security has to be balanced against other requirements, such as functionality.

To see the problem in this position, let’s logically extend it to a more radical position. Why stop with email? Why not also advocate for the use of text-only web browsers?

I exclusively use text-only email and use text-only browsers on occasion. I think they are great. They are faster. They cut down on advertising, tracking and other nonsense. For users with visual impairment, they are an obvious choice and work better with text-to-speech software.

But, they do this by getting rid of features like javascript, which many sites use to provide some of their functionality. Of course, it is possible to create versions of websites (or email) that work without requiring javascript, like Google has done with Gmail, but it does not always make sense to do, e.g., YouTube, and often, it is not in the business interests of the companies involved to do it, such as Facebook, websites of financial institutions, etc.

Which brings us to the key point, security comes at a cost. If you choose a text-only email client/provider or browser, then many of the emails you read or the websites you visit will not work as the author intended. This can protect you from the occasional phishing website or email containing a virus from a criminal organization. But, it’s no guarantee. Further, for every email or website this protects against, there will be thousands of legitimate emails and websites that will not work as intended.

The reality is, by selecting text-only email, you’ll start to see many emails with text with the following: “If you have trouble viewing this email, read the online version: [link]”, and it will become second nature to copy and paste that link into a modern browser to see the “correct” version of the email. Changing to text-only email does provide a little more incentive to think about the link, but for most people, it will introduce a lot more inconvenience, and the change will have little impact on their security.

 

OpenBSD: Configuring mutt & gpg/gpg2

After spending some time configuring the mutt email client to use gpg2 in OpenBSD 6.1 and not finding a straight-forward explanation online, I thought I would document my process so other novice OpenBSD users would not have the same difficulties I had. I have used these same instuctions with some modification to configure mutt on Debian, Arch and other Linuxes, and it has helped me get to a working configuration.

  • Install mutt and gnupg.

# pkg_add -i mutt gnupg [add cyrus-sasl to your package manager on linuxes without it baked in]

A series of options will display. Pick the current version of mutt-1.8.0v3-gpgme-sasl and gnupg-2.1.15p2.

  • Copy the system example gpg.conf file to your home directory.

$ cp /usr/local/share/gnupg/options.skel /home/bedouin/.gnupg/gpg.conf

  • Add this text to the gpg.conf file [seemed necessary on OpenBSD, not on some varieties of Linux sans gnome]

# Enable gpg-agent
use-agent
pinentry-mode loopback

  • Start the gpg-connect-agent daemon.

$ gpg-connect-agent

  • Import your secret and public keys into your keyring (see man if you need to make them new).

$ gpg2 –decrypt file.sec.gpg | gpg2 –import –batch

  • After import, check to make sure the secret keys imported.

$ gpg2 -K

  • Create a file /home/bedouin/.gnupg/email-password.gpg with this text.

set imap_pass = “yourpassword”
set smtp_pass = “yourpassword”

  • Encrypt email password file.

$ gpg2 –encrypt /home/bedouin/.gnupg/email-password.gpg

  • Finally, create a .muttrc configuration file and add a line to decrypt your password, which also has the benefit of launching gpg-agent and saves your password for use in mutt. Example:

# email configuration

set ssl_starttls = yes

set ssl_force_tls = yes

set folder = imaps://user@emailprovider.com:993

set spoolfile = imaps://user@emailprovider.com/INBOX

set postponed = +Drafts

set record = +Sent

set trash = +Trash

mailboxes = +INBOX

set hostname = emailprovider.com

set from = user@emailprovider.com

set smtp_url = smtp://user@emailprovider.com:587

set postpone = ask-yes

set delete = ask-no

set editor = “emacs”

set visual = “emacs”

set noconfirmappend

# Email password
source “gpg2 -dq /home/bedouin/.gnupg/email-password.gpg |”

# GPG

set pgp_sign_as = user@emailprovider.com

set pgp_use_gpg_agent = yes

set pgp_timeout = 3600

# Reduce polling frequency to a sane level
set mail_check=60

# keep a cache of headers
set header_cache=~/.hcache

# Display download progress
set net_inc=10

This should get you to a working set-up to read and write email. This discussion helps make explicit a few points that took me a few hours to figure out, e.g., without gpg-connect-agent started, I had not imported my secret key into my key ring despite thinking I had.

Also, I tried to indicate where gpg-connect-agent and some of these other steps were unnecessary on Linux distros in an update a year later.

Good luck!