Mail catcher is good solution to test email sending by SMTP, such as:

  • https://mailcatcher.me/
  • https://github.com/linux-china/mail-catcher
  • https://github.com/maildev/maildev
  • https://github.com/mailhog/MailHog

It will be good to add MailConnectionDetails support to make email sending test easy with mail catcher container.

Comment From: wilkinsona

We could update the auto-configuration to add MailConnectionDetails but I'm not sure how much we can do beyond that. As the list above shows, there are a variety of options for running an SMTP server. In terms of official Docker images for the above, there are:

How the SMTP server is configured differs from image to image so I don't think we can offer a general purpose implementation for getting connection details from a container. MailHog appears to be the most popular, so perhaps that's the place to start? It would feel a little odd to have MailConnectionDetails and only have a properties-based implementation.

Comment From: linux-china

MailHog is good for me. All these mail catchers, they almost use 1025 as SMTP port, and I think we just use 1025 as exposed port for spring.mail.port.

Comment From: wilkinsona

The port should be fine. It's username and password that are more complicated. For example, maildev uses MAILDEV_OUTGOING_USER and MAILDEV_OUTGOING_PASS environment variables to configure the credentials for sending mail. These are easy for us to extract from the container and use in the connection details. On the other hand, MailHog seems to use a file which would be much harder to deal with unless we only supported the defaults.

Comment From: linux-china

@wilkinsona, is it possible to introduce org.springframework.boot.properties.xxxx labels, and these labels will be added ad Spring Boot properties. Example as following: 

services:
  mail:
    image: "maildev/maildev"
    ports:
      - '1025'
    labels:
      org.springframework.boot.properties.spring.mail.host = "${container.getHost()}"
      org.springframework.boot.properties.spring.mail.port = "${container.getMappedPort(1025)}"
      org.springframework.boot.properties.spring.mail.username = demo

Value cloud be a SpEL, and container is the variable of GenericContainer or sub GenericContainer.
This way is still ok for other containers, such as NATS, Apache Pulsar etc.

Comment From: eddumelendez

It would feel a little odd to have MailConnectionDetails and only have a properties-based implementation.

Given ConnectionDetails is the entrypoint to do this, it wouldn't be that odd. Doing that, will allow to users create libraries with specific ConnectionDetailsFactory where there are more than one image or not an official image to choose such as mail and activemq. One example is RedisContainerConnectionsDetails, currently only supports standalone but there are images where cluster can be enabled and it's totally fine if spring boot doesn't provide RedisClusterConnectionDetailsFactory but the infrastructure is already there to do it for third-parties.

This is probably related.

Comment From: eddumelendez

For cases like this one and probably #35080 https://github.com/spring-projects/spring-boot/commit/26566d4a30233bb002449a2c0d7a8ffc84d3438e would fix it

Comment From: dominik-kovacs

this would be a wonderful feature, however, I am not sure how much is MailHog maintained

edit: https://github.com/axllent/mailpit This seems to be an actively maintained project

Comment From: eddumelendez

I learn about mailpit today and seems good https://hub.docker.com/r/axllent/mailpit 100M+ pulls and it offers multiarch images. Credentials can be configured via env var as well https://mailpit.axllent.org/docs/configuration/smtp/#passwords-via-environment. TLS support https://mailpit.axllent.org/docs/configuration/certificates/ and it offers a UI for local development

Comment From: linux-china

Using Mailpit with Spring Boot: https://dimitri.codes/spring-boot-mailpit/

Mailpit is great with lots of feature, and it's light.

Comment From: psommersguter

I would +1 this.

For this example repository I also added Mailpit to showcase its usage. Although it is already very simple to add Mailpit through Testcontainers (as described in the previous mentioned blog post and as shown in the little configuration actually needed) there is an unexpected pitfall.

The MailSenderAutoConfiguration requires the spring.mail.host as a condition to activate.
Registering the spring.mail.host property through a DynamicPropertyRegistrar bean unexpectedly is not enough to trigger the auto-configuration although the "Precendence" section of the DynamicPropertyRegistrar JavaDoc would lead you to believe otherwise. You actually need to manually set this property (e.g. in a application.properties with a dummy value) to trigger the MailSenderAutoConfiguration.

Therefore, having some sort of MailConnectionDetails and (in the best case) have all the infrastructure in place so we could annotate the Mailpit container bean with a @ServiceConnection would be great!
Alternatively, as I think that the solution through a DynamicPropertyRegistrar is actually already quite elegant, adjusting the initialization to not need the dummy value for sring.mail.host would be fine as well in my option.

I understand that my point of view is very Mailpit centric right now. Supporting all kinds of other mail-catching solutions through something like MailConnectionDetails might be more tricky. All other mentioned mail-catching projects don't seem to be in active development, though.