I respect the writeup, although personally think the use-case described is too specific for general mail hosting. I have had a different experience for a similar amount of time running a couple of mail servers for home and work myself. I didn’t have the luxury of avoiding spam/virus filtration on the work server due to the domain’s history and the nature of 3rd party users with varying degrees of tech literacy. Most issues I have faced with maintaining these servers have been down to the filtration elements the author was able to avoid, specifically the virus scanner growing in memory footprint as hot new virus definitions are included. The overall virtual footprint of my postfix/dovecot/sql/nginx/roundcube/spamass/clamav stack has grown significantly over the years on clam alone, depsite no real change in usage patterns.
Ongoing maintenance outside of ClamAV has been minor, but something will pop up now and again when a large 3rd party makes a decision that forces others to follow suit, or a new mail client is picky about protocols, etc.
At the time I needed to deploy these servers, the task was more difficult and required a lot more scrutiny than most other admin work I had done at that point (from a history of web server and backup system maintenance). The mail servers tended to require more active maintenance than most other small/self-hosting roles like web/file/game servers, or deploying a NAS or network gateway with a taylor-made distro/OS. Familiarity was the main roadblock; there was a lot of mail-specific terminology and best practices that differ from other server software. There is also a lot of ‘legacy friction’ related to bolting on separate daemon interaction that SMTP was never meant for while still maintaining backward compatibility with SMTP servers and mail clients. I have seen a lot of parallels with deploying and troubleshooting fediverse and ActivityPub driven software, likely due to the similarly decentralized behavior and reliance on 3rd party uniformity. I think it’s probably fair to call mail hosting ‘hard’, at least comparatively.
No shade on the writer though, and there are plenty of other ways to make mail hosting easy on yourself in 2023 (containerism and automation, or all-in-one solutions like Mail-in-a-box come to mind). Despite the difficulties, I’d rather the option to self-host mail not be yanked from the average user just because Google or Microsoft has the user-share to disengage with the rest of the network without much consequence, as they have done in the past for other things.
I respect the writeup, although personally think the use-case described is too specific for general mail hosting. I have had a different experience for a similar amount of time running a couple of mail servers for home and work myself. I didn’t have the luxury of avoiding spam/virus filtration on the work server due to the domain’s history and the nature of 3rd party users with varying degrees of tech literacy. Most issues I have faced with maintaining these servers have been down to the filtration elements the author was able to avoid, specifically the virus scanner growing in memory footprint as hot new virus definitions are included. The overall virtual footprint of my postfix/dovecot/sql/nginx/roundcube/spamass/clamav stack has grown significantly over the years on clam alone, depsite no real change in usage patterns. Ongoing maintenance outside of ClamAV has been minor, but something will pop up now and again when a large 3rd party makes a decision that forces others to follow suit, or a new mail client is picky about protocols, etc.
At the time I needed to deploy these servers, the task was more difficult and required a lot more scrutiny than most other admin work I had done at that point (from a history of web server and backup system maintenance). The mail servers tended to require more active maintenance than most other small/self-hosting roles like web/file/game servers, or deploying a NAS or network gateway with a taylor-made distro/OS. Familiarity was the main roadblock; there was a lot of mail-specific terminology and best practices that differ from other server software. There is also a lot of ‘legacy friction’ related to bolting on separate daemon interaction that SMTP was never meant for while still maintaining backward compatibility with SMTP servers and mail clients. I have seen a lot of parallels with deploying and troubleshooting fediverse and ActivityPub driven software, likely due to the similarly decentralized behavior and reliance on 3rd party uniformity. I think it’s probably fair to call mail hosting ‘hard’, at least comparatively.
No shade on the writer though, and there are plenty of other ways to make mail hosting easy on yourself in 2023 (containerism and automation, or all-in-one solutions like Mail-in-a-box come to mind). Despite the difficulties, I’d rather the option to self-host mail not be yanked from the average user just because Google or Microsoft has the user-share to disengage with the rest of the network without much consequence, as they have done in the past for other things.