Move from MailHog to Mailpit or a better-maintained mail capture tool

[stasadev]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

MailHog is not actively maintained, and there is an alternative solution.

Describe your solution

Mailpit https://github.com/axllent/mailpit is a new default for laravel/sail and laravel/laravel skeleton from v10.x.

It looks like a drop-in replacement, the ports are the same. DDEV can easily migrate to it as well.

Why replace MailHog? - See README.md, there are several good reasons.

Describe alternatives

Continue to use MailHog.

Additional context

There are many places in DDEV where the word "mailhog" is used - it can be tedious to replace them all.

I suggest just updating this line in the ddev-webserver's Dockerfile.

For start, just keep using mailhog name for binary, but use mailpit repo (create a new fork under DDEV org) under the hood.

[rfay]

One thing that has been suggested over the years is to run mailhog in a different container.

One thing you could do here is create an add-on that uses mailpit (overriding the /etc/supervisor config), and we could get some miles on this.

[stasadev]

The mailpit add-on sounds good, I'll give it a try.

[tyler36]

@stasadev

I created one last week: https://github.com/tyler36/ddev-mailpit

[tyler36]

Mailpit does not have feature-parity with Mailhog at the moment.
One feature that is missing is the ability to "release mail".

[stasadev]

@tyler36, thank you!

At first, I didn't find the add-on because I missed this issue

• ddev get --list --all is not returning all available unofficial add-ons #4795.

I tested the add-on with symfony/mailer, and it works great!

[JshGrn]

I don't think this issue should be closed as you are correct, MailHog should be phased out in place of MailPit, is there any internal intention on migrating this into core ddev like MailHog?

[rfay]

The conversation has only just started :) But as @tyler36 says, "Mailpit does not have feature-parity with Mailhog at the moment."

[tyler36]

I think a move to Mailpit would be preferable because it's being actively developed.

"release mail" is a feature that Mailhog has, but Mailpit does not. it is something that I have ever used, but came up on Slack the other day. There's an feature request issue on Mailpit #29.

It would be nice if we had a config option to select Mailhog or Mailpit, similar to database type. Having both as addons is OK, but I think we need this service baked into DDEV out of the box.

[rfay]

Probably the best thing to do is incubate as an add-on, then when we have experience with it, it can be brought into the main DDEV tool.

[tyler36]

What are other popular mail capture tools?

• MailCapture is pretty basic and hasn't been updated recently.

[stasadev]

There is a list of mail transfer agents, but looking at it, we don't really have a good alternative solution for development.

So the most useful at the moment are MailHog and Mailpit.

[EvilBMP]

Other alternatives to MailHog are:

