Thoughts on running small volume mail servers

[jggimi]

A couple of days ago in another thread, I was asked:

Originally Posted by fvgit

How much time & effort do you spend maintaining your mailserver? I've been remotely considering setting sth. like that up myself every once in a while. But every time Peter Hansteen posts one of his spam-related blogposts I tell myself: 'Nah, maybe not...'

I'd like to use this thread to discuss the effort, rather than all of the provisioning bits. For provisioning guidance, see Gilles Chehade's excellent blog post, Setting up a mail server with OpenSMTPD, Dovecot and Rspamd. Even if you select completely different software tools, there's plenty of good advice there about all of the fiddly bits that don't have much to do with your specific software choices, such as (prior) IP address and domain reputation, and setting up all the outgoing authentication protocols needed to participate in modern acceptable email transfer.

I perceive 2 key administrative tasks for operating mail servers:

1. Governing outbound SMTP traffic
   
   This is absolutely key to prevent both a decline in reputation and being added to blacklists.
   
   To avoid spam-pumps -- including from any IoT devices in your local networks -- unauthenticated internal mail should be blocked or rejected -- and you should either scan logs or be notified about these attempts, so you can find any spam-pumps and correct the compromised device.
   
   Authenticated mail should be monitored for volume, as a spam-pump could possibly have a valid authentication key or userid/password pair.
   
   I use a simple cron script which scans /var/log/maillog.0.gz and outputs a count of outbound emails. I can then review logs manually if I have any concerns. My mailservers block (and send to pflog) any attempts to send unauthenticated mail by internal network devices, and I check pflog files with tcpdump(8) every so often. So far, no internal spam-pumps of either kind.
2. Filtering or blocking incoming spam.
   
   This is always where most effort is expended.We want to stop all spam, but let non-spam through. There are many technologies that we can choose from to automate, or semi-automate blocking and/or filtering. But technologies shift, and we need to keep up or shift our focus. Years ago I used greylisting as a way to address incoming spam-bots, but with the advent of major mailer pools greylisting became less effective -- even harmful. In the last several years SPF analysis as a part of greylisting can make it useful once more.
   
   I use a combination of blocking and filtering. Any Email that gets through blocklists will be analyzed and tagged for sorting into an Inbox or Spam folder.
   
   Until quite recently I was using one automated blocklist (bgp-spamd), but it recently went defunct and I removed it. For years, I've been manually managing two local blocklists (short and long term). But with the recent re-addition of filters into my mail server software of choice, I've turned off all manual blocklists and have returned to using DNS-based blocklists as I used to do many years ago.