Summary

  • RFC 5248 created a governed registry for SMTP enhanced status codes so specifications and implementations could reuse public meanings without collisions.
  • Registration proves vocabulary custody, not that a particular server diagnosed a message correctly, a client preserved the evidence, a retry policy was sound or delivery occurred.

A precise label can still be a claim

Consider a mail operations screen showing 5.7.14 Trust Relationship Required. The label is specific. It has a place in an IANA registry. Its history can be traced to a published Best Current Practice. None of that establishes which trust check ran, which identity was tested, whether the server chose the code correctly, or whether another attempt later succeeded.

RFC 5248 solved a real coordination problem. RFC 3463 had made the enhanced-code space extensible but had not supplied an explicit procedure to register and track additions. Conflicting definitions followed. RFC 5248 therefore created public custody for the vocabulary and updated the specifications that had already extended it, including RFC 4468 and RFC 4954.

That custody is valuable precisely because it is bounded. It can answer, “What meaning has this code been assigned, by whom, under which reference and change controller?” It cannot answer, “What happened inside this mail system?” The first is registry evidence. The second requires runtime evidence.

Three tables distribute semantic control

The familiar code has three positions: class, subject and detail. RFC 5248 does not govern them as one undifferentiated list. IANA maintains class sub-codes, subject sub-codes and enumerated status codes. An enumerated entry combines a subject and detail while retaining a class wildcard, because a defined condition may be used with more than one class when its specification permits it.

Each record carries more than a friendly phrase. It includes the code, summary or sample text, description, reference and standards status, submitter and change controller. Enumerated entries also carry an associated basic SMTP status. These fields are a map of semantic responsibility: the reference explains the condition; the controller owns permitted changes; the registry keeps assignments from colliding.

The associated basic status is deliberately non-exclusive. If an entry lists a three-digit reply, that does not forbid the enhanced code from appearing with another reply. The field may say Any or Not given. An auditor who treats the table as a one-to-one validation matrix invents a constraint the registry expressly declines to make.

Even the escape hatch has a narrow meaning. X.0.0 is the only undefined code and applies when only the response class is known. It records limited knowledge; it does not fill the missing cause with authority.

Review keeps the namespace coherent

New assignments use the Specification Required policy. RFC 5248 wanted non-standards specifications to be readily available and emphasized avoiding confusion and collision, not creating needless barriers. The current policy framework in RFC 8126 combines a permanently available public specification with designated-expert review of clarity, stability and technical quality.

This is a governance filter, not an implementation certification. The expert does not observe a production queue, reproduce a delivery failure, audit every parser or approve a company’s retry algorithm. A code can be well specified while a server emits it for the wrong condition. Conversely, a genuine local condition may be poorly represented by the code chosen for it.

Change authority is similarly explicit. A standards-track registration normally changes through an update to the standard. A non-standards registration is controlled by its named controller. Routine edits are expected to correct description or reference rather than silently repurpose the number or sample text. The IESG retains exceptional power to resolve conflicts. Those rules protect shared meaning over time; they do not reach backward into every log line already written.

The registry’s initial contents make the distinction unusually clear. RFC 5248 imported values from published RFCs and also values already used in industry without a published specification. It seeded security codes under IESG control. It also reassigned the “Trust Relationship Required” condition from an earlier use of X.7.8 to X.7.14. A registry can repair a collision and publish a better semantic home. It cannot prove when deployed software migrated or whether archived events used the old value consistently.

Class is policy input, not destiny

RFC 3463 gives the first digit an operational grammar. Class 2 denotes success in a delivery status notification. Class 4 marks a persistent transient failure: a later attempt may succeed. Class 5 marks a permanent failure for which changing the message or destination is generally required.

These are strong instructions for interoperable handling, but their language is not metaphysics. RFC 5321 tells an SMTP client to act on the reply code rather than the explanatory text. It treats 4yz as a reason to try later under appropriate conditions and 5yz as a reason not to repeat the exact request unchanged. It also acknowledges that an apparently permanent condition can later be corrected.

Thus 4.x.x is not a promise that retry will work, and 5.x.x is not proof that the world can never change. A scheduler still needs message identity, recipient, attempt history, elapsed time, queue policy and fresh server responses. A registered label can guide the next decision. It cannot supply the missing observations.

RFC 2034 governs carriage of enhanced status codes in SMTP replies. RFC 5248 governs custody of the vocabulary. A server’s emission logic, a client’s parser, a queue’s persistence and a delivery system’s final evidence sit beyond both. Combining those surfaces into one green or red badge destroys the chain that an investigation later needs.

More detail can create more exposure

The registry’s security discussion resists the idea that maximum specificity is always better. Enhanced codes can reveal internal implementation details. Authentication failures are the clearest case: distinguishing an unknown user from a bad password can give an attacker a useful oracle. Specifications are expected to tell server software when detail should be restricted.

This makes disclosure policy another independent control. A less specific public reply may be the correct security decision even when a more specific internal diagnosis exists. The public code, restricted code, private log and final incident finding should not be collapsed into one field. Absence of detail is not automatically evidence of poor diagnostics; presence of detail is not automatically evidence of truth.

Preserve a delivery evidence ladder

An operational record should move through distinct receipts. First, the code parses. Second, the observed registry version contains the assignment. Third, an implementation claims the registered condition. Fourth, the basic and enhanced replies fit the governing specification. Fifth, the client preserves the exact response and transaction context. Only then can server logs, queue transitions or independent observations corroborate cause.

Above that sit decisions and outcomes: whether retry policy targeted the correct message and recipient; whether a later transfer completed; whether the destination accepted the message; whether a mailbox or application disposed of it; whether a person or business process acted on it. No dotted code climbs that ladder by itself.

Lu Heng’s running-code and reality-layer discipline matters here. A registry is a symbolic coordination surface whose value depends on implementations that preserve its distinctions. Runtime behaviour is evidence about what machines did. Neither layer should impersonate the next. The reliable system keeps the public definition, emitter, parser, policy action and outcome as linked but separately authoritative facts.

Sources