filters cannot be applied retroactively, however.

be sure to write your filters before receiving anything. Especially important if you're importing your email for the first time... and insanely annoying if you want to debug such an advanced filter.

as always with fastmail: It has great features... but always with a massive caveat.

Ooooof, wow, thanks for the heads up. There's no way that's going to work... I edit my filters and apply them retroactively... There's no way I can set them in stone the first time. :( is there any email service that doesn't have this limitation?

Its not on FastMail, its on Sieve. It is a hook that runs on receiving. To my knowledge if you want Sieve this is the only option. I use it with Protonmail and it is the same way. I also run it on my own mailserver.

One nice thing, for me at least, is it runs prior to the email ending up in your inbox and I am uses to Outlook rules were rules execute post arrival.

Sieve is an RFC email language. There's no reason Sieve recipes couldn't be applied to a corpus of existing email; that's an implementation detail of FastMail. Sure, it isn't necessarily the same as pre-receive (for example, anything you discarded the first time isn't going to show up again, and any manipulations made the first time aren't going to undo themselves). But it could be done; it's not really Sieve's problem.

Wouldn't using something like https://github.com/lefcha/imapfilter also be an option?

It would be awesome if some day there was a "jmapfilter". I think JMAP would be really efficient for this use case.

Most of my filters are simple searches. And if you can search, you can apply it retroactively.

Also FastMail’s search works for any email header so it can be more potent than that of Gmail.

I wonder why can’t they add a checkbox to apply the rules retroactively. Seems to be simple enough.