[HN Gopher] MailCatcher runs a super simple SMTP server
___________________________________________________________________
MailCatcher runs a super simple SMTP server
Author : mooreds
Score : 280 points
Date : 2024-11-18 16:51 UTC (1 days 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.
| diggan wrote:
| > 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 wrote:
| You ignored first part of that sentence.
| naniwaduni wrote:
| "Not changing" has value in its own right.
| fiddlerwoaroof wrote:
| 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.
| picohik wrote:
| 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.
| diggan wrote:
| > 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.
| e12e wrote:
| >> 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=24
| 225...
| account42 wrote:
| > 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.
| naniwaduni wrote:
| 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.
| sureIy wrote:
| 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 wrote:
| Try add it to the Gemfile of a modern Rails project, the
| dependencies are very out of date and it won't install.
| snackernews wrote:
| Docs say
|
| > Please don't put mailcatcher into your Gemfile. It will
| conflict with your applications gems at some point.
| NewJazz wrote:
| 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.
| sj26 wrote:
| It's not designed to go in your Gemfile
|
| gem install mailcatcher
|
| :-)
| bdcravens wrote:
| I always run Mailcatcher as a standalone Docker image (I'm
| already using Docker Compose for development), with no
| issues.
| 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.
| d_sc wrote:
| Any good guides on mailpit + playwright e2e working together?
| 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/
| dustedcodes wrote:
| I run https://msgdrop.io which is a commercial alternative with
| a great API and handy features.
| Vendan wrote:
| 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 wrote:
| Mea cupla. Fixed.
| Onavo wrote:
| 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?
| jedberg wrote:
| 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 wrote:
| What about a fly.io container?
| aforwardslash wrote:
| 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.
| kilroy123 wrote:
| For my site https://aichat.email this is how I do this:
|
| SendGrid Inbound Parse --> node.js server --> back to user
| patja wrote:
| I didn't think SES received. It's just a sender.
|
| I run postfix.
| valunord wrote:
| What usecases are you finding for this kind of a tool?
| apocalyptic0n3 wrote:
| 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.
| jallmann wrote:
| 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
| account42 wrote:
| > this one isn't being maintained anymore
|
| > Latest version: 0.10.0 (released Friday, 25th May 2024)
|
| ???
| snthpy wrote:
| There's also Stalwart which I've been meaning to try out.
|
| https://github.com/stalwartlabs/mail-server
| dirkc wrote:
| I use https://github.com/maildev/maildev, they have a docker
| image that I run as part of my local dev setup
| tijn wrote:
| 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.
| izietto wrote:
| I see mailcatcher repo has fairly recent commits, what do you
| mean by "isn't being maintained anymore"?
| aidenn0 wrote:
| The maintainer says it's still being maintained:
| https://news.ycombinator.com/item?id=42178862
| 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
| pmontra wrote:
| 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.
| 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.
| doublerabbit wrote:
| 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.
| 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
| pmontra wrote:
| 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.
| 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...
| sj26 wrote:
| 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 :-)
| sj26 wrote:
| I actively endorse https://github.com/mailhog/MailHog if you
| want something more Go-flavoured or operationalised. But it is
| also "complete."
| hk1337 wrote:
| 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.
| zinxq wrote:
| Mailinator.com has a free version .. just use any inbox
| @mailinator.com and voila!
| ldthorne wrote:
| 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
| yenoham wrote:
| 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
| e12e wrote:
| 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
| latchkey wrote:
| Heh, we started this one 15 years ago now...
| https://github.com/voodoodyne/subethasmtp
| elliotec wrote:
| 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!
___________________________________________________________________
(page generated 2024-11-19 23:02 UTC)