More than ten years ago, I was in charge of maintaining the web site www.isis-cnes.fr (owned by the spatial french agency). It was a frontend to sell satellites images and the ordering workflow for the images was a little bit complex. It consist in a lot of steps, interacting with different users, including waiting for email notifications. Thus testing this application was painfull. I finally implemented a bypass in the mail system. Instead of being sent by the MTA, mails could be also written to the disk. I remember that we also had regressions, because the testing server do not use HTTPS, but a simple HTTP. :-/

Recently I encountered a very similar situation when prototyping an application including an instance of passbolt. Passbolt is a password manager, and the application was deployed on kubernetes. Passbolt strongly relies on email. Validate emails means usually, deploying at least DNS server, STMP server and a webmail.

Good news, in 2024 there are now tools to setup https and mail transfert on kubernetes :-) :

• minikube to have a small kubernetes environment on a laptop
• mkcert to setup "true" HTTPS connexion
• mailhog to receive the emails and give the possibility to read them

Properly configured HTTPS server with mkcert

I really like mkcert because it allows to locally test configurations that include HTTPS protocol. Minikube documentation explains here how to configure a default certificate. The default certificated is used when you make a configuration error in your ingress. To serve a valid certificate for your application, you will need to generate additionnal certificates for the ingress:

mkcert -key-file passbolt.test-key.pem -cert-file passbolt.test-cert.pem passbolt.test

The command will generated two files: a private key (passbolt.test-key.pem) and a certicate (passbolt.test-cert.pem). These files can be used in the tls section of the ingress.

Using mailhog

Mailhog is very simple Web interface, that you can use to verify the email notification. It requires almost no configuration when deploying on Kubernetes, just an ingress if you want to avoid access with a port forward.

With the default configuration of the helm chart, you will loose the e-mails each time you restart minikube. But it's possible to store mail in a maildir folder or in a mongodb database. Another limitation of mailhog is the lack of support for TLS authentication for incoming SMTP connexion (see issues/84). So you need to configure your app to send email without TLS authentication.

alternatives

The combo minikube/mkcert/mailhob is perfect for me. But I know that there is others possibilities. Like using a staging environment on kubernetes or using a mail service in your favorite cloud provider. And you, what is your prefered method ?