chatmail/core: the Rust engine that turns e-mail into a messenger

A Rust core for speaking e-mail to other messengers

The chatmail core library implements low level network and encryption protocols, and the README states it is integrated by many chat bots and higher level applications so they can securely participate in the globally scaled e-mail server network.

That framing explains the design. The library is not a chat application. It is the part that knows how to speak SMTP and IMAP to an ordinary mail provider, how to build and parse MIME, and how to encrypt the payload, so that a desktop client, a mobile app or a bot can present a familiar messaging interface on top of infrastructure that already exists everywhere.

The users are therefore developers building a client, not end users installing one. The README points to the Delta Chat contribution page as the project home page, and lists Android, iOS, Desktop, Pidgin, Telepathy, Ubuntu Touch and several bots among the frontends built on the Rust library or its language bindings. The library sits one level below all of those, and the API surface that frontends actually consume is often the JSON-RPC server rather than the Rust crates themselves.

The protocol stack the library keeps out of the caller

The README lists what the library handles so that API users do not have to know much about it: secure TLS setup with DNS caching and shadowsocks and proxy support, SMTP and IMAP handling through the async-smtp and async-imap crates, safe and interoperable MIME parsing with mailparse and MIME building with mail-builder, security audited end to end encryption with rPGP plus the Autocrypt and SecureJoin protocols, ephemeral peer to peer networking using Iroh for multi-device setup and webxdc realtime data, and a P2P group membership protocol that requires no server state.

The Cargo.toml confirms the shape of the stack. The crate is named deltachat, at version 2.64.0-dev with edition 2024 and rust-version 1.89. Dependencies include async-imap, async-smtp, async-native-tls, async-zip, blake3, brotli, base64, fast-socks5, fd-lock and escaper, alongside workspace members for the derive macros, contact tools, format-flowed and the ratelimit crate.

The release profile is tuned for small binaries rather than speed. It sets lto = true, panic = 'abort', opt-level = 'z', codegen-units = 1 and strip = true, and a vendored OpenSSL feature is available for TLS builds that cannot rely on a system library. Optimising for size at the cost of raw throughput is a deliberate trade-off for a library embedded in mobile apps.

Running the REPL against a local profile database

The fastest way to see the library work is the command line client. The README compiles and runs it with cargo:

$ cargo run --locked -p deltachat-repl -- ~/profile-db

The argument is the profile database file, and the utility creates it if it does not exist. Installing the binary is a separate optional step:

$ cargo install --locked --path deltachat-repl/

after which the same client is invoked directly as `deltachat-repl ~/profile-db`.

Configuring an account happens inside the client itself:

Chatmail is awaiting your commands.
> set addr [email protected]
> set mail_pw yourpassword
> configure

Then `> connect` opens the connection to the mail server. The rest is a small set of verbs: `> make-vcard my.vcard 1` exports a public key as a vCard file, `> addcontact [email protected]` and `> import-vcard key-contact.vcard` create contacts, `> listcontacts` prints them, and `> createchat 10` followed by `> chat 12` opens a chat where `> send hi` delivers a message. `> help` lists the rest.

Building the C library and the JSON-RPC server side by side

The repository ships several fronts onto the same core, and the bindings directory listing shows how wide that is: deltachat-ffi/, deltachat-jsonrpc/, deltachat-jsonrpc-bindings/, deltachat-rpc-server/, deltachat-rpc-client/, python/, deltachat-repl/ and deltachat-contact-tools/.

The C library can be installed system wide with CMake, and the README gives the sequence:

$ git clone https://github.com/chatmail/core.git
$ cd deltachat-core-rust
$ cmake -B build . -DCMAKE_INSTALL_PREFIX=/usr
$ cmake --build build
$ sudo cmake --install build

Separately, the project provides reproducibly built deltachat-rpc-server static binaries offering a stdio based high level JSON-RPC API for instant messaging purposes.

The direction of travel is visible in the bindings notes. libdeltachat is going to be deprecated and only exists because Android, iOS and Ubuntu Touch are still using it, and new projects are asked to use the JSON-RPC API instead. JavaScript has an npm package at @deltachat/jsonrpc-client, Python is published on PyPI as deltachat, Go bindings live in a separate repository, and Java and Swift bindings are contained in the Android and iOS repos. Anyone starting a new integration today should plan for JSON-RPC, not for the C ABI.

