Ware Send — Technical Due Diligence

Résumé exécutif

Moteur self-hosted d’envoi e-mail sortant. API HTTP et SMTP authentifié convergent vers la même file; pas de mailbox, MX entrant, POP3, IMAP ni webmail.

Ware SendAdmission, persistance, file, scheduler, contrôle adaptatif et observabilité

→

Postfix / MTATransport SMTP externe, file, retry et defer après acceptation locale

→

Client / infrastructureVPS/cloud, DNS, IP, réputation, politiques d’usage et exploitation

Preuve benchmark contrôlée — 100K

Transport SMTP réel en environnement contrôlé; le receiver accepte et mesure les messages mais ne représente pas les politiques inbox publiques.

MESURÉ100.000/100.000accepted → Postfix → receiver · gap 0

Effective receiver28,83 msg/sP95 68,09 · peak 75,95

Multi-Domain1.000 domains100 recipients/domain · CV 0

Engine → Postfix99,992% reuse8 opens / 100.000 transactions

Host CPU23,2% avgpeak 53,8%

I/O pressure8,2% iowait avgPSI I/O some peak 55,2

PROJECTION ARITHMÉTIQUE74,7M / 30d7,47× the continuous rate required for 10M/30d

Adaptive / pressure55,2 PSI I/O peak308 transitions · run queue peak 14

QUALITÉ DU TEST: DIRTY : Postfix a démarré avec 1 963 éléments queue/deferred; preuve opérationnelle, pas certification du maximum.
10M/30 jours exigent 3,86 msg/s. Mesure: 28,83 msg/s (7,47×); projection linéaire: 74,7M/30 jours dans les mêmes conditions.
Profil sans pièce jointe. Ce n’est pas un SLA inbox.
Evidence: WS-BENCH-20260826-100K-MD1000 · wsba_20260826T133652_366c357f

Méthodologie d’analyse et point de mesure

Chaque couche répond à une question différente : générateur, Engine, MTA/receiver et délivrabilité externe.

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

Périmètre

Moteur self-hosted d’envoi e-mail sortant. API HTTP et SMTP authentifié convergent vers la même file; pas de mailbox, MX entrant, POP3, IMAP ni webmail.

Architecture

Message, Blob et Delivery sont persistés avant 202/250. Un scheduler weighted-fair et domain-aware alimente une fenêtre Postfix contrôlée.

Sécurité

Token API et mot de passe SMTP sont séparés; secrets complets remis une fois, hashes seuls persistés. TLS SMTP obligatoire, service non-root.

Données et confidentialité

Contenu et metadata restent sur la VPS du client; le backend DB Ware n’est pas dans le chemin critique par message.

Fiabilité

202/250 suivent un commit local durable. Recovery, fsync, atomic rename, quarantine et GC protègent le spool; une fenêtre at-least-once Postfix↔commit local subsiste.

Scheduler & Adaptive Engine

Scheduler weighted-fair/domain-aware avec classes de coût, fairness campagne/tenant et limites par domaine. Adaptive Engine 1.3.x combine CPU, iowait, run queue, load, PSI Linux, croissance des files/Postfix et latence de commit avec hystérésis.

Observabilité

Status/activity/analytics authentifiés et Analysis Report v3.1 avec phases, percentiles, Adaptive, PSI, Queue-ID et télémétrie Engine→Postfix; les données complètes restent sur la VPS et le HTML utilise une timeline compacte.

Sémantique de livraison

Le Queue-ID Postfix est capturé pour corrélation via la soumission SMTP locale. L’acceptation MTA ne garantit pas l’inbox.

Opérations et continuité

Binaires amd64/arm64, SHA-256, licence offline signée, rollback et validation post-installation.

Capacité et benchmark

Le 26/08/2026, un test Multi-Domain contrôlé a livré 100 000/100 000 messages à un serveur SMTP destinataire contrôlé sur 1 000 domaines, sans gap, à 28,83 msg/s effectifs. 10M/30 jours exigent 3,86 msg/s; projection linéaire: 74,7M/30 jours dans les mêmes conditions. Ce n’est ni un SLA ni une garantie inbox.

Responsabilités

Composant	Responsabilité
Ware Send	Admission, persistance, file, scheduler, contrôle adaptatif et observabilité
Postfix / MTA	Transport SMTP externe, file, retry et defer après acceptation locale
Client / infrastructure	VPS/cloud, DNS, IP, réputation, politiques d’usage et exploitation

Risques et limites connus

ID	Registre
R-01	Pas de garantie exactly-once entre systèmes indépendants.
R-02	202/250 ne prouve pas l’arrivée en inbox.
R-03	Aucun throughput maximum publié sans benchmark.
R-04	VPS, DNS, IP et réputation sont des responsabilités partagées.

Posture conformité

Aucune certification SOC 2, ISO 27001 ou autre n’est revendiquée sans audit indépendant.

Registre des preuves

ID	Éléments de preuve
E-01	Architecture interne
E-02	Tests Go/race/vet
E-03	SHA-256 et manifests
E-04	Developer Documentation
E-05	Hardening du service
E-06	Analytics local
E-07	Procédures de rollback

Les éléments de preuve peuvent être présentés lors de la revue technique selon le périmètre et les autorisations applicables.

Dossier de due diligence technique