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

[mzhang28]

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]

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]

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]

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

async-email/async-imap#21

[djc]

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

[link2xt]

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.