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
replies(17):
MailPit, MailCrab and smtp4dev are modern alternatives.
https://github.com/axllent/mailpit
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.
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.
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.
> Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.
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 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.
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.
SendGrid Inbound Parse --> node.js server --> back to user
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.
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...
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.
Maintenance doesn't always mean UI redesigns or non-compatible config changes. Sometimes it is just fixing bugs and updating or replacing old dependencies.
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?