Show HN: Posthorn, self-hosted mail gateway

Posthorn ended up the way it did because I had three different things all hitting Resend at the same time: a contact form, a couple of apps that only had SMTP email support and some scripts I wanted to email results from. I didn't want to have to maintain three different things doing functionally the same routing. Putting them in one binary helped me consolidate credentials and logs.

You're not wrong about the split though, I thought about breaking the two out. I'd originally written the http form handler as a caddy module (which I called caddy-formward to be cute) but ultimately I went the other way because the code after the ingress is the same regardless of how you come into the service and I didn't want to rewrite all that logic.

Have you encountered a similar issue with multiple apps where nullmailer hasn't been enough? Curious how you handled it if so.

My current plans are for Posthorn to stay focused on email. There's enough work here that I think it justifies a dedicated tool.

I have some v2 roadmap ideas for things like multiple outputs per endpoint so that a contact form submission can fire both an email and a webhook in the same call to support things like form -> email + slack or script triggers an email + pager duty alert.

That's complimentary to the email though, not something I had planned to build out as a stand alone use case. I'd be interested in hearing how that would be useful for you though!

1) Posthorn doesn't host email - no inbox, no IMAP so it doesn't replace what it sounds like all-inkl is doing for you. All it does is take the outgoing messages from any of your hosted/local apps and take care of the plumbing of handing them off to a transactional provider (like Resend or Postmark). Those servers are the ones sending the mail, using their IPs and their sending reputation. Any blacklist concern is really tied to your sending domain and not a new risk from Posthorn. Just the same setup you'd do if you were calling something like Resend directly. If you're following their guidelines, you'll be fine.

2) On the VPS side, if your goal is to be able to ssh in, install some stuff and run your own services, something like Hetzner is a well regarded EU centric option with solid technical support baked in. Security is mostly on you and down to what you install and how you configure it. That can be a huge learning curve and a whole other kettle of fish, definitely not without risk.

> something where security is high and support is 24/7 available

You are not going to get great 24/7 support inside anything like €6/month (though many may promise it!), so that service may not be as overpriced as you think.

Another thing to consider is that many VPS providers have “dirty” IP ranges so you will have trouble with getting your mail delivered. A common solution to this is to use a mail delivery service (like mailgun, mxroute, and many others) so your mail comes from a managed “clean” source and has less chance of summarily being declared spam just from the source address alone (these services also reduce the need to think about spf/dkim/etc and keep an eye out on changes that may happen in that realm). Essentially by self-hosting a service like this, you are taking back the admin of managing all that so you have to ask yourself if it is worth saving a few € per month, and consider what you might lose if something goes wrong and all your mail starts bouncing.

> switch to some VPS/root or anything where I can SSH and install, compile my own services

Be wary of most really inexpensive options here. In most cases you will experience performance degradation (at random times, or just almost always) and other issues due to noisy neighbours on oversold infrastructure.

> I really want to try this, but I'm afraid my DNS will be blacklisted if I do.

The best (but unfortunately time-consuming) way to get comfortable with this is probably to register a sacrificial domain and set it all up for that domain on hosts not associated with your domains that normally send mail. Play with it, break it, fix it, break it again, etc., until you feel confident you aren't going to screw yourself by trusting your own admin of all this on a domain that actually matters.

For something simple try https://mailinabox.email/

> would love to switch to some VPS/root or anything where I can SSH and install, compile my own services, but something where security is high and support is 24/7 available.

Those sound like expensive requirements to me. You want managed self hosted email? Some else providing support will be expensive.

Posthorn is built for the opposite end of that, you've already decided you want to use a transactional provider for app mail and you just want to stop having to deal with wiring it into all of the things. Obviously for a big production app you build your own mail service, but for gluing together a bunch of different apps you're self hosting, I think this makes sense and addresses a real issue.

If you want an API piece to augment what you already have, Posthorn might still be useful regardless of how the rest of your mail is set up. A Posthorn JSON endpoint is just a POST with Bearer auth and an idempotency key. Example from my docs:

curl -X POST https://posthorn.yourdomain.com/api/transactional \ -H "Authorization: Bearer $WORKER_KEY_PRIMARY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: reset:user-123:$(date -u +%FT%H)" \ --data '{ "to_override": "bob@example.com", "subject_line": "Reset your password", "message": "Click here: https://app.example.com/reset/abc" }'

Could run alongside your existing mail server. It's a small enough overhead that the juice might be worth the squeeze.

I do not remember if I have ever used the GNU mail program that is available on Linux, but my e-mail server is hosted on FreeBSD, so I have used very frequently the FreeBSD CLI utility to send e-mail messages from scripts.

Moreover, all FreeBSD servers come configured by default to send automatically a variety of e-mail reports to the administrator, to inform about incidents or statistics, so there are a lot of examples of usage from scripts.

Similar idea in that it receives SMTP and transforms it to a provider specific API but it's unique for the ProtonMail use case of bridging to your personal mail client and it handles both sending (SMTP) and receiving (IMAP).

Posthorn is server side and outbound only. It runs in your stack and enables apps to send email that otherwise can't. It fronts multiple transactional providers via config and doesn't touch inbound at all.

How much effort has it been to keep it running? Glad that it works for you!

My (intentional) reference was to the older mail courier horn.

If all the apps you're running can already integrate via HTTPS API, Posthorn doesn't solve anything for you in that case, unless the unified credential, single retry policy and logging meaningfully simplifies things for you.

And honestly, SES was the easiest integration for me to write (even if it ended up being the most LOC), their documentation, examples and error responses gave me a really easy time setting it up. Additionally, because it does need such a verbose implementation SES ends up being a great case study for Posthorn and not needing to maintain the same 200 line signing routine in multiple different places.

I should probably tighten up that line. What I really meant to say is that the average self-hoster who just wants to enable a few services to send email doesn't want to run a mail server. Different audiences, different (and both correct) answers.

I set out to solve some pretty specific problems of my own but I'm genuinely curious how others have tackled these things. Posthorn and Postal don't compete in my head. Postal makes you into your own provider, which is something I personally deeply want to avoid. Posthorn assumes you've already picked a provider (which might be Postal, actually, it would work just fine pointed at a self-hosted Postal instance).