Método de evidencia

Diseñamos cada paso para que, si dentro de años alguien afirma que un mensaje no llegó o que un anexo era otro, un perito o un juez pueda comprobar lo ocurrido sin tener que confiar en Notificado. Cuando dos opciones técnicas son posibles, elegimos la que hace más fácil la verificación independiente.

Antes de enviar construimos el mensaje exacto que saldrá (archivo .eml, con encabezados, texto y adjuntos), lo guardamos sin modificaciones y lo sellamos en el tiempo. Ese archivo es el que entregamos al proveedor de correo. El destinatario recibe el mismo texto y los mismos adjuntos, con el mismo Message-ID; la huella SHA-256 de cada adjunto está en la constancia. En el tránsito, el proveedor puede recodificar el mensaje y poner sus propios encabezados, entre ellos la fecha.

Calculamos la huella SHA-256 del mensaje completo y de cada documento adjunto. Cualquier cambio en un archivo, por mínimo que sea, produce una huella distinta. Las huellas aparecen en la constancia de entrega.

Un archivo que no cabe como adjunto puede entregarse por enlace de descarga. El mensaje congelado lo lista con su nombre, su tamaño en bytes y su huella SHA-256, y no lo lleva adjunto. Al congelar el mensaje, el archivo se copia al almacenamiento inmutable y la copia se comprueba contra esa huella. La cadena registra cuándo se usó el enlace del destinatario y cuándo nuestro servidor transmitió el archivo completo, con la huella de los bytes transmitidos: eso prueba la transmisión, no que el destinatario lo haya abierto. El archivo se conserva 10 años desde el envío y después se elimina, con un evento en la cadena. Su huella permanece en la constancia y en el paquete de evidencia, que lo referencia por su huella sin incluirlo: quien conserve una copia puede compararla, también sin conexión.

Las huellas se sellan con el protocolo estándar RFC 3161 ante al menos dos autoridades de sellado de tiempo independientes entre sí, FreeTSA y DigiCert. Conservamos cada token de sello (.tsr) tal como lo emitió la autoridad. Un sello prueba que el contenido existía, idéntico, en ese momento; dos sellos independientes evitan depender de un solo proveedor.

El mensaje sale firmado con DKIM desde nuestro dominio. Los documentos van adjuntos y, además, cada destinatario recibe un enlace personal de descarga. El adjunto prueba qué contenido llegó; el enlace prueba el acceso.

Una notificación puede programarse para que salga en la próxima apertura de un día hábil, en lugar de enviarse de inmediato.

Mientras está programada, el mensaje no se congela, no se sella en el tiempo, no se descuentan créditos y nada se entrega al transporte de correo. Todo eso ocurre cuando el envío se libera, igual que en un envío inmediato, y el envío a cada destinatario es el que registra el evento de transporte.

Tres eventos de la cadena dejan el registro: la programación (quién la confirmó, cuándo y para cuándo), su cancelación, si la hubo, y la liberación para el envío.

La constancia muestra un bloque «Programación del envío» solo cuando el envío fue programado. El bloque indica quién confirmó la programación, cuándo y para cuándo, el horario de referencia de los despachos con su versión, y cómo terminó. Un envío que nunca fue programado no añade nada a la constancia, cualquiera que sea la hora en que salió.

El horario de referencia sirve para leer las fechas con un criterio más cauteloso; no es una regla legal. La constancia no imprime ninguna fecha de efecto legal: registra hechos, y su valoración corresponde al juez.

• Aceptación del servidor de correo del destinatario: respuesta SMTP, dirección IP del servidor remoto y hora.
• Rebotes y fallas de entrega, con la respuesta recibida.
• Visitas a la página de la notificación desde el enlace personal: la primera de cada día (hora de Colombia), con hora, dirección IP y navegador. Un escáner de seguridad del correo también puede abrir ese enlace, así que es un indicio.
• Descargas de documentos por el enlace personal: hora, dirección IP y navegador.
• Acuse de recibo del destinatario, cuando lo da.
• Aperturas del mensaje.

Conservamos la respuesta cruda de cada proveedor, no solo los campos interpretados, para que el evento pueda reconstruirse.

Algunos servicios de correo descargan las imágenes de un mensaje de forma automática, sin que una persona lo abra. Por eso una apertura se registra y se muestra siempre como indicio, nunca como prueba de lectura.

Los eventos nunca se modifican ni se borran: solo se agregan. Cada evento guarda la huella del anterior y su propia huella se calcula sobre esa huella y su contenido. Alterar, quitar o reordenar un evento rompe la cadena desde ese punto, y la verificación indica el primer evento afectado.

Cada noche calculamos una huella única (raíz de Merkle) de todos los eventos del día y la sellamos en el tiempo con todas las autoridades. Así, ni siquiera nosotros podríamos reescribir un día completo sin que se note.

Los mensajes congelados, los documentos, los sellos de tiempo, las constancias y las respuestas crudas de los proveedores se guardan en almacenamiento de escritura única (WORM) en modo de cumplimiento durante al menos 10 años desde que se escriben. Durante ese plazo nadie puede borrarlos ni sobrescribirlos, tampoco un administrador de Notificado. Como un proceso puede durar más, conserve también el paquete de evidencia (.zip), que se verifica sin conexión.

Guardamos todas las horas en UTC y las mostramos en hora legal de Colombia (America/Bogota), con la hora UTC al lado.

Cada 5 minutos comparamos el reloj de nuestros servidores con la hora legal de Colombia que difunde el Instituto Nacional de Metrología y registramos la diferencia. Cada medición queda como un evento en la cadena, con el servidor consultado, la diferencia y el tiempo de ida y vuelta; si la diferencia pasa de 100 milisegundos, queda además marcada. Cada evento cita, dentro de su huella, la medición más reciente registrada, y el paquete de evidencia trae las mediciones de la cadena que citan sus eventos, para que verificar.js compruebe sin conexión su huella y su lugar en la cadena.

La medición es nuestra propia consulta al servidor del Instituto y ningún tercero la firma. Nuestro reloj no es la prueba de la hora. El momento del mensaje lo prueban los sellos de tiempo RFC 3161, que emiten autoridades independientes antes del envío, y los eventos posteriores quedan cubiertos por el ancla diaria, que también se sella en el tiempo.

La constancia de entrega es un PDF con los datos del envío, las huellas, los eventos y los sellos de tiempo, con firma electrónica (PAdES) hecha con una llave propia de VENOMTECH S.A.S. y con un código QR que lleva a la página pública de verificación. El paquete de evidencia (.zip) reúne el mensaje original, los documentos, los registros de eventos en formato crudo y legible, los tokens de sello de tiempo, la constancia y las instrucciones de verificación sin conexión.

Cada constancia lleva una firma PAdES hecha con la llave de VENOMTECH S.A.S. (NIT 901.991.367-7). Su X.509 es propio (autoemitido), y por eso un lector de PDF puede mostrar la identidad del firmante como desconocida o no confiable; eso no indica que el documento cambió. La firma prueba que el PDF no cambió desde que Notificado lo firmó. Para comprobar que la firma es la nuestra, compare la huella SHA-256 del firmante (la muestra `openssl x509 -fingerprint -sha256` sobre firma/cert-chain.pem del paquete, o el panel de firmas del lector de PDF) con la publicada aquí; desde la versión 2026-10-v7 del método, la constancia también la imprime en su sección «Cómo comprobar esta constancia». Deben ser idénticas; una llave nueva se publicará aquí sin retirar las anteriores.

sha256 Fingerprint=30:53:AB:A4:2B:96:6E:5F:B6:FC:F4:55:2C:82:B4:94:4F:A5:C1:AF:C0:85:18:25:1E:D7:95:B3:4E:D0:14:56
self-2026 · active
subject=CN=Notificado — firma de constancias, serialNumber=901991367-7, organizationIdentifier=NTRCO-901991367-7, O=VENOMTECH S.A.S., C=CO
issuer=CN=Notificado — firma de constancias, serialNumber=901991367-7, organizationIdentifier=NTRCO-901991367-7, O=VENOMTECH S.A.S., C=CO
2026-09-24T21:30:16Z → 2036-09-24T21:30:16Z

Con el paquete de evidencia y herramientas estándar, sin acceder a Notificado:

• Ejecute el verificador incluido (verificar.js, con Bun): repite todas las comprobaciones y dice cuál falla.
• Compruebe las huellas SHA-256 de todos los archivos contra el archivo SHA256SUMS.
• Verifique cada sello de tiempo con OpenSSL contra la cadena de confianza (archivo .pem) de la autoridad que lo emitió.
• Revise la firma de la constancia y compare la huella del firmante con la publicada en esta página.
• Recalcule la cadena de eventos siguiendo las instrucciones del paquete; la primera huella que no coincida señala el evento alterado.

Los comandos de abajo muestran la forma. El LÉAME de cada paquete los imprime con los nombres reales de sus archivos.

bun verificar.js
sha256sum -c SHA256SUMS
openssl ts -verify -data mensaje/<id>.eml -in sellos/<sello>.tsr -CAfile sellos/tsa-ca/<autoridad>.pem
pdfsig constancia.pdf
openssl x509 -in firma/cert-chain.pem -noout -fingerprint -sha256

En la página de verificación, cualquier persona puede escribir el código de una constancia o cargar el PDF: su huella se calcula en su propio navegador, el archivo no se envía a nuestros servidores, y la página responde si la constancia es auténtica y está inalterada. Solo mostramos fecha, estado y huella; nunca el contenido del mensaje ni datos personales del destinatario.

Este método describe cómo producimos y conservamos la evidencia; su valor probatorio y la validez de la notificación los determina el juez del proceso. Cada versión de este documento se publica con su número de versión, y cada constancia indica la versión del método con la que se produjo: queda registrada en el evento de emisión de la constancia y en el LÉAME del paquete. Las versiones anteriores siguen publicadas, sin cambios.