Mailrise: Bridging Legacy SMTP Alerts to Modern Notifications with Docker and Apprise

Mailrise solves exactly this problem: it acts as an SMTP-to-modern-notifications bridge powered by Apprise, allowing anything that can send an email to notify you via Slack (and many other services).

In this post, I’ll walk through:

• Running Mailrise with Docker
• Configuring Slack as a notification target
• Sending messages from the command line using msmtp
• Practical use cases on servers and desktops

This setup works great for:

• SSH login alerts
• Automatic update notifications
• Simple local automations
• Lab and homelab monitoring
• Legacy devices that only speak SMTP

Architecture Overview

At a high level, the flow looks like this:

Legacy system / script
        |
      SMTP
        |
     Mailrise
        |
     Apprise
        |
 Slack / Push / Chat

Mailrise listens on SMTP, inspects the recipient address, and routes the message to the correct Apprise configuration.

Running Mailrise with Docker

Mailrise is lightweight and runs perfectly as a single container.

Docker Compose Project Structure

mailrise/
├── docker-compose.yml
└── mailrise.conf

docker-compose.yml

version: "3.8"

networks:
  monitoring:
    driver: bridge

services:
  mailrise:
    image: yoryan/mailrise:latest
    container_name: mailrise
    volumes:
      - ./mailrise.conf:/etc/mailrise.conf
    ports:
      - "8025:8025"
    networks:
      - monitoring

Mailrise listens on SMTP port 8025, which avoids conflicts with system mail services and does not require root privileges.

Setting Up Slack for Mailrise

Mailrise relies on Apprise’s Slack integration, which requires a Slack App and Bot Token.

1. Create a Slack App

1. Go to https://api.slack.com/apps
2. Click Create New App
3. Choose From scratch
4. Give it a name (e.g. Mailrise)
5. Select your workspace

2. Enable Bot Tokens

1. Go to OAuth & Permissions
2. Under Scopes → Bot Token Scopes, add:
   • chat:write
3. Install the app to your workspace
4. Copy the Bot User OAuth Token (xoxb-...)

3. Invite the Bot to Your Channel

In Slack, run:

/invite @mailrise

If you skip this step, Mailrise will return SMTP 450 errors when trying to deliver messages.

4. Build the Apprise Slack URL

Your final Slack URL looks like this:

slack://mailrise@xoxb-xxxxxxxx/#alerts

• mailrise → bot name
• xoxb-... → bot token
• #alerts → Slack channel

Mailrise Configuration

Mailrise uses a single YAML configuration file to define notification targets. In our case, we configure Slack with the URL we just created.

mailrise.conf

configs:
  slack:
    urls:
      - slack://mailrise@xoxb-xxxxxxxx/#alerts

Key points:

• slack is the configuration name
• The email recipient determines which config is used
• slack@mailrise.xyz will route to this config

You can add multiple configs (Slack, Signal, Pushbullet, etc.) side-by-side later.

Update mailrise.conf and start Mailrise.

Start Mailrise

From the folder in which you created the docker-compose.yml file, run:

docker-compose up -d

Verify that the container is running:

docker-compose ps

Accessing Mailrise

Mailrise exposes a single SMTP endpoint:

• SMTP: smtp://localhost:8025

There is no web UI — Mailrise is intentionally minimal and script-friendly.

Sending Messages from the Command Line with msmtp

For scripts, cron jobs, and automation, msmtp is a perfect lightweight SMTP client.

Installing msmtp

On macOS:

brew install msmtp

On Linux (Debian/Ubuntu):

sudo apt install msmtp

Configuring msmtp

Create the configuration file:

vi ~/.msmtprc

Add the following:

defaults
auth off
tls off

account mailrise
host localhost
port 8025
from youremail@yourdomain.com

account default : mailrise

Notes:

• No authentication required
• No TLS required (local delivery)
• from can be any valid email address

