Summary

  • RFC 5260 evaluates one selected timestamp under an occurrence, zone, date-part and comparator policy; a true result proves that comparison, not the historical truth of the timestamp.
  • Evidence must keep the raw ordered headers, selector, parse and zone decisions, script revision, fixed execution instant, predicate result and observed action separate.

The cutoff was precise because the wrong clock had been made precise

A procurement gateway received a bid minutes before a deadline. Its Sieve rule inspected the second Received: field, shifted the extracted time to a fixed offset and redirected messages after the cutoff to a late-submission queue. The rule was deterministic. Months later, the mail path had gained a security appliance. The second occurrence now described a different hop.

Nothing in the script changed. The selected fact did.

That is the institutional problem hidden inside a small filtering extension. RFC 5260 is exact about how a date test works, and just as exact about what it cannot guarantee. A predicate can be correct for the bytes and policy it received while the business conclusion attached to it is wrong.

One occurrence enters the test

The date test names one header type. Without the index extension, the first field of that name is used. With :index n, counting begins at one. Add :last and counting runs backwards. When a script names several header types for a header or address test, their occurrences are counted in the order of the script’s header list.

Those are syntactic coordinates. They are not trust rankings. RFC 5260’s own example says a fixed offset can identify the local-domain entry time only as long as the field offset remains consistent. A gateway insertion, migration or new security hop can move the coordinate while preserving every line of policy code.

The receipt therefore needs the ordered header inventory and the exact selected occurrence. Recording only “index 2 matched” loses the object to which index 2 referred.

Parsing compresses several causes into false

The test returns false if the header is missing, the extracted value is syntactically invalid, the calendar value is impossible, or the valid value simply fails the comparison. Operationally, these are different conditions. A missing trusted hop, a malformed hostile field and an ordinary out-of-window message should not become one unexplained boolean in an audit trail.

The relational :count view is similarly narrow: one means the selected field exists and contains a valid date; zero means otherwise. It is not a count of every date-bearing header, and validity is not authenticity.

Zone policy changes the civil-time question

:originalzone preserves the offset written in the extracted value. :zone shifts the instant to a specified fixed offset. Supplying both is an error. Supplying neither requires the server’s local time zone.

The comparison can therefore depend on execution policy that is absent from the message. Two systems can receive identical bytes and run equivalent scripts yet ask different civil-time questions because their local-zone configuration differs. Conversely, preserving an original offset proves only what the field asserted. A numeric offset is not a geographic location, a daylight-saving history or a custody record.

Current time is stable only inside one execution

currentdate uses the script’s current date and time rather than a message header. RFC 5260 requires all such tests within one script execution to refer to the same instant. This is valuable: a script cannot cross midnight between two predicates and contradict itself.

But the guarantee is local. It does not attest the sender’s clock, queue entry, final delivery, reading or another worker’s execution. The RFC also warns that time-dependent tests make script behavior harder to analyze. A review of source code without the execution instant cannot reconstruct the branch.

A more reliable header is still a bounded claim

The security section draws a useful distinction. Date: is typically supplied by the sender and can be altered anywhere. The uppermost Received: field is typically added by the local mail system and is harder for the sender or an intermediary to falsify.

“Harder” and “typically” matter. The local field may provide strong evidence about local receipt. It does not authenticate the full earlier route, establish when the sender created the content, or prove what happened after filtering. Evidence quality belongs to each field’s producer and custody boundary, not to the fact that a date parser accepted it.

The decision receipt

For consequential date-derived automation, retain:

  • the message and raw-header hash, ordered header inventory and selected occurrence;
  • header name, :index, :last, header-list order and raw extracted value;
  • syntax and calendar validity, original offset, requested or server-local zone and normalized date part;
  • comparator, match type, key list, capability set and Sieve script identity and revision;
  • execution host and the one captured currentdate instant;
  • predicate result with a distinct false-reason class;
  • selected action, action execution result and final mailbox or redirect observation; and
  • every later human or automated decision that treated the time result as authority.

This receipt does not make the timestamp true. It prevents a precise computation from being misremembered as a historical fact.

Sources