WARE SEND / TECHNICAL DUE DILIGENCE
REVISÃO TÉCNICA EXTERNA

Technical Due Diligence

Referência técnica externa para revisão de arquitetura, segurança, operação, continuidade e riscos do Ware Send. O documento descreve controles implementados e limites conhecidos; não substitui auditoria independente.

Documento
WS-TDD-001
Release analisada
Engine 1.3.1 · API v1 · SMTP Submission 587/465 · Analysis v3.1
Classificação
Uso externo · sem segredos operacionais
Fornecedor
DB Ware Company

Resumo executivo

Motor de entrega de e-mail outbound self-hosted. API HTTP e SMTP Submission autenticado convergem para a mesma fila. O Ware Send não é mailbox, MX inbound, POP3, IMAP ou webmail.

Ware SendAdmissão, persistência, fila, scheduler, adaptive e observabilidade
Postfix / MTATransporte SMTP externo, queueing, retry e defer após aceite local
Cliente / infraestruturaVPS/cloud, DNS, IP, reputação, políticas de uso e operação

Evidência de benchmark controlado — 100K

Transporte SMTP real em ambiente controlado. O receiver é um servidor SMTP destinatário que aceita e mede mensagens; ele não representa as políticas de inbox de provedores públicos.

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
PROJEÇÃO ARITMÉTICA74,7M / 30d7,47× the continuous rate required for 10M/30d
Adaptive / pressure55,2 PSI I/O peak308 transitions · run queue peak 14
QUALIDADE DO ENSAIO: DIRTY: o Postfix iniciou com 1.963 itens em queue/deferred. Os dados são válidos como evidência operacional, mas não são apresentados como certificação do teto máximo.
10 milhões em 30 dias exigem 3,86 msg/s contínuos. A taxa efetiva medida foi 28,83 msg/s (7,47×); projeção linear nas mesmas condições: 74,7 milhões/30 dias.
Sem anexo neste perfil. Projeções não substituem benchmark por tamanho de mensagem e não constituem SLA de inbox.
Evidence: WS-BENCH-20260826-100K-MD1000 · wsba_20260826T133652_366c357f

Metodologia de análise e onde medir

Cada camada responde a uma pergunta diferente. A Due Diligence separa evidência do gerador, do Engine, do MTA/receiver e da entregabilidade 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

Escopo do produto

Motor de entrega de e-mail outbound self-hosted. API HTTP e SMTP Submission autenticado convergem para a mesma fila. O Ware Send não é mailbox, MX inbound, POP3, IMAP ou webmail.

02

Arquitetura

A admissão persiste Message, Blob e Delivery antes de confirmar 202/250. O scheduler weighted-fair e domain-aware alimenta uma janela controlada do Postfix. O Postfix continua responsável pelo protocolo SMTP externo, filas SMTP e retry/defer após assumir a mensagem.

03

Segurança

Bearer tokens da API e senha SMTP pertencem a domínios de credenciais separados. Segredos completos são entregues uma única vez e o servidor persiste hashes. SMTP exige TLS. O serviço roda sem root e recebe apenas capacidades mínimas necessárias.

04

Dados e privacidade

Conteúdo e metadata da fila permanecem na VPS controlada pelo cliente. O backend DB Ware não participa do caminho crítico de cada mensagem. Blobs são compartilhados por mensagem para evitar cópias por destinatário e são removidos conforme lifecycle/retention.

05

Confiabilidade

202 HTTP e 250 SMTP significam que o Ware Send assumiu responsabilidade após commit durável local. Recovery, atomic rename, fsync, quarantine e GC de objetos protegem o spool. A semântica continua at-least-once na janela extrema entre aceitação pelo Postfix e commit terminal local.

06

Scheduler & Adaptive Engine

Scheduler weighted-fair/domain-aware com classes de custo, fairness por campanha/tenant e limite por domínio. O Adaptive Engine 1.3.x usa pressão composta: CPU, iowait, run queue, load, Linux PSI CPU/I/O/memória, crescimento de backlog/Postfix e latência de commit, com histerese.

07

Observabilidade

Status, activity e analytics autenticados; Analysis Report v3.1 separa fases, percentis, scheduler/Adaptive, PSI, Queue-ID e Engine→Postfix. Evidência bruta de alta resolução permanece na VPS; o HTML usa timeline escalar limitada para continuar auditável e enviável por e-mail.

08

Semântica de entrega

O Ware Send diferencia aceitação local de entrega externa. Quando a submissão local SMTP ao Postfix está habilitada, o Queue-ID do Postfix é capturado para correlação. Aceitação pelo MTA remoto não equivale a leitura/inbox e não deve ser apresentada como garantia de recebimento humano.

09

Operação e continuidade

Instalação privada, binários amd64/arm64, manifests SHA-256, licença assinada offline, rollback e validação pós-instalação. O diretório de releases pode manter somente a release publicada atual; os pacotes de continuidade preservam fonte, documentação e evidências de build.

10

Capacidade e benchmark

Em 26/08/2026 um ensaio controlado Multi-Domain entregou 100.000/100.000 mensagens a um servidor SMTP destinatário controlado, com 1.000 domínios, zero gap e taxa efetiva de 28,83 msg/s. Dez milhões em 30 dias exigem 3,86 msg/s contínuos; a projeção linear do ritmo medido é 74,7 milhões/30 dias nas mesmas condições. É evidência de desempenho, não SLA nem garantia de inbox.

Responsabilidades

ComponenteResponsabilidade
Ware SendAdmissão, persistência, fila, scheduler, adaptive e observabilidade
Postfix / MTATransporte SMTP externo, queueing, retry e defer após aceite local
Cliente / infraestruturaVPS/cloud, DNS, IP, reputação, políticas de uso e operação

Riscos e limites conhecidos

IDRegistro
R-01Não há garantia exactly-once entre sistemas independentes; a janela residual Postfix↔spool é observável, mas não transacional.
R-02Entrega no inbox não pode ser inferida de 202/250 ou Queue-ID local; requer evidência remota/DSN quando disponível.
R-03O benchmark de 100K começou com 1.963 itens em queue/deferred do Postfix e foi classificado DIRTY; é evidência controlada, não certificação do teto máximo.
R-04VPS, DNS, IP, reputação e políticas dos MX permanecem responsabilidades e variáveis externas à capacidade do Engine.
Compliance posture

Este material descreve controles técnicos implementados. Ele não declara certificação SOC 2, ISO 27001, PCI DSS ou outra certificação que não tenha sido obtida por processo independente.

Registro de evidências

IDEvidências disponíveis
E-01100K Multi-Domain controlled SMTP benchmark — 100.000/100.000, 1.000 domínios, zero gaps
E-02Analysis Report v3/v3.1 — percentis, fases, Adaptive, PSI e correlação
E-03Analysis export v3.1 — 129,2 MB → 1,53 MB (-98,8%) preservando evidência bruta na VPS
E-04Engine→Postfix — 100.000 transações, 8 conexões abertas, 99,992% reuse, zero falhas
E-05Go tests + race detector + vet e builds amd64/arm64
E-06Manifests e SHA-256 da release v4.5.1
E-07Campaign Completion Report e Developer API 1.3.x
E-08Configuração de hardening, instalação, atualização e rollback

Evidências podem ser apresentadas durante avaliação técnica conforme o escopo e a autorização aplicáveis.