Producto · Cadena de evidencia
Seis hechos por mensaje. Cada uno con su registro.
Esta página recorre la cadena completa: del byte-stream que sale por el cable al proof bundle que un tercero comprueba sin conectarse a mailack.
Sistema en construcción. Trabajamos con clientes en piloto.
Los seis hechos, por mensaje.
Cada hecho tiene un registro propio, capturado en el momento en que ocurre. Si no hay registro, no se afirma.
Contenido exacto
Qué decía el mensaje, byte por byte. El hash se calcula sobre el byte-stream canónico que salió por el cable.
hash · byte-stream canónico
Instante de emisión
Cuándo se emitió. Date queda fijado antes de hashear y la raíz del lote se sella ante el PSC con sealed_at.
Date fijado · sealed_at
Aceptación en la entrega
El mensaje fue aceptado para entrega. Queda la respuesta SMTP literal de esa conversación, con el queue id asignado.
250 2.0.0 · queue id
Entrega o rechazo
El desenlace. El DSN RFC 3464 llega por el return-path y se archiva crudo, antes de parsearlo.
RFC 3464 · return-path VERP
Integridad en el tiempo
La evidencia no cambió desde el sellado. Conservación WORM y prueba de inclusión contra la raíz sellada.
WORM · prueba de inclusión
Verificabilidad por terceros
Cualquier tercero comprueba el hash canónico y la prueba de inclusión por su cuenta, offline, con el CLI. La constancia la respalda el PSC que la emitió.
mailack-verify · sin red
Dos capturas por entrega, en dos momentos distintos.
La aceptación y el desenlace son hechos separados. Se registran por separado y ninguno sustituye al otro.
En el momento: la respuesta SMTP literal
mailack-dispatcher conserva la línea exacta con la que se aceptó el mensaje en la entrega, incluido el queue id asignado. No un código traducido: la línea tal cual.
>>> MAIL FROM:<bounce+9f2c1e7a-…@mailack.com>
<<< 250 2.1.0 Ok
>>> RCPT TO:<user@domain.com>
<<< 250 2.1.5 Ok
>>> DATA
<<< 354 End data with <CR><LF>.<CR><LF>
>>> .
<<< 250 2.0.0 Ok: queued as 4bK9Qz3Yx1zDespués: el mensaje RFC 3464 crudo
El desenlace llega después, por el return-path VERP. mailack-collector archiva el .eml íntegro antes de parsearlo y lo correlaciona con su mensaje de origen.
Reporting-MTA: dns; mail-out-01.mailack.comArrival-Date: Wed, 29 Jul 2026 11:04:14 -0600Final-Recipient: rfc822; user@domain.comAction: deliveredStatus: 2.0.0Remote-MTA: dns; mx.domain.comDiagnostic-Code: smtp; 250 OK queue id 4bK9Qz3Yx1zEvidencia cruda tal como se archiva, antes de parsear. El .eml original se conserva en almacenamiento WORM; lo que ves es su contenido literal.
Se hashea lo que salió por el cable. Nada más.
Antes de hashear se fijan Message-ID y Date. Desde ese punto el byte-stream es definitivo: el MIME nunca se re-serializa.
Si un byte cambia, el hash cambia. Por eso primero se fija el mensaje y después se hashea, sobre el byte-stream exacto que sale por el cable.
Un árbol por ventana. Una constancia por raíz.
Los hashes entran a un árbol Merkle RFC 6962 en ventanas de una hora o diez mil hojas. mailack-sealer sella la raíz ante el PSC; cada mensaje conserva su prueba de inclusión.
Sellar la raíz cubre todas las hojas de la ventana: la prueba de inclusión conecta cada mensaje con la raíz sellada. Para litigio, también se emite constancia individual del mensaje bajo demanda.
Se conserva en WORM. Se verifica sin red.
La evidencia queda en Object Storage con retención y bucket lock. El proof bundle se verifica con el CLI, sin consultar a mailack.
Qué trae el proof bundle
- Hash canónico del mensaje
- Ruta de inclusión hasta la raíz
- Raíz del lote
- Constancia NOM-151 del PSC
Conservación WORM
GET /v1/messages/{id}/proof-bundle
./bin/mailack-verify bundle.json -eml mensaje.emlEl CLI recalcula el hash del .eml y reconstruye la ruta de inclusión hasta la raíz sellada, sin red y sin depender de mailack. La constancia se coteja contra el PSC que la emitió.
Residencia de datos y valor probatorio no son lo mismo.
Las dos importan. Cada una responde a una pregunta distinta, y no se intercambian.
La IP mexicana acredita desde dónde
El correo sale de OCI mx-monterrey-1 con IP de egreso fija y HELO propio. Eso acredita desde dónde se emite y dónde reside la evidencia. Es un argumento contractual y regulatorio. No es prueba del mensaje.
La constancia NOM-151 acredita qué y cuándo
El valor probatorio proviene exclusivamente de la constancia de conservación NOM-151 emitida por el PSC sobre la raíz del árbol. Es lo que un tercero coteja en la verificación.
Ve la cadena completa con un mensaje tuyo.
En la demo: el envío, las dos capturas y la verificación offline del proof bundle.