How it works

From uncertain message to evidence-led advice.

Percival is designed to show the evidence behind its recommendation, not simply present a score or a vague warning.

What users can submit

Percival currently supports uploaded .eml files, pasted email content and a forward-by-email workflow where the inbound configuration is available.

What Percival examines

The service reviews sender details, reply-to information, message wording, extracted links and attachment metadata before mapping those signals to a calm recommendation.

How sender checks work

Percival compares visible sender details with reply-to information and the domains referenced in the message. A mismatch does not prove malicious intent, but it can be a useful warning sign.

How links are analysed

Links are extracted from the submitted content and normalised for comparison. The current environment keeps link handling server-side and does not automatically visit links from the user's browser.

How attachments are analysed

Attachment metadata such as file name, type and size are reviewed. Percival does not execute uploaded files, and the current implementation treats attachment content as untrusted.

How content patterns are reviewed

The wording of the message is checked for urgency, payment requests, credential requests, blackmail language and other patterns that often appear in phishing and fraud emails.

How the risk level is produced

Percival combines observed evidence and rule-based checks into one of four outcomes: likely safe, needs caution, high risk or inconclusive.

What the result means

The recommended action is the most prominent part of the result, followed by the reasons, supporting evidence and any limitations or incomplete checks.

What Percival cannot guarantee

It may miss some malicious emails, and a clean result does not prove that a message is safe. Independent verification still matters, especially for money or password requests.

How user data is handled

The current implementation analyses email submissions within the request flow and should only retain what is operationally necessary for safe handling, abuse prevention and fault investigation.