Self Hosting Email Server | Hacker News Reader

Self Hosting Email Server

garron.blog

46 pointsg-garron26 comments

I was a mail administrator for around 10 years in a fairly small business and I can’t imagine why anyone would want to host their own email. My old employer contacted me because a system I had built finally died and they wanted to build a new one. Once I got over the shock that they had still been using it I suggested going with a hosted solution. I mean they’re relatively cheap for good service and avoids a world of hurt for the inexperienced mail admin. At first they insisted they wanted to keep it in house so I went over what all they needed to build a new system. About a week and several “how do I” emails later I get one more: “we decided to go with a hosted solution.” I was happy. They are happy even if they don’t know they are. It’s more of a commitment than I think some folks often realize.

> I can’t imagine why anyone would want to host their own email

resisting mass surveillance

Also, whatever value Clinton saw in self-hosting.

The main use case was to support her Blackberry.

> Also, whatever value Clinton saw in self-hosting.

I assume it was to prevent FOIA requests which is not a big risk for the majority of us.

There was a LOT of surveillance of her emails.

No doubt but targeted surveillance is very different from mass surveillance.

I'm hosting my own mail-server without any problems, for former jobs i supported MS-Exchange small iRedmail instances and ~big self-made solutions, sure it is a commitment but is that not every internet facing service?

Surprised this wasn’t mentioned as it’s awesome: https://mailinabox.email/

Also https://mailcow.email -- it's stupidly simple to get a full email stack working

mailinabox is working perfectly for me. Give it a try if you want something easy to set up and maintain.

I’m a huge fan of Zimbra, dedicated all-in-one mail solution using your favorite software under the hood that doesn’t take much knowledge to administer. Plus you have support you can fall back on.

Downsides: ui starting to show its age. No container support.

Not to nitpick but I think that the part about the spf record isn’t that great.

The typical spf record has ip addresses, blocks of ip addresses, or hosts but I don’t think just v=spf1 mx ~all.

Not for simple setups. If the same servers are used for both ingoing and outgoing, "mx" is all you want or really need.

If you use a third-party hosting service for webmail, IMAP, etc, where they might also handle outgoing for particular clients, or for hosted outbound services (EasyDNS offers this), then you would usually "include:" their SPF records rather than copy their rules and addresses.

Theoretically, hardcoding some addresses might be useful as a performance optimization or failsafe, but I'm not sure the value is that great, and it adds to the workload and disruption risk if and when you have to move networks. But maybe the value is greater than I'm aware.

I don’t think that an SPF record with just mx -all gives you that. You need to put IP addresses, IP address blocks, or hosts for the spf to be valid.

Maybe the author left out the host in the assumption that the reader would understand that part but essentially mx -all tells mail servers and inbox providers to soft fail all mail from the domain.

Most of the mechanisms (a, ip4, ip6, mx, and ptr) effectively resolve to one or more IP addresses which are then matched against the sender IP address. The "mx" mechanism will query the MX records for the envelope (MAIL FROM) sender domain, query the A records for every MX record, and then try to match all those resolved IP addresses to the sender IP address. If one of the IP addresses matches, then the mechanism's action qualifier is applied, short-circuiting further resolution. As the default qualifier is "+" (pass), a match on "mx" (i.e. "+mx") means to accept the message.

If your MX hosts are the only permissible outbound hosts, and the inbound and outbound IP addresses are the same, then the "mx" mechanism is all you need. The very purpose of the "mx" mechanism and most others is to avoid having to hardcode IP addresses in your policy.

Yes, but as a matter of syntax, don’t you have to specify the IP address? What is the mx refereeing to in your example?

V=spf1 ip4:198.51.100.123 ~all

I think the ptr mechanism’s deprecated.

Anyway, if you’re correct that a valid and complete spf record can be published without an IP address, IP address block, or included hosts, then I’ve learned something new today.

So you are saying that v=spf1 mx -all is a valid and complete spf record?

OpenSMTPd is simple enough to setup on your own. No need for gigantic ‘dockerized’ email packages where it is virtually impossible to understand what is going on.

But i want imap too, and a web-mail, oh and a Calendar and contact (with team-functionality) too, synchronize them to my phone, and i want sieve functionality, anti-spam, and because it's written a pseudo antivirus-solution. And a self-service solution so users can reset the password with 2FA...still easy?

Yes, generally if you over-complicate something it becomes over-complicated.

So you give your users the root password so they can change the password them-self....oversimplification often solves just a small portion of a bigger problem.

Why did whoever think #FFFFFF text on the #000000 background is a good idea?

I hear this repeated often. But why? Whoever think it's not a good idea? There's a reason why contrast is usually maximized on readable paper. Text contrast is very important part of readability. I often see pretty much unusable sites, because someone thinks that it's so smart and cool to create sites, which content is clearly not worth of reading.

The other commenters here are right about the importance of text contrast, but there is a consensus in typography that pure white on pure black contributes to eye strain and decreased stamina when reading. This is especially true for people with astigmatism who experience a glowing effect around the letters known as halation. While there is room here for both personal preference and accessibility needs for a true 21:1 contrast ratio, a better default would be to use a white on a dark gray background. Supporting a dark mode design is a lot harder than just inverting the colors, which this site appears to fall short on.

It's simple and easier to read.

A slightly lower contrast may look nicer (and be more accurate to printed text) but often sites are excessive with it. It may not even be exactly the designer's fault since their monitor's gamma and contrast will probably be better than the average visitor.

Another related problem is that of font weight. Fonts too thin can also hamper readability but the weight on-screen will be variable with the user's font settings and how exactly it's set up with aliasing, shaping etc. To add to that some digital fonts are displayed at the wrong weight because they were designed with bleed in mind.

I don't have a problem with it.

Maybe you should turn your brightness down or add some more lighting in your room? Pure white shouldn't be blinding you.

I'm using BenQ SW2700PT which was calibrated, and my room is also not bright at all. The pure white text on pure black background give me headache, but I don't have any issues on https://nim-lang.org/docs/manual.html dark mode which isn't pure black and white.

Reply on news.ycombinator.com