[iruoy]

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

[olex]

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.

[d_sc]

Any good guides on mailpit + playwright e2e working together?

[masa331]

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

[iruoy]

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.

[diggan]

> 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.

[rnewme]

You ignored first part of that sentence.

[naniwaduni]

"Not changing" has value in its own right.

[fiddlerwoaroof]

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.

[sureIy]

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.

[Widdershin]

Try add it to the Gemfile of a modern Rails project, the dependencies are very out of date and it won’t install.

[snackernews]

Docs say

> Please don't put mailcatcher into your Gemfile. It will conflict with your applications gems at some point.

[NewJazz]

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.

[bdcravens]

I always run Mailcatcher as a standalone Docker image (I'm already using Docker Compose for development), with no issues.

[sj26]

It's not designed to go in your Gemfile

gem install mailcatcher

:-)

[gregoriol]

Same for Mailhog

[Vendan]

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

[sj26]

Mea cupla. Fixed.

[andix]

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 ([e-mail]), 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.

[crimsonnoodle58]

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/

[Saris]

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

[hoistbypetard]

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.

[nicoburns]

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).

[andix]

I've seen a few shared Mailpit installations in companies. I think that's a quite popular pattern.

[andix]

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.

[jallmann]

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

[Onavo]

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?

[aforwardslash]

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.

[jedberg]

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.

[Onavo]

What about a fly.io container?

[kilroy123]

For my site https://aichat.email this is how I do this:

SendGrid Inbound Parse --> node.js server --> back to user

[patja]

I didn't think SES received. It's just a sender.

I run postfix.

[aidenn0]

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

[valunord]

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

[apocalyptic0n3]

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.

[account42]

> this one isn't being maintained anymore

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

???

[dirkc]

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

[tijn]

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.

[snthpy]

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

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

[izietto]

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

[sigio]

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

[dustedcodes]

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

[yenoham]

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/