• MailPit ( https://github.com/axllent/mailpit - as already mentioned)
• Maildev ( https://github.com/maildev/maildev )
• Inbucket ( https://github.com/inbucket/inbucket )
• Mailocal ( https://github.com/jfoucher/Mailocal )
• Sendria ( https://github.com/msztolcman/sendria )

I only tested MailPit, Maildev an Inbucket via docker-composer.*.yaml in one of my local projects. I was not able to launch Inbucket quickly, so I skipped that. MailPit and Maildev were fast up and running. They both seem to be a good MailHog equivalent, whereas MailPit is written in Go (as MailHog is/ was) and Maildev is a NPM/ NodeJS application.

So, if MailHog should be replaced, then I recommened MailPit as well, which FYI Ian Kent (maintainer of MailHog) does as well:

mailhog/MailHog#442 (comment)

[EvilBMP]

Mailpit does not have feature-parity with Mailhog at the moment. One feature that is missing is the ability to "release mail".

SMTP Relay has been implemented already - see: https://github.com/axllent/mailpit/wiki/SMTP-relay

[Morgy93]

Something else that is preventing Mailpit from being the new default?
I don't miss any feature and just love Mailpit in comparison to Mailhog. But it offers nice features like dark mode, attachments, plain text mail preview and built-in caniemail.com checker ❤️

[tyler36]

@Morgy93
Yes, I'm failing in love with Mailpit and it's continued development.
Is there anything else we can improve on the mailpit addon? https://github.com/tyler36/ddev-mailpit

[liayn]

Something else that is preventing Mailpit from being the new default? I don't miss any feature and just love Mailpit in comparison to Mailhog. But it offers nice features like dark mode, attachments, plain text mail preview and built-in caniemail.com checker ❤️

We recently noticed that its REST API is different. Not sure if this is a deal-breaker though.

[rfay]

Something else that is preventing Mailpit from being the new default?

Well, nobody has proposed a migration technique or done a PR to implement it. I'm glad that people like it, and are using https://github.com/tyler36/ddev-mailpit

I think maybe the first step toward mailpit would be to promote it to the ddev org. What do you think @tyler36 ?

[stasadev]

It is easy to replace MailHog with Mailpit.

The only change needed here:

ddev/containers/ddev-webserver/Dockerfile

Line 100 in e0b1772

RUN set -x; curl --fail -sSL "https://github.com/ddev/MailHog/releases/download/v${MAILHOG_VERSION}/MailHog_linux_${TARGETPLATFORM##linux/}" -o /usr/local/bin/mailhog && chmod +x /usr/local/bin/mailhog

Can be tested locally:

echo 'ARG TARGETPLATFORM="linux/amd64"
ENV MAILPIT_VERSION="1.8.2"
RUN set -x \
    && curl --fail -sSL "https://github.com/axllent/mailpit/releases/download/v${MAILPIT_VERSION}/mailpit-linux-${TARGETPLATFORM##linux/}.tar.gz" -o /tmp/mailpit.tar.gz \
    && mkdir -p /tmp/mailpit-unpacked \
    && tar -xzvf /tmp/mailpit.tar.gz -C /tmp/mailpit-unpacked \
    && mv /tmp/mailpit-unpacked/mailpit /usr/local/bin/mailhog \
    && chmod +x /usr/local/bin/mailhog \
    && rm -rf /tmp/mailpit*' > .ddev/web-build/Dockerfile

[rfay]

Well, there's docs changes as well, and changes to the launch command, and then there's the discussion about whether mailpit should run in its own container instead of on the ddev-webserver.

[stasadev]

Yes, I just provided what I talked about in the first post of this issue.

Also, I really like the idea of ​​an add-on because it has so many customization options.

[rfay]

Also, I really like the idea of ​​an add-on because it has so many customization options.

Do you think it should remain in core DDEV or are you saying it should become just and add-on? Of course mailhog already has the same customization options.

[stasadev]

I mean, it's easier to see what can be changed by looking at the add-on config.

On the other hand, I won't even change the default config since I use it as a simple email viewer.

My opinion: it should remain in the core DDEV.

[rfay]

Thanks. What's your opinion about whether it should remain in ddev-webserver? That's certainly the simplest path forward as far as code.

[stasadev]

I'm fine with ddev-webserver.

In fact, when I started using DDEV, I was surprised to see MailHog included because I had previously used it as another Docker service. I didn't even think it could be done like this.

[tyler36]

then there's the discussion about whether mailpit should run in its own container instead of on the ddev-webserver.

Personally, I lean towards running in it's own container. It's much easier to debug and disable services when they are isolated. With addons, if it's in the web container and theres a problem, it can prevent the web-container from starting.

I'm happy to go with the crowd though.

[rfay]

With addons, if it's in the web container and theres a problem, it can prevent the web-container from starting

I don't think this has happened with mailhog in the entire history of DDEV though...

[Morgy93]

Three people, three different opinions. 😅

I like the idea of removing Mailhog from the core and using add-ons instead.

It's much more flexible and one could provide an add-on for every other "option" out there. Just as reminder:

• Mailhog ( https://github.com/mailhog/MailHog )
• MailPit ( https://github.com/axllent/mailpit )
• Maildev ( https://github.com/maildev/maildev )
• Inbucket ( https://github.com/inbucket/inbucket )
• Mailocal ( https://github.com/jfoucher/Mailocal )
• Sendria ( https://github.com/msztolcman/sendria )
• (Probably more, thanks to @EvilBMP for the list)

Currently, no real "drop-in replacement" is possible, because of the bundled Mailhog. (Global command, ports etc.)

And if Mailpit is abandoned we don't have to care about the bundled package anymore. 😁

[tyler36]

I like the idea of removing Mailhog from the core and using add-ons instead.

@Morgy93 Yes, that what I was thinking.

[Berdir]

I think having working e-mail handling out of the box with DDEV is a very valuable feature and making it an optional addon would require everyone to always get that addon in a project before that works? It being on a separate container also requires to configure your application to send mails via smtp to that host, whereas it just works right now for example with Drupal.

[tyler36]

I think having working e-mail handling out of the box with DDEV is a very valuable feature and making it an optional addon would require everyone to always get that addon in a project before that works

You're right! I've been using DDEV for so long I've gotten use to the idea that tests email are capture and I don't end up spaming "admin@example.com" with alerts and logs.

[rfay]

Yes, the reason DDEV had mailhog from the beginning was to try to prevent escaping emails!

[mfrieling]

Yes, the reason DDEV had mailhog from the beginning was to try to prevent escaping emails!

I think that is an important feature. I know of two situations where this is life saving.

1. Your setup requires different unique email addresses following a specific scheme (like a Drupal site with multiple user accounts with different roles for testing all perspectives and evtl. a domain restriction for email addresses). And not all providers or email servers support addresses of the form alias+distinction@hostname.tld like Google does.
2. You need to clone a production site for preparing migration tests of new features to it, but can't clean up the databases etc. and replace real addresses with test addresses on the production server for whatever reasons. As of now by just importing the production data into the local DDEV instance and cleanup there you can be sure no email will escape to a real recipient.

[rfay]

Working on this!

[rfay]

Please test and review:

• feat: replace MailHog with Mailpit, provide global router port configuration, fixes #4827, fixes #5220, for #4701 #5313 (comment)

[EvilBMP]

ddev launch -m does not work. It simply opens the default DDEV project URL without the port. Opening the default DDEV project url with the correct port (as mentioned in ddev status) works correctly though.

Sending mails to localhost:1025 in the web container works as expected and shows them in Mailpit.

[stasadev]

@EvilBMP, everything is good on my end.

$ DDEV_DEBUG=true ddev launch -m
FULLURL https://my.ddev.site:8026

Maybe your browser removes the port before opening the link?

[rfay]

@EvilBMP you do have to ddev restart for the new version of the launch command to be installed. It's also possible you have an old launch somewhere besides ~/.ddev/commands/host.

[rfay]

This is now in HEAD