Hacker News new | ask | show | jobs
by toadkicker 3247 days ago
I use http://mailinabox.email which totally automates running your own mail server. Highly recommend taking a look at it!
1 comments

What about spam?
I use a self-maintained version of the same email stack (Dovecot, Postfix, Spamassassin) and Spam is pretty much not a problem. I train the Bayes filter on my collection of 10,000 spams and a few thousand hams every 6 months and, while I do get an occasional false negative I feel that spam is pretty much fully under control. Self-hosting email is fun you guys!
As long as you set up SPF, DMARC, DKIM, reverse DNS, and SSL/TLS, plus do that all correctly. Oh, and make sure you pick a provider or host whose IP ranges aren't damaged goods. And don't get me started about sender reputation with the various email providers, or the often erroneous blacklists (and fighting to get your server/IPs off and kept off).

IMO, there are limitless other things I'd rather be doing than these!

You're right that all those things are needed, and it did take me a while to get them all working. But now I know about tools like mail-tester [1] that analyze your emails and tell you exactly how to fix them. Once you know what to do, it's really not that much actual work to set them up.

[1] https://www.mail-tester.com/

How feasible would running a mailing list (say 10k subs, one email/week) be off your setup?
We're doing something like that.

The problem is that you need a lot more volume to be able to use the feedback loop mechanisms ( https://blog.returnpath.com/what-is-a-feedback-loop/ ) efficiently.

Sure, it all works, but it's still the old piece of shit SMTP wild wild west, because when it stops working, you can do nothing. (But usually going to the saloon, having a rough night and waiting will solve things.)

You forgot DNSSEC +DANE
You do not need to set up DNSSEC+DANE, and, in fact, doing so is very likely to make your system less reliable; the primary function DNSSEC has in practice is to cause outages.

Observe how few of the major sites are DNSSEC-signed. In reality the only purpose signing has is allowing your site to vanish from view of the few DNS resolvers dumb enough to do DNSSEC validation.

Self-hosting email is fun you guys!

I figured that it would be, but trying to set it up was the single most frustrating thing I've ever experienced running a Linux box, and I never did get anything properly working after many days of trying. The principles seemed straightforward enough and there was plenty of software available, but what I really wanted was to self-host the mail store and IMAP server but send/receive via ISPs or other services who are better at administering a full-time SMTP setup than I am, and somehow I just never could find the magic incantations in the settings files to make that go. :-(

Did you try exim4? That was pretty good a few years back, but honestly I took the advice to offload to service and don't run a "real" one anymore. I do on my dev box as localhost so I can test authentication scripts and the like but that's all.
Well, for outbound you'd presumably want an "authenticated smarthost" with setup details on your side varying by what mail server you're using locally.

For inbound, you'd presumably want the server using fetchmail or getmail to then push them into your local mailboxes. Should be plenty of documentation on those projects.

There was plenty of documentation, and what I was trying to do was along the lines you mentioned. My problem was that if anything there were too many different moving parts in the software and too much documentation. Individually it was quite clear what each part was supposed to be doing. Collectively, it simply didn't work: messages weren't reliably sent or delivered, sometimes generating various kinds of logs or error messages, other times silently as far as I could tell. The hard part was trying to pin down which part of the system wasn't set up properly, and I simply didn't have and couldn't find the knowledge to solve that problem within a reasonable amount of time.

Given that fundamentally neither email protocols nor mail store structure on a typical Linux box are particularly complicated, and that all of the software I was using was well established and reputable, it was an exceptionally frustrating experience. Someone with more skill than me would surely have installed the relevant half dozen or so packages from the distro, edited a few configuration files to set up the remote mail server details and identify the local processes to each other, and had everything working within a few minutes. Unfortunately, without that knowledge the sheer number of options and possibilities was overwhelming and I never got that far. What I really needed was a one-page HOWTO for the most simple use case and a setting for each package that said "don't try to do anything clever or unusual", but what I had at the time was literally hundreds of screens' worth of detailed parameters and config file options, each written according to the conventions and assumptions of their own package.

Why don't you just download your mails from your provider via getmail or the like?
I could, but the object of the exercise was to be able to fetch the mail to a local server and then access it from any device on my network (including potentially from a mobile device via VPN). I also wanted to do things like spam filtering and automatically filing incoming mail according to various rules, the same as I'd do with a standalone mail client, and sending all outgoing mail via a system that could keep copies. This is well beyond the scope of running something like fetchmail on its own.
Most email clients allow the user to configure a separate outbound email server.
I self-host my email with a very similar setup, and while alright I wouldn't go so far as to call it fun. It's funny how pushing messages to my iOS device is actually harder to configure than sending emails. (hacked-together exchange support / IMAP push etc)