Evidence method

We design every step so that if, years from now, someone claims a message never arrived or an annex was different, an expert or a judge can establish what happened without having to trust Notificado. When two technical options are possible, we choose the one that makes independent verification easier.

Before sending, we build the exact message that will go out (an .eml file with headers, text and attachments), store it unmodified and timestamp it. That file is what we hand to the mail provider. The recipient gets the same text and the same attachments under the same Message-ID; each attachment's SHA-256 is on the constancia. In transit, the provider may re-encode the message and set its own headers, the date among them.

We compute the SHA-256 fingerprint of the whole message and of each attached document. Any change to a file, however small, produces a different fingerprint. The fingerprints appear on the proof of delivery.

A file that does not fit as an attachment can be delivered by download link. The frozen message lists it with its name, its size in bytes and its SHA-256 fingerprint, and does not carry it attached. When the message is frozen, the file is copied to immutable storage and the copy is checked against that fingerprint. The chain records when the recipient's link was used and when our server transmitted the whole file, with the fingerprint of the bytes transmitted: that proves the transmission, not that the recipient opened it. The file is kept for 10 years from the send and then deleted, with an event on the chain. Its fingerprint remains on the constancia and in the evidence package, which references it by its fingerprint without including it: anyone who kept a copy can compare it, offline too.

The fingerprints are timestamped using the standard RFC 3161 protocol by at least two mutually independent timestamp authorities, FreeTSA and DigiCert. We keep each timestamp token (.tsr) exactly as the authority issued it. A timestamp proves the content existed, identical, at that moment; two independent timestamps avoid depending on a single provider.

The message leaves DKIM-signed from our domain. The documents are attached and, in addition, each recipient gets a personal download link. The attachment proves which content arrived; the link proves access.

A notification can be scheduled to leave at the next opening of a business day instead of being sent at once.

While it is scheduled, the message is not frozen, not time-stamped, no credits are charged and nothing is handed to the mail transport. All of that happens when the send is released, exactly as in an immediate send, and the send to each recipient is the one the transport event records.

Three events on the chain keep the record: the scheduling (who confirmed it, when and for when), its cancellation, if there was one, and the release for sending.

The constancia shows a "Programación del envío" block only when the send was scheduled. The block states who confirmed the schedule, when and for when, the reference court hours with their version, and how it ended. A send that was never scheduled adds nothing to the constancia, at whatever hour it left.

The reference hours are a reference for reading dates more cautiously; they are not a legal rule. The constancia prints no date of legal effect: it records facts, and weighing them is for the judge.

• Acceptance by the recipient's mail server: SMTP response, remote server IP address and time.
• Bounces and delivery failures, with the response received.
• Visits to the notification page from the personal link: the first of each day (Colombia time), with time, IP address and browser. An email security scanner can also open that link, so it is an indication.
• Document downloads through the personal link: time, IP address and browser.
• The recipient's acknowledgement of receipt, when given.
• Message opens.

We keep each provider's raw response, not only the parsed fields, so the event can be reconstructed.

Some mail services download a message's images automatically, without a person opening it. That is why an open is always recorded and shown as an indicio, never as proof of reading.

Events are never modified or deleted: they are only appended. Each event stores the previous event's fingerprint, and its own fingerprint is computed over that fingerprint and its content. Altering, removing or reordering an event breaks the chain from that point, and verification names the first affected event.

Every night we compute a single fingerprint (Merkle root) of all the day's events and timestamp it with every authority. So not even we could rewrite a whole day unnoticed.

Frozen messages, documents, timestamps, proofs of delivery and raw provider responses are kept in write-once (WORM) storage in compliance mode for at least 10 years from when they are written. During that period nobody can delete or overwrite them, not even a Notificado administrator. As a proceeding can last longer, also keep the evidence package (.zip), which verifies offline.

We store every time in UTC and display it in Colombian legal time (America/Bogota), with UTC beside it.

Every 5 minutes we compare our servers' clock with Colombian legal time as broadcast by the Instituto Nacional de Metrología and record the difference. Every measurement is recorded as an event in the chain, with the server asked, the difference and the round trip; one over 100 milliseconds is also flagged. Each event cites, inside its hash, the most recent measurement recorded, and the evidence package carries the chained measurements its events cite, so that verificar.js checks their hash and their place in the chain offline.

The measurement is our own query to the Instituto's server and no third party signs it. Our clock is not the proof of time. The moment of the message is proven by the RFC 3161 timestamps that independent authorities issue before sending, and later events are covered by the daily anchor, which is timestamped too.

The proof of delivery (constancia de entrega) is a PDF with the send details, fingerprints, events and timestamps, with an electronic signature (PAdES) made with VENOMTECH S.A.S.'s own key and a QR code leading to the public verification page. The evidence package (.zip) holds the original message, the documents, the event logs in raw and readable form, the timestamp tokens, the constancia and offline verification instructions.

Every constancia carries a PAdES signature made with the key of VENOMTECH S.A.S. (NIT 901.991.367-7). Its X.509 is our own (self-issued), which is why a PDF reader may show the signer's identity as unknown or untrusted; that does not mean the document changed. The signature proves the PDF has not changed since Notificado signed it. To check the signature is ours, compare the signer's SHA-256 fingerprint (`openssl x509 -fingerprint -sha256` on the bundle's firma/cert-chain.pem prints it, as does the PDF reader's signature panel) with the one published here; since method version 2026-10-v7 the constancia also prints it, in its section "Cómo comprobar esta constancia". They must be identical; a new key will be published here without withdrawing the earlier ones.

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

With the evidence package and standard tools, without accessing Notificado:

• Run the bundled verifier (verificar.js, with Bun): it repeats every check and says which one fails.
• Check the SHA-256 fingerprints of every file against the SHA256SUMS file.
• Verify each timestamp with OpenSSL against the trust chain (.pem file) of the authority that issued it.
• Check the constancia's signature and compare the signer's fingerprint with the one published on this page.
• Recompute the event chain following the package's instructions; the first fingerprint that does not match points to the altered event.

The commands below show the form. Each package's README prints them with the real names of its files.

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

On the verification page anyone can enter a constancia's code or load the PDF: its fingerprint is computed in their own browser, the file is not sent to our servers, and the page answers whether the constancia is authentic and unaltered. We only show date, status and fingerprint; never the message content or the recipient's personal data.

This method describes how we produce and keep the evidence; its probative value and the validity of the notification are for the judge of the case to decide. Each version of this document is published with its version number, and each constancia states the method version it was produced under: it is recorded in the constancia's issuance event and in the package's README. Earlier versions stay published, unchanged.