Summary

  • RFC 5235 normalizes implementation-specific spam and virus checks for portable Sieve rules, but spamtest :percent value zero deliberately combines tested-and-clear with untested or unknown states.
  • A consequential filter therefore needs a separate receipt for test execution and provenance. The portable score, the Sieve branch, the selected action and the recipient's outcome are distinct evidence surfaces.

One result, three histories

Imagine an inbound policy that permits a low-risk path when the normalized spam percentage is zero. The first message crossed a current scanner and its rules found no spam indicators. The second reached a system where scanning was disabled. A third was handled by a Sieve implementation that could not determine whether the check ran. RFC 5235 permits the same percent result for all three.

That is not a defect hidden in the specification. It is a boundary written into it. The extension gives scripts a portable value even though the underlying checks are implementation-specific. Portability answers, “What normalized result may this script compare?” It does not automatically answer, “Which examination produced it?”

When those questions are merged, absence of evidence quietly acquires the authority of a clean finding.

Normalization trades detail for reach

Before a script can compare scanner output across implementations, local evidence must be mapped onto a common scale. RFC 5235 says the implementation supplies a normalized result string. A script may also request implementation-specific text, but the RFC warns that doing so sacrifices portability.

The trade is legitimate. Common values let one Sieve rule operate without knowing every scanner's private vocabulary. Yet a normalized number is a projection, not the source record. It omits the scanner identity, engine version, ruleset date, policy profile, inspected representation, skipped content, timeout state and reason a check may not have run.

Leaders often ask a portable field to serve both automation and audit. Those jobs pull in opposite directions. Automation benefits from a small stable vocabulary. Audit needs the provenance and exceptions that the vocabulary intentionally discards. The answer is not to abandon normalization. It is to keep the source receipt beside it.

Zero changes meaning with the scale

RFC 5235's two spam scales expose the danger precisely. Without :percent, value zero means not tested or unknown, while value one means tested and definitely clear. With :percent, value zero may mean tested and clear, not tested, or indeterminate test status.

A dashboard that stores only “zero” can therefore lose even the scale that gives the value meaning. A policy migration from the ten-step scale to percentage form can change the evidentiary interpretation without changing the visible digit. Aggregating results from both forms makes the record still weaker.

The specification provides a separate question. With relational :count, count one means the underlying test was done; count zero means it was not done or Sieve cannot determine that it was done. This restores an execution boundary, but not full provenance. It does not identify the scanner, prove the rules were current, show which parts were inspected or certify that the exported result was authentic.

The header can become an authority channel

Some implementations may carry scanner results in private message headers. RFC 5235's security guidance insists that only a legitimate check process may supply the result and that senders or intermediaries must not be able to spoof such headers.

That requirement reveals the control surface. Once a field can steer filtering, whoever can write the field can influence the decision. A normalized value is not harmless metadata; it is a compact authority claim. Its trust depends on the path that created it, the boundary that protected it and the component that interpreted it.

The RFC also notes that scanners should be kept current and that virus detection is not perfectly reliable. Authentic provenance is therefore necessary but insufficient. A genuine stale scanner result is still genuine. A correctly exported value from incomplete inspection is still correctly exported. Integrity of the channel cannot substitute for fitness of the check.

Result, branch, action and outcome

The score answers one question within the interface. A Sieve comparison answers whether a branch matched. The script may then select an action. A mail system may attempt that action. Storage, transfer or rejection may produce another receipt. The recipient may observe something else again.

RFC 5235 does not collapse these stages, and an operating record should not either. “Spam score zero” does not prove that a scan ran. “Rule matched” does not prove that the intended action executed. “Filed into a mailbox” does not prove that a person read or trusted the message. Each claim needs evidence addressed to its own subject.

This is also the boundary with earlier Sieve coverage. The important mechanism here is not the catalogue of actions. It is the information lost when implementation-specific examination becomes a portable result before any action is chosen.

What the record does not establish

RFC 5235 names no current scanner deployment, vendor performance, false-positive rate, false-negative rate, malware campaign or operational incident. Its IANA registrations prove that extensions are registered, not that they are widely or correctly implemented. The standards record supplies semantics, not market evidence.

Nor is every zero unsafe. A low-consequence workflow may rationally accept an unknown test state. The governance error is subtler: treating that policy choice as though the value itself proved clearance. Risk acceptance and factual proof are different records.

The virus scale reinforces the point. Its values distinguish untested or unknown, clear, made harmless, possibly infected and definitely infected states. Those labels remain outputs of an underlying process whose freshness and reliability must be governed separately.

Keep the portable value and the execution receipt

For each consequential filter decision, retain two linked records. The portable-result record should include the extension and scale, normalized value, comparison, branch and script version. The execution record should include whether the check ran, the scanner and ruleset identifiers, update time, inspected representation, exclusions or errors, trusted result channel and the principal responsible for the policy.

Then keep action and outcome receipts downstream rather than writing them back into the score. Preserve untested, unknown, timed-out and partially inspected states as first-class outcomes. Do not coerce them into a clean value merely because a downstream system requires a number.

Lu Heng's reality-first doctrine applies directly: a convenient description cannot replace evidence of running activity, and a protocol label cannot be the accountable principal. One owner must decide when normalized ambiguity is acceptable and when execution proof is mandatory.

The filter may return zero. The organisation should still know whether anyone looked.

Sources

Additional standards record

  1. RFC 5235 plain text
  2. RFC 5235 information record
  3. RFC 5235 Datatracker record
  4. RFC 5235 history
  5. RFC 5235 errata
  6. RFC 5235 referenced-by record