Hacker News new | comments | show | ask | jobs | submit login

It's absolutely possible to run an email server in 2016 and I encourage anyone capable to do so!

Email is one of the bastions of the decentralised Internet and we should hang on to it.

Every day more and more people are moving to Gmail/Hotmail/Outlook and while I do understand the reasons, it also puts more and more power into the hands of these providers and the little guy (us) gets more screwed (like marked as junk by default by them :< )

Having said that, here's my check list for successfully delivering email:

- make sure your IP (IPv6) is clean and not listed in any RBL, use e.g. http://multirbl.valli.org/ to check

- make sure you have a correct reverse dns (ptr) entry for said IP and that ptr/hostname's A record is also valid

- make sure your MTA does not append to the message headers your client's IP (ie x-originating-ip), messages can be blocked based only on "dodgy" x-originating-ip (see eg https://major.io/2013/04/14/remove-sensitive-information-fro... )

- set up SSL properly in your MTA, there are so many providers giving away free certs nowadays

- SPF, DKIM, DMARC - set them up, properly, this site can come in handy for checking yourself https://www.mail-tester.com/

- do not share the IP of your email server with a web server running any sort of scripting engine - if it gets exploited in any way usually sending spam is what the abusers will do

- last but not least - and while I loved qmail and vpopmail - use Postfix or Exim, they are both more fit for 2016, more configurable and with much, much larger user bases and as such bigger community and documentation.


> Email is one of the bastions of the decentralised Internet and we should hang on to it.


I hope someone will eventually create an "E-mail server in a box" package for Ubuntu LTS, so that more people can run their own E-mail. I'm not saying it has to be super-easy for everyone, just that it should avoid unnecessary chore work (like configuring postfix to always use TLS, or plugging postgrey into postfix).

As long as you know Docker, this is pretty much what you are asking: https://github.com/tomav/docker-mailserver. I use it in combination with the rainloop webmail client: https://github.com/jprjr/docker-rainloop.

Everything is configured with a single docker-compose, read about it here: https://news.ycombinator.com/item?id=11748036

What is it if anything that happens if my internet cuts out at my home, should I instead use some sort of hosting provider for my mail server?

My ISP has a nice service, called tertiary MX. It's a MX server to add at the lowest priority that will accept emails into a queue that attempts to delivery to the primary MX every 15 minutes for a month.

    > What is it if anything that happens if my internet cuts
    > out at my home,
You bounce any incoming emails in that period, and (obviously) can't send any.

    > should I instead use some sort of hosting provider
    > for my mail server?
I suppose that's a trade-off against how reliable you consider your ISP and electricity supply, and the volume or importance of email you'd be likely to receive in such a period.

Bounce? No. The servers trying to send mail to your server will retry for up to, typically, four or five days, before they bounce the mail back to the sender.

Mail was written to be resilient against network downtime.

That's why you soft bounce. It tells the sender that you can't receive the email _at this time_.

Pretty sure you can't do anything when you're not connected to the internet.

A connection timeout is a soft bounce.


   The sender MUST delay retrying a particular destination after one
   attempt has failed.  In general, the retry interval SHOULD be at
   least 30 minutes; however, more sophisticated and variable strategies
   will be beneficial when the SMTP client can determine the reason for

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  It MAY
   be appropriate to set a shorter maximum number of retries for non-
   delivery notifications and equivalent error messages than for
   standard messages.  The parameters to the retry algorithm MUST be

That's why sending mta's should resend. Think sendmail does this every few hours or so

Ha, I wrote that so cautiously, thinking "I'm sure this terminology's not right, I'll probably be called out on it"!

Thanks though, I learned something :)

Regardless of what we call it - the sender would get a copy back with a message not containing the word 'bounce' that says it failed to send, right?

No, no message will be sent until after 4-5 days have passed without connection.

It's usually a bad idea to run email from a home internet connection because it massively increases the chances of your mail being marked as spam. The hardest part of running a mail server is making sure your mail gets through spam filters, and the IP is critical to this.

I forgot to mention that I use the abovementioned setup on a dedicated server, while also setting up a secondary MX dns record for bouncing the mail in case of malfunctioning as sister comments suggested.

I've been doing a similar thing but with Poste.io. https://poste.io/

It has a decent web admin panel built-in to the box and also a copy of RoundCube Webmail. It'll even automatically set-up LetsEncrypt SSL for you.

You might want to set-up rainloop manually though because RoundCube isn't the best.

