Sirup [](https://matrix.to/#/#pimalaya:matrix.org) [](https://fosstodon.org/@pimalaya)
July 26, 2026 · View on GitHub
CLI to spawn pre-authenticated IMAP/SMTP sessions and expose them via Unix sockets
Table of contents
- Features
- Coverage
- Installation
- Configuration
- Usage
- AI disclosure
- License
- Social
- Contributing
- Sponsoring
Features
- Pre-authenticated sessions: connect and log in once, then expose the live IMAP or SMTP session on a Unix socket so any local client can speak the raw protocol without holding your credentials.
- Account discovery wizard: run with no subcommand and it finds a provider's servers from an email address, a server URL or a bare domain, then prints a ready-to-save account config fragment on stdout.
- SASL authentication: anonymous, login, plain, oauthbearer, xoauth2 and scram-sha-256 (the last requires the
scramfeature). - STARTTLS and implicit TLS: pick either from the account's server scheme, with the ALPN token inferred per protocol.
- REPL: a built-in reference client that forwards raw commands to the socket, for testing and as an implementation example.
- Machine-readable output:
--jsonswitches supported commands to JSON for scripts. - Full standard, blocking client with TLS support:
- Rustls with ring crypto (requires
rustls-ringfeature, enabled by default) - Rustls with aws crypto (requires
rustls-awsfeature) - Native TLS (requires
native-tlsfeature)
- Rustls with ring crypto (requires
Tip
Sirup uses cargo features to gate protocol and TLS support; the default set is declared in Cargo.toml.
Coverage
| RFC | What is covered |
|---|---|
| 9051 | IMAP: the pre-authenticated session, capability advertisement and NOOP keepalive |
| 5321 | SMTP: the message submission session, EHLO greeting and NOOP keepalive |
| 4616 | The PLAIN SASL mechanism |
| 7628 | The OAUTHBEARER SASL mechanism |
| 7677 | The SCRAM-SHA-256 SASL mechanism (requires the scram feature) |
| 6186 | Locating IMAP and submission services through DNS SRV records |
Discovery also covers the PACC draft and Mozilla Thunderbird Autoconfiguration, neither of which is an RFC.
Installation
Pre-built binary
Sirup can be installed with the installer:
As root:
curl -sSL https://raw.githubusercontent.com/pimalaya/sirup/master/install.sh | sudo sh
As a regular user:
curl -sSL https://raw.githubusercontent.com/pimalaya/sirup/master/install.sh | PREFIX=~/.local sh
These commands install the latest binary from the GitHub releases section.
For a more up-to-date version than the latest release, check out the releases GitHub workflow and look for the Artifacts section. These pre-built binaries are built from the master branch.
Note
Such binaries are built with the default cargo features. If you need specific features, please use another installation method.
Cargo
cargo install --locked --git https://github.com/pimalaya/sirup.git
With only IMAP support:
cargo install --locked --git https://github.com/pimalaya/sirup.git \
--no-default-features \
--features imap,rustls-ring
Nix
If you have the Flakes feature enabled:
nix profile install github:pimalaya/sirup
Or run without installing:
nix run github:pimalaya/sirup
Sources
git clone https://github.com/pimalaya/sirup
cd sirup
nix run
Configuration
Run sirup with no subcommand to launch the wizard: it asks for an email address, a server URL or a bare domain, runs provider discovery, prompts for the SASL credentials, then prints the resulting account as a ready-to-save [accounts.<name>] TOML fragment on stdout. Prompts render on stderr, so you can append it straight to your config:
sirup >> ~/.config/sirup/config.toml
Sirup never writes your configuration itself; the config stays entirely user-owned.
A configuration is loaded from the first valid path among:
$XDG_CONFIG_HOME/sirup/config.toml$HOME/.config/sirup/config.toml$HOME/.siruprc
Override the path with -c
Usage
Every command and subcommand is documented through --help. The common flows:
sirup start # start a pre-authenticated session for the default account
sirup start --account work # ... for a named account
sirup repl # attach the reference client to the running session
The start command runs as a blocking daemon, best placed in a systemd service or equivalent: it connects to the server, performs the TLS negotiation and authentication, then exposes the session on a Unix socket. Any client that can read from and write to that socket can then drive the session; the greeting is replaced by an IMAP PREAUTH line (carrying the upstream capabilities) or an SMTP 220 ready line.
Logs go to stderr; --log-level and --log-file control verbosity and destination, and --json switches supported output to machine-readable objects.
AI disclosure
This project is developed with AI assistance. This section documents how, so users and downstream packagers can make informed decisions.
- Tools: Claude Code (Anthropic), invoked locally with a persistent project-scoped memory and a small set of repo-specific rules.
- Used for: Refactors, mechanical multi-file edits, boilerplate (feature gates, error enums, derive macros, trait impls), test scaffolding, doc polish, exploratory design conversations.
- Not used for: Engineering, critical code, git manipulation (commit, merge, rebase…), real-world tests.
- Verification: Every AI-assisted change is read, compiled, tested, and formatted before commit. Behavioural correctness is verified against the relevant RFC or upstream spec, not assumed from the model output. Tests are never adjusted to fit AI-generated code; the code is adjusted to fit correct behaviour.
- Limitations: AI models occasionally produce code that compiles and passes tests but is subtly wrong. The verification workflow catches most of this; it does not catch all of it. Bug reports are welcome and taken seriously.
- Last reviewed: 26/07/2026
License
This project is licensed under either of:
at your option.
Social
- Chat on Matrix
- News on Mastodon or RSS
- Mail at pimalaya.org@posteo.net
Contributing
Contributions are welcome: start with CONTRIBUTING.md, which opens with the Pimalaya-wide guides to read first.
Sponsoring
Special thanks to the NLnet foundation and the European Commission that have been financially supporting the project for years:
- 2022 → 2023: NGI Assure
- 2023 → 2024: NGI Zero Entrust
- 2024 → 2026: NGI Zero Core
- 2027 in preparation…
If you appreciate the project, feel free to donate using one of the following providers:
