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

> […]You still have to solve for deliverability, which is something I hope to never have to do. […]

This is the exact case where I'd be really afraid of running it on my own and this I VERY STRONGLY BELIEVE should NOT be the case. Participating in email should be easy.

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.

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

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.