IMPROVEMENT: More flexible notification system

What works really good and what I am using now is following:

1) Create a mailrise docker container on the OMV server with docker compose:

services:
  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    restart: unless-stopped
    ports:
      - 8025:8025
    volumes:
      - ./mailrise.conf:/etc/mailrise.conf:ro

the mailrise.conf has to be set, e.g. for notifications to gotify like this, but can be configured using any apprise url structure. A sample mailrise.conf is here:

I did following simple config for gotify:

configs:
# You can send to this config with "gotify@mailrise.xyz".
#
gotify:
  urls:
    - gotifys://URL/API

Then set the OMV notification settings accordingly:
SMTP-server: 192.168.1.2 (change this to your OMV instance local IP-adress.)

SMTP-port: 8025
Encryption: None
Sender email: any@any.com
recipient email gotify@mailrise.xyz (change according to the mailrise.conf)

This forwards mail received to my gotify instance and notifies me.

Mailrise/gotify pair. That's brilliant.

I've just started looking for something along these lines to "convert/modernize" some notifications on older stuff that only does email notifications without using a paid service. You might have saved me days or even weeks of digging and testing.

Quote from oopenmediavault

What works really good and what I am using now is following:

1) Create a mailrise docker container on the OMV server with docker compose:

Code

services:
  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    restart: unless-stopped
    ports:
      - 8025:8025
    volumes:
      - ./mailrise.conf:/etc/mailrise.conf:ro

the mailrise.conf has to be set, e.g. for notifications to gotify like this, but can be configured using any apprise url structure. A sample mailrise.conf is here:

I did following simple config for gotify:

Code

configs:
# You can send to this config with "gotify@mailrise.xyz".
#
gotify:
  urls:
    - gotifys://URL/API

Then set the OMV notification settings accordingly:
SMTP-server: 192.168.1.2 (change this to your OMV instance local IP-adress.)

SMTP-port: 8025
Encryption: None
Sender email: any@any.com
recipient email gotify@mailrise.xyz (change according to the mailrise.conf)

This forwards mail received to my gotify instance and notifies me.

Display More

First, thanks again for posting this info. Mailrise was the key, as the conversion from email to an IM was the part I was just getting into looking for. I had looked at apprise, but had not found mailrise yet.

I managed to get my notifications set up, but I did deviate from your example a bit. I was having some issues with mailrise intermittently not accepting emails from postfix, possibly because something on the debian/omv install was getting in the way or postfix wasn't liking using the loocalhost/loopback IP/ LAN IP to essentially send mail to itself. I also have a lot running on my system, so instead of spending days trying to figure out what the issue was, I installed an ubuntu server vm, with docker on it to run the notification services and directed the mail to the vm.

I also didn't use gotify in the end. My phone (given to me by my employer) is an iPhone. iPhone has an iGotify app, which also required running an iGotify docker to enable "push" for the notifications to the iGotify app. This worked, but the app on the phone kept disconnecting it from the gotify server docker after a while and I would have to re-enter all the credentials. So instead I linked it up with Signal, using the signal-cli-rest-api docker to send the mailrise output to.

So far it seems to be working great

Quote from ryecoaaron

Care to share more details? Seems like a good example compose file for the compose plugin.

I was planning on pulling together my setup into some documentation to share. I only finished the config last night before I went to bed and would like to run it for a few days before writing something up to make sure it continues to behave and survive a reboot or two if you know what I mean.

As I mentioned though, I ended up setting up an ubuntu server vm to act as the smtp server for postfix to send to. It may be possible to get around the issue I was seeing by using a macvlan in docker, but if the system only has one nic, any hairpinning blocks on the LAN may be a problem too. I have my vm's set to use a second nic that is registered but not configured in OMV so that there is a completely different hardware mac address than the OMV configured nic letting me avoid all hairpinning restrictions.

