WARE SEND / TECHNICAL DUE DILIGENCE
REVISIÓN TÉCNICA EXTERNA

Paquete de due diligence técnico

Material de arquitectura, seguridad, confiabilidad, operación y riesgo para evaluación técnica. No contiene secretos privados ni sustituye una auditoría independiente.

Documento
WS-TDD-001
Release revisada
Engine 1.3.1 · API v1 · SMTP Submission 587/465 · Analysis v3.1
Clasificación
Uso externo · sin secretos operativos
Proveedor
DB Ware Company

Resumen ejecutivo

Motor self-hosted de entrega de correo saliente. API HTTP y SMTP autenticado convergen en la misma cola; no es buzón, MX entrante, POP3, IMAP ni webmail.

Ware SendAdmisión, persistencia, cola, scheduler, control adaptativo y observabilidad
Postfix / MTATransporte SMTP externo, cola, retry y defer tras la aceptación local
Cliente / infraestructuraVPS/cloud, DNS, IP, reputación, políticas de uso y operación

Evidencia de benchmark controlado — 100K

Transporte SMTP real en ambiente controlado; el receiver acepta y mide mensajes, pero no representa políticas de inbox públicas.

MEDIDO100.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
PROYECCIÓN ARITMÉTICA74,7M / 30d7,47× the continuous rate required for 10M/30d
Adaptive / pressure55,2 PSI I/O peak308 transitions · run queue peak 14
CALIDAD DEL ENSAYO: DIRTY: Postfix inició con 1.963 elementos queue/deferred; evidencia operacional, no certificación de capacidad máxima.
10M/30 días requieren 3,86 msg/s. Se midieron 28,83 msg/s (7,47×); proyección lineal: 74,7M/30 días en las mismas condiciones.
Perfil sin adjunto. No es SLA de inbox.
Evidence: WS-BENCH-20260826-100K-MD1000 · wsba_20260826T133652_366c357f

Metodología de análisis y dónde medir

Cada capa responde a una pregunta distinta: generador, Engine, MTA/receiver y entregabilidad externa.

Technology / evidenceMeasurement layerWhat it measuresUse in Due Diligence
Integration LabClient → Ware Send APIConcurrency, HTTP latency, TCP/TLS/TTFB, new vs reused/multiplexed connectionsIngress generator and integration efficiency
Engine AnalysisWare Send EngineDurable admission, LOAD/DRAIN phases, P50/P95/P99, scheduler, Adaptive, CPU/iowait/run queue/PSI, pending, Postfix submit latency, Queue-IDEngine bottlenecks and internal capacity
Benchmark AnalysisPostfix → controlled SMTP receiverMessages/recipients received, rates/percentiles, domain distribution, TCP sessions, end-to-end gapsControlled SMTP transport integrity and effective egress
Campaign Completion ReportWare Send → customer report addressCampaign accepted jobs/recipients, Postfix handoff, failures, retries, Queue-ID count, per-domain distribution, revisionCustomer-facing campaign completion at Ware Send/Postfix boundary
Postfix logs / DSNMTA → remote MXRemote SMTP replies, defer, bounce and DSN evidence when availableRemote delivery evidence beyond Ware Send completion
DNS / reputation / inbox testingPublic Internet / destination providerPTR, SPF, DKIM, DMARC, reputation/blocklists and provider-specific inbox placementDeliverability analysis outside Engine throughput
01

Alcance

Motor self-hosted de entrega de correo saliente. API HTTP y SMTP autenticado convergen en la misma cola; no es buzón, MX entrante, POP3, IMAP ni webmail.

02

Arquitectura

Message, Blob y Delivery se persisten antes de responder 202/250. Scheduler weighted-fair y consciente de dominio alimenta una ventana controlada de Postfix.

03

Seguridad

Token API y contraseña SMTP están separados; los secretos completos se entregan una vez y el servidor conserva hashes. SMTP exige TLS y el servicio no ejecuta como root.

04

Datos y privacidad

Contenido y metadata permanecen en la VPS del cliente; DB Ware no está en el camino crítico por mensaje.

05

Confiabilidad

202/250 representan commit duradero local. Recovery, fsync, atomic rename, quarantine y GC protegen el spool; queda una semántica at-least-once en la ventana Postfix↔commit local.

06

Scheduler & Adaptive Engine

Scheduler weighted-fair/domain-aware con clases de coste, fairness por campaña/tenant y límites por dominio. Adaptive Engine 1.3.x combina CPU, iowait, run queue, load, PSI Linux, crecimiento de colas/Postfix y latencia de commit con histéresis.

07

Observabilidad

Status/activity/analytics autenticados y Analysis Report v3.1 con fases, percentiles, Adaptive, PSI, Queue-ID y telemetría Engine→Postfix; la evidencia completa queda en la VPS y el HTML usa una timeline compacta.

08

Semántica de entrega

El Queue-ID de Postfix se captura para correlación cuando se usa la ruta SMTP local. Aceptación por MTA no equivale a inbox.

09

Operación y continuidad

Binarios amd64/arm64, SHA-256, licencia firmada offline, rollback y validación post-instalación.

10

Capacidad y benchmark

El 26/08/2026 una prueba Multi-Domain controlada entregó 100.000/100.000 mensajes a un servidor SMTP destinatario controlado, en 1.000 dominios y sin gaps, a 28,83 msg/s efectivos. 10 millones/30 días requieren 3,86 msg/s; la proyección lineal es 74,7M/30 días en las mismas condiciones. No es SLA ni garantía de inbox.

Responsabilidades

ComponenteResponsabilidad
Ware SendAdmisión, persistencia, cola, scheduler, control adaptativo y observabilidad
Postfix / MTATransporte SMTP externo, cola, retry y defer tras la aceptación local
Cliente / infraestructuraVPS/cloud, DNS, IP, reputación, políticas de uso y operación

Riesgos y límites conocidos

IDRegistro
R-01No existe garantía exactly-once entre sistemas independientes.
R-02202/250 no demuestra entrega en inbox.
R-03No se publica throughput máximo sin benchmark.
R-04VPS, DNS, IP y reputación son responsabilidades operativas compartidas.
Postura de compliance

No se declaran certificaciones SOC 2, ISO 27001 u otras sin auditoría independiente.

Registro de evidencias

IDEvidencias
E-01Arquitectura interna
E-02Tests Go/race/vet
E-03SHA-256 y manifests
E-04Developer Documentation
E-05Hardening del servicio
E-06Analytics local
E-07Procedimientos de rollback

Las evidencias pueden presentarse durante la revisión técnica según el alcance y la autorización aplicables.