Add mail sender support for spring-boot-testcontainers

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

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

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:

mailcatcher 1M+ pulls
mail-catcher 404 pulls
maildev 10M+ pulls
MailHog 100M+ pulls

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.

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.

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.

@wilkinsona

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

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.

For cases like this one and probably #35080 26566d4 would fix it

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

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

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

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

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.

Cover mail service connection discovery and lifecycle

Navigation Menu

Add mail sender support for spring-boot-testcontainers #35127

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add mail sender support for spring-boot-testcontainers #35127

Description

Activity

wilkinsona commented on Apr 28, 2023

linux-china commented on Apr 28, 2023

wilkinsona commented on Apr 28, 2023

linux-china commented on Apr 29, 2023

eddumelendez commented on Apr 29, 2023

eddumelendez commented on May 3, 2023

dominik-kovacs commented on Mar 24, 2024

eddumelendez commented on Sep 25, 2024

linux-china commented on Sep 26, 2024

psommersguter commented on Oct 6, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions