## Server

1. Configure (and install if needed – though usually it's present, but barely used) Postfix or other MTA. There are guides around, it is pretty simple, and actually that's it: the rest builds around it.
2. To not look like a spammer to other servers:
   - Set DKIM: DNS record and OpenDKIM
   - Set SPF DNS record
   - Set DMARC DNS record
   - Set reverse DNS records
   - Get into DNSWL
   - If IPv6 is used, make sure that a /64 subnet is assigned (as per RFC6177)
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 uacme and certbot are fine after some tweaking (particularly setting them to run as a dedicated user, rather than root).
5. Dovecot or something else for IMAP, possibly for SMTP submission, 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 just read and compose them on the server).
6. Optionally, set Web Key Directory, DANE (RFC 7929), or other OpenPGP key discovery method.

Dovecot can also be used for SASL (for both Dovecot and Postfix). See the private server setup and simpler server setup documentation for more precise instructions, and possibly the "user authentication" note for more options.

### 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.

### Being marked as spam

Gmail (and maybe other large email providers) would occasionally mark/hide messages coming from smaller servers (and/or just not from themselves) as spam, even with SPF, DKIM, whitelists, messages being sent/delivered from them to you first. Not much can be done about it: once a mail server accepts a message, it is its responsibility to deliver it. Large commercial companies just keep messing up interoperability, as they always do.

### Spam that gets through

Not much spam gets through with just configured Postfix and postscreen, but when it does, it should be possible to report the abuse to its ISP. Though spam from those who accept such reports and resolve the issues is unlikely, and as a last resort there are `client_checks` (or a firewall) to reject messages from spammy IP addresses or subnets. But one should be careful with that, since it is rather frustrating (and all too common) when you're a good actor being treated as a bad one.

Dealing with spam coming form large providers is about as tricky as sending messages to them: they deliver spam just as regular messages, don't get blacklisted by honeypots automatically, and you proboably don't want to blacklist them manually because of all the legitimate users. Yet Gmail's abuse report form seems to be broken (simply nothing happens when I hit "submit": no network requests or UI changes, even with JS enabled), and their support is infamousely unreachable even by their own users. Then there's IP address's abuse contact (ripe-contact@google.com), but since they are their own hoster, it's probably also broken (as with the web UI, there's no visible reaction, not even automated; though at least there's a possibility of it working).

For more on incoming spam, see my network abuse notes.

### Port 25 redirection

Residential ISPs tend to block incoming SMTP connections, which is supposed to stop spam somehow, but if it was not for that, an IP address without NAT (and preferably static) would be sufficient at least to receive email directly, without a remote server. To get around that, there are services for port redirection, though I have not tried any, and they seem to be odd and/or to cost about as much as a remote VM (similarly to paid email).

## Client

Both notmuch and mu4e use xapian, which provides fast search. It is also nice to compose and read messages in Emacs (unless you are a vi user, perhaps), so I target those.

Some prefer mutt, which has a simpler configuration, and less modular, more self-contained. But its default key bindings are based on those of Vim, QWERTY-oriented, which is awkward if you use a different keyboard layout. Thunderbird is quite bloated, but perhaps more suitable for casual users. Claws Mail looked odd and half-baked all around to me each time I tried it over the years, but it is a relatively lightweight GUI client. But I focus on simpler Emacs clients (such as mu4e) in the following sections.

### Option 1: 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).

### Option 2: SSH

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

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

And `example-sendmail.sh`:

    #!/bin/sh
    ssh mail.example.com /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. Or use the sshfs method.

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/example-sendmail.sh

Later it turned out to be handy to set mail sending this way, while retrieving it via IMAP, when a public provider (Yandex) that I used for work email with my own domain, to avoid dependencies on a personal server, decided to charge for using a custom domain and disabled SMTP. That way, the work server does not have to accept SMTP connections still, and it was already configured to send mail notifications from local clients (for both a website hosted there and munin), while incoming mail is handled as it used to be.

### OpenPGP

GnuPG can be used with mu4e (and perhaps most of the other common Emacs MUAs) out of the box, does not 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 (banned in Russia), 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 (blocked in Russia), runbox.com, mailfence.com (also blocked in Russia), posteo.de, maybe mailo.com (blocked in Russia). 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 and other pubnixes, including tildeverse ones, financed primarily with donations. Also disroot.org, dismail.de (no new registrations since 2021-05-28 though), riseup.net (rather politicized, blocked in Russia).

In 2024, I registered at Microsoft's hotmail.com, but my account (which only received one confirmation message from OpenStreetMap) was locked in a couple of days, with Microsoft claiming that it violated an unidentified part of the agreement, and that they need my phone number in order to resolve it. Apparently people who provide their phone numbers are unexpectedly locked out of Microsoft accounts as well, and there are regular stories like that about Google's Gmail, too. Though it also looks like many people do manage to use those larger services. As mentioned above, I ran into an unpleasant change of service terms with Yandex as well. Also receiving Gmail spam, reporting it, but spam from the same addresses keeps coming afterwards. Interaction with those larger commercial IT companies is generally a bad experience.

## 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 is set on a single machine that you also use for everything else, that is 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 user accounts and data (commonly selling the data, messing up authentication and blocking accounts for strange reasons, with no way to contact customer support, sometimes mangling messages, restricting access to accounts until you provide more of personal data after a policy change), with the services they provide (including turning unlimited plans into limited ones, free into paid, cheap into more expensive), etc. Even technical issues with larger services may be equally or more common: though they have dedicated staff, larger setups tend to be considerably more complex and unusual, hence less reliable.

But private ones require regular payments and maintenance. It is 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 is no shortage 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. That is a hard part, since not many people seem to care about service providers, control, etc. Maybe it is a good approach though: worrying about all the small things and possibilities may be too much, whether one uses a private or a public service.

It is particularly unfortunate when other online services depend on email, allowing email-based account recovery: that way, the loss of an email address compromises those accounts as well. Sometimes it is possible to set a two-factor authentication, with the second factor being something relatively sensible, like TOTP, effectively disabling email-based account recovery that way, since that usually only allows to reset the password.