MailCatcher runs a super simple SMTP server
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 :-)
There is also Mailpit[0] in this space. Actively maintained, written in Go, runs from a single static binary, very low footprint.
Does anyone know of a similar tool for catching SMS messages in local/development environment? My company uses mailtrap[0] in our development environments to give engineers and product managers a tool to preview emails that would otherwise be sent to users and we're looking for a similar tool for the SMS messages that we send via Twilio. I'd love to have a shared "inbox" per-development environment where PMs can see all the SMS messages that would have been sent (namely to whom the message was sent + the content of the SMS). Ideally it'd hook into whatever Twilio SDK your app is using to send messages (Python, in our case) to intercept calls and route them to the sandbox instead.
It seems like Twilio played with this idea with the Twilio Dev Phone project[1] but that project doesn't seem to be actively maintained.
[0] https://mailtrap.io [1] https://github.com/twilio-labs/dev-phone
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.
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.
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.
For a long time I used to use smtp-sink — http://www.postfix.org/smtp-sink.1.html
$ smtp-sink -u nobody -R /tmp/smtp-sink -d "maildir/%Y-%m-%d/mail.%H.%M." 127.0.0.1:25 1024
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.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?
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...
Heh, we started this one 15 years ago now... https://github.com/voodoodyne/subethasmtp
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 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've been using Mailcatcher for dev on a rails app that... well, sends mail sometimes. It has been so incredibly easy to use and run, and I can't imagine needing anything else than what it has. Thanks @sj26 and collaborators!
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 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?
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.
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 use https://github.com/ChangemakerStudios/Papercut-SMTP on windows.
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
Reminds me of my days of building integrations against SendGrid, testing was always "fun".
If you are looking for hosted version, Mailsnag.com does it and more for pretty cheap (or free).
[dead]
If you want a hosted version MailSlurp works well
Mailinator.com has a free version .. just use any inbox @mailinator.com and voila!
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