Filters sort and mark mail how you want

[FredOnline]

From the Fastmail blog:

https://fastmail.blog/2020/03/23/ema...ation-filters/

If you love a tidy inbox, the wait is over to take rules to the next level.

[gardenweed]

Interesting. It all sounds good. Especially the bit about being able to forward emails after a search.

But - it looks like it requires an "upgrade" button to be pushed in the settings menu.

My questions are:
i) what functionality is lost if one selects the rules upgrade, and
ii) is the rule upgrade process reversible?

[Grhm]

Since there is no mention of it, I would add
iii) Can we still use Sieve script if we upgrade?

[xyzzy]

I was playing around with this stuff for the last two or three weeks now so I think I have some of the answers.

Functionality lost?
None as far as I can tell. But if you use Sieve it won't (apparently as of today) you can't turn on the new rules stuff.

I think they are worried that their new way of handling rules in sieve can cause syntax errors with existing user-written sieve code. As best as I can tell only with any code that might be in the last user edit block.

For example the old rules stuff was a series of elsif blocks. Not any more. So if the last edit block continues on with an elsif it's an uncaught syntax error. It will be caught if you create or change a rule. But if not I don't know what happens at run time when an invalid sieve script is executed.

I never got that far in my initial testing because create a new rule does do a syntax check and I do have code in that last edit block that started with an elsif. I now precede that code I added with a test of all the possible switches (variables) the new FM-generated rules code now use.

Early in my testing I submitted a ticket on this potential problem and now it comes back to bite me in the form that I can no long enable/disable the old and new rules stuff. I disabled it to see if I could enable in in the release so now I'm locked out.

At any rate, from a UI point of view no old functionality appears to be lost. There are some UI inconveniences to create a rule though since they added the ability to test a rule.

is the rule upgrade process reversible?
If you don't have any of your own sieve code, at the moment, yes. They way it has worked up till now is you could enable/disable it from beta.fastmail.com. Since I can no longer enable it from either because I have sieve code I don't know if there is a disable in the release version.

Can we still use Sieve script if we upgrade?
As of today, beats me. They won't even allow you to test the new rules stuff if you have sieve additions in either release or beta. Sieve was one of the primary reasons I switched to FM. If we can't use it what's the point?

If no user sieve, they don't need sieve tester either. One less thing for them to support -- what little support they ever do on it anyhow.

IMO all they need to do is add a syntax check when the new rules stuff is enabled and report an appropriate error at that time.

[hbs]

On twitter they answered Sieve will stay: https://twitter.com/Fastmail/status/1242638419228078086

[JamesHenderson]

yes, it's using if and stop (rather than if and elseif)

but written in a way that seems more complex than necessary:
set "stop" "Y";
and
if allof( not string :is "${stop}" "Y",

I have always just written:
stop;

[xyzzy]

The "stop" they are testing is a variable set earlier to indicate further down that execution is to stop after some additional action. But the code is not ready to stop execution at the point they set it.

Here's the tests I inserted at the beginning of the last edit block before my additional code...

if anyof(string :is ["${stop}", "${skipinbox}", "${hasmailbox}", "${deletetotrash}", "${spam}"] "Y",
         exists "X-LinkId") {
  stop;
}

That covers all their various test switches where they haven't added stops (although skipinbox and hasmailbox may be redundant). Now the original code I have down there can start with it's own if or remain an elsif. I changed mine to an if.

IMO, it's a shame they didn't "sprinkle" a few underscores in their switch names to help reduce possible naming conflicts with identifiers the user might use in their own code.

I submitted a ticket last night requesting they allow me to turn the new rules stuff back on.

----
Update:
I looked at a copy of the last time I updated my sieve code (I always save a copy) and I noticed they had added the following just before the last edit block (at the end of section 6),

if string :is "${stop}" "Y" {
#   For backwards compatibility
}

That may be the result of my earlier ticket where I warned them about introducing a syntax error with existing user code that may have started the last edit block with an elsif.