There's no rush to move away from MailCatcher or MailHog, but if you're not using those solutions already I see no reason to use them over the maintained options.
> I see no reason to use them over the maintained options
Things that don't change over a longer time period can be more comfortable sometimes. Especially things you use often and build up a sort of "muscle memory" about.
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.
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.
It depends. If it's not exposed to a network and doesn't have any awful bugs, than it should be fine.
Usually those mailtrap servers have some exposure to the company intranet or sometimes the internet, which could be problematic. Even test systems might receive sensitive data in the emails, that shouldn't be leaked to an attacker. An unmaintained software might have well known security issues.
It really only likely matters if you're one of those who is tempted to let it run on `0.0.0.0` instead of loopback only.
Assuming you're not, there's certainly no urgency to migrate. But keep it in the back of your mind that it's unmaintained, and if things go weirdly wrong during an OS or ruby upgrade, remember that you will need to fix it or pick up something else that's kind of similar.
If you're not already using it, it might be a good idea to pick up something else.
I like [mailpit](https://github.com/axllent/mailpit) because it's a single static binary and because it has a nice api I can use during testing to see if a message made it out of the system I'm testing.
But none of that argues for switching away from a thing that's working for you.
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
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 protocol is quite simple to implement. The tricky part is triggering the lambda and then holding the connection open long enough to get the message.
You can’t trigger a lambda directly via tcp. You’d have to go through a gateway. That gateway would have to hold both sides of the connection open for a pretty long time.
Hiya! I'm the maintainer. It's true I don't do much to it these days. But that's because it's complete. There are lots of things I would love to do to improve it. But none of it would dramatically improve what it does. I fix things when they break. But if it ain't broke...
Happy to answer any questions, or be persuaded that something is broken or would be a dramatic improvement :-)
This is a development tool, not production. For it's intended use it is mature. There has been Git activity within the last year so I am not sure why that would be considered unmaintained by some.
If something is important to someone in particular, they should implement a pull request or see the author's website about making a donation or paying for the development of a particular capability.
This is very useful, I use it with Docker Compose in my Flask course to handle sending email in development and tests in a way that doesn't require making an external network call or set anything up on my host. It's perfect for local development and the maintained Docker image supports amd64 and arm64 CPU architectures.
Oh man, MailCatcher is worth its weight in gold. Years ago I used to use this to verify mail coming out from a Rails webapp was doing what it was supposed to. It is extremely useful.
I found it quickly after coming to the realization that a "mailtrap" for local development was very likely a solved problem.
It took 15 minutes and 10 lines of code to add it to the current project's docker-compose-file and so far it's working great. I love how easy docker/podman makes it to set up such services.
What is the intended or typical use for something like this? Testing other applications that send email comes to mind, or am I missing some other uses?
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.
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").
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).
We used to use MailCatcher, and it worked quite nicely, but then switched to Arm machines and it broke. So we are using Mailpit https://mailpit.axllent.org (which also nice, but more complicated to setup).
Looks like MailCatcher fixed the Arm issue – maybe we will switch back.
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.
Many years ago, I threw together something like this in Go (SMTP on one side, a web server on the other, boltdb underneath). We use it for automated tests that involve email notifications, invitations, etc. QA could hit the app and the mail server in the same automated browser.
I was just thinking how I’d like to have my NAS run scheduled scrubbing but wanted an email warning when it was upcoming to prevent unexpected performance issues.
I don’t want my NAS reaching out to the internet except for OS updates and maybe packages to add functionality. I certainly don’t want to hook up one of my email accounts. A tool like this is perfect. I’ll check out the currently maintained projects listed in a sibling comment.
Recently swapped from using the Gem version of this to the docker version on an older ruby on rails project as part or turning it into a devcontainer utilizing docker. Seemed to work well for local dev.
I don't understand. What are use cases for using this or Mailpit? Can't you just create a new email address on existing server and check it? Why do you need different setup and different infra?
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.
Maybe a good use for this is as a low cost final failover. Stick it on
a random box as mx3 priority 100 and if everything else goes south at
least you'll find all the emails eventually.
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.
A tool like this is very useful, but this one isn't being maintained anymore. MailHog isn't either.
MailPit, MailCrab and smtp4dev are modern alternatives.
https://github.com/axllent/mailpit
https://github.com/tweedegolf/mailcrab
https://github.com/rnwood/smtp4dev
What usecases are you finding for this kind of a tool?
I use Mailcatcher for almost ten years now and never had a problem with it. Maybe is doesn't need maintenance?
There's no rush to move away from MailCatcher or MailHog, but if you're not using those solutions already I see no reason to use them over the maintained options.
> I see no reason to use them over the maintained options
Things that don't change over a longer time period can be more comfortable sometimes. Especially things you use often and build up a sort of "muscle memory" about.
Try add it to the Gemfile of a modern Rails project, the dependencies are very out of date and it won’t install.
Docs say
> Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.
It's not designed to go in your Gemfile
gem install mailcatcher
:-)
Same for Mailhog
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.
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.
The website is out of date, last release was actually in may (like smtp4dev) https://github.com/sj26/mailcatcher/releases/tag/v0.10.0
Mea cupla. Fixed.
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.
It depends. If it's not exposed to a network and doesn't have any awful bugs, than it should be fine.
Usually those mailtrap servers have some exposure to the company intranet or sometimes the internet, which could be problematic. Even test systems might receive sensitive data in the emails, that shouldn't be leaked to an attacker. An unmaintained software might have well known security issues.
It really only likely matters if you're one of those who is tempted to let it run on `0.0.0.0` instead of loopback only.
Assuming you're not, there's certainly no urgency to migrate. But keep it in the back of your mind that it's unmaintained, and if things go weirdly wrong during an OS or ruby upgrade, remember that you will need to fix it or pick up something else that's kind of similar.
If you're not already using it, it might be a good idea to pick up something else.
I like [mailpit](https://github.com/axllent/mailpit) because it's a single static binary and because it has a nice api I can use during testing to see if a message made it out of the system I'm testing.
But none of that argues for switching away from a thing that's working for you.
This kind of product could also be useful in shared development environments (such as the sort that QA teams might have access to for example).
I've seen a few shared Mailpit installations in companies. I think that's a quite popular pattern.
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/
Yup, can recommend mailpit, running a couple of instances here as well.
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 protocol is quite simple to implement. The tricky part is triggering the lambda and then holding the connection open long enough to get the message.
You can’t trigger a lambda directly via tcp. You’d have to go through a gateway. That gateway would have to hold both sides of the connection open for a pretty long time.
It would be tricky but doable.
Hiya! I'm the maintainer. It's true I don't do much to it these days. But that's because it's complete. There are lots of things I would love to do to improve it. But none of it would dramatically improve what it does. I fix things when they break. But if it ain't broke...
Happy to answer any questions, or be persuaded that something is broken or would be a dramatic improvement :-)
I actively endorse https://github.com/mailhog/MailHog if you want something more Go-flavoured or operationalised. But it is also "complete."
There is also Mailpit[0] in this space. Actively maintained, written in Go, runs from a single static binary, very low footprint.
[0]: https://mailpit.axllent.org/
This is a development tool, not production. For it's intended use it is mature. There has been Git activity within the last year so I am not sure why that would be considered unmaintained by some.
If something is important to someone in particular, they should implement a pull request or see the author's website about making a donation or paying for the development of a particular capability.
This is very useful, I use it with Docker Compose in my Flask course to handle sending email in development and tests in a way that doesn't require making an external network call or set anything up on my host. It's perfect for local development and the maintained Docker image supports amd64 and arm64 CPU architectures.
An example of that is here: https://github.com/nickjj/build-a-saas-app-with-flask/blob/d...
For a long time I used to use smtp-sink — http://www.postfix.org/smtp-sink.1.html
Until I joined a team that didn’t find cli as fun and preferred GUI tools. And that’s when I found mailcatcher. It’s solid and just works.Oh man, MailCatcher is worth its weight in gold. Years ago I used to use this to verify mail coming out from a Rails webapp was doing what it was supposed to. It is extremely useful.
We recently started using smtp4dev: https://github.com/rnwood/smtp4dev
I found it quickly after coming to the realization that a "mailtrap" for local development was very likely a solved problem.
It took 15 minutes and 10 lines of code to add it to the current project's docker-compose-file and so far it's working great. I love how easy docker/podman makes it to set up such services.
What is the intended or typical use for something like this? Testing other applications that send email comes to mind, or am I missing some other uses?
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
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.
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").
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
We used to use MailCatcher, and it worked quite nicely, but then switched to Arm machines and it broke. So we are using Mailpit https://mailpit.axllent.org (which also nice, but more complicated to setup).
Looks like MailCatcher fixed the Arm issue – maybe we will switch back.
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.
Oh nothing much: Mailpit is installed via a script and then we added a systemd unit vs 'gem install mailcatcher && mailcatcher'
Many years ago, I threw together something like this in Go (SMTP on one side, a web server on the other, boltdb underneath). We use it for automated tests that involve email notifications, invitations, etc. QA could hit the app and the mail server in the same automated browser.
I was just thinking how I’d like to have my NAS run scheduled scrubbing but wanted an email warning when it was upcoming to prevent unexpected performance issues.
I don’t want my NAS reaching out to the internet except for OS updates and maybe packages to add functionality. I certainly don’t want to hook up one of my email accounts. A tool like this is perfect. I’ll check out the currently maintained projects listed in a sibling comment.
I wonder what penetration testing would show in it. When there is web and rewrite to display there is a lot to do in terms of security
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.
Recently swapped from using the Gem version of this to the docker version on an older ruby on rails project as part or turning it into a devcontainer utilizing docker. Seemed to work well for local dev.
I use https://github.com/ChangemakerStudios/Papercut-SMTP on windows.
If you are looking for hosted version, Mailsnag.com does it and more for pretty cheap (or free).
I don't understand. What are use cases for using this or Mailpit? Can't you just create a new email address on existing server and check it? Why do you need different setup and different infra?
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.
If you want a hosted version MailSlurp works well
Reminds me of my days of building integrations against SendGrid, testing was always "fun".
Maybe a good use for this is as a low cost final failover. Stick it on a random box as mx3 priority 100 and if everything else goes south at least you'll find all the emails eventually.
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.