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

Email servers are notoriously difficult to configure, hence all these solutions ranging from tutorials to "everything included" systems. Recent activity on HN about mail servers: Mox, Poste.io from yesterday [1], Mailinabox, mailcow, ispmail, maddy, stalwart jmap, etc.

Many of these systems keep redoing the same work over and over which seems wasteful.

What I'd like is a "mail reverse proxy" that does all the work to manage DNS, SPF, DKIM, DMARC, etc and handles sending and receiving emails, but doesn't do any storage or user management. Instead it forwards mail from/to the "real" mailserver sitting somewhere in a private network. (Maybe using LMTP [2]?)

This way you could roll the dice until you get a $5 VPS with a clean static IP and just park it there permanently, where it does nothing but sends and receives emails from your real mail server wherever you want to host it. Kinda like a PO box. You never have to worry about upgrading it to get more storage, or switching providers and losing your IP, if it gets hacked the worst it can do is spy on live email traffic and send spam until its patched.

Why doesn't this exist already?

[1]: https://news.ycombinator.com/item?id=34901703

[2]: https://datatracker.ietf.org/doc/html/rfc2033




> Many of these systems keep redoing the same work over and over which seems wasteful.

There certainly is duplication of effort, but all these systems try to bring something new to the table.

> Why doesn't this exist already?

Because you haven't written it yet? (;

But seriously, I've had a somewhat similar thought. But instead of running a "reverse mail proxy" on a VPS, I was hoping to take a VPS, set up some tunnel magic (with wireguard probably) that forwards all traffic coming in from the internet, intact with original IPs, to my local side of the tunnel, and vice versa. So my local machine just has the same public internet IPs configured as the VPS and all internet traffic is going through the tunnel. So just use a VPS for its IPs. That way my data is not stored at my hosting party. If anyone has set this up already, or thinks this is a bad/good idea, I'd like to hear.


Wireguard itself can help you out with the task of forwarding traffic or creating an overlay network. There's also ngrok and tailscale for forwarding traffic and doing NAT traversal. Except for wireguard, these are commercial platforms, the open source alternatives I know of, are (respectively):

- https://bore.pub && https://sslip.io - https://github.com/juanfont/headscale

I don't think there's anyone using this kind of tools for emails, the technical limitations elude my understanding TBH. This comment might be border to off-topic, but I think the tools fill in the niche use-case you just mentioned. Have fun!

edit: might be of your interest to check this list! https://github.com/anderspitman/awesome-tunneling#recommenda...


Another open source option is zrok (https://zrok.io/), we have just released v0.32. Its built on top of OpenZiti.


A simpler platform but not suitable for hosting serious stuff yet I guess is https://pinggy.io


> all these systems try to bring something new to the table

That's great, I just wish that they all didn't have to hurdle the same (very high) bar before they can get to the "something new" part.

> some tunnel magic that forwards all traffic coming in from the internet ... to my local side of the tunnel, and vice versa

Yes! I considered that too. It'd kinda be like tailscale funnel, which mostly targets web hosting scenarios. Hilariously, they poked fun at the $5/mo vps idea in their article about funnel back in November [1]:

> Yes, you could spin up a $5/month VM somewhere and forward a port from its public internet IP to your tailnet with one line in your rinetd.conf file. But is that fun? Do you really need a(nother) Linux VM in your life?

(we're definitely being called out here lol)

Sadly, funnel wouldn't work in our case because we need an unshared static IP. But that hint about rinetd could help, from the man page [2]:

> it is able to redirect a large number of connections without a severe impact on the machine. This makes it practical to run services on machines inside an IP masquerading firewall.

[1]: https://tailscale.com/blog/introducing-tailscale-funnel/

[2]: https://manpages.debian.org/unstable/rinetd/rinetd.8.en.html


it's also wasteful in a different way: a lot of effort put towards building on top of a remarkably bad pseudonymous protocol based on anachronistic trust assumptions

from that point of view the refactoring to do is separating identification from transport and storage/lookup - for these things there are very good solutions but there is no cohesive protocol that is solid and widely adopted, and it's unclear if that will happen anytime soon, or ever - rather than just doing away with the mail metaphor in favour of the pager+answerphone metaphor which can be seen as a total overlap as you add features

but you're right that since email is here now and it "works" now, especially from a social perspective, then it makes sense to free up people from silos - what effectively webmail and proprietary messaging/social media are - and perhaps the best way is the toolkit approach you describe which would go about email a bit like git did with version control: establish protocols for the separate aspects of the system and then provide the user with a supervisor command tool, which can be automated to some particular use cases if need be but is flexible enough that it doesn't require one particular setup


The way I look at it is that we're gonna have email for a long time, realistically at least another 50 years, probably 100. So if we're stuck with it, we might as well make it as painless as possible.

I totally agree that we should look for better protocols, for example Matrix looks like it could eventually be a good replacement for email. But whatever email is replaced with will definitely need some kind of way to interface with email during the transition, and a pre-built mail reverse proxy / IP gateway will only help with that.


> What I'd like is a "mail reverse proxy" that does all the work to manage DNS, SPF, DKIM, DMARC, etc and handles sending and receiving emails, but doesn't do any storage or user management.

spf, dkim and dmarc are all dns related. Running nameserver and mail servers on the same system doesn't sound like a good idea, nor does having a mailserver with write access to dns-records. using a central administration for both however sounds beneficial. but then why stop there and not add all kinds of other useful features and voila, you have a full blown control panel far away from being a simple solution for mail.

I think dns for mail needs to be complicated, otherwise people lightly just set their spf records incorrectly which gets their mailservers blacklisted. or they just will never know why their mails get blocked. if they even find out about that.


For small loads (<100k emails/month) and a $5/month budget, you can get this with AWS SES and a few lines of code on Lambda.


The idea certainly has merit, but if it doesn't do storage or user management, how can you secure it?


Any kind of secure tunnel between the mail gateway and the backing server would work. A wireguard or tailscale tunnel for example.


You just described Haraka.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: