A Major Update for MailTrigger – A Simple HTTP-based Email Notification Service

A few days ago, I’ve made major updates to MailTrigger – a tool that allows you to asynchronously send emails using an HTTP API.

I originally described MailTrigger and the rationale behind that tool in this article: MailTrigger: A Simple HTTP-based Email Notification Service

To summarise:

While there’s no shortage of libraries, APIs and services that help with one or more aspects of this requirement there’s no simple yet comprehensive solution that covers everything from triggering an email event, managing the content of different notification email templates and actually sending the email.

In order to address this issue I created a Spring Boot-based service called MailTrigger (licensed under Apache License, Version 2.0). MailTrigger allows you to asynchronously send emails using an HTTP API. Emails are represented as channels and generated from Markdown templates which are kept in the same source code repository as the software itself. This allows you to simply clone or fork the MailTrigger GitHub repository and use that for managing your email templates.

The most important of these updates is that, as per a feature request by GitHub user timrettop, there now is an official MailTrigger Docker image, which allows you to run MailTrigger in a Docker container:

In the MailTrigger project root folder, there’s an example Dockerfile that can be used to build the image, as well as a sample docker-compose.yml with an example configuration. The latter can be used to run the application via the usual Docker Compose command:

As an added benefit, MailTrigger now also allows you to configure a custom template directory. That way you don’t necessarily have to add your templates to the application source code anymore, which requires recompiling, restarting, and redeploying the applications, but you rather can use an external directory for managing those templates now, which for many environments and use cases should greatly simplify running and managing the MailTrigger application.

Finally, I also updated MailTrigger to the latest Spring Boot version, as well as bumped the project’s other dependencies, most importantly Log4J 2 (see Log4J2 Vulnerability and Spring Boot, The Recent Log4j2 Vulnerability and How to Address it in Spring Boot Applications):

While with its default setup MailTrigger itself isn’t affected by the recent Log4j 2 vulnerabilities, some might have chosen to use Log4j 2 in lieu of the default Logback logging library. To remedy potential security issues that might arise from that, MailTrigger now explicitly sets Spring Boot’s log4j2.version Maven property to the most recent Log4j 2 version, which contains fixes for those vulnerabilities: