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.
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.
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).
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.)
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.
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.
On your Mac, go into Terminal and type “nc 10.0.0.5 4190” (use whatever your Helm’s local IP address is in place of 10.0.0.5) and hit return. You should see something like this:
“IMPLEMENTATION” “Dovecot Pigeonhole”
“SIEVE” “fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext”
“NOTIFY” “mailto”
“SASL” “”
“STARTTLS”
“VERSION” “1.0”
OK “Dovecot ready.”
If you get that far, at least you know the server end is working. Then it’s just getting the client configured correctly.
Given that I work on Internet protocols for a living, the lack of good support for Sieve is kind of embarrassing and a bummer. This shouldn’t be rocket science.
I’m having a little trouble figuring out the Sieve account credentials for my helm.
It connects and asks for a login and pass but using the ones I use for email on that same device don’t seem to work.
Does anyone who’s gotten this working have any suggestions?
EDIT: Apparently my clipboard wasn’t working right and I wasn’t actually pasting in the password. I’m in and have setup a Blacklist script still need to test how well it works. But honestly the interface to this should be in the Helm app.
I’ve got things working, I’ve tested it and my Blacklist rule works, but it appears the rules are specific to the user I logged in with.
What I’d really like to do is setup a domain wide rule.
I can see from sieve docs that this appears to be possible by having the rule inside of the domain-before.sieve or domain-after.sieve rule files. But I can’t figure out via the GUI apps how I’d go about doing that.
I totally missed that sieve allows for server-wide rules; I hope tech support can supply an answer for how to configure those on the Helm.
As for an interface in the Helm app: I would not want to configure this on a phone or tablet. This is definitely a power-user feature that deserves a real UI. The fact that there is no good app out there to do this really stinks, but I don’t think it’s worth the Helm team’s time to try to put this into the config app.
(That said, I really wish they could figure out a way to write a reasonably secure desktop configuration app. Typing on my phone or tablet is really tedious for a bunch of the config options and having a proper desktop UI – not a web form – would be incredibly helpful. It’s definitely on the top of my soon-to-be-sent feature list.)
I wouldn’t want a desktop app. More than likely they’d port something to linux or create some janky java app. Web interface would be MUCH better for all users and lessen the amount of resources required to write and maintain additional app software. Just don’t forward the web interface across the AWS VPN, and maybe even add an on/off slider in the mobile app to enable it. That way you can make your edits, then disable the interface.
The problem with a web interface is of course security. I wouldn’t trust Apache on the Helm to be dorking around with system settings; that seems like a gaping security hole. (Also on my feature request list is a web server so that I could serve up my own web pages, and I’m sure that already makes the Helm folks nervous, but at least that sort of thing could be put into a sandbox so that any code run didn’t have system privileges.) The reason for using a mobile app is because you have much more control over the client and therefore more control over what each side of the interaction can do. Sure, only allowing access through the local address helps somewhat, but you’re still depending on the home network being secure, which is…optimistic.)
But now we’re far afield of the topic of this thread. Perhaps we should start a new thread about config apps. Let’s leave this to the discussion of sieve, and hopefully how to configure the server-wide scripts.
It’s already got a NextCloud web interface. Some (well, at least me) are asking for a webmail interface. Enabling an additional interface on the inside only, that you can disable when not using,
I don’t care about mobile apps, just responding to your comment about a desktop app. That idea is far worse than a web interface.
Did you figure out the cause?
If I do a “nc -vvv helmlocal 4190” the only output I get is
Connection to helmlocal 4190 port [tcp/sieve] succeeded!
That is nc manages to open a connection to the helm server but no output back from the server.
It’s a V2 helm with firmware 2.470. The actual IP-address to helmlocal is the same as the android app reports.
