[HN Gopher] MailCatcher runs a super simple SMTP server
___________________________________________________________________
MailCatcher runs a super simple SMTP server
Author : mooreds
Score : 102 points
Date : 2024-11-18 16:51 UTC (6 hours ago)
(HTM) web link (mailcatcher.me)
(TXT) w3m dump (mailcatcher.me)
| ozim wrote:
| I use https://github.com/ChangemakerStudios/Papercut-SMTP on
| windows.
| jweir wrote:
| 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.
| olex wrote:
| 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.
| jweir wrote:
| Oh nothing much: Mailpit is installed via a script and then
| we added a systemd unit vs 'gem install mailcatcher &&
| mailcatcher'
| iruoy wrote:
| 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
| masa331 wrote:
| I use Mailcatcher for almost ten years now and never had a
| problem with it. Maybe is doesn't need maintenance?
| gregoriol wrote:
| Same for Mailhog
| iruoy wrote:
| 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.
| olex wrote:
| 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.
| Saris wrote:
| Does it need maintenance? It doesn't seem like much of a
| problem for working software that is local only.
| hoistbypetard wrote:
| 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 wrote:
| 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 wrote:
| I've seen a few shared Mailpit installations in
| companies. I think that's a quite popular pattern.
| andix wrote:
| 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.
| sigio wrote:
| Yup, can recommend mailpit, running a couple of instances here
| as well.
| yenoham wrote:
| 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/
| andix wrote:
| 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.
| crimsonnoodle58 wrote:
| 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/
| SoftTalker wrote:
| 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?
| jayknight wrote:
| 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).
| asyx wrote:
| Yep. We use this locally as the default smtp server so we can
| see how our email templates render
| olex wrote:
| 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").
| rietta wrote:
| 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.
| mooreds wrote:
| 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
| achairapart wrote:
| 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/
| jeppester wrote:
| 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.
| nonrandomstring wrote:
| 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.
| hoistbypetard wrote:
| 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.
| urda wrote:
| Reminds me of my days of building integrations against SendGrid,
| testing was always "fun".
| alsetmusic wrote:
| 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.
| rietta wrote:
| 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.
| brandonaaron wrote:
| 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.
| Ocha wrote:
| If you are looking for hosted version, Mailsnag.com does it and
| more for pretty cheap (or free).
| nwgo wrote:
| 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?
| wkirby wrote:
| 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.
| hoistbypetard wrote:
| 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.
| jackthemuss wrote:
| If you want a hosted version MailSlurp works well
| p0w3n3d wrote:
| 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
| dunham wrote:
| 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.
| pak9rabid wrote:
| 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.
| msantos wrote:
| 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.
| nickjj wrote:
| 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...
___________________________________________________________________
(page generated 2024-11-18 23:00 UTC)