Summary

  • RFC 5183 standardizes access to execution-context values such as location, phase, remote-host and remote-ip. These are interpreter-provided inputs, not certificates of organizational origin, trust or successful delivery.
  • The RFC explicitly warns that remote-host may come from an untrusted PTR lookup. A suffix match can therefore select a valid Sieve branch while authorizing the wrong party.

The filtering rule looked restrained. Mail whose remote-host ended in .example.com could bypass the external-sender quarantine; everything else entered the ordinary review path. The test matched, the script ran, and the message arrived in the priority mailbox. The audit entry recorded an internal source.

The only evidence behind that classification was a PTR answer. The connecting address was controlled outside the organization, and the operator of its reverse-DNS zone had chosen a hostname under the familiar suffix. RFC 5183 uses essentially this case to warn that remote-host is not a sound test of whether mail came from “outside.” The script can be syntactically correct, the comparison can be exact and the resulting action can still rest on an untrusted label.

This is a conceptual control failure, not an allegation about a named service. It exposes a recurring governance mistake: a standardized name is promoted from observation to authority without preserving how the observation was made.

The extension reports a context, not an identity

Sieve was designed to filter mail at or around final delivery without giving users arbitrary programs. RFC 5183 adds the environment capability so a script can behave differently when it moves between systems, runs at different service points or receives a message through different transport circumstances.

The test takes an item name and a list of keys. It uses the familiar Sieve match and comparator framework; absent explicit choices, the match is :is and the comparator is i;ascii-casemap. The current message is not the direct source of the value. The interpreter obtains it from its operating environment, while the script supplies the comparison target.

That division matters. A header is part of the message record. An environment item is a statement by the runtime about the situation around the message. Neither kind of statement is automatically trustworthy, but their evidence paths are different. An audit that stores only “environment matched” loses the interpreter, source method, raw value and policy that made the match meaningful.

The initial vocabulary is useful precisely because it is modest. domain and host describe the execution context. location distinguishes MTA, MDA, MUA and message-store evaluation. phase says pre-, during or post-final delivery. name and version identify the interpreter product. remote-host and remote-ip describe the applicable remote SMTP, LMTP or Submission client.

None of those definitions says “trusted organization,” “employee,” “inside network,” “approved build,” “message committed” or “user received it.” Those are stronger local claims that require additional evidence.

Existence, emptiness and trust are three questions

RFC 5183 makes optional information survivable. If an item does not exist, its test must fail rather than abort the script. A script can probe for an item with :contains and an empty key because every returned string contains the empty string. That technique answers whether the implementation knows the item.

It does not answer whether the item carries information. remote-host, for example, returns the empty string when a hostname cannot be obtained. With RFC 5231's relational :count, an empty returned string counts as zero and a nonempty one as one. The rule counts the value, not confidence, source diversity or semantic completeness.

A production policy therefore needs three states, not one Boolean. First: is the item implemented? Second: was it populated for this invocation? Third: is its derivation trustworthy enough for this decision? Treating the first affirmative result as an answer to all three turns graceful portability into an authorization bug.

Failing closed also has to be explicit. If the hostname is unavailable, a security rule should enter a known conservative branch and record why. Quietly falling through to the same action used for a verified internal peer erases the difference that the RFC carefully preserves.

A DNS suffix is not a perimeter

The security section is unusually direct. An implementation may use any technique to determine remote-host, and the trustworthiness varies. A common technique is a PTR lookup on the client IP address. That information may come from an untrusted source; a party able to create a PTR record can choose the domain to which it points.

The resulting string can still be a legitimate environment value. The protocol has not malfunctioned. The error occurs when the local policy silently upgrades “the configured resolver returned this PTR name” into “this connection belongs to the named organization.” Registration of the item standardizes the question, not the authority of the answer.

A defensible hostname-based decision records at least the peer address, the exact reverse query, resolver context, response and cache age, the validation and forward-confirmation policy, and the relationship between the resulting name and the party being authorized. DNSSEC, where applicable, can authenticate DNS data under its chain; it does not convert the reverse-zone operator's chosen label into corporate identity or prove the sender's business role.

