WAIT — Missing license — unclear to depend on

• Last commit today
• CI configured
• Tests present
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No license — legally unclear to depend on

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Stalwart is a Rust-based all-in-one mail and collaboration server implementing JMAP, IMAP4rev2, POP3, SMTP, CalDAV, CardDAV, and WebDAV protocols. It solves the need for a modern, single-binary mail server that supports both legacy protocols (IMAP/SMTP) and contemporary standards (JMAP) while providing calendar, contact, and file storage capabilities—all written in Rust for memory safety and performance. Monorepo workspace with protocol-specific crates: crates/imap, crates/jmap, crates/smtp, crates/pop3, crates/managesieve for protocol layers; crates/store for persistence; crates/directory for auth/accounts; crates/coordinator for clustering; crates/common for shared primitives. Each protocol crate has a -proto variant (imap-proto, jmap-proto, dav-proto) separating wire format from business logic. Entry point is crates/main.

Systems administrators and hosting providers deploying self-hosted mail infrastructure; developers integrating mail/calendar/contact backends into applications; organizations seeking GDPR-compliant alternatives to SaaS email providers. Users value the comprehensive protocol support and single unified codebase over patchwork solutions.

Production-ready. The project has extensive CI/CD workflows (ci.yml, test.yml, trivy.yml security scanning), 16+ upgrade guides (UPGRADING/v0_04.md through v0_16.md) indicating mature version progression, and 13M+ lines of Rust code. The presence of AGPL + SEL dual licensing and formal SECURITY_PROCESS.md shows professional maturity, though the active upgrade path suggests ongoing breaking changes across versions.

Moderate risk from complexity: 24 interdependent crates in the workspace (jmap, imap, smtp, store, directory, coordinator, etc.) create maintenance surface area. Single-source-of-truth architecture means bugs in the store or coordinator crates affect all protocols; no modular opt-out. Dependency risk is high given Rust's ecosystem size, though lock files (Cargo.lock) are committed. AGPL-only licensing may restrict commercial deployments without explicit negotiation.

Active maintenance evident from 16 sequential upgrade paths and comprehensive test/CI automation. Dependabot configuration (dependabot.yml) indicates continuous dependency updates. Recent work spans protocol compliance (RFC references in README for JMAP extensions, IMAP4rev2, RFC9425 Quotas), clustering features (coordinator crate), and spam filtering (spam-filter, nlp crates). No specific milestone dates visible in file list, but regular upgrades suggest 4–8 week release cadence.

git clone https://github.com/stalwartlabs/stalwart.git
cd stalwart
cargo build --release
cargo run --release

For Docker: docker build -f Dockerfile -t stalwart . or use Dockerfile.fdb for FoundationDB backend. Check crates/main/Cargo.toml for binary target.

Daily commands: For dev: cargo run -p stalwart (entry in crates/main). For release: cargo build --release && ./target/release/stalwart or containerized: docker run -p 143:143 -p 993:993 -p 25:25 stalwart. Configuration via TOML (see UPGRADING guides for schema changes). Requires listening ports for IMAP (143/993), SMTP (25/587), JMAP (80/443), CalDAV/CardDAV (80/443).

• Cargo.toml: Workspace root defining 24 crates and compilation profiles; essential for understanding build options and dev/release/test differences
• crates/main/Cargo.toml: Primary binary target; entry point for the full mail server
• crates/store/src: Persistence layer abstraction; all protocols depend on this for CRUD operations across messages, accounts, calendars
• crates/common/src/auth/: Unified authentication/authorization system used by all protocols; critical for security model
• crates/jmap-proto/src: JMAP wire format and state machine; defines modern API surface
• crates/imap-proto/src: IMAP4rev2/rev1 parser and state machine; legacy protocol support
• crates/coordinator/src: Distributed clustering and replication logic; required for multi-node deployments
• UPGRADING/: Migration guides for each version; essential reference for breaking changes and schema migrations

New protocol feature: Add to respective crate (e.g., crates/imap/src for IMAP extensions). Storage backend: Modify crates/store/src/backend/. Authentication: Edit crates/common/src/auth/. Directory/accounts: crates/directory/src. Shared utilities: crates/utils/src or crates/common/src. Tests: Each crate has tests/ subdirectory; run cargo test --workspace. Build scripts: crates/common/build.rs for compile-time generation.

Database schema migration: Each upgrade version requires explicit migration (see UPGRADING/v0_16.md, etc.). Cargo workspace must be built as whole unit; building single crates may fail due to shared build.rs. Licensing: AGPL-only for open source + SEL for commercial; code contributions require understanding dual-license implications. Protocol state machines: IMAP and JMAP have complex RFC-defined state machines (e.g., IMAP SELECTED state); test carefully. Async runtime: Tokio-dependent; blocking calls will deadlock. Sieve scripts: Custom Sieve extension syntax not in RFC5804; check docs for divergences. Store backend abstraction: Switching from RocksDB to FoundationDB requires database migration and compatibility testing.

