App issues

[dl1ch]

Hi!

I'm interested in having the mailrise app as a middleware for all applications and manage there all the accesses to other notification systems, but I'm encountering some issues. I have multiple questions about the app:

• When using the wildcard "@" with sendgrid:// or mailto:// (mailtos://) connections the "${to}" field is not setup properly and thus cannot forward the email. Could you add the feature for the "${to}" variable to be used also in the "urls" config section? This would make the app much more dynamic
• I have an email address for which I want to use a different notification connection, but the email has a dot "." in the string. How to add the full email (a workaround is to use the wildcard sign, but that might filter other emails too)?
• Could you add a feature to relay / modify / template the email notification based on the source app sending the notification instead of the recipient? (usage: I don't want that all source apps send the same subject string)
• The source email received in the mailrise app is most probably formatted in HTML and I didn't find any documentation that the relaying connection has to convert the input to the format "text" (using tgram:// I HAD to use "?format=text), if not there were errors in the app. Why don't you use by default the HTML type of source, thus eliminating the option to set the "mailrise.body_format: html" option in the config?

Additionally, you could add in the documentation for debugging purposes to use the following docker-compose command:
entrypoint: ["mailrise","-vv","/etc/mailrise.conf"]

Thanks for your answers!

[YoRyan]

Fair questions. Two points to make here:

When I was creating Mailrise, I envisioned the configuration format as a simple 1:1 mapping from email address to Apprise configuration YAML, since that seemed sufficient for the homelab purposes I had in mind. But clearly, it’s not sufficient to cover all of the use cases people are coming up with, especially organizational use. I think the current format has been overloaded enough and the goal should be to implement a new format flexible enough for everyone, perhaps something like what Junction did. You do already have the custom router API if you are handy with Python and need a fully customized solution.

Mailrise already reads the email mimetype and forwards it to Apprise, so you should almost never have to use body_format: html unless you have a badly behaving email client. The problem is that most Apprise targets, like Telegram, do not actually support HTML content and will produce ugly notifications filled with markup or reject them entirely. There is no way to know what will happen ahead of time because Apprise does not provide any information to the caller except for a boolean that is “True” if at least one notification was produced. Perhaps the right thing to do here is to coerce the markup to text by default, from Mailrise’s end, since odds are you don’t want and can’t use an HTML notification. Certainly the documentation on this issue could be a little better.