that's the difference between rainloop and roundcube?

There is something you can do to install that : https://mailinabox.email/

I've been using it for a year. Works great. One of the most thoughtfully designed and complete bits of software I've ever run into.

I'm especially delighted with it's self monitoring and the status change email messages it sends me.

That it includes webmail and gives me a nicely featured DNS server only makes it a touch more awesome.

I run it at Digital Ocean for ten bucks a month. I support family and friends. My email does not pass through google or microsoft servers and that makes me very happy.

DigitalOcean is just as susceptible to surveillance as Google or Microsoft.

If you aren't sending encrypted email, it makes no difference where your email is hosted.

I don't think the point is to avoid surveillance (although self-hosting may make it slightly more inconvenient to snoop). The point is to own your own data, not depend on Microsoft/Google's benevolence.

That attempt at the problem looks pretty nice. Thanks for sharing it.

Mail in a box works great... replaced my old sendmail setup - using an external DNS is a bit funky, but a great package.. support multiple domains easily, pop3/imap and web client. Recommend.

It prefers to use its own DNS server because email DNS is tough. However, it provides the information to do it. While it probably took me a couple of hours to figure it out, I now have a DNS template at my registrar that makes it nearly automatic. That said, where I don't need the performance of a hosted DNS system, I let mailinabox take care of it.

a recommendation for mailinabox, I've been using it for about 6 months, very nice

The problem is that setting up an MTA that can deliver to gmail etc can't e.g. Be done (typically) on a dynamic IP like you'd have at home and the scripts running would have to interact with your registrar and/or DNS provider to properly configure DNS (unless it also sets up a nameserver, which would make assumptions about how the domain is / could be used).

There are a lot of moving parts, and being an email admin requires some maintenance like being vigilant about not allowing spam. An automated script to set it up for people who wouldn't know how to run it would be doing those people a disservice.

The problem there is most of the hard work the OP mentions has nothing to do with the mail server itself, but instead it's around DNS, networking, certificates, and monitoring 3rd party services.

Some of this may be able to be automated, but that's the hard part; not installing and configuring a few software packages.

This is definitely an issue. The emails server is easy. The tedious part is the infrastructure setup.

The real problem is that the unencrypted nature of email makes most solutions non-starters. If end-to-end were the default, then you could imagine having a process whereby you ran a P2P service which kept your MX records pointed to a cluster of network members, all of whom agreed to act as your MX fallback if you went down and which collectively handled monitoring and distributing blacklist notifications.

You're implying that this is not advisable to do because any such fallback could snoop the data?

I'm sorry I'm not sure I quite understand what you say the problem is and how it relates to the unencrypted nature of email.

The "email server in a box" is called a Mac Mini with the Server package.

It's such an easy-to-use email system. Been working great on a home static-IP address for me for a couple years now.

Maybe when (if?) Apple releases a new one. Right now the hardware on the Mac Mini is so pathetically underpowered for the price, and Apple has shown such blatant disdain for both the Mini and the Pro that it almost feels like they don't want customers for those product lines.

How on Earth MacMini with 8GB of RAM and i7 CPU is underpowered for the use? It is underpowered in only one way - energy consumption is so low that there are even server farms built on MacMinis, and colocation services targeting this brave little server.

Not for the use, for the price.

You get a custom operating system that literally no one else offers. It is a bit hard to put a price on that, but to me, it's absolutely worth the money they ask for the mini. I would even risk saying it's very cheap for what it offers.

Like the others noted here - it is well worth the price, since it saves a lot of time for admin, is easy to use and provides extra value for money.

You pay extra for Macs so you don't have to spend as much time to set it up.

Your time is valuable, right?

Thank you for mentioning https://www.mail-tester.com/ - I wish I knew this site existed back when I was setting up my mail server. I struggled setting up SPF and DKIM, having a site that validates your config is very helpful.

I would suggest running OpenSMTPD over any of the alternatives, it's much easier to configure and should be/remain secure as it comes from the OpenBSD people (the audit from Qualys attests to that).

Yeah I'll have to disagree here. I beat my head against this horribly documented MTA just trying to get virtual users to work with a relay host. I gave up after three days of slitting my wrists trying to get it to work. It's horribly documented, getting help out of the obsd folks is like getting blood from a turnip, but if it works for you great! But I would never agree it's easier to configure or has better documentation than postfix.

