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.
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.
Yeah, people underestimate the value of “finished” software: in an ecosystem with lots of stable dependencies, there’s very little reason for useful software to change constantly.
Even "finished" software needs maintenance. Nothing is ever bug-free so needs fixes. And it doesn't live in a vacuum, the ecosystem evolves and continuous adjustments are needed when APIs evolve or libraries change.
In well-written software, the maintenance burden is low, but it's not zero. Without any maintenance, you can maybe run some piece of software in some closed-off container for a while, but it will keep rotting away and eventually you won't even be able to compile it anymore.
What about "GNU Hello", never finished? Clearly this isn't true for 100% of all software, so the only thing we can conclude is that it either "depends" and/or is very subjective.
> when APIs evolve or libraries change.
If you live/work inside an ecosystem that favor stability over "evolving APIs", you can actually be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
Does "small burst of activity and dependency updates twice a year" seem inadequate to you? That's the scale of maintenance that the project in question seems to exhibit, which is what we're apparently calling not maintained.
Commenter was just making the fair point that the dependencies are out of date.
Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
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 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.
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.
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 easy answer is to use an smtp server; many languages have stable packages to implement that.
You can also use postfix with procmail or exim - leave the smtp stuff to tried and true packages, and have your code receive messages either via maildir or direct scripting.
The long answer is: first make sure you don't have a blacklisted IP; ask your cloud provider for permission to enable an MTA (mail transfer agent) and have fun seeing 99% of your email traffic being either brute force auth attempts or spam delivery attempts.
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.
If you're building a system that sends out emails, you generally can't send emails locally. So you instead use a service like MailCatcher/MailHog/MailPit/Mailtrap as an SMTP server that will "catch" the emails as they are sent. Then you just open that app up and you can see what emails were sent, what their content is, who they were sent to, etc. Some of these services also include email evaluation tools for things like identifying unsupported HTML/CSS, checking image/message sizes, headers, etc.
The other use case is when you're in a staging environment. You should generally seed such environments with fake email addresses but you can never be sure those emails are truly fake, and you can never be sure what email addresses your testers are using. So you set up MailPit and A) you never send a real person a fake email accidentally and B) all testers can see all emails.
It seems like almost everyone has written an SMTP server; I use https://github.com/tijn/devmail which has no web interface but a POP server. This is by design so you can see your mail in an actual mail client like Apple's Mail.app or Thunderbird.
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
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 :-)
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.
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.
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.
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.
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.
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?
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).
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'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!
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.
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?
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.
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'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
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.
Any good guides on mailpit + playwright e2e working together?
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.
You ignored first part of that sentence.
"Not changing" has value in its own right.
Yeah, people underestimate the value of “finished” software: in an ecosystem with lots of stable dependencies, there’s very little reason for useful software to change constantly.
Even "finished" software needs maintenance. Nothing is ever bug-free so needs fixes. And it doesn't live in a vacuum, the ecosystem evolves and continuous adjustments are needed when APIs evolve or libraries change.
In well-written software, the maintenance burden is low, but it's not zero. Without any maintenance, you can maybe run some piece of software in some closed-off container for a while, but it will keep rotting away and eventually you won't even be able to compile it anymore.
> Even "finished" software needs maintenance.
What about "GNU Hello", never finished? Clearly this isn't true for 100% of all software, so the only thing we can conclude is that it either "depends" and/or is very subjective.
> when APIs evolve or libraries change.
If you live/work inside an ecosystem that favor stability over "evolving APIs", you can actually be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work. I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
>> What about "GNU Hello", never finished?
Most recently removing an outdated dependency?
> 2024-07-02 18:04:21 -0700 > maint: remove the obsolete gettext module
https://git.savannah.gnu.org/cgit/hello.git/commit/?id=24225...
> be able to use libraries that are decades old, that doesn't have any bugs for the stuff they expose and things just work.
Acknowledging that all software has bugs is the first step to be able to produce high quality.
> I mostly experience this in the Clojure ecosystem, but I'm sure it's true for other ecosystems too.
How many decades exactly has your clojure existed without any bugs?
> Nothing is ever bug-free
Neither is the maintained modern software. If the bugs that there are don't affect you then you don't actually need the fixes.
Does "small burst of activity and dependency updates twice a year" seem inadequate to you? That's the scale of maintenance that the project in question seems to exhibit, which is what we're apparently calling not maintained.
Yes, you definitely don't want to risk closing up all those holes discovered in the last 10 years, lots of people might be left out of your servers.
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.
Commenter was just making the fair point that the dependencies are out of date.
Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
I always run Mailcatcher as a standalone Docker image (I'm already using Docker Compose for development), with no issues.
It's not designed to go in your Gemfile
gem install mailcatcher
:-)
Same for Mailhog
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.
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.
Does it need maintenance? It doesn't seem like much of a problem for working software that is local only.
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.
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.
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/
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 easy answer is to use an smtp server; many languages have stable packages to implement that. You can also use postfix with procmail or exim - leave the smtp stuff to tried and true packages, and have your code receive messages either via maildir or direct scripting.
The long answer is: first make sure you don't have a blacklisted IP; ask your cloud provider for permission to enable an MTA (mail transfer agent) and have fun seeing 99% of your email traffic being either brute force auth attempts or spam delivery attempts.
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.
What about a fly.io container?
For my site https://aichat.email this is how I do this:
SendGrid Inbound Parse --> node.js server --> back to user
I didn't think SES received. It's just a sender.
I run postfix.
What usecases are you finding for this kind of a tool?
If you're building a system that sends out emails, you generally can't send emails locally. So you instead use a service like MailCatcher/MailHog/MailPit/Mailtrap as an SMTP server that will "catch" the emails as they are sent. Then you just open that app up and you can see what emails were sent, what their content is, who they were sent to, etc. Some of these services also include email evaluation tools for things like identifying unsupported HTML/CSS, checking image/message sizes, headers, etc.
The other use case is when you're in a staging environment. You should generally seed such environments with fake email addresses but you can never be sure those emails are truly fake, and you can never be sure what email addresses your testers are using. So you set up MailPit and A) you never send a real person a fake email accidentally and B) all testers can see all emails.
The maintainer says it's still being maintained: https://news.ycombinator.com/item?id=42178862
> 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
It seems like almost everyone has written an SMTP server; I use https://github.com/tijn/devmail which has no web interface but a POP server. This is by design so you can see your mail in an actual mail client like Apple's Mail.app or Thunderbird.
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/
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 :-)
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."
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/
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 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
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.
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.
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.
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'
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.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
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
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'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!
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.
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?
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.
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'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.
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
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.
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!