💾 Archived View for thrig.me › blog › 2023 › 10 › 19 › local-smtp-server.gmi captured on 2023-12-28 at 15:48:23. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Local Smtp Server

Someone was asking about a mail server where clients would be able to send mail, local only, and obtain mails via IMAP. This will involve some work and annoyance. You'll need a mail server (Postfix or OpenSMTPD are not terrible choices) and an IMAP server (Dovecot is typical, though I haven't run IMAP in years). The mail server would probably offer SMTP AUTH via SASL on the submission port (TCP/587) over SSL for clients to send email with. So you'll need certificates and authentication setup. Probably custom authentication that does not use system accounts. "Only local" requires configuration so that clients cannot send mail to the internet. I forget how to make Postfix do that offhand (Postfix configuration isn't always easier than Sendmail was); for smtpd.conf on OpenBSD 7.4 maybe something like

    match for domain "example.org" action "get_it_to_dovecot"
    match for local action "get_it_to_dovecot"
    match for any reject

plus various tests with various suitable messages from various clients and programs. Or maybe the system mail needs to not go to Dovecot? This is how email setups get complicated.

Using a VPN would help, as SMTP servers on the internet get attacked, a lot. Custom ports for IMAP and Submission would eventually be found, and may complicate the mail client configuration. Probably not a good idea. If not a VPN:

The user passwords will need to be strong. One thing attackers do is guess user passwords. A lot. Two factor authentication is a thing, but is additional complexity. With only local email spam to the rest of the internet shouldn't be a problem, but there could be things to cleanup if a password is guessed, or the spammer might waste a bunch of resources before being shutdown.
Depending on the mail clients you may need to support custom passwords so that gmail does not have a copy of the user's system password.
Custom passwords can be made stronger than usual (like, 100 random characters to copy and paste into the mail client) but some users may need to specify a custom password if they need to manually input the password somewhere.
Authentication might be restricted to a particular group so that only members of that group can use SMTP AUTH. This will prevent passwords from being guessed for other random system accounts. Or the SMTP passwords can come from an authentication source distinct from that used by the system, in which case a custom group may not be necessary.
There should be some sort of log scanning and firewall auto-banning system to keep the password guessers down to a dull roar (unless you do two-factor auth?). fail2ban is common here, but has had a number of security vulnerabilities involving bad regex and poor use of system(3) type calls. Check for patches.
Or, you could use something to only open the service up to certain IP addresses, but that pushes complexity onto the client systems.
The mail server, imap server, log scanning, firewall blacklists, maybe a web or gemini server with a custom password changing form, system monitoring, etc. will need some amount of system resources. This is not very resource intensive, but may not fly on a micro virt or old potato. Backups, users who keep 70,000 messages in their inbox (mostly unread), and other such problems do exist.
Everything else that I've forgotten about.

Even with a VPN you may need some of the above measures. Rate limiting and detection when limits are breached might be good to have: a legitimate mail client of a legitimate user could go nuts and send thousands of messages. Some of the above issues are rare, but I'm sensitive to them as I've had to cleanup from spammers and other problems too many times. For example, an intern once did not consult with IT at all, and somehow managed to start sending a test message to everyone on a huge external mailing list lots of times.

Alternative

Other folks have simply given up on mail servers: running one is not too difficult, but there are a lot of little fiddly details that must be gotten right, various ongoing maintenance tasks, and huge downsides for potentially lots of people if you screw something up. Do you have the time and the tuits? Or how much would it cost to outsource? Is there some other way the problem could be solved, maybe with some other protocol or service?

There can be a lot to learn if you're new to running a mail server, as opposed to following the changes over the last 25 years or so. This is probably similar to a computer game where the barrier to entry is too high as the game caters to folks who have been playing it for decades, and the only ones left playing it have been grandfathered into the complexity.

tags #opensmtpd #smtp #emailhatestheliving