Glossary

Communication provenance, defined

This glossary defines the vocabulary Fromenance uses for communication provenance, one sentence per term, so the same words mean the same thing on this site, in the docs, and in the product. Definitions are stable; when one changes, the change is noted here.

Communication provenance: Communication provenance is authoritative, sender side evidence that a specific institution issued a specific communication to a specific recipient at a specific time, which is what Fromenance provides and what domain authentication like DMARC does not.
Registration: Registration is the act of telling Fromenance, at send time, that a communication went to a recipient, carrying a recipient hash, a content fingerprint, a message id, the sent time, and the visible From address, and receiving a verify code in return.
Verify code: A verify code is the 8 symbol Crockford base32 identifier, shown as XXXX-XXXX with a checksum in the eighth symbol, that Fromenance issues per registration and the institution places in the message footer.
Verify footer: The verify footer is the sentence an institution adds to registered messages, such as "Not sure this email is from Northfield Bank? Forward it to verify@northfieldbank.com or enter code KX73-PQ9G at northfieldbank.com/verify. Reference: KX73-PQ9G", with the code repeated so one copy survives rewrapping and OCR.
Recipient hash: A recipient hash is hmac-sha256 of the lowercased, trimmed recipient address keyed with the tenant's secret, which is the only form in which Fromenance ever holds a recipient on a registered communication.
Content fingerprint: A content fingerprint is the 64 bit SimHash (plus SHA-256) of a message's normalized visible text that Fromenance computes identically at registration and at verification so a forwarded copy can be matched without storing the body.
Content normalization: Content normalization is the deterministic pipeline (HTML to text, gateway link unwrapping, forward chrome removal, footer removal, URL to domain replacement, whitespace and case collapse) that Fromenance runs before fingerprinting so both sides compute the same bits.
Fingerprint threshold: The fingerprint threshold is the maximum Hamming distance, 6 of 64 bits by default and tunable per tenant, at which Fromenance treats two content fingerprints as the same communication.
Submission: A submission is one customer question to Fromenance, arriving by forward to verify@ or by paste, .eml upload, or screenshot on the institution's verify page, and resolving to exactly one verdict.
Verdict: A verdict is Fromenance's immutable answer to a submission, one of Verified, Not verified, or Known fraud, with the rule that produced it and an analyst override trail.
Verified: Verified is the Fromenance verdict returned when a submission matches a registered communication for that recipient, worded in the reply as "matches a communication we registered and sent to you on" the recorded time.
Not verified: Not verified is the Fromenance verdict returned when no registered communication matches a submission, worded as "no registered communication matches", which does not by itself mean the message is fraudulent.
Known fraud: Known fraud is the Fromenance verdict returned when a submission's indicators are on the tenant's fraud list or its fingerprint matches a submission an analyst confirmed as fraud.
Authoritative Mode: Authoritative Mode is a per tenant Fromenance setting, enabled only by a backoffice operator after outbound coverage is reviewed (the working threshold is 95 percent for 30 days), that changes the Not verified reply from "no registered communication matches" to "we did not send this".
Coverage: Coverage is the share of an institution's actual outbound volume on a stream that is registered with Fromenance, tracked per sending source against the tenant's stated volume, and the prerequisite for Authoritative Mode.
Coverage gap: A coverage gap is a legitimate communication that was not registered, surfaced in Fromenance when an analyst marks a Not verified submission as legitimate or when a reserved code is never completed within 24 hours.
Replay attack: A replay attack is the use of a real Fromenance verify code or footer on a message it was not issued for or to a person it was not sent to, which resolves to Not verified for the customer and to a high priority internal flag.
Footer replay: Footer replay is the specific replay attack in which an attacker copies an institution's genuine verify footer into a lure, which Fromenance detects because the code is bound to one registration and one recipient hash.
Trust check: The trust check is the gate Fromenance applies to every message arriving at a tenant inbox: the slug resolves, the forwarding hop passes DKIM or ARC for a domain the tenant owns, and that domain's _fromenance TXT token matches.
Trust TXT record: The trust TXT record is the single DNS record, _fromenance.<domain> TXT "v=fromenance1; t=<slug>; k=<token>", that anchors a tenant's domain in Fromenance and is re-checked daily.
Redirect rule: A redirect rule is the mail flow rule on verify@yourdomain.com that redirects (rather than forwards) messages to the tenant inbox so the customer remains the sender and Fromenance can reply to them.
Reply identity: A reply identity is the sending domain from which Fromenance verdict replies leave, either a DKIM signed subdomain the tenant delegates (recommended) or the Fromenance reply domain with the tenant's display name for pilots only.
Locked verdict block: The locked verdict block is the fixed text and timestamp in every Fromenance reply template that carries the verdict wording, cannot be edited by the tenant, and never quotes the suspicious message or uses stronger language than the registry supports.
Reserve flow: The reserve flow is the Fromenance registration path for ESPs that cannot provide the rendered body: reserve a verify code before send, inject it with the ESP's merge mechanism, and let the send event complete the registration.
Sending source: A sending source is one Fromenance integration that registers communications (API, an ESP adapter, or a journal address), with its own health metrics: last event, events per hour, signature failures, and reserve to complete ratio.
Journal or BCC path: The journal path is the Fromenance registration method in which a sending system BCCs or journals to journal-<slug>@ingest.fromenance.com and the full message is hashed, fingerprinted, and registered without application changes.
Indicator: An indicator is a URL, domain, IP, phone number, email address, QR payload, or wallet address that Fromenance extracts deterministically from a non verified submission and stores with first seen, last seen, and count.
Fraud list: The fraud list is a tenant's set of indicators and fingerprints, added only by analyst action or confirmed campaign clustering, that makes later matching submissions resolve to Known fraud in Fromenance.
Analyst override: An analyst override is the audited action of marking a Fromenance submission as fraud (adding its indicators and fingerprint to the fraud list) or as legitimate (creating a registration retroactively and flagging a coverage gap).
Site key: A site key is the public, origin bound key that a Fromenance verify page or widget sends with each submission; it carries no secret and is rate limited per key and per IP.
Verify page: A verify page is the institution hosted page, typically yourdomain.com/verify, where a Fromenance widget accepts pasted text, an .eml file, or a screenshot and renders the verdict in the institution's branding.
Campaign: A campaign is a Fromenance cluster of three or more submissions in 72 hours that share indicators, kit fingerprint, or fingerprint proximity, which an analyst can name, merge, split, and close; clustering is on the intelligence roadmap.
Communication provenance graph: The communication provenance graph is the accumulated Fromenance dataset joining authoritative records of what institutions sent to victim submitted impersonation attempts and their infrastructure, correlated across institutions on indicators only.