Email is ridiculously complex—the technology is dead simple, but the number of exceptions and (undocumented) rules you need to abide by or risk getting banned by half the internet without being told is nothing to sneeze at.

I should know: I have built multiple support platforms that worked through email (amongst other channels).

You mention wanting to start at the SMTP level, and then building a Qt interface. So you’re going to write an SMTP client, an IMAP/POP3/JMAP client, a storage engine, a user interface, and a better search system, all on your own? You’re describing a gargantuan task.

No offense, but each one of those could be a project on its own. You probably think they’re all simple tasks (they’re not), and that you can follow a few RFCs to get things going (you can’t), and that it’ll be easy to debug (it won’t). Finally, I think you’re underestimating how large people’s email maps get.

Why not write a plugin for Thunderbird that improves the search?

You may consider helping the Thunderbird devs

https://www.phoronix.com/news/Thunderbird-Rust-2024

In order to provide some contra to the other comments here

Have fun! Unless you have insane amounts of freetime you probably won't finish it or get it to a state of solid usability. But maybe the journey is the goal and that doesn't even matter.

There's an old joke that every sufficiently big program eventually grows it's own built-in email client. IOW more email clients are the last thing we need.

How substantial and bleeding edge a project do you want to take on? We could use a fast search engine with more modern NLP stuff than Lucene had last time I looked, though idk about now. You could then possibly integrate it with Thunderbird.

Do a Thunderbird Addon instead. I dont think such a project would be sustainable, or that all this fragmentation helps

Lemmy's ActivityPub library needs some help.

It could be worth making it a lib upon which a frontend can be built. For example any logic that goes into retrieving and sending emails, storing data, loading configuration, etc. would be in the lib and whichever frontend somebody wants to tack on would use that lib - TUI, GUI, CLI, web, whatever.

You might want to make it somewhat protocol agnostic. SMTP is used by probably most services, but more and more are using APIs. IINM gmail is oauth and uses the gmail API. Tutanota and Protonmail use their own APIs, but maybe their clients and the proton bridge unveil those somewhat.
Regardless, making it protocol agnostic would allow contributors or third-party authors to add new transports.

Also, slint allows for quite good UI development in rust. I'm not sure yet how good they are with smaller screens, but IMO a client that works on desktop and linux mobile would be awesome.

CC BY-NC-SA 4.0

Maybe something nexus project related? Working with the largest research paper database is definitely going to provide you with a decent challenge.