search

djc / tokio-imap

Tokio-based IMAP implementation
Apache License 2.0
123 stars 42 forks source link

Why is Client's public API so restrictive? (i.e hardcoded port, unable to opt out of TLS, etc) #112

Open mzhang28 opened 3 years ago

mzhang28 commented 3 years ago

STARTTLS implementations serve over unencrypted TCP and then performs a TLS handshake to "upgrade" the connection rather than starting from scratch. Additionally, unencrypted IMAP connections are sometimes desired (localhost?) and doesn't seem to be supported either.

Since Client is genericized over the actual TCP stream type, could it also just expose a constructor that doesn't necessarily construct a TlsClient?

djc commented 3 years ago

Mostly for security reasons. I'm not opposed to making this more flexible, I'll be happy to review PRs that do so.

(To be honest, I think async-imap is a more popular crate offering more functionality, but of course I'm happy if you want to use tokio-imap!)

mzhang28 commented 3 years ago

I see, I didn't know about async-imap before but it seems to depend on async-std rather than tokio and I don't think I want to introduce async-std into my project. I may take a peek into how their Client works and incorporate it into my project and if it works well then I'll make a PR. Thanks for your reply!

djc commented 3 years ago

Yeah, it does depend on async-std -- I somehow thought it was more runtime-agnostic, but that seems to be stuck:

https://github.com/async-email/async-imap/pull/21

djc commented 3 years ago

(Happy to review PRs to extend the Client API, too.)

link2xt commented 9 months ago

async-imap at this point works with async-std and tokio and does not even setup connections itself. You setup a connection and give it to async-imap.