Secure the file:

chmod 600 ~/.msmtprc

Sending a Test Message

Mailrise expects the recipient address in the format:

<config-name>@mailrise.xyz

Send a message to Slack:

echo "Body text" | msmtp "Subject line" slack@mailrise.xyz

Within seconds, the message appears in your Slack channel.

Practical Use Cases

Linux Server Login Alerts

Add this to /etc/pam.d/sshd or a login script:

echo "SSH login on $(hostname) by $USER" | \
msmtp "SSH Login Alert" slack@mailrise.xyz

Automatic Update Notifications

For unattended upgrades:

echo "Automatic updates completed successfully on $(hostname)" | \
msmtp "System Updates" slack@mailrise.xyz

Desktop Automations

I use the same setup on my MacBook for:

• Folder watcher scripts
• Build notifications
• Local cron jobs
• Home automation triggers

Because everything talks SMTP, the same tooling works everywhere.

Running Mailrise Automatically on Linux based Server Startup (systemd)

On a Linux server, you typically want Mailrise to start automatically on boot and shut down cleanly during system shutdown. While Docker itself can restart containers, using systemd gives you better control, logging, and dependency management.

Below is a simple and robust systemd unit that starts your Mailrise Docker Compose project at boot.

Create a systemd Service Unit

Create the following file:

sudo vi /etc/systemd/system/mailrise.service

Add the contents below:

[Unit]
Description=mailrise
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c "docker compose -f /home/user/docker/mailrise/docker-compose.yml up --pull always --detach"
ExecStop=/bin/bash -c "docker compose -f /home/user/docker/mailrise/docker-compose.yml stop"

[Install]
WantedBy=multi-user.target

What This Does

• Requires / After docker.service
  Ensures Docker is fully running before Mailrise starts
• Type=oneshot + RemainAfterExit=yes
  Treats Docker Compose as a managed task rather than a long-running process
• ExecStart
  • Starts Mailrise in detached mode
  • Automatically pulls updated images on reboot (--pull always)
• ExecStop
  Cleanly stops the Mailrise stack during shutdown or service stop

Adjust the path /home/user/docker/mailrise/docker-compose.yml to match your actual setup.

Enable and Start the Service

Reload systemd to pick up the new unit file:

sudo systemctl daemon-reload

Enable Mailrise to start at boot:

sudo systemctl enable mailrise

Start it immediately:

sudo systemctl start mailrise

Verify the Service Status

Check that Mailrise is running correctly:

sudo systemctl status mailrise

You should see:

• The service marked as active
• Docker Compose having started the container successfully

If anything goes wrong, systemd logs are available via:

journalctl -u mailrise

Why Use systemd Instead of Docker Restart Policies?

While Docker restart policies work well for single containers, systemd + Docker Compose provides:

• Explicit startup ordering
• Centralized logging
• Easy upgrades via --pull always
• Clear operational semantics for servers

For infrastructure services like Mailrise, this approach is predictable, transparent, and production-friendly.

With this in place, Mailrise becomes a fire-and-forget component of your server setup — always available to turn SMTP alerts into modern notifications.

Troubleshooting

Mailrise Returns SMTP 450 Errors

Most common cause:

• Slack bot is not invited to the target channel

Fix it by running:

/invite @mailrise

Then retry sending the message.

Why Mailrise?

Mailrise hits a sweet spot:

• Zero-friction SMTP ingestion
• Modern notification delivery via Apprise
• Docker-native
• Stateless and easy to reason about
• Perfect for homelabs and production servers alike

If a system can send email, it can now notify you where you actually look.

Conclusion

Mailrise turns SMTP from a legacy liability into a powerful compatibility layer. With a few lines of Docker Compose and a tiny msmtp config, you get modern notifications everywhere, without rewriting old tools or scripts.

It’s one of those small infrastructure components that quietly becomes indispensable once installed.

Happy alerting 🚀