Email

I quite like email – perhaps mostly not because of design or technical qualities, but because nice tools exist and there's plenty of users, so it can easily be used for communication. Though even the design is not so bad: SMTP by itself is quite usable, OpenPGP is better than plain text messages (though could be much better, and there's plenty of criticizm), it's all open and federated. Some of the email criticizm goes as far as to propose to replace it with something, but without proposing any viable alternative – so it doesn't seem like the time to abolish it yet, and here are some email-related notes.

Server

  1. Configure (and install if needed – though usually it's present, but barely used) postfix or other MTA. There's plenty of guides around, it's pretty simple, and actually that's it: the rest builds around it.
  2. To not look like a spammer to other servers:
  3. To filter spam, set postscreen and regular postfix settings (see Postfix Anti-UCE Cheat Sheet and rob0's postscreen(8) configuration; a local caching DNS server is useful to speed things up a bit). It works well to filter the spam, while spamassassin (via spamass-milt, for instance) may hog too much memory for a small VM, leading to OOM killer rage. Other options include bogofilter, which would require training, and Rspamd. Postgrey may also be used.
  4. LE to obtain X.509 certificates for TLS. ACME clients are mostly poor, but certbot is usable after some tweaking (particularly setting it to use a dedicated user).
  5. Dovecot or something else for IMAP and/or synchronization over SSH (optionally: as an alternative, one can read messages via ssh on a server, retrieve them into a local maildir with rsync, or something like that).
  6. Optionally, set Web Key Directory (i.e., user keys served by a web server), DANE, or other OpenPGP key discovery method.

Dovecot can also be used for SASL (for both Dovecot and postfix); see the "user authentication" note.

IPv6 and DNSBLs

DNSBL records appear for no apparent (or discoverable) reason in spamhaus's CSS blacklist (part of ZEN), /64 IPv6 subnets at once; delisting procedure is automated but complicated by Google captcha and partially broken (it reports success without actually delisting, and sometimes reports a captcha error even after solving the captcha, which is quite hard when using Tor). See also: Blacklisted by Spamhaus SBLCSS.

One way to mitigate it is to stick to IPv4: smtp_address_preference = ipv4 in /etc/postfix/main.cf. Another one is to get a /64 IPv6 subnet, assuming that they don't just blacklist subnets at random.

Client

Both notmuch and mu4e use xapian, which provides fast search. It's also very nice to compose and read messages in emacs (unless you're a vi user, perhaps), so I'm targeting those.

Option 1: SSH

SSH-only setup allows to use just SSH keys, with no SMTP or IMAP between client and server. Messages can be retrieved with, for instance, doveadm sync, and sent with a remote sendmail. An example with relevant mu4e context variables:

(message-send-mail-function   . message-send-mail-with-sendmail)
(sendmail-program             . "/home/defanor/bin/uberspace-sendmail.sh")
(mu4e-get-mail-command        .
 ,(concat "doveadm sync sh -c "
   "\"SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh uberspace.net doveadm dsync-server\""))

And uberspace-sendmail.sh:

#!/bin/sh
ssh uberspace.net /usr/sbin/sendmail "$@"

Though an issue with this method of synchronisation (as described here, without additional customisations) is that messages removed from mu4e would be reloaded by doveadm sync, and one would have to use doveadm search and doveadm expunge instead, or switch to IMAP for cleanup.

Another caveat is that even setting the remote sendmail script as sendmail in $PATH won't necessarily make all the programs to use it: for instance, git would still require to set it explicitly (in .gitconfig or as a command-line argument), as "smtp-server":

[sendemail]
        smtpServer = /home/defanor/bin/uberspace-sendmail.sh

Option 2: IMAP + SMTP

mbsync can be used to retrieve messages via IMAP, and postfix can also be set locally to get more flexibility and better SASL options than emacs smtpmail library provides (see the user authentication note).

OpenPGP

GnuPG can be used with mu4e (and perhaps most of the other common Emacs MUAs) rather easily, doesn't require any special setup.

mu4e with git

While git-send-email(1) bypasses mu4e, receiving patches still requires to point git (or another DVCS) to a message that is normally first seen in one's MUA. I find it handy to define a custom mu4e message action that simply does (kill-new (mu4e-message-field msg :path)), so that the result can then be fed into git-am(1).

Etiquette

While there are different views and advices on email etiquette, relatively common ones are to use plain text, to properly quote relevant parts of messages when needed, to avoid bloating messages with signatures, and of course to adhere to general writing practices. Or, in other words, to be considerate and make minimal assumptions about readers' MUAs. RFC 1855 (Netiquette Guidelines) is worth reading.

Public providers

With seemingly decent email providers (e.g., fastmail.com, migadu.com), accounts cost like a hosted VM (VPS, VDS, or whatever they are called this year) or more, so it may be desirable to get a remote VM at once. Although there are slightly cheaper (or even partially free) ones as well: mailbox.org, runbox.com, mailfence.com. As for free ones, there is a few seemingly fine options, though usually they don't seem that nice after an attempt to use them; the ones commonly advertised as secure and/or ethical tend to not even provide SMTP and/or IMAP, not to mention SSH. Domain registrars tend to provide email services, though the quality varies. And there are ones like sdf.org, financed primarily with donations.

On reliability

My primary concern with using private email for everything has been that regarding reliability, which is actually broader than just email. And if it's set on a single machine that you also use for everything else, that's a single point of failure for many things.

There are potential issues with public services as well: the companies that maintain those can go out of business, usually can do whatever they want with your accounts and data, with the services they provide, etc.

But private ones require regular payments and maintenance. It's not much harder than maintaining your personal machine, and usually cheaper than paying for an internet connection, electricity, and so on, but it is an additional burden. Very small one, but collecting things like that is always unpleasant: there's plenty of other ways to get into trouble simply by staying idle.

Using 2-3 servers instead of one and teaming up with others (for both payments and maintenance) may be helpful to mitigate those issues, but that requires some trust. I guess that's the hardest part, since not many people seem to care about service providers, control, etc. Maybe it's even a nice approach: worrying about all the small things and possibilities may be too much, whether one uses a private or a public service.