Summary

  • RFC 5335's experimental mailbox syntax could pair a non-ASCII address with an optional all-ASCII alternative. The related downgrade procedure could select that alternative when a downstream SMTP hop lacked the required capability. The RFC explicitly admitted that the two addresses might reach different mailboxes or different people.
  • RFC 6530 later recorded why the model was removed: the pairing could not be authenticated, implementations did not interoperate reliably, and the long-term complexity outweighed the hoped-for compatibility. The standards-track design chose native end-to-end support and visible failure over an in-transit substitution whose authority was unclear.

A fallback string became a routing decision

The tempting story about internationalized email is a story about characters. A mailbox can contain a name written in the script its owner uses. Header values can carry UTF-8 directly. A legacy relay speaks only an older alphabet, so the system supplies an ASCII spelling and continues.

That story fails at the decisive word: spelling. An email local part is not ordinary prose. It is an identifier interpreted inside an administrative domain. Replacing one local part with another does not transliterate a label on the same box unless an authoritative system has made that relationship true.

RFC 5335 made the problem unusually visible. Its experimental header grammar permitted an internationalized mailbox to carry an optional ASCII alternate address. The related SMTP and downgrade specifications allowed that alternate to replace the original path when an incapable hop appeared. A relay's missing capability could therefore decide which address moved forward.

The result looked like graceful degradation. It might also be a change of recipient.

The RFC did not conceal this. Its security section says the ASCII and non-ASCII addresses may lead to different mailboxes or even different people. Delivery may then depend on the capabilities of the MTAs on the route. The specification calls the configuration a possible user or administrative choice and recognizes the violation of least astonishment. That candour is more valuable than a false guarantee: the protocol carried an association, not proof of identity equivalence.

Syntax could carry the pair; it could not authorize the bond

Several statements can all be true at once. The UTF-8 address can be syntactically valid. The ASCII address can be syntactically valid. The pair can be encoded exactly as the experimental grammar required. The sending server can honestly advertise support. None of those facts establishes that both addresses designate the same principal.

The missing receipt is authority over the binding. Who asserted the association? Did the owner of the internationalized mailbox approve it? Does the receiving domain route both addresses into one account? Is the relationship current? Can it be revoked? Can an administrator prove that the fallback was not copied from a stale directory, guessed from a romanized name, or assigned later to somebody else?

These are not Unicode questions. They are control questions.

Lu Heng's distinction between a record and the authority projected through it applies cleanly here. A registry row, protocol field or directory attribute can report an address pair. It does not, by existing, acquire the mandate to substitute one human principal for another. Running code can demonstrate that the second address accepts mail; it still cannot prove that the first addressee authorized that delivery.

A safe data model therefore does not store alternate_address as a harmless string. It stores a claim with a principal, issuer, scope, creation event, review time and revocation path. If that evidence is missing, the system has discovered an unverified candidate, not an identity-preserving fallback.

The incapable hop was not the right authority

RFC 5504 showed how consequential the choice could become. When downgrading an SMTP envelope, it replaced a non-ASCII path with the decoded ALT-ADDRESS. If the domain of the alternate differed, the current SMTP connection might no longer be appropriate. The downgrading agent had to resolve and route toward the new domain.

At that moment the operation crossed two boundaries. It changed the mailbox identifier, then potentially changed the administrative domain responsible for delivery. Yet the trigger was not a fresh instruction from the sender or recipient. It was an observation about a downstream server: this hop does not advertise the experimental capability.

Capability is legitimate evidence for choosing a transport operation. It is poor authority for choosing a person.

The distinction matters because the relay is positioned to observe a technical constraint, not to establish identity equivalence. It can know that the original form cannot pass. It may know that an alternate string accompanied the transaction. It cannot infer, from those facts alone, that delivery to the alternate preserves the sender's intention.

The least dangerous responses are narrower. Retry through a capable route. Return a visible failure. Ask an authoritative submission system to apply a previously verified mapping. Do not let a middlebox turn its own limitation into power to redefine the recipient.

Preservation metadata was evidence with holes

The downgrade design tried to preserve what it changed. Downgraded-* header fields could retain original envelope or header information while the traditional fields became ASCII-only. That was useful provenance. It was not a cure.

