Executive summary
Self-hosted outbound email delivery engine. HTTP API and authenticated SMTP Submission converge into the same queue. Ware Send is not an inbound MX, mailbox, POP3, IMAP or webmail product.
Controlled benchmark evidence — 100K
Real SMTP transport in a controlled environment. The receiver is a destination SMTP server that accepts and measures messages; it does not represent public-provider inbox policies.
Ten million messages in 30 days require 3.86 msg/s continuously. The measured effective rate was 28.83 msg/s (7.47×); linear projection under the same conditions: 74.7M/30 days.
No attachment in this profile. Projections do not replace message-size-specific benchmarking and are not an inbox SLA.
Evidence: WS-BENCH-20260826-100K-MD1000 · wsba_20260826T133652_366c357f
Analysis methodology and where to measure
Each layer answers a different question. Due Diligence separates generator, Engine, MTA/receiver and external deliverability evidence.
| Technology / evidence | Measurement layer | What it measures | Use in Due Diligence |
|---|---|---|---|
| Integration Lab | Client → Ware Send API | Concurrency, HTTP latency, TCP/TLS/TTFB, new vs reused/multiplexed connections | Ingress generator and integration efficiency |
| Engine Analysis | Ware Send Engine | Durable admission, LOAD/DRAIN phases, P50/P95/P99, scheduler, Adaptive, CPU/iowait/run queue/PSI, pending, Postfix submit latency, Queue-ID | Engine bottlenecks and internal capacity |
| Benchmark Analysis | Postfix → controlled SMTP receiver | Messages/recipients received, rates/percentiles, domain distribution, TCP sessions, end-to-end gaps | Controlled SMTP transport integrity and effective egress |
| Campaign Completion Report | Ware Send → customer report address | Campaign accepted jobs/recipients, Postfix handoff, failures, retries, Queue-ID count, per-domain distribution, revision | Customer-facing campaign completion at Ware Send/Postfix boundary |
| Postfix logs / DSN | MTA → remote MX | Remote SMTP replies, defer, bounce and DSN evidence when available | Remote delivery evidence beyond Ware Send completion |
| DNS / reputation / inbox testing | Public Internet / destination provider | PTR, SPF, DKIM, DMARC, reputation/blocklists and provider-specific inbox placement | Deliverability analysis outside Engine throughput |
Product scope
Self-hosted outbound email delivery engine. HTTP API and authenticated SMTP Submission converge into the same queue. Ware Send is not an inbound MX, mailbox, POP3, IMAP or webmail product.
Architecture
Admission persists Message, Blob and Delivery before returning 202/250. A weighted-fair, domain-aware scheduler feeds a controlled Postfix active window. Postfix remains responsible for external SMTP, SMTP queueing and retry/defer after it accepts the message.
Security
API Bearer tokens and the SMTP password are separate credential domains. Full secrets are delivered once and only hashes remain on the server. SMTP requires TLS. The service runs without root and receives only the minimum capabilities required.
Data & privacy
Queue content and metadata remain on the customer-controlled VPS. DB Ware backend services are not in the critical path for each message. Blobs are shared per message to avoid per-recipient copies and are removed according to lifecycle and retention.
Reliability
HTTP 202 and SMTP 250 mean Ware Send accepted responsibility after a local durable commit. Recovery, atomic rename, fsync, quarantine and object GC protect the spool. Semantics remain at-least-once in the extreme window between Postfix acceptance and the local terminal-state commit.
Scheduler & Adaptive Engine
Weighted-fair/domain-aware scheduling uses cost classes, campaign/tenant fairness and per-domain limits. Adaptive Engine 1.3.x uses composite pressure: CPU, iowait, run queue, load, Linux PSI CPU/I/O/memory, backlog/Postfix growth and commit latency, with hysteresis.
Observability
Authenticated status, activity and analytics plus Analysis Report v3.1 with phase-aware percentiles, scheduler/Adaptive, PSI, Queue-ID and Engine→Postfix telemetry. Full-resolution evidence remains on the VPS while e-mail HTML embeds a bounded scalar timeline.
Delivery semantics
Ware Send distinguishes local acceptance from external delivery. When local SMTP submission to Postfix is enabled, the Postfix Queue-ID is captured for correlation. Remote-MTA acceptance does not equal inbox placement or human read confirmation.
Operations & continuity
Private installation flow, amd64/arm64 binaries, SHA-256 manifests, offline signed licensing, rollback and post-install validation. The server release directory may retain only the currently published release; continuity packages preserve source, documentation and build evidence.
Capacity & benchmark
On Aug 26, 2026 a controlled Multi-Domain run delivered 100,000/100,000 messages to a controlled SMTP destination server across 1,000 domains with zero gaps at an effective 28.83 msg/s. Ten million messages in 30 days require 3.86 msg/s; a linear projection of the measured rate is 74.7M/30 days under the same conditions. This is performance evidence, not an SLA or inbox guarantee.
Responsibilities
| Component | Responsibility |
|---|---|
| Ware Send | Admission, persistence, queue, scheduler, adaptive control and observability |
| Postfix / MTA | External SMTP transport, queueing, retry and defer after local acceptance |
| Customer / infrastructure | VPS/cloud, DNS, IP, reputation, use policies and operations |
Known risks and boundaries
| ID | Record |
|---|---|
| R-01 | There is no exactly-once guarantee across independent systems; the residual Postfix↔spool window is observable but not transactional. |
| R-02 | Inbox delivery cannot be inferred from HTTP 202, SMTP 250 or a local Queue-ID; remote/DSN evidence is required when available. |
| R-03 | The 100K benchmark started with 1,963 Postfix queue/deferred items and was classified DIRTY; it is controlled evidence, not a maximum-capacity certification. |
| R-04 | VPS, DNS, IP reputation and destination-MX policies remain operational variables outside Engine capacity. |
This material describes implemented technical controls. It does not claim SOC 2, ISO 27001, PCI DSS or any other certification unless separately obtained through an independent process.
Evidence register
| ID | Available evidence |
|---|---|
| E-01 | 100K Multi-Domain controlled SMTP benchmark — 100,000/100,000, 1,000 domains, zero gaps |
| E-02 | Analysis Report v3/v3.1 — percentiles, phases, Adaptive, PSI and correlation |
| E-03 | Analysis export v3.1 — 129.2 MB → 1.53 MB (-98.8%) while raw evidence remains on the VPS |
| E-04 | Engine→Postfix — 100,000 transactions, 8 opened connections, 99.992% reuse, zero failures |
| E-05 | Go tests + race detector + vet and amd64/arm64 builds |
| E-06 | Release v4.5.1 manifests and SHA-256 |
| E-07 | Campaign Completion Report and Developer API 1.3.x |
| E-08 | Service hardening, install, update and rollback procedures |
Evidence can be presented during technical review according to applicable scope and authorization.