Haraka

Haraka is a Node.js‑based SMTP server engineered for high throughput and low latency. It can accept and forward thousands of concurrent connections, delivering tens of thousands of messages per second on commodity hardware. Unlike traditional MTAs such as Postfix or Exim, Haraka does not aim to be a mail store; instead it focuses on the routing and filtering phase of email delivery. This makes it an ideal complement to existing LDA/IMAP solutions (e.g., Dovecot) or cloud‑based mail stores.

Technical Stack

• Runtime: Node.js (v14+), leveraging the event‑loop for async I/O.
• Language: Modern JavaScript (ES6+), with optional TypeScript support for plugins.
• Configuration: Plain text files under config/ (e.g., host_list, smtp_forward.ini) and a lightweight plugin registry (config/plugins).
• No external database: All state (e.g., relay queues) is managed via the filesystem or in‑memory structures, though plugins may integrate with Redis, MySQL, or other stores as needed.

Architecture

Haraka follows a pipeline model where each SMTP command (HELO, MAIL FROM, RCPT TO, etc.) is processed by a chain of asynchronous handlers. The core engine exposes hooks (onData, onRcpt, onMailFrom) that plugins can register to alter behavior. This design yields:

• Low overhead: Each connection runs in a single event loop; no per‑connection threads.
• Extensibility: Adding a new feature is as simple as dropping a .js file into plugins/ and enabling it in the registry.
• Modularity: Core functionalities (e.g., DNS lookups, DKIM signing) are split into independent plugins that can be composed arbitrarily.

Core Capabilities

Deployment & Infrastructure

• Self‑hosting: Requires only Node.js and sufficient disk space for queues. Runs on Linux, macOS, or Windows.
• Containerization: Official Docker images are available; the lightweight nature makes it suitable for Kubernetes or ECS deployments.
• Scalability: Horizontal scaling is achieved by running multiple Haraka instances behind a load balancer. Each instance can share a common queue directory or use an external message broker (e.g., RabbitMQ) via plugins.
• Resource footprint: Typically < 200 MB RAM per instance, with CPU usage proportional to connection volume.

Integration & Extensibility

• Plugin System: The core is intentionally minimal; most functionality lives in plugins. Developers can write their own plugins in pure JavaScript, leveraging Node’s async/await syntax.
• Third‑party Plugins: A rich ecosystem exists (SpamAssassin, DKIM, DNSBL, SPF, DMARC). New plugins can be published to npm and dropped into plugins/.
• Configuration API: Plugins expose configuration files (*.ini) that can be edited without code changes. Runtime reloading is supported.
• Event API: Handlers can listen to SMTP events (onMailFrom, onRcptTo) and emit custom events for downstream services.

Developer Experience

• Documentation: The README, inline plugin docs (haraka -h plugins/<name>), and a growing wiki provide clear guidance. Each plugin includes a help command that prints usage.
• Community: Active mailing list, GitHub issues, and Slack channels. Contributors can submit pull requests for new plugins or core improvements.
• Testing: CI pipelines with coverage reports ensure reliability; developers can run tests locally via npm test.
• Debugging: Verbose logging and a built‑in haraka -d debug mode help trace SMTP flows.

Use Cases

1. High‑traffic web services that need to send transactional emails (e.g., password resets) without external SMTP providers.
2. Custom spam filtering layers that integrate with internal policies before handing off to a downstream MTA.
3. Email routing for micro‑services where each service owns its own address space and requires dynamic recipient rewriting.
4. Compliance enforcement (DKIM signing, DMARC checks) in environments that cannot rely on third‑party SMTP relays.

Advantages Over Alternatives