Skip to content
/ tokio-imap Public

Tokio-based IMAP implementation

License

Apache-2.0, MIT licenses found

Licenses found

Apache-2.0
LICENSE-APACHE
MIT
LICENSE-MIT
Notifications You must be signed in to change notification settings

djc/tokio-imap

Repository files navigation

imap-proto and tokio-imap

Build status Join the chat at https://gitter.im/djc/tokio-imap MIT license Apache License 2.0

All feedback welcome. Feel free to file bugs, requests for documentation and any other feedback to the issue tracker or tweet me.

tokio-imap and imap-proto are maintained by Dirkjan Ochtman. If you depend on these projects, please support the project via GitHub Sponsors or contact me for support.

tokio-imap: futures-based IMAP client

crates.io, downloads crates.io, latest release API docs, latest release

NOTE: Unlike imap-proto, tokio-imap doesn't receive much maintenance. As an alternative we suggest to evaluate async-imap instead.

A Tokio stack-based, fully asynchronous IMAP library, with strong focus on following the relevant specs, mainly IMAP4rev1, but with limited support for the Conditional STORE extension. The type system is used to help enforce correctness where possible. So far, there is only client code and lots of infrastructure that supposedly could be shared -- no server yet. (If you want a tokio-based server, look at IMAPServer.)

Feature highlights

  • Fully asynchronous by using tokio-core and tokio-io
  • Uses the type system to help enforce correct operation according to spec
  • nom-based parser (in imap-proto), so far only used for server response messages

Limitations

  • Alpha-level implementation -- no tests yet, limited protocol coverage
  • Server is totally unimplemented at this stage

How to get started

Have a look at the mailsync crate for example usage.

imap-proto: IMAP types and protocol parser

crates.io, downloads crates.io, latest release API docs, latest release

imap-proto is a low-level IMAP protocol support crate, using the type system to provide a safe API. It was extracted from tokio-imap into a separate crate so that different protocol implementations can share it as common infrastructure (as proposed by rust-imap contributors). The code tries to closely follow the IMAP4rev1 RFC, plus extensions.

Protocol support is implemented in three parts:

  • Types that attempt to closely reflect specification requirements
  • A parser implementation to help consume protocol messages
  • Builder types to help produce protocol messages

Progress

  • Client
    • Parser: many common server responses implemented
    • Types: most common types implemented
    • Message builder: most common commands implemented
  • Server
    • Parser: not started
    • Types: not started
    • Message builder: not started