First, the preserved field described a transformation; it did not authenticate the binding that justified it. An observer could see that address A had become address B and still have no proof that A's owner authorized B.

Second, RFC 5504 had to limit preservation. When one SMTP transaction targeted multiple recipients, adding each original recipient to a Downgraded-Rcpt-To header could disclose addresses to the other recipients. The procedure therefore prohibited that header in the multi-recipient case. Privacy protection was correct, but it meant the audit trail could vary with transaction shape.

Third, the new fields created their own trust problem. A malicious actor could insert something that looked like downgrade provenance. Some transformations lost information, and perfect reconstruction was not always possible. Signatures could also be affected because rewriting headers changes the material over which integrity mechanisms operate.

The evidence hierarchy must remain explicit. A Downgraded-* field can be evidence that a message reports a transformation. It is not automatically trusted evidence that the transformation occurred, that the mapping was authentic, that the new destination belonged to the same person, or that the message was delivered.

A green delivery result could hide a red identity result

Suppose the ASCII fallback accepts the message. The final MTA returns success. A monitoring system records delivered=true. From the transport layer's perspective, that may be accurate. From the sender's perspective, the important question remains unanswered: delivered to whom?

This is where compatibility metrics become dangerous. Bounce avoidance is easy to count. Recipient continuity is harder. A product team may celebrate a higher acceptance rate while silently moving messages from an internationalized mailbox into a shared legacy inbox, an abandoned alias, an assistant's queue or an address reassigned to another employee.

The better operational record carries a chain rather than one badge:

  1. original envelope recipient;
  2. capability observed at the blocking hop;
  3. actor and policy that authorized any transformation;
  4. exact alternate selected;
  5. authenticated evidence binding the two addresses;
  6. route and destination domain after substitution;
  7. SMTP acceptance receipt;
  8. mailbox delivery or application outcome, where available.

Failure at one layer must not be repainted as success by a later layer. A message accepted at address B does not prove that delivery to address A succeeded.

The experiment ended by removing the bridge

RFC 5335 was published as Experimental in 2008. RFC 6532 replaced it on the Standards Track in 2012. The change was not a tidy renaming of UTF8SMTP to SMTPUTF8. The architecture changed.

RFC 6530's review of the experiment says the earlier family permitted—and effectively required—non-ASCII addresses to be accompanied by all-ASCII equivalents for in-transit downgrading. The address pairs could not be authenticated. Initial implementations had interoperability problems. The combined requirements and long-term implications were too complex to be satisfactory.

The standards-track design removed in-transit downgrading. RFC 6532 describes native end-to-end UTF-8 headers in an 8-bit-clean environment assured by the transport system. It does not promise that a legacy 7-bit route can be crossed by quietly selecting another address. Unsupported infrastructure requires other handling; the specification does not manufacture equivalence.

That retreat is an engineering result, not an embarrassment. Experiments are useful when they expose which elegant abstractions fail under operational pressure. Here the abstraction was “equivalent ASCII address.” Once the system had to authenticate the pair, preserve provenance, protect multi-recipient privacy, survive signatures, route changed domains and interoperate with diverse software, the word equivalent carried more weight than the mechanism could bear.

The durable lesson is about bounded authority

Modern systems still face the same temptation even when they never implement RFC 5335. Identity platforms keep recovery emails. Messaging products hold aliases. Customer databases contain preferred and legacy addresses. Transliteration tools generate ASCII forms. Migration projects redirect one namespace into another.

Each can repeat the experimental mistake: because two identifiers are stored together, software assumes either may stand in for the same person under operational pressure.

The safe rule is stricter. Association is not equivalence. Equivalence is not authorization. Authorization is not delivery. A system may use a fallback only within the scope for which the responsible principal approved it, and it must preserve evidence of that approval alongside the actual substitution.

Sometimes visible failure is the more faithful result. A bounce says the intended address could not be carried on the available path. Silent delivery to an unverified alternate says success while changing the subject of the transaction. Reliability that preserves the wrong principal is not continuity; it is a misdelivery with a good uptime graph.

Sources