• JMAP (JSON Mail Access Protocol) — Core modern protocol competing with IMAP; defines stateless request/response semantics Stalwart must honor for mail clients and interop
• IMAP4rev2 state machine — Legacy protocol with strict state transitions (NOT_AUTHENTICATED → AUTHENTICATED → SELECTED); Stalwart's IMAP layer must enforce these rules
• ManageSieve protocol — Server-side mail filtering script management; Stalwart's crates/managesieve and Sieve interpreter must parse RFC5804 commands
• CalDAV/CardDAV (WebDAV extensions) — Calendar and contact sync protocols; Stalwart's DAV layer (crates/dav-proto, crates/dav) implements RFC4791 and RFC6352 semantics
• Pluggable storage backends — crates/store abstracts RocksDB vs FoundationDB; critical for deployments choosing consistency model and scalability trade-offs
• Sieve mail filtering language — RFC5228 scripting language executed server-side; Stalwart's interpreter must parse and safely execute user scripts without security holes
• SASL authentication — Framework for protocol-agnostic credential exchange; Stalwart reuses SASL across IMAP, SMTP, POP3 reducing auth code duplication

• mailcow/mailcow-dockerized — Popular self-hosted mail stack, but uses Postfix + Dovecot; Stalwart competes as unified single-binary alternative
• matrix-org/synapse — Similar Rust-based (Python in Synapse's case) unified communication server; both target self-hosted federation
• nextcloud/server — Ecosystem companion for calendar/contact/file storage; Stalwart CalDAV/CardDAV can sync with Nextcloud
• fastmail/JMAP-Spec — Official JMAP specification repository; normative reference for Stalwart's JMAP implementation
• imapclient/imapclient — Python IMAP client library; useful for writing integration tests against Stalwart's IMAP server

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for OAuth2/OIDC flows in crates/common/src/auth/oauth

The OAuth module (oauth/config.rs, oauth/token.rs, oauth/introspect.rs, oauth/oidc.rs) lacks dedicated integration tests. Given this is a security-critical authentication system handling external identity providers, comprehensive test coverage for token validation, OIDC discovery, and introspection flows would prevent regressions and improve maintainability. Currently, the test profile has overflow-checks enabled, making it ideal for catching edge cases.

• [ ] Create crates/common/src/auth/oauth/tests.rs with test modules for each oauth/*.rs file
• [ ] Add tests for OIDC config parsing and validation (oauth/config.rs)
• [ ] Add tests for OAuth token generation, refresh, and introspection flows (oauth/token.rs, oauth/introspect.rs)
• [ ] Add tests for OIDC discovery and claim validation (oauth/oidc.rs)
• [ ] Update crates/common/Cargo.toml to include test dependencies (mockito or similar for HTTP mocking)
• [ ] Verify tests run with cargo test -p common and pass in CI

Add GitHub Actions workflow for automated dependency audit and cargo-deny checks

The repo has CI, scorecard, and trivy workflows (.github/workflows/), but lacks automated dependency vulnerability scanning with cargo-deny or similar Rust tooling. Given Stalwart's security-focused positioning (SECURITY.md, SECURITY_PROCESS.md exist) and the large workspace with 23 crates, a dedicated dependency audit job would catch known vulnerabilities early. This complements the existing trivy.yml but adds Rust-specific checks.

• [ ] Create .github/workflows/cargo-deny.yml with job to run cargo deny check on all workspace members
• [ ] Add cargo-deny.lock or create a deny.toml at repo root with advisories and license configurations
• [ ] Configure the workflow to run on: [push to main, pull_request, schedule: weekly]
• [ ] Add step to upload results as GitHub Advisory if vulnerabilities found
• [ ] Test locally with cargo install cargo-deny && cargo deny check
• [ ] Document new workflow in CONTRIBUTING.md

Add protocol-specific benchmark suite for IMAP, JMAP, and SMTP in crates/*/benches/

The Cargo.toml defines a [profile.bench] section with LTO and optimization enabled, but the file structure shows no existing benches/ directories in the protocol crates (crates/imap, crates/jmap, crates/smtp, crates/email, crates/pop3, crates/managesieve). Adding protocol-specific benchmarks would help track performance regressions, validate the server's scalability claims, and provide baselines for optimization efforts. This directly supports the 'scalable' promise in the README.

• [ ] Create crates/imap/benches/imap_parser.rs to benchmark IMAP command parsing (critical for protocol performance)
• [ ] Create crates/jmap/benches/jmap_serialization.rs to benchmark JMAP JSON/CBOR serialization
• [ ] Create crates/smtp/benches/smtp_processing.rs to benchmark message acceptance and validation
• [ ] Create crates/email/benches/email_parse.rs to benchmark email parsing and MIME handling
• [ ] Add benchmark invocation to .github/workflows/ci.yml with cargo bench --no-run to validate builds
• [ ] Document how to run benchmarks locally in CONTRIBUTING.md with cargo bench -p imap -- --profile-time=10

• Add missing IMAP extension test coverage: The crates/imap/src directory likely has protocol extensions (CONDSTORE, QRESYNC, APPENDLIMIT per RFC references) but may lack comprehensive unit tests; audit implemented extensions against RFC requirements and add test_*.rs files.
• Document OAuth2 flow in README: crates/common/src/auth/oauth/ exists but integration docs are missing; add examples to README showing how to configure OAuth2 providers for account authentication.
• Implement basic telemetry dashboard: crates/trc for tracing is committed, but no visualization mentioned; add a simple Prometheus exporter or example Grafana dashboard JSON in examples/ directory.
• Add missing error handling tests in store layer: crates/store/src likely has error paths for corrupted data, quota exceeded, etc.; grep for unimplemented!() or TODO and add integration tests for failure modes.
• Create migration validation script: UPGRADING/ guides are manual; write Python script in scripts/ to validate schema compatibility before upgrade (similar to flyway or liquibase patterns).

Stalwart Labs demonstrates generally solid security practices with AGPL licensing, documented security policy, and multi-layer architecture. However, the codebase faces elevated risks due to: (1) Custom cryptographic implementations requiring specialized security review, (

• Medium · Overflow Checks Disabled in Release Build — Cargo.toml - [profile.release]. The release profile has overflow-checks = false, which disables integer overflow detection in production builds. This could allow integer overflow vulnerabilities to go undetected, potentially leading to buffer overflows or other memory safety issues. Fix: Consider enabling overflow-checks in release builds or implement explicit overflow checking for critical arithmetic operations. At minimum, document this decision and ensure thorough testing of arithmetic operations.
• Medium · Debug Assertions Disabled in Release Build — Cargo.toml - [profile.release]. The release profile has debug-assertions = false, which disables all debug assertions in production. Combined with disabled overflow checks, this reduces runtime safety guarantees in production environments. Fix: Consider enabling debug-assertions for critical security checks. Alternatively, implement explicit assertions for security-critical code paths that remain active in release builds.
• Medium · OAuth Cryptographic Implementation Concerns — crates/common/src/auth/oauth/crypto.rs. The codebase includes custom OAuth and cryptographic implementations (crates/common/src/auth/oauth/crypto.rs). Custom crypto implementations are high-risk areas prone to subtle vulnerabilities. Fix: Ensure all cryptographic operations use well-established, audited libraries (e.g., rustls, ring, argon2). Conduct security audits of custom crypto implementations. Document the cryptographic algorithms and key derivation functions used.
• Medium · Multi-Protocol Support Increases Attack Surface — crates/imap, crates/jmap, crates/smtp, crates/dav, crates/managesieve, crates/pop3. The application implements multiple complex protocols (IMAP, JMAP, SMTP, CalDAV, CardDAV, WebDAV, ManageSieve, POP3) with separate protocol parsers and handlers. Each protocol parser is a potential attack vector for injection attacks, buffer overflows, and protocol confusion. Fix: Implement comprehensive fuzzing for all protocol parsers. Conduct security-focused code reviews of parsing logic. Consider using parser combinators or proven parsing libraries to reduce implementation errors.
• Medium · Missing Input Validation Documentation — Protocol handling crates (imap-proto, jmap-proto, dav-proto, email). With support for multiple protocols handling user input (email, commands, calendar data), the lack of visible input validation patterns in the file structure suggests potential injection risks. Fix: Implement and document strict input validation for all user-supplied data. Use allowlists rather than denylists. Validate all email addresses, calendar data, WebDAV paths, and protocol commands against strict schemas.
• Low · LTO Enabled in Release Build — Cargo.toml - [profile.release]. While Link Time Optimization (LTO) can improve security by enabling more aggressive compiler optimizations, it significantly increases build time and can make debugging harder. Combined with strip = true, binary analysis becomes more difficult. Fix: Maintain this configuration for production but ensure debug symbols are preserved separately for security incident response. Consider maintaining separate debug and release binaries.
• Low · Incomplete Security Policy — SECURITY.md. The SECURITY.md file is incomplete (truncated in provided snippet), and the security reporting process may not be fully documented. Fix: Ensure SECURITY.md is complete with all contact information for security disclosures, expected response times, and disclosure timeline. Consider implementing a bug bounty program.
• Low · Docker Build Uses Latest Rust Version — Dockerfile - cargo-chef base image and apt-get install. The Dockerfile uses rust-slim-trixie which is a latest/unstable base image that may have untested updates. The build process also installs from apt without pinning package versions. Fix: Pin specific Rust and Debian package versions. Use a known-good cargo-chef version tag instead of latest. Document the tested Rust/Debian versions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/stalwartlabs/stalwart shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live stalwartlabs/stalwart repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/stalwartlabs/stalwart.

What it runs against: a local clone of stalwartlabs/stalwart — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in stalwartlabs/stalwart | Confirms the artifact applies here, not a fork | | 2 | Default branch main exists | Catches branch renames | | 3 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of stalwartlabs/stalwart. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/stalwartlabs/stalwart.git
#   cd stalwart
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of stalwartlabs/stalwart and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "stalwartlabs/stalwart(\\.git)?\\b" \\
  && ok "origin remote is stalwartlabs/stalwart" \\
  || miss "origin remote is not stalwartlabs/stalwart (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/stalwartlabs/stalwart"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.