this post was submitted on 20 Mar 2024
25 points (96.3% liked)

Rust

5651 readers
12 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
25
Looking for my next project (programming.dev)
submitted 5 months ago by [email protected] to c/[email protected]
21 comments fedilink hide all child comments
 

Hey all,

I'm going to be moving on to my next project and have been thinking about doing an email client. I like Thunderbird, but the search is terrible, and I also want to tackle something that needs pretty high performance for processing emails etc.

Any suggestions or considerations I should think about?

I'll focus on just getting SMTP going in a CLI then I'll introduce some sort of frontend using Qt.

top 21 comments
sorted by: hot top controversial new old
[–] [email protected] 14 points 5 months ago (1 children)

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?

[–] [email protected] 5 points 5 months ago* (last edited 5 months ago) (1 children)

No offense taken. But I've made no assumptions on the simplicity, and I know its a big task and want to start small. I don't mean to compete with Thunderbird, just I like it.

I think it would be a great exercise in learning the protocol and message handling.

[–] [email protected] 3 points 5 months ago

Okay, fairy nuff.

In that case, I would probably start with writing an SMTP or IMAP proxy first. It will teach you everything you need to know about the protocols, and you can reverse engineer the protocols using a client that already works.

It would give you a tangible project outline, which I believe is often critical to not lose motivation or interest.

If you accept using libraries, there’s the imap crate, the mail_send crate, and samotoo crate that are worth looking at.

[–] [email protected] 10 points 5 months ago (1 children)

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.

[–] [email protected] 3 points 5 months ago

Cheers, yea its just something to work on/look into. I'll never finish it of course, but if I can get a few versions into it and has some users/interest I'll keep working on it.

[–] [email protected] 10 points 5 months ago (2 children)

You may consider helping the Thunderbird devs

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

[–] [email protected] 5 points 5 months ago

Yep. I think I may actually do that. I'm leaning towards doing an extension for search to get all the emails into Elasticsearch or Meilisearch.

[–] [email protected] 2 points 5 months ago

@GarlicToast @Matty_r , definitely do. With the little money I have, I use this program on 3 machines of mine. The junk mail filter isn't perfect, but actually works compared to Hotmail's junk filter.

[–] [email protected] 9 points 5 months ago (2 children)

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.

[–] [email protected] 1 points 5 months ago

Maybe a plugin would make more sense and reduce the scope a bit?

[–] [email protected] 1 points 5 months ago (1 children)

Can you give some examples of large programs with their own email client?

[–] [email protected] 2 points 5 months ago

I've heard this joke about emacs, not sure if it is true though.

[–] [email protected] 5 points 5 months ago

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

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

Lemmy's ActivityPub library needs some help.

[–] [email protected] 1 points 5 months ago

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

[–] [email protected] 1 points 5 months ago (2 children)

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

[–] [email protected] 2 points 5 months ago

Slint looks pretty cool. Has a very strong material UI feel to it.

[–] [email protected] 1 points 5 months ago (1 children)

I think you’re misguided about the APIs. Gmail supports IMAP and SMTP. Proton supports those too if you run an encryption bridge on your computer. Fastmail supports IMAP/JMAP/SMTP (they invented JMAP to try and innovate).

Email providers most likely must provide SMTP and IMAP due to compatibility requirements with Apple Mail and other clients.

[–] [email protected] 1 points 5 months ago (1 children)

I tried setting up KMail, Thunderbird, and another email client whose name I can't remember, to use gmail, but they refused to work. Back then the thunderbird doc said something about using APIs instead IMAP+SMTP because google had deactivated "insecure apps". Maybe they undid that? Dunno. Was about a year ago. Possibly because it was locked down at org level, but that would be a valid usecase for using API.

Proton's bridge is 10€ a month or something, but there's API access to proton regardless of price. Didn't know Fastmail had SMTP/IMAP.

CC BY-NC-SA 4.0

[–] [email protected] 1 points 5 months ago (1 children)

First sentence on the first hit when searching for “Gmail smtp imap”:

For non-Gmail clients, Gmail supports the standard IMAP, POP, and SMTP protocols.

https://developers.google.com/gmail/imap/imap-smtp

What you’re referring to is the fact that GMail has apparently disabled authentication using username + password for SMTP/IMAP. I would assume that application passwords still work fine as a workaround, even if they don’t mention it specifically.

[–] [email protected] 1 points 5 months ago

What you’re referring to is the fact that GMail has apparently disabled authentication using username + password for SMTP/IMAP. I would assume that application passwords still work fine as a workaround, even if they don’t mention it specifically.

Oh, yes that might be it! There is a hope again to using a third-party email client! The gmail web client is decidedly not my favorite.

Thanks!

CC BY-NC-SA 4.0