Workspace mail delivery
The workspace gateway inspects incoming messages and records an Evidence Passport for completed investigations. Only messages allowed by sender authentication and the delivery policy are relayed. A Passport verifies the integrity of the recorded evidence; it does not prove that a message is harmless.
Failed sender authentication can reject delivery. When analysis is unavailable, the gateway returns a temporary SMTP deferral so the sending mail server can retry. Model availability follows the configured 7 a.m. to 7 p.m. IST window after its scheduled activation.
Mail-domain routing, TLS, recipient restrictions and actual delivery checks must pass before a workspace gateway is activated. The portable CLI below is a controlled integration test using real SMTP and analysis. Its bundled fixtures are test messages, separate from customer inbox traffic.
TRUSTED SMTP · ONE- OR TWO-LAPTOP DEMO
The sender submits a real .eml or bundled controlled YAML fixture over the private demo SMTP path. The receiver directly observes transport facts, sends the message for VeriTrustLab analysis, and applies the returned policy decision before downstream delivery.
[BOUNDARY] trusted SMTP receiver
[OBSERVED] client IP · HELO · envelope
[ANALYSIS] VeriTrustLab Stage-3 request
header claims remain separate from directly observed facts
[POLICY] allow / reject / defer
01 · Evidence boundary
Received: claims.02 · Prepare once
Windows PowerShell 5.1+. The CLI installs Tailscale if missing, restores the Tailscale Windows service if needed, and reuses a healthy authenticated device profile. Only when Tailscale reports NeedsLogin does the CLI request a fresh AuthURL, copy it to the clipboard, and open it in the normal/default browser. Incognito/InPrivate profiles are not used. For a two-laptop demo, both machines must join the same/shared tailnet; the same physical Wi-Fi is not required.
The receiver uses Node.js 24; if it is unavailable, the 2.5.4 CLI can obtain a portable Node.js 24 runtime. It also requires a dedicated VeriTrustLab API key scoped to gateway:scan and VERITRUST_EMAIL_RECEIVER_SECRET of at least 32 bytes. The bundled SMTP companion uses the raw trusted-receiver endpoint, which evaluates direct receiver facts and does not trust sender-carried Authentication-Results headers.
Use the complete ZIP above. It contains the sender, receiver, package-local launchers, validator, release notes, two controlled YAML fixtures (legitimate + phishing), and the version-matched mail-gateway runtime. The launchers always run from the folder that actually contains the extracted package, including duplicate-download folders with a suffix such as (1), so an older extraction cannot be mixed into the current runtime.
03 · Receiver laptop
# Open PowerShell in the folder you actually extracted
$env:VERITRUST_API_BASE_URL = "https://www.veritrustlab.in"
.\Run-VeriTrust-Receiver.cmdOn first use, enter the receiver-only VeriTrust API key and receiver secret. The key is server-side bound to its organization/workspace, so resulting SMTP investigations are stored under that account. The values are DPAPI-protected on that Windows user profile. Startup performs a non-mutating credential preflight before the SMTP listeners are exposed. The receiver then starts a Tailscale listener and a 127.0.0.1:2525 same-laptop listener, and prints one short-lived pairing code. If your extracted folder has a suffix such as (1), launch from that actual folder; the 2.5.4 launcher uses its own package directory automatically. Never copy the VeriTrustLab API key or receiver secret to the sender laptop.
04 · Sender laptop
# Open PowerShell in the folder you actually extracted
.\Run-VeriTrust-Sender.cmdThe pairing code contains only the temporary SMTP endpoint and ephemeral SMTP credential. Every receiver launch first clears only the previous VeriTrust receiver/runtime instance, releases stale demo listeners, and generates a new SMTP password; it does not terminate the sender CLI or erase the Tailscale device identity. If sender and receiver are on the same laptop, the sender detects that both sides have the same Tailscale IP and automatically connects to 127.0.0.1:2525. On a different laptop it uses the receiver's Tailscale IP.
05 · Live transaction
/demo legitimate
/demo phishing
/send C:\VeriTrust-Demo\message.eml06 · Recovery
For a two-laptop demo, confirm both machines are online in the same/shared Tailscale tailnet and the sender can see the receiver's 100.64.0.0/10 address. The CLI first reuses a healthy authenticated profile. If Tailscale reports NeedsLogin, it runs the login flow, polls for the fresh AuthURL, copies it to the clipboard, and opens it in the normal/default browser. If the profile is only offline, it uses tailscale up. Recovery can refresh the Windows service, but normal restart does not log the device out.
Restart the receiver elevated so the restricted Windows Firewall rule can be repaired. Do not expose TCP 2525 publicly.
Verify the deployment origin, the receiver-only gateway:scan key, receiver secret, and Vercel runtime configuration. Treat provider/API failure as a safe defer condition. If receiver startup/runtime fails, inspect %LOCALAPPDATA%\VeriTrust\MailConsole\receiver-last-error.log and the printed runtime-log tail; fatal errors remain visible instead of immediately closing the window.