Forwarded is not reported

Awareness programmes usually report one number: how many clicked. The second number would be more interesting. How many reported the mail? Because only that helps in a real incident. A click that does not happen prevents one incident. A report that arrives prevents the next twenty.

But you only get that number once the reporting path works. And that is where the problem starts.

Not every reporting path is equally good

The usual advice is: forward the suspicious mail to IT. That is right but imprecise, because forwarding is not just forwarding.

With ordinary inline forwarding a new message is created that quotes the old one in its body. The sender of the new message is the person reporting. The headers of the suspicious mail are gone, and with them the authentication results that would show whether the sender was genuine at all. If the mail is forwarded as an attachment or redirected instead, the original survives. With a redirect the reporting person appears in Resent-From while the original sender stays in the header, cleanly separable.

Where the difference becomes visible is the report itself. Reporter and sender sit there as two separate fields. If a Resent-From is present, both are filled. If it is missing, the sender field stays empty. Not out of sloppiness, but because the information no longer exists in the message. Whoever opens such a report during triage has nothing to work from.

Hence buttons, but as a convenience

You can teach people to forward as an attachment or to redirect. Except hardly anyone knows those functions, and in some clients they are hidden. A one-click report button takes the decision away: it transmits the message in its original form, with unchanged headers, text body and HTML body.

The framing matters here: the buttons are a convenience, not a prerequisite. The route via a reporting mailbox works in every client and remains the supported standard. Anyone who cannot or does not want to roll out software loses nothing, as long as mail is forwarded as an attachment or redirected.

Including HCL Notes

There are buttons for Thunderbird, Outlook, Gmail and HCL Notes. The last one is the unusual one: the common awareness tools ship Outlook and Gmail, sometimes Thunderbird. For Notes and Domino there is little to be found, even though the platform is still running in municipalities, insurers and parts of the mid-market. We built a Java agent for it, because the Domino Java runtime brings HMAC-SHA256 and an HTTPS call with it.

That comes with a caveat we do not hide. The agent can only deliver the true original if Domino kept the mail as MIME. If the server converts incoming mail into Notes rich text, which is a common default, the original headers are lost. The agent then builds a replacement message and marks it as reconstructed. That finding is shown during triage, so nobody concludes from missing DKIM data that the mail was unremarkable. Where the server configuration cannot be changed, the mailbox route is the more accurate reporting method. Our own documentation says so.

A report is a case, not an inbox entry

What happens next decides whether people keep reporting. Every report gets a number, a status from new to confirmed or benign, a classification as phishing, spam, malware, business email compromise or legitimate, a severity and an owner. Links and attachments are extracted and counted, and whatever the reporting person wrote themselves stands as its own field instead of disappearing into the quote.

The part that cost us the most thought

A report button running during an awareness campaign will inevitably receive your own simulations. The obvious move is to file those as benign. That would be an open invitation: an attacker would only have to make their mail look like a simulation to slip past triage.

So it is verified rather than believed. The check reads the authentication results of the message and compares them with the expected sender domain of your own simulation. With an asymmetry that mattered to us: an explicit failure on the expected domain weighs more than a match elsewhere. A DKIM failure there is an active warning sign, not a missing piece of evidence. Incidentally, that is why the headers matter so much: without them there is nothing to verify.

And what the server replies: as little as possible

A report is always acknowledged the same way, with no information about whether the mail was recognised as a simulation or filed as a suspected case. That is deliberate. The button runs in the reporting person's mailbox, and that information would tell them which mails are simulations. The test could be gamed with it. A rejection likewise does not distinguish between a wrong signature and an expired timestamp, because that would only help someone guessing.

Reporting is not punished

Normally, training goes to whoever clicks. Here the reporting person can be assigned the awareness course too, explicitly as recognition. That inverts the signal: reporting is not something to justify but the expected behaviour. The same holds for the channel: simulations now also run by SMS, and the question stays the same.

More on the module page. Why the report rate feeds into the Human Security Index, and what is deliberately not measured there, was covered here yesterday.