remote-ip is closer to the transport observation, but it is not a universal identity either. Relays, submission services, proxies, NAT and trusted-forwarding arrangements can make the immediate peer different from the human or system that originated the message. Local architecture must say which hop the item represents and which decisions that hop may authorize.

Location and phase locate evaluation, not completion

A script can distinguish location=MTA from MDA, MUA or MS. It can distinguish phase=pre, during and post. Those labels let one script adapt to different execution points. They do not create an end-to-end receipt.

“Post” is relative to final delivery in the Sieve model. It is not evidence that a particular fileinto, redirect, notification or downstream store operation committed, survived replication or became visible to a user. “MS” says a message store evaluates the script; it does not identify the node, loaded script generation, database transaction or mailbox replica that later served the record.

RFC 6785 makes the boundary concrete. For IMAP-triggered Sieve it sets location to MS and phase to post, then adds items such as imap.cause, imap.mailbox and imap.changedflags. imap.mailbox is fixed when the script begins and does not change after a fileinto action. It is therefore an invocation fact, not a live destination field.

Similarly, imap.changedflags can say which flags changed without saying whether each was set or reset; the script must test the current state separately. A context field is allowed to answer one bounded question. The audit fails when it asks the field to testify about later state that the specification deliberately leaves elsewhere.

Registries coordinate names, not meaning across every system

RFC 5183 creates a registry for standard and vendor-defined items. Standard interoperable items need Standards Track or Experimental RFC definitions. Vendor items begin with vnd. and are registered to prevent collisions. The current IANA registry shows both the original fields and later IMAP Sieve fields, plus a vendor namespace.

That is successful minimum specification. Independent systems can agree that phase and remote-host name the same general questions. Future RFCs can add scoped groups such as the imap. items. Vendors can expose useful local state without pretending that it is an Internet standard.

But a registration is not conformance testing, attestation or semantic translation. Moving a script that depends on vnd.vendor-a.cluster to another product may make the test false, may leave the item absent or may require a new local adapter. Even standard items can expose different operational granularity because the deployment chooses its architecture and derivation methods.

RFC 5463's ihave illustrates another layer: a script may test whether capabilities are available. Capability presence, item existence, nonempty value and decision-grade trust remain four separate claims. Advertising environment proves that the interpreter understands the extension. It does not promise that every item is populated or suitable for authorization.

The receipt must preserve provenance and effect

High-impact mail policies need an evidence object stronger than a log line. It should bind an immutable policy identifier to the exact script hash and loaded interpreter build; record capabilities, environment item and raw value; preserve source and derivation method; capture the transport peer and invocation point; and store the comparator, branch and selected action.

Then it must continue past Sieve. The action engine's response, the receiving SMTP/LMTP/IMAP or storage transaction, and the final mailbox or user-visible state are distinct receipts. This does not duplicate the separate question of whether a Sieve action generally equals a delivery outcome. Here the upstream problem is whether the value that selected the action had the authority assigned to it.

The discipline also reduces information leakage. RFC 5183 notes that environment data can reveal provider or enterprise infrastructure. A runtime need not expose every internal label to every user script. Operators can publish the minimum stable context required for safe portability, protect sensitive details and retain richer provenance in controlled audit systems.

The closing test is straightforward: can the organization prove where this value came from, why that source was trusted for this branch and what changed after the action? If the answer is only that a standardized string matched, the label has acquired authority the running system never supplied.

Sources

  1. RFC 5183 — HTML
  2. RFC 5183 — plain text
  3. RFC Editor information page
  4. IETF Datatracker document page
  5. IETF Datatracker history
  6. IETF Datatracker references
  7. RFC 5183 errata
  8. RFC 5228 — Sieve base specification
  9. RFC 5228 information page
  10. RFC 5231 — relational extension
  11. RFC 5598 — Internet Mail Architecture
  12. RFC 6785 — IMAP events in Sieve
  13. RFC 6785 information page
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — Sieve ihave extension
  16. IANA Sieve Extensions registry
  17. IANA Sieve Environment Items registry
  18. Heng Lu — reality layers
  19. Heng Lu — minimum specification and voluntary adoption
  20. Heng Lu — running code is primary