tokio-imap
tokio-imap copied to clipboard
Tokio-based IMAP implementation
# Introduction While the crate does a great job communicating with standard IMAP servers it lacks the serenity to do so with unknown extensions or servers with unknown responses. The...
[IMAP4 ID extension](https://datatracker.ietf.org/doc/html/rfc2971) example from [here](https://datatracker.ietf.org/doc/html/rfc2971#section-3.2) ```rust use imap_proto::Response; fn main() { // https://datatracker.ietf.org/doc/html/rfc2971#section-3.2 let line = r#"* ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" "5.5" "support-url" "mailto:[email protected]")\r\n"#; match...
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...
Hey, cargo-fuzz revealed a stack overflow in my implementation of `search-key`and thus I had a look at which parsers are defined recursively. You can see the result here: https://github.com/duesee/imap-proto-server/issues/3 I...
At this point imap-proto tries all the parsers that are implemented. It has to be so for unsolicited responses, but for solicited responses there could be a subscription mechanism, so...
- [ ] Rank _n_ most often used API items. - [ ] Document those items. I am going to spend significant time on this crate, if all goes well....
supporting server-initiated notifications (standardized keeping one/multiple connections to the server open) using [IMAP IDLE](https://tools.ietf.org/html/rfc2177) or [IMAP NOTIFY](https://tools.ietf.org/html/rfc5465) extensions would be helpful, although it's not a very high priority for me...
RFC 3501 [section 7.4.2](https://tools.ietf.org/html/rfc3501#section-7.4.2) has a lot to say about envelopes that would be handy to include in the docs for `Envelope`. Beyond that though, there are some observations there...
The nom code for parsing would be easier to read if the grammar rules from https://tools.ietf.org/html/rfc3501#section-9 would be placed in comments above each rule. Here is an example of what...
Dear @djc, Can you add the support of RFC 9266: Channel Bindings for TLS 1.3? - https://datatracker.ietf.org/doc/html/rfc9266 Channel Bindings for TLS: https://datatracker.ietf.org/doc/html/rfc5929 - XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html - XEP-0440:...