Server-side mail rules , mailing lists, etc

#1

Is there any plan to add some ability to have some server-side (i.e. on the Helm) mail rules. Things like: “put messages containing this subject in this mailbox”.

Rules are implemented in most desktop clients but is absent in mobile clients such as iOS default Mail client.

If one leaves a desktop client open to apply the rules then it’s possible that the mobile client will see it first then then need to update again and it will move.

So having it done server side is preferable.

Some other items that would be nice would be something like (intra-domain) mailing lists or aliases that will be duplicated across multiple mailboxes.

2 Likes
#2

Not a documented feature (so no complaints if it goes away), but the mail server on the Helm does have the ManageSieve protocol (RFC 5804) turned on. If you have a mail client (like Thunderbird) or standalone client that supports ManageSieve, you can put server-side Sieve (RFC 5228) scripts on the server and the server will execute them on delivery. So far, my scripts are working just fine.

I created my own little mini mailing list using Sieve.

1 Like
#3

Thanks; this looks exactly like I’m looking for (as long as it doesn’t go away). I’m going to give it a try.

#4

Any special setup details to share? I installed the Sieve add-on for Thunderbird (and also am trying the standalone Sieve client from https://github.com/thsmi/sieve), but cannot connect to the Helm on port 4190 (or 2000).

#5

I am connecting to the local LAN IP address on port 4190 using the macos implementation from https://dev.azure.com/thsmi/sieve/. (With the macos version, you have to go hunting through the artifacts to get a build.)

#6

It would be great if the Helm developers could publish a tutorial and build rule-making into the app.

2 Likes
#7

My problem ended up being that the Sieve client wasn’t authenticating with the Helm for some reason. I have RainLoop installed on a server and was able to access and change my sieve rules through their interface.

#8

The most common reason this occurs is that the certificate has to be accepted as an exception. Since your local network IP doesn’t resolve to your Helm domain, the certificate won’t be considered valid. Another approach to resolve this is to add a split DNS configuration in your network so your Helm’s IP resolves to its public domain.