[flagged]
Show HN: Posthorn, self-hosted mail gateway
51–60 of 68 posts
Re: Show HN: Posthorn, self-hosted mail gateway
#52> Nobody wants to self host email server. I do. Though I am self hosting it to have my personal email, being well... personal. Not for my company so maybe I am not the target. Interesting project though. I always felt missing API to just send emails from some script in my mail server.
Any UNIX-derived operating system has some kind of command-line utility for sending email messages (named mailx or mail or Mail). 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 au…
Yes I know I am using it. I just think API, built-in API should be standard. Creating separate mailbox for each self hosted service I am running and testing it and making sure it is using TLS instead of STARTTLS or other way around and fixing user name because some services send using domain and some not, and setting correct port because 465 did not work even if it should be using SSL... It is so much hussle. Maybe it was fun when I was doing PHP forms 20 years ago but not now. Now I want to have just API with /mail/send and API key and forget about all of that.
Re: Show HN: Posthorn, self-hosted mail gateway
#53> Nobody wants to self host email server. I do. Though I am self hosting it to have my personal email, being well... personal. Not for my company so maybe I am not the target. Interesting project though. I always felt missing API to just send emails from some script in my mail server.
Personal mail is the one case I think where hosting your own MTA still makes sense when you want to own the addresses and the data. You still have to solve for deliverability, which is something I hope to never have to do. 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…
Yeah I looked throught that but could not sent response to your comment because for some reason HN decided I am posting to fast. Yeah I was doing it manually and sending 2 comments a day. FFS.
Anyway yeah it looks interesting. In theory I could start it up with my mail server, which already is using docker compose, configure it and use API for sending emails.
I will give it a try.
Re: Show HN: Posthorn, self-hosted mail gateway
#54How does this differ from using protonmail-bridge? Seems like a similar concept.
Re: Show HN: Posthorn, self-hosted mail gateway
#55Earlier quoted context omitted.
They seem to be on 7.2, which will get security patches until August this year: https://github.com/postalserver/postal/blob/8ef89606bc34146f... https://rubyonrails.org/maintenance Not great, but better than 6.x.
The links shows: gem "rails", "= 7.1.5.2" I don't know rails well, but that sounds like 7.1 (that is unsupported) and not 7.2?
Ah, my bad. Wishful thinking going from GitHub to rails site.
Rails minor versions are a bit odd imnho - but you're right 7.1 isn't under support anymore.
Re: Show HN: Posthorn, self-hosted mail gateway
#56Confusing title, "self-hosted mail" and "self-hosted email gateway" are two quite different things :-/
My eyes first Spoonerized the title to "Hostporn, selfhosted porn gateway". I didn't get a full night's sleep last night...
Re: Show HN: Posthorn, self-hosted mail gateway
#57Earlier quoted context omitted.
Personal mail is the one case I think where hosting your own MTA still makes sense when you want to own the addresses and the data. You still have to solve for deliverability, which is something I hope to never have to do. 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…
Yeah I looked throught that but could not sent response to your comment because for some reason HN decided I am posting to fast. Yeah I was doing it manually and sending 2 comments a day. FFS. Anyway yeah it looks interesting. In theory I could start it up with my mail server, which already is using docker compose, configure it and use API for sending emails. I will give it a try.
Yeah, this is a good point I should probably make a bigger deal out of in the documentation. I also have it automated with docker compose/ansible so it just deploys with the apps that need it and starts working.
Let me know how it works out for you, happy to help in any way I can. Also feel free to make any feature requests or open an issue on GitHub.
Re: Show HN: Posthorn, self-hosted mail gateway
#58Earlier quoted context omitted.
Haven't used Apprise, but it looks interesting! 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…
We've chosen Apprise just for the big number of services supported, actually at the moment we only use email and telegram as notification output channels. Apprise does not accept SMTP protocol as input, so you're bound exclusively to API, binary exec or third party integrations. I think Posthorn could fill a gap if it will integrate the possibility to send a webhook (alongside/instead of email).
Awesome. This is helpful, thanks. You're doing my market research for me!
Seems like most setups only really need 2-3 channels, rather than the ~140 supported by Apprise. Definitely worth me looking into when I start to work towards a v2 release and supporting webhooks in general.
The part I'm not sure about yet is how I'm going to implement it. My current approach is to custom write a transport layer for each provider, so a generic webhook would be the first non-bespoke transport. I don't want to lock myself into the path of writing a bespoke solution for every email provider and every channel (that's basically reimplementing Apprise in Go with better email support). I'm hoping I can get a generic webhook that would be good enough for most use cases.
I'll also need to think about if I want to support an email + webhook use case or pick one per request. If I built that and you deployed it for email + telegram, would that be good enough for your use case? You could also just deploy it alongside Apprise if you have an email need that we handle better (and I think we definitely do, especially once I ship html email in 1.x).
If you do end up using Posthorn, please let me know how it goes and feel free to open up any issues you see on GitHub.
Re: Show HN: Posthorn, self-hosted mail gateway
#59How does this differ from using protonmail-bridge? Seems like a similar concept.
If I'm understanding it right, protonmail-bridge exposes an IMAP and SMTP interface to your local mail client so that if you want to use something like Outlook or Apple Mail to talk to ProtonMail you can.
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.
Re: Show HN: Posthorn, self-hosted mail gateway
#60> Nobody wants to run a mail server in 2026. We do, and thats why we use Postal [1]. The more SaaS applications that self-host email the better. It forces the big guys, ie Microsoft, to improve their blocklists and not lazily block entire ranges. Yes its work contacting them occasionally, but it keeps the internet open. The alternative is an internet where they control it all. 1. https://docs.postalserver.io/
Security is the main worry when hosting email servers, not just of the email service, but also in preventing attacks via email. Antivirus integration is available with Postal. May be it is a good idea to chain multiple antivirus solutions. Instead of just expecting that Google or Microsoft would prevent malicious email, Postal may enable better control and transparency.
No, this isn't a worry. Where are you sourcing this? "not just the email service, but also preventing attacks via email".. is saying the same thing, in a rather GPT style.