You may be able to modify what I have done a bit and get a compose yaml file working for a one nic system. As a point of interest though, when I was still running the containers on the omv docker and having the intermittent problems, there was a compose plugin update available, so I took it, and while the update was happening, I was flooded with all the test notifications that were in the queue, but once the update was done and the compose plugin restarted, the intermittent problems resumed. This point may be of interest to you if you are trying to work something up and are seeing anything strange happen, but since the problems seemed to be intermittent, this one flooding of test messages could be completely unrelated.

I may even look at setting up a second nic in the vm that uses the kvm 192.168.122.x range to keep the postfix to smtp route completely “inside the box”

Quote from ryecoaaron

The compose plugin doesn't have a service that could restart to do something like this. Other than marking the module dirty (which will trigger the apply banner), the plugin being updated doesn't even trigger a saltstack run. Any plugin being installed/updated will trigger omv-engined to be restarted. Was there a docker update too?

Nope only one update sitting there for the compose plugin. This of course didn’t trigger a docker/container restart so as I said the behavior may or may not be related to the compose update, I just thought I should share the info in case you see any strange behaviour when working up your example yaml file.

So here is the 2 container compose file I used, the mailrise.conf file for signal, as well as basic notification settings used for omv and links to the documentation on the 2 containers.

Since both containers are in the same yaml file they are automatically on the same docker network and can therefor use the the container name for traffic between the containers. As I have this running in a VM, the appdata paths are just to a directory on the root of the vm's vda. (I switched the vm to a debian 12 instead of ubuntu 24.04 as there seems to be an issue with ubuntu 24.04 where the docker containers become invisible to docker but are still running, making it a bit difficult to troubleshoot or monitor, possibly due to the snap install process instead of a native install. I also added the second nic I mentioned above to it to keep the postfix to mailrise traffic "in the box")

The mailrise.conf file needs to be created before running the container as it is not created by the container and needs to be a bind mount to a file not a directory.

Once set up, you obviously will need a signal account for your phone, and the signal-api container will need to be linked to your signal account using this address modified from their docs http://<ip address of server>:8080/v1/qrcodelink?device_name=signal-api and using your camera to capture the QR code in the signal app

services:

  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    restart: unless-stopped
    environment:
      - UID=1000
      - GID=100
    ports:
      - 8025:8025
    volumes:
      - /appdata/mailrise/mailrise.conf:/etc/mailrise.conf:ro

  signal-cli-rest-api:
    image: bbernhard/signal-cli-rest-api  
    container_name: signal-api
    restart: unless-stopped
    ports:
      - 8080:8080
    volumes:
      - /appdata/signal-api:/home/.local/share/signal-cli
    environment:
      - MODE=native
        
      
networks:
  default:
    name: notifications
    driver: bridge       

configs:
# You can send to this config with "signal@mailrise.xyz".
# command syntax using international +1 phone number - signal://hostname:port/FromPhoneNo/ToPhoneNo
#
  signal:
    urls:
      - signal://signal-api:8080/+1nnnnnnnnnn/+1nnnnnnnnnn

OMV notification settings (adjust as required)

server: 192.168.122.241 (static vm ip set on the internal kvm default network)

port: 8025

sender address: your email address

recipient primary email: signal@mailrise.xyz

...and finally links to the github pages of the 2 projects

GitHub - YoRyan/mailrise: An SMTP gateway for Apprise notifications.

An SMTP gateway for Apprise notifications. Contribute to YoRyan/mailrise development by creating an account on GitHub.

github.com

GitHub - bbernhard/signal-cli-rest-api: Dockerized Signal Messenger REST API

Dockerized Signal Messenger REST API. Contribute to bbernhard/signal-cli-rest-api development by creating an account on GitHub.

github.com

Here is another one specifically for telegram that I have just been playing with. This also seems to work well and when running on omv, does not give me the intermittent issues I was seeing with mailrise when running on the local system instead of the vm during my initial testing. Once again, I will have to run it for a little while before blessing it.

There are a lot more things with native telegram support so this may be a better option for a compose example file. It only requires setting up a telegram bot to make it work, and the same bot can then be used for anything with native telegram support or theoretically even apprise to telegram.

GitHub - KostyaEsmukov/smtp_to_telegram: A small program that listens for SMTP and sends all incoming Email messages to Telegram

A small program that listens for SMTP and sends all incoming Email messages to Telegram - KostyaEsmukov/smtp_to_telegram

github.com

Read the rest of the messages here and wanted to chime in again for a second.

As already said in my post, the configs can be adjusted to whatever notification service you have and want to use. This is all already documented within apprise / mailrise and does not need to be specifically mentioned imo, apart from linking to the two, which I already did.

There is also no need to add more containers or anything ,as the apprise syntax can do that already. See

Signal notification
Telegram notification
all possible notification services are listed here:

All possible ones

So all of the additional containers (signal api, telegram...) is not necessary as far as I understand and complicates the process.

Quote from ryecoaaron

Care to share more details? Seems like a good example compose file for the compose plugin.

I also already made a post here that shows how to set up things with an easy example (no VM and other things needed) which you approved already ryecoaaron. So what is missing there?
Tutorial Thread

Of course I didnt mean that you have to remember. I just specified that there is a post already which should show how to set up those notifications. I didn't know that config files is bad for the compose-plugin. alright .
All in all I didnt want to attack you or anyone here, just stated some more info about it.

Sso I have been doing a bit more digging into this. I seem to have been able to get mailrise to behave by adding environment entries for UID and GID. This was based on reading that mailrise does not like to run as root and it was recommended to run as 998:998, but since I'm not dbtech, I used an omv standard of 1000:100, the same user that owns the config file. modified compose file here:

services:

  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    restart: unless-stopped
    environment:
      - UID=1000
      - GID=100
    ports:
      - 8025:8025
    volumes:
      - /srv/dev-disk-by-uuid-d69073e2-e8f5-4605-aaa2-eb2c662b20b4/appdata/mailrise/mailrise.conf:/etc/mailrise.conf:ro

I can now configure it to send via any of the supported apprise configs.

Which in turn got me thinking. Sonce a lot of users run nextcloud, whu not use the nextcloud talk messager for notification.

Here is the nextcloud based mailrise.conf file:

configs:
# You can send to this config with "nctalk@mailrise.xyz".
      # url format
      # - nctalk://user:pass@host/RoomId
      # - nctalks://user:pass@host/RoomId1/RoomId2/RoomIdN
#

  nctalk:
    urls:      
      - nctalk://user:pass@host/RoomId

Simply fill in the user, password, host IP and room ID(s) for a nextcloud chat to use. In talk, a room is a conversation, so you need to create a conversation first. The Room ID can be found when opening the talk app in a browser and looking at the 8 characters at the end of the address. I would recommend making another user for notifications in nextcloud first and use that user to make the conversation. Then at least the conversation can't be deleted by the normal user and can be re-joined if it is left by mistake.

This might be the simplest option for a compose example as it does not require any bot creation in something like telegram and does not require revalidating pin numbers every couple of days with signal, or any other complicated setups for other IM apps.

Quote from BernH

it was recommended to run as 998:998, but since I'm not dbtech......

I am so disappointed!

Quote from gderf

I am so disappointed!

Ain't no stinkin' 998 here

Quote from oopenmediavault

Of course I didnt mean that you have to remember. I just specified that there is a post already which should show how to set up those notifications. I didn't know that config files is bad for the compose-plugin. alright .
All in all I didnt want to attack you or anyone here, just stated some more info about it.

You might not have been trying to attack, but that is the way it comes across.

I posted about setting up a vm, because the config you posted was not working correctly for me running on omv, and if you read it, you would see that it was explained why. Some people may even prefer to run it as a vm or even repurpose an old raspberry pi as an smtp to IM relay. Everything does not have to be native docker. It was not saying anything that you posted was wrong. If it works for you great, but there is also no need to tell me the things I did were wrong if they work for me. My setup is not your setup.

Keep in mind too that we are all learning here. Trying new things and figuring out ways customize things to work the way we want them to work. There is going to be some back and forth and discussion on things.

This is a user forum.