Mailpit works amazingly for us. Thanks to it having a very simple API, we've been able to integrate it into Playwright e2e tests, and can easily verify things like complete new user registration and password reset flows in seconds. And the UI is handy for local dev work.

I use Mailcatcher for almost ten years now and never had a problem with it. Maybe is doesn't need maintenance?

The website is out of date, last release was actually in may (like smtp4dev) https://github.com/sj26/mailcatcher/releases/tag/v0.10.0

Easy REST API access can be a quite useful feature too.

For automated integration testing it's a must. The test can verify in the end if the expected emails were sent out.

I think Mailpit can even be set up as a real SMTP server, handling a (sub) domain. Either as a MX or just via forwarding rules. Sometimes it can be useful to periodically run integration tests on a production system. So your tests could create accounts based on your test domain (random-user-name@testsystem.company.tld), which is deliverable from every email server, and the tests can verify the delivery. An automated script can then periodically delete the *@testsystem.company.tld accounts.

Postal Server is a full featured docker based one that supports inbound and outbound email and has an API. Can be used for dev or production.

https://docs.postalserver.io/

Does it need maintenance? It doesn't seem like much of a problem for working software that is local only.

For those that don't want to run a SMTP server, I built Ephemeral Postal which offers a basic API for polling a mail box and retrieving messages, along with an in-browser UI. You get an entire subdomain to yourself that will take any address that you throw at it. https://ephemeralpostal.com

What’s the easiest way to receive email programmatically without having to resort to a hosted service like SES? Is the SMTP protocol simple enough that it can be implemented in for example a serverless lambda?

The maintainer says it's still being maintained: https://news.ycombinator.com/item?id=42178862

What usecases are you finding for this kind of a tool?

> this one isn't being maintained anymore

> Latest version: 0.10.0 (released Friday, 25th May 2024)

???

I use https://github.com/maildev/maildev, they have a docker image that I run as part of my local dev setup

There's also Stalwart which I've been meaning to try out.

https://github.com/stalwartlabs/mail-server

I see mailcatcher repo has fairly recent commits, what do you mean by "isn't being maintained anymore"?

Yup, can recommend mailpit, running a couple of instances here as well.

I run https://msgdrop.io which is a commercial alternative with a great API and handy features.

Open-source is good for solo and small projects, but there are commercial solutions with continuous support, etc. and other features (e.g. SMS) like Mailosaur too

https://mailosaur.com/

Mailcatcher works great for me. Glad to see you still keep up with bug fixes when needed.

I normally just run it in a docker container configured in docker compose.

I could do without the extra links giving credit in Mailhog, so I will stick with mailcatcher. I know you don't manage Mailhog but that's what will keep me with mailcatcher.

I actively endorse https://github.com/mailhog/MailHog if you want something more Go-flavoured or operationalised. But it is also "complete."

This is what Mailosaur[0] offers - countries available depends on tiers though due to the number operating costs and associated regulations.

[0] https://mailosaur.com

Not the same thing, bit VCR and variants can help with testing external api calls (see "ports to other languages"):

https://github.com/vcr/vcr

Who says it's not for production?

Just because it's not actively developed doesn't mean it's always a development tool.

Looks bug free and feature complete to which I would conclude is more production worthy than most.

What about Mailpit did you find complicated to setup? For us, the Docker image works out of the box, and about all the configuration needed is pointing the SMTP client that does the mail sending to localhost instead of the normal outgoing mail servers.

I use it for testing and local development.

We list it in our docs under 'other services'[0], where it is called out for local development.

Because it has an API[1] you can use it for integration testing as well.

Because it runs in docker, you can use it with any stack, not just ruby.

I would not run it in a prod setting.

0: https://fusionauth.io/docs/get-started/download-and-install/...

1: https://mailcatcher.me/#api

We heavily use it for end-to-end testing. The API is integrated into our Playwright tooling, so we run e2e tests that verify entire user flows including email "steps" - such as the new user registration flow ("Open landing page - click through to registration - fill out and submit form - find confirmation email in Mailpit - click link - log in with new user credentials").

A customer of mine runs a service that sends email notifications and OTP codes. We use Mailcatcher to look at the emails without having to wait for them to get to our real inboxes. Furthermore it catches all the emails, even the ones sent to somebody@example.com so we can have totally fake email addresses in our dev databases.

I use it with docker-compose.yml in Rails and Django applications to catch all emails coming out of a local development copy and be able to confirm they are sent as well as to troubleshoot the layout of those email templates.

This exactly. You run it in your dev environment so that your application can send email and you can view it, without actually sending real emails (that might accidentally go out to real people if you aren't careful).

Yep. We use this locally as the default smtp server so we can see how our email templates render

Local development of an app that will send email. For example, when I'm building a django app, running it via `runserver`, I don't want it to go to an external mail server. And using the console logger for SMTP gets really noisy. Being able to point my browser at Mailpit's web UI lets me see all the messages the app has sent.

It's particularly nice for things like magic links and testing that email confirmations are working.

This is useful for non prod environments, especially local, where you don’t want some background job sending emails welcome to jdoe@gmail.com when you are testing the sign up flow. It allows you to safely send outbound emails to any address without worry that they will actually be delivered, without having to change your application code.

I'd probably use something that's maintained for that... This isn't maintained, and back when I used to do penetration testing, attacking a backup mx was something we routinely did. Those mx records call hostile attention to the systems they point to.

It's a tool for catching emails sent from a local app under development. The developer sending those mails already has local access to the machine.

If someone runs it exposed to the public internet... Oh wow, that could be interesting.