I'm genuinely curious here since opensmtpd has been by far the easiest to configure MTA I've ever seen. What problem(s) did you have? Virtual users through a relay host is literally one simple line:

    accept for domain "example.com" virtual <users> relay via relay.example.com
I don't see how anyone could conclude that is more difficult than postfix.

And have you tried it? Because when I tried it it did not work as documented.

Yes, it works as expected. Again, what problem(s) did you have? Vague "its hard" replaced with an even more vague "it didn't work" comes off as trolling rather than a legit problem.

There was http://seclists.org/oss-sec/2015/q4/11

PS. maybe that's one of the vulnerabilities mentioned in the report (1). Anyway it's an argument for me to run Qmail/qpsmtpd instead.

(1) https://www.qualys.com/2015/10/02/opensmtpd-audit-report.txt

Yeah those issues were found in the Qualys audit. They have been fixed so the codebase should only be stronger now.

I just wish we had something that wasn't written in C.

Try running any such program through Softbound + CETS or SAFEcode (already in LLVM). They turn C programs memory-safe. Should knock out most of your risk immediately with an acceptable performance hit unless your volume is really, really high. Code-Pointer Integrity at least protects control flow with max of around 10% penalty. Given they're all alpha by few developers, they need more people using them on various software and doing error reports if they fail.

SPF, DKIM, DMARC could be dropped if you actually use aws ses to send your mails, you can actually forward the mails there. So it's pretty impossible that your messages will be in spam. The only thing you need to manage is incoming mail now and not being a open relay.

Hence defeating one of the main purposes of running your own mail server in the first place: decentralization.

Unfortunately SES servers seem to be regularly blacklisted. A quick google confirms. I've been using SES for 3-4 months now and had a few hard bounces with specific mention to the IP being banned.

The last spam that got through GMail's filter was from amazonses.com. It wasn't clear how to report it back to Amazon.

actually I never had blacklisting problems on aws ses. My guess would be that the big providers ignoring the blaklists for themself. I mean even Google sometimes gets on a blacklist or Microsoft on still no email happened to be in Spam filter.

And if you still want them, AWS supports enabling these for your outgoing emails.

Burn how do you ensure your mails aren't tossed in the spam box of the big ones?

Each of the points mentioned in the post you replied to contribute to the decision if big players mark your mails as spam or not.

It's also recommended to not have any "vacation" autoreply mails - you will get spam with blacklist's honeypot email addresses as apparent sender and end up on blacklists.

How realistic is it to be able to do all this from a Digital Ocean or other VPS, given that those IP blocks may have already been used by spammers or may be used periodically by spammers? I.e. it's trivial for them to set up VPSes on the fly.

I'd feel nervous about doing this at home. For one thing, my ISP is a residential cable internet provider, and not 100% guaranteed uptime as a result. I'd hate to miss mail or worry whether I did.

>- make sure your IP (IPv6) is clean and not listed in any RBL, use e.g. http://multirbl.valli.org/ to check

I recently ran into issues with the PTR on a mail server and did the lazy/unsustainable move of just disabling IPv6. Wish I had found this post before!

If you can't control your PTR on IPv6, in postfix I recommend using: "smtp_address_preference = ipv4", instead of fully disabling IPv6.

This way you can still receive email from IPv6 servers.

I run an smtp server from home with a static IPv4 address (for which the ISP lets me configure the PTR), but their IPv6 is "beta" and they don't yet support delegation, which is rather frustrating, but different topic.

Plus make sure that your whois is not registered behind proxy registrars. In other words use your real name and real email address.

> Email is one of the bastions of the decentralised Internet and we should hang on to it.

ITYM federated Internet, agreed though.

Any open source mail servers taht set all this up? Last I checked in 2011 there weren't any.


>use Postfix or Exim

Better yet, opensmtpd.

I disagree with you. I consider email legacy technology because of its reliance upon DNS and static IP addresses. These two requirements make hosting email unnecessarily costly.

What replaces email?

For most of the people I interact with, and most of the usecases: Viber

i consider viber legacy technology because of its reliance on a centralized system and which will stop working as soon as vc money runs out

Moreover, Viber's adoption is highly concentrated in some specific countries so, depending on where your friends are based, it might not be a viable solution.

I uninstalled Viber when the last friend still using it started using WhatsApp.

Btw, everybody still has email and SMS like in the 90s. For me SMS are a fallback when IM won't work for a given person; email is my primary mean of communication for business. Furthermore I can archive and search email much more than IMs.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact