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.

https://tools.ietf.org/html/rfc5321#section-4.5.4.1

   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
   non-delivery.

   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
   configurable.

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?