Why is Fastmail's search so terrible and how can it be improved?

(I work for Fastmail). I'm not quite sure what to make of this. We believe our search is generally as powerful as Gmail's, and in some ways more so (see all the things we support here: https://www.fastmail.help/hc/en-us/articles/360060591213-Sea...), but we're always happy to hear ideas for improvements.

> no partial matches

To make your search fast, we use an index. This means we match on stemmed whole words by default (so a search for "bus" would match "busses", but not "business" for example). We also support prefix matching, if you end with a `` (e.g. "bus" would match both "busses" and "business"). We cannot support pure substring matches. This is exactly the same as Gmail as far as I can tell (although their stemming algorithm is probably slightly different). Gmail also doesn't support prefix searches as far as I know, just stemmed whole word matches.

> no matches for spelling mistakes

I see if your result has no matches in Gmail, it applies spelling correction and shows you what results this produces instead — I agree, this is a nice feature, I'll add it to our ideas bank.

> weird indexing of some sort of email content (attachments?) that leads to a match when there is absolutely nothing related in that email

We index the contents of attachments (again, as does Gmail I believe). By default we search everywhere, including inside attachments if you just search for a word. Most users find this helpful. If you want to restrict to just searching the message content, you can do so with the `body:` operator.

> it has no idea about the context of the search to improve matches, like 'flight' being possibly related to e.g. travel

I'd love to hear more about how you expect this to work. Searching a Gmail account on the web for "flight" doesn't seem to do anything special I can see, but maybe it does so in their app?

This seems like a rant. I've never thought that Fastmail's search is terrible. In fact I've found it really fast and accurate when I use it.

It's true that, now that you mention those potential improvements, it would be great to have them but it just means that Google's search is better than Fastmail's rather than Fastmail's being terrible.

No partial matches probably related to how they index emails to save on space, I found it annoying once or twice too but not a big deal. As for the rest - well, I don't really want it to 'fix' my typos(especially since I'm bilingual) and I actually like indexing of email attachments, I often looked for products I bought and found them through invoice attachments.

I like how fast it is though, I instantly get results from gigabytes of old emails, I can forgive lack of partial matches here.

I wouldn't call any of these low-hanging fruits. Implementing these from backend side is not trivial. The last one basically needs ML model, unless you want to hardcode things (remember, there are other languages than English too). I find Fastmail search acceptible.

I always considered Fastmail to be a transport/protocol provider and the web/mobile apps to be conveniences. If I had any of these concerns, I'd download or otherwise replicate the data and to my searches elsewhere.

Since there are Fastmail people here, I'll say the web app's search is slowly improving, but it leaves a lot be desired. For example, it is stupid around interpreting time intervals for search. E.g.,

You can ask it to Search "between" times.

If you give it __Jan__ and __Feb__, of course, you expect it to include everything between Jan 1 and Feb 28 (if it's not a leap year) or Feb 29 (if it is a leap year). What does it do?

after:2023-01-01 before:2023-02-02

Sad.

To everyone who appreciates Fastmail search: how can I search all emails with empty subjects? I've been banging my head against this for years.

I think it's simple and works very well

Please don’t crapify my Fastmail search. I don’t want it to be like Google, giving me what it thinks I want rather than what I asked for.

search works fine for me. it's spam detection that's terrible.