go is supposed to do a good part of the protection

That protects you against most memory safety bugs (though Go is not memory safe in the presence of concurrency - data races on slices in objects shared between goroutines can break memory safety), but that doesn’t protect you against logic bugs. A lot of these can be prevented by threading a capability model through your system and respecting the principle of intentionality everywhere, but that doesn’t mean that the principle of least privilege is something to ignore. Mail servers are among the most aggressively attacked systems on the Internet so it’s a good idea to aggressively pursue both.

would you have ideas on where separations would be good to have?

At a minimum, I’d consider separating the pre- and post-authentication steps. If an attacker compromises the pre-auth process but doesn’t have valid credentials then they should find that they’ve compromised a completely unprivileged process.

The authentication should also then be a separate process. This may need some restricted filesystem access (or limited database connectivity), depending on how you store credentials (or possibly they’re loaded before the process starts before it drops privileges and the auth process is restarted whenever they change - with a target deployment of <10 users, that should be fairly simple), but it shouldn’t be allowed to create any network or IPC connections, or access most of the local filesystem.

The post-auth process should be confined to being able to inherit the network connection created when it is started and having access only to the mail store for the specific user. This ensures that no bug in the code that communicates with a user can perform filesystem accesses for other users. If the backing store is a database, the same applies, just use the database’s ACLs instead.

Some of the other services would also benefit from being compartmentalised. For example, you have spam filtering. A significant proportion of spam emails are trying to ship malware to the user, and compromising the mail server is a great way of doing this (and may avoid the need to compromise the client). Even the simple case of exhausting resources so that the next spam email gets through the filters or all email processing stops need to be in scope for this kind of threat model, so you probably want to process each inbound email in a separate process that returns a single value (spam probability) to the parent and runs with tight resource limits, so the worst that an attacker can do is push an email past the filter.

The component that does Let’s Encrypt / ACME things almost certainly needs to be isolated - anyone who compromises that can sign arbitrary private keys. I don’t know how much of ACME you’re implementing, mail servers often use the DNS-based variant since a mail server may be pointed to by MX records that it does not have an A record for. A thing that can create and update DNS records is a very high-value target.

Similarly, DMARC keys are high value (if they can be compromised then an attacker can send email that is indistinguishable from email that you sent). Signing should be done in a separate process that just does the signing and so even an attacker who compromises a client connection can do an online attack but can’t exfiltrate the keys.

As I recall, Ben Laurie added support for Capsicum to the Go standard library some years back, so these kinds of thing are fairly easy to add in Go programs.

This is just off the top of my head without thinking things through in too much detail. You can probably do a lot better understanding the shape of your code. I’d encourage you to think about three things:

• What is your threat model? What is an attacker trying to do and any given point and what should you assume that they can do? This helps frame the next steps. For example, email is often used for password-reset links, so one attack to consider is someone intercepting a password reset link. What components do they need to compromise to get there? If they compromise one user, have they compromised all of them?
• How do you enforce the principle of least privilege? For every component, what is the absolute minimum that it needs to have access to? Can you make that set smaller without losing functionality?
• How do you enforce the principle of intentionality? If a component needs to have access to two bits of important state (for example, two users’ credentials or mail boxes, two different mail boxes, a mail box and a different folder on the system), then how do you ensure that it is exercising the one that it intends to?

The last high-profile Exchange bug was a violation of the Principle of Intentionality: Exchange had access to a system location, but intended to write a configuration file into the configuration-file directory and did not use anything vaguely like a capability system to prevent this. Capsicum and similar systems make this easy: you would have a directory descriptor for the configuration directory and use it with openat and so be unable to create a config file anywhere else.

and about sieve: i’ve never used it. how does one use it with current mail stacks? from memory, i think it is a way to match messages and take action on them, like moving them to a mailbox, or possibly set flags? how does one configure the rules? just editing a text file on a server, in a web interface, or in a mail client?

ManageSieve is a protocol for sending Sieve scripts from the client to the server. Clients expose it in different ways. I’ve seen a couple of things that look like the rule editor in Outlook or Mail.app but I tend to use a Thunderbird plugin that exposes the scripts directly. It is a bit nicer than just editing the script on the server because ManageSieve doesn’t let you install a script with syntax errors and lets the server report the error to the client, so the client doesn’t need to know every extension that the server supports (and there are a lot)

Dovecot also has support for IMAPSieve, which runs sieve scripts in response to events. This is most commonly used for detecting things being added to or removed from a spam folder to trigger learning. I think you have built-in support for that? It can also be used for things like providing a virtual mailbox that auto-files email according to your latest rules if you drop mails there, or running external scripts so you can copy an email with a calendar attachment into a mail box and have the attachment passed to your calendar, and other automation workflows.

in my mind a “pure go application” does not include c code, which mattn/go-sqlite3 does. i’ve seen modernc.org/sqlite, but i’m not entirely at ease with the idea. a lot of code (sqlite), translated.

i’m afraid adding multiple storage backend options would require a relatively large storage interface. i think there are bigger fish to fry at this moment. (:

Sounds great. Thanks for the info, I’m sure I’ll be giving this a try some time. Cheers :-)