> ## Content Index
> Fetch the complete content index at: https://corti.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Mailrise: Bridging Legacy SMTP Alerts to Modern Notifications with Docker and Apprise
- URL: https://corti.com/mailrise-bridging-legacy-smtp-alerts-to-modern-notifications-with-docker-and-apprise/
- Published: 2025-12-12T16:21:30.000Z
- Updated: 2025-12-12T16:21:30.000Z
- Author: Sascha Corti

**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`

```yaml
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**](https://api.slack.com/apps?ref=corti.com)
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`

```yaml
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:

```bash
docker-compose up -d

```

Verify that the container is running:

```bash
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:

```bash
brew install msmtp

```

On Linux (Debian/Ubuntu):

```bash
sudo apt install msmtp

```

---

### Configuring msmtp

Create the configuration file:

```bash
vi ~/.msmtprc

```

Add the following:

```ini
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:

```bash
chmod 600 ~/.msmtprc

```

---

### Sending a Test Message

Mailrise expects the **recipient address** in the format:

```
<config-name>@mailrise.xyz

```

Send a message to Slack:

```bash
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:

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

```

### Automatic Update Notifications

For unattended upgrades:

```bash
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:

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

```

Add the contents below:

```ini
[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:

```bash
sudo systemctl daemon-reload

```

Enable Mailrise to start at boot:

```bash
sudo systemctl enable mailrise

```

Start it immediately:

```bash
sudo systemctl start mailrise

```

---

### Verify the Service Status

Check that Mailrise is running correctly:

```bash
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:

```bash
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 🚀