Peer to peer setup and a group model with no server state

Two items in the protocol list are worth separating from the mail work, because they are where the project goes beyond classic e-mail.

The first is ephemeral peer to peer networking using Iroh, which the README ties to multi-device setup and to webxdc realtime data. In other words, a new device can be paired with an existing one directly, over a temporary peer to peer path, rather than by transferring secrets through the mail server. This is a materially different trust model from forwarding an OpenPGP key by e-mail.

The second is a group membership protocol described as simulation and real-world tested, and crucially one that works without requiring server state. Traditional chat groups live on the server, which means the server knows who is in the group and can enforce membership. Here the membership rules travel with the group itself, so participants can verify the roster from the messages they hold.

The repository root contains spec.md and standards.md, which are the places to look for the normative description of these protocols. The README does not summarise the cryptography, so treat those specifications rather than the overview as the source of truth for the security model.

Fuzzing, ignored tests and what a contribution actually costs

The project takes input from hostile places, so its test story is worth reading before you patch anything. The normal suite is:

# run tests
$ cargo test --all

Some tests are expensive and marked with #[ignore], and the README is explicit that the --ignored argument goes to the test binary rather than to cargo itself:

$ cargo test -- --ignored

Fuzzing uses bolero, installed as a tool:

$ cargo install --locked cargo-bolero

and run from the fuzz directory:

$ cd fuzz
$ cargo bolero test fuzz_mailparse -s NONE

The corpus lives at fuzz/fuzz_targets/corpus, and for the fuzz_mailparse target it can be seeded from ../test-data/message/*.eml files. There is also a proptest-regressions/ directory in the root, which is where property test failures get pinned.

Two build details will trip up a first build. The C FFI crate is built separately with cargo build -p deltachat_ffi --release, and on Windows the README notes that Perl may need to be installed as well to compile deltachat-core. Debugging is aided by DCC_MIME_DEBUG, which prints outgoing and incoming messages when set, and by RUST_LOG=async_imap=trace,async_smtp=trace for protocol level tracing.

Two licence statements that do not agree

The repository is not archived and the last push was on 2026-10-21, with tagged releases v2.63.0 on 2026-10-09, v2.62.0 on 2026-09-22 and v2.61.0 on 2026-09-21, so releases are landing regularly against the main branch.

Licensing is where an adopter needs to slow down. The Cargo.toml in the repository root declares license = "MPL-2.0" for the deltachat package. The project, however, is filed on GitHub under a custom licence that GitHub cannot classify, with a pointer to the LICENSE file at the root of the tree.

Those two statements are not obviously the same thing. MPL-2.0 is a well known file level copyleft licence, and a root level LICENSE file that predates or overrides the manifest field would change what an integrator owes. The repository also carries a NOTICE file style convention through its release documentation, and RELEASE.md and CHANGELOG.md exist for upgrade notes.

So the practical step is to read LICENSE and compare it against the Cargo.toml field before shipping. The file level copyleft obligation of MPL-2.0, if that is what governs, applies to modifications of the covered files, and it does not reach your own modules, but that reading depends on what the LICENSE file actually says. This is not legal advice, it is a reason to open one file before you vendor the crate into a product.

Editorial conclusion

chatmail/core suits teams that want the Delta Chat messaging stack without reimplementing SMTP, IMAP, MIME and OpenPGP, and that can accept a Rust build in their release pipeline. It does not suit projects that need a stable, licence classification today, because the Cargo.toml declares MPL-2.0 while the repository is filed under a custom licence, and it does not suit environments without a native toolchain, since building on Windows also needs Perl. Before adopting, read the LICENSE file and compare it with the MPL-2.0 field in Cargo.toml, then confirm your platform can build the deltachat_ffi crate and that your mail provider works with the configure and connect steps above.

Frequently asked questions

Official sources

1. chatmail/core on GitHub
2. Issues
3. Project website
4. README
5. Releases