Hosting email with mailcow dockerized worked pretty good on my netcup vps, but before you go into hosting email ask yourself a few questions:

• Will you use your selfhosted mail for important things? (Banking, official correspondence and so on)
• Can you promise a near 100% uptime? Otherwise, some email might not reach you.
• How important is the Mail you send? Some (stupid) Blocklists generally block all IP ranges that are sold out by vps companies and other kinds of IAAS.
• If you register any accounts with your selfhosted mail, can you guarantee yourself that your email account is secure? Don’t underestimate what an attacker can do with a compromised Mail account.

I personally ended up scrapping my email server eventually. Nowadays I pay a company to do the mail hosting, you just need to set some DNS records and they do everything else. Personally, I’m with proton, but there are many good alternatives.

email is one of the only services i just gave up on (after rolling my own exchange for over a decade). its too annoyingly complex, tedious to do correctly for just yourself. its not worth it.

You can selfhost the email server wherever you want. But you’ve to use some external system to deliver the email or you’ll end up in spam because your residential IP is most likely dynamic and already flagged by most email providers.

One way to do it is to get a VPS somewhere and setup Wireguard on it. Then configure your local system to bind to the Wireguard interface and IP so all email send and received using the tunnel. Dovecot doesn’t care what interface it is running on, Postfix has specific options that you can change in master.cf to accommodate the fact that it will be binding to the VPN IP and the real IP is the VPS public IP.

1. Setup a install of Dovecot / Postfix / Rspamd on your local server: https://workaround.org/ispmail-bookworm/
2. Start by setting up a Wireguard tunnel between your local server and the VPS: https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-20-04
3. Create a outgoing transport for the email that uses the WG tunnel and is aware of the VPS public IP:

out-wg      unix  -       -       n       -       -       smtp
 -o proxy_interfaces=188.xxx.xxx.xxx # the real public IP of the VPS
 -o smtp_bind_address=10.0.0.2 # the IP that your local server has on the WG interface
 -o inet_interfaces=10.0.0.2 # same as above
 -o myhostname=server.example.org # should match the PTR / reverse DNS entry on the VPS IP
 -o smtp_helo_name=server.example.org # should match the PTR / reverse DNS entry on the VPS IP
 -o syslog_name=smtp-wg

4. Set your VPS firewall to NAT/forward incoming traffic on port 25, 587, 465 and 993 to the local server (wireguard client 10.0.0.2);
5. Change main.cf to use the transport by adding: default_transport = out-wg.

That’s everything you need to get it going. Use https://www.mail-tester.com/ to debug if DKIM and everything else is properly setup at the end.

Do not try to host outbound mail on residential IP blocks, delivery will be really bad. Cheap VPS is same story. You best bet is VPS from some not well know provider, they may be avoid to be in blacklist in M$ and Google. Inbound mail is fine anywhere as so long as you can have port 25 open. DDNS works too.

I’ve setup my email via a VPN to my own server.

• DNS, mail, business web, cusromer web on VPSes (2, 1 primary, 1 secondary DNS only)
• Personal email, incoming and outgoing via VPS, personal websites (all static) on local system (RPi 4 8GB)

This gives the advantage that your outgoing email always comes from the VPS ip address (pick a VPS provider that is trusted) and when your line is down, incoming email is cached on your VPS. It’s a tad of double work, but pretty secure. Even connecting to my employer to work from home is not a big issue. (and that connection is limited to it’s own vlan)

Also, with this method, you can route the mail into your network via port 26 when 25 is blocked or even set an outgoing vpn to your VPS and route the email that way. You’ll be provider independent at home. (I even have a private ipv6 /48 via a tunnel broker)

You’ll need to work a lot on your knowledge though, without DNSSEC, SPF, DKIM and DMARC the big 2 (Google and hotmail) will refuse your email.

I think mail forwarders are still a good way to go. It’s hard to predict how Internet providers will react to email running in their networks.

These days I have an ec2 at AWS for my mail server and use SES for outbound mail. I’m thinking of moving “receiving” back into my network with a simple chat forwarding service but keep SES for outbound. They handle all the SPF and DKIM things and ensure their networks aren’t on blacklists.

This is the approach I use, not sure if it’ll work for your use case but I can assure you it works for at least a few users. It’s all sort of manual set up but from your comments it sounds like you’re just doing this for friends and family and not on an enterprise level. I admire your efforts!

First off, I have a purelymail account on which I set up domains and accounts for each user. I have mine set up so user1@anydomain.com all goes to the user1 mailbox (and user2@anydomain.com goes to the user2 inbox regardless of domain, etc.) but you can set up some pretty complex routing if you want - and if you know a bit of sieve there’s even that. Purelymail handles the actual email sending/receiving so I’m putting a lot of trust in them, but it seems like they have a good track record and I don’t think I could do better on my own. Plus they’re dirt cheap. My big concern with email is always deliverability. Anyway, you’ll see this is all set up in such a way that I’m using purelymail now, but I’m not tied down to them.

Second, I use this image (linking to the repo and not the docker hub version so you can inspect the Docker file for opsec reasons. In my set up I build it from source because I have a couple modifications) which is a dovecot IMAP server + getmail. This is python getmail not go-getmail and not fetchmail. The repo itself has some pretty straightforward instructions but the way it works is basically that users inside the docker container each map to a mail directory. So each user’s credentials is actually a Linux username and password within the container. I have mine set up so it’s like user1, user2, etc. (which confused my users initially because automatic set up forms are never set up this way) but you could set it up however you need. Then, there’s a Cron set up to run getmail which you have to configure yourself within a cron.d folder that you mount on the container. For mine I have it configured to use POP3 so that when it gets stuff off purelymail it’s automatically deleted.

Finally, you just set up your mail clients to use this IMAP server and purelymail’s SMTP but if you know how to set up a forwarder you can always have it relay through purelymail. Purelymail even has the ability to relay emails to your SMTP server.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

9 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #461 for this sub, first seen 29th Jan 2024, 13:05] [FAQ] [Full list] [Contact] [Source code]