I/O SMTP [](https://docs.rs/io-smtp/latest/io_smtp) [](https://matrix.to/#/#pimalaya:matrix.org) [](https://fosstodon.org/@pimalaya) [](https://pimalaya.org/sponsor/)

August 15, 2026 · View on GitHub

SMTP client library for Rust

This library is composed of 3 feature-gated layers:

Low-level I/O-free coroutines: no_std-compatible state machines containing the whole SMTP logic, usable anywhere
Mid-level light client: a standard, blocking client wrapping a stream you opened yourself
High-level full client: the light client plus TCP connections and TLS negotiations handled for you

Features

I/O-free coroutines: no_std state machines; no sockets, no async runtime, run them from any blocking, async or fuzz harness.
Message submission: greeting, capability discovery, sender and recipient declaration, message data with automatic dot-stuffing, session reset and teardown, plus an all-in-one send.
STARTTLS: upgrade a plain connection to an encrypted one, detecting bytes injected before the handshake.
Authentication: the PLAIN, LOGIN, ANONYMOUS, XOAUTH2, OAUTHBEARER and SCRAM-SHA-256 mechanisms, with or without inline initial response.
Delivery status notifications: ask the server to report successful, failed or delayed delivery, per recipient.
Server limits and diagnostics: declared maximum message size and enhanced status codes.
Light client: a standard, blocking client wrapping a stream you opened and secured yourself.
Full client with TLS support:
- Rustls with ring crypto (requires rustls-ring feature, enabled by default)
- Rustls with aws crypto (requires rustls-aws feature)
- Native TLS (requires native-tls feature)

Tip

I/O SMTP is written in Rust and uses cargo features to gate backend support. The default feature set is declared in Cargo.toml or on docs.rs.

RFC	What is covered
5321	SMTP itself: greeting, hello handshakes, sender and recipient declaration, message data, reset, keep-alive and quit
1870	Message size declaration: read the maximum message size the server accepts
3207	STARTTLS: upgrade a plain connection to TLS, refusing upgrades preceded by injected bytes
3461	Delivery status notifications: the notify, return, envelope and original-recipient submission parameters
3463	Enhanced status codes: the refined three-part codes some servers attach to their replies
4954	The authentication extension: the exchange wrapping every mechanism, with optional inline initial response
4505	The ANONYMOUS authentication mechanism
4616	The PLAIN authentication mechanism
7628	The OAUTHBEARER authentication mechanism, signing in with an OAuth 2.0 bearer token
7677	The SCRAM-SHA-256 authentication mechanism, verifying the server signature against replay