haraka 0.0.33 → 3.3.1

package/SECURITY.md

@@ -0,0 +1,178 @@
+# Security Policy
+
+## Supported Versions
+
+Security fixes are applied to the **current release** only. We encourage all users to run the latest version.
+
+| Version        | Supported |
+| -------------- | --------- |
+| 3.1.x (latest) | ✅        |
+| < 3.1          | ❌        |
+
+## Reporting a Vulnerability
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+Use [GitHub Private Vulnerability Reporting](https://github.com/haraka/Haraka/security/advisories/new) to disclose security issues confidentially. This allows the maintainers to assess and patch the issue before public disclosure.
+
+Include as much of the following as possible:
+
+- A description of the vulnerability and its potential impact
+- Steps to reproduce or a proof-of-concept
+- Affected version(s)
+- Any suggested mitigations or patches
+
+## Response Process
+
+1. **Acknowledgement** — We aim to acknowledge reports within **72 hours**.
+2. **Assessment** — We will confirm the issue, determine severity, and identify affected versions.
+3. **Fix & Release** — A patch release will be prepared and coordinated with the reporter.
+4. **Disclosure** — A GitHub Security Advisory (and CVE if applicable) will be published after the fix is available.
+
+We follow [coordinated vulnerability disclosure](https://vuls.cert.org/confluence/display/CVD). Reporters are credited in the advisory unless they prefer otherwise.
+
+## Security Advisories
+
+Published advisories are listed at:
+**https://github.com/haraka/Haraka/security/advisories**
+
+## Threat Model
+
+Haraka is an SMTP server and plugin host. It accepts inbound network
+connections, parses SMTP commands and message content, and can deliver mail
+outbound when an operator enables relaying or outbound.
+
+This threat model assumes the operator controls the host, configuration,
+enabled plugins, credentials, TLS material, and any external services Haraka
+is configured to use.
+
+### Data flow
+
+```mermaid
+flowchart LR
+    client["SMTP client<br/>(untrusted)"]
+    dns["DNS resolver<br/>(untrusted)"]
+    peer["Outbound peer<br/>(untrusted)"]
+    operator(["Operator<br/>(trusted)"])
+    subgraph haraka["Haraka process — trust boundary"]
+        listener["Listener / TLS / Parser"] --> plugins["Plugin pipeline"]
+        plugins --> queue[("Queue · FS")]
+        queue --> delivery["Delivery"]
+        stores[("Config · TLS keys · Logs")]
+    end
+    client <--> listener
+    plugins <--> dns
+    delivery --> peer
+    operator -.-> stores
+    operator -.-> plugins
+```
+
+The trust boundary is the Haraka process. External peers (SMTP clients, DNS
+resolvers, outbound peers) are untrusted; data crossing the boundary inbound
+must be validated before it affects delivery, state, or process behavior.
+Inside the boundary, plugins, the queue, configuration, TLS material, and
+logs share the Haraka process privilege and are the operator's
+responsibility — they are not a security boundary against each other.
+
+### Assets
+
+The assets Haraka aims to protect:
+
+- **Message content** in transit and queued on disk
+- **AUTH credentials** received via SMTP AUTH, and any upstream credentials
+  Haraka holds for outbound or backend services
+- **TLS private keys** and certificates used by the listener and for
+  outbound delivery
+- **Queue integrity** — no injection, alteration, or deletion of queued
+  messages from outside the trust boundary
+- **Availability** of the SMTP service to legitimate clients
+- **Sender reputation** of the operator's deployment — Haraka must not be
+  abusable as an open relay or spam amplifier under documented
+  configuration
+
+### Entry points and actors
+
+Untrusted data enters Haraka through:
+
+- **SMTP listeners** on the operator-configured ports (typically 25, 465,
+  587, and any additional listeners enabled by plugins or configuration)
+- **PROXY protocol or XCLIENT metadata** when the operator has enabled
+  trusted-relay forwarding
+- **DNS responses** to lookups performed by Haraka core or plugins
+  (rDNS, SPF, DKIM, MX, DNSBL, etc.)
+- **Outbound SMTP responses** received from peers during delivery
+
+Haraka distinguishes these actors:
+
+- **Anonymous SMTP client** — connecting from the network without
+  authentication; trusted only to issue SMTP commands subject to policy
+- **Authenticated submission user** — passed SMTP AUTH; trusted with the
+  envelope and policy the operator's auth backend permits, nothing more
+- **Trusted relay peer** — a network source the operator has configured to
+  bypass certain checks (e.g. permitted to relay, or whose PROXY/XCLIENT
+  metadata is honored)
+- **Operator** — controls the host, configuration, and installed plugins;
+  fully trusted
+- **Plugin code** — runs inside the trust boundary with full process
+  privilege; treated as trusted-as-installed, and not a security boundary
+
+### Haraka does not trust
+
+- SMTP clients and other remote peers, including commands, envelopes, headers,
+  bodies, attachments, authentication attempts, HELO/EHLO names, and proxied
+  client metadata before validation
+- Data returned by remote services Haraka communicates with, such as DNS
+  lookups and outbound SMTP peers
+- Untrusted remote input must not be able to trigger behavior beyond
+  documented SMTP and plugin semantics, such as unauthorized relaying,
+  unintended command execution, protected-data disclosure, or service
+  unavailability
+
+### Haraka trusts
+
+- The operating system, filesystem, Node.js runtime, local network, process
+  privileges, and local administrators operating the service
+- Haraka configuration and deployment choices, including listener exposure,
+  relay and authentication policy, TLS certificates, proxy settings, and
+  enabled plugins
+- Code loaded as plugins or dependencies. Plugins run with Haraka's process
+  privileges and are not a security boundary
+- Upstream services and dependencies as separate projects; flaws in those
+  components are usually reported upstream unless Haraka's integration creates
+  a distinct vulnerability
+
+### STRIDE summary
+
+In-scope threats are classified using [STRIDE][stride] applied at the
+Haraka trust boundary shown above. A finding that lets a remote peer
+cause any of the following under documented or default-safe configuration
+is generally a vulnerability.
+
+| Category                   | Example threats at the Haraka boundary                                                                                 |
+| -------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| **S**poofing               | Forged HELO/EHLO or AUTH, identity bypass, unvalidated XCLIENT or proxy metadata accepted as authoritative             |
+| **T**ampering              | SMTP smuggling, CRLF or header injection, parser inconsistencies that change how a message is delivered or interpreted |
+| **R**epudiation            | Remote input that erases or forges the Received: trail, or otherwise defeats logging under default configuration       |
+| **I**nformation disclosure | Leakage of message content, credentials, or internal state through SMTP responses, DSNs, error messages, or logs       |
+| **D**enial of service      | Deterministic resource exhaustion or crashes triggered by remote input without operator misconfiguration               |
+| **E**levation of privilege | Remote code execution, or escape of documented SMTP/plugin semantics into arbitrary behavior inside the Haraka process |
+
+Plugins execute inside the trust boundary by design, so a malicious or
+vulnerable plugin can produce any STRIDE category above. Findings that
+require installing such a plugin are not vulnerabilities in Haraka itself.
+
+[stride]: https://en.wikipedia.org/wiki/STRIDE_model
+
+## Scope
+
+Issues that require control of a trusted element are out of scope, including:
+
+- Vulnerabilities requiring control of the host OS, filesystem, Node.js
+  runtime, local administrator account, or other trusted infrastructure
+- Malicious or compromised plugins or dependencies intentionally installed or
+  enabled by the operator
+- Pure misconfiguration of listeners, relay policy, TLS, proxying, or
+  outbound destinations unless Haraka's documented defaults create the
+  insecure state
+
+Issues in third-party plugins maintained outside this repository should be reported to their respective maintainers.

package/TODO

@@ -0,0 +1,22 @@
+- Milter support
+- Ability to modify the body of email
+    - Done for banners. Modifying the rest, not so much.
+
+Outbound improvements
+ - Provide better command line tools for manipulating/inspecting the queue
+ - Add the ability to force a run on a specific queue file or destination domain
+ - Make retry times configurable (handle RFC requirements for 5 days and DSN queued warnings)
+ - Disable deliveries for a domain
+
+Plugin behavior changes
+ - in SpamAssassin plugin, change default behavior of 'legacy' status header.
+   Presently, when undefined, legacy is used. Legacy support should be changed to
+   only when requested, with a sunset date.
+ - data.uribl; expand short URLs before lookups, add support for uri-a (sbl.spamhaus.org), uri-ns, uri-ns-a lookup types.
+
+Built-in HTTP server
+- use the same TLS/SSL certs as smtpd
+- auth against SMTP-AUTH provider
+
+Update tests to detect HARAKA_NETWORK_TESTS and skip network tests unless it's set
+  (to prevent annoying test suite failures that are tangential to Haraka)