X.400 (1984) specified message recall, scheduled delivery, read receipts, and baked-in encryption years before SMTP, but a 266-page prescriptive spec lost to a 68-page implementable one.
Key Takeaways
X.400 prescribed outcomes (“the submission envelope contains the information the MTS requires”); SMTP described exact commands (MAIL, RCPT, DATA) – the difference made SMTP deployable by any sysadmin.
X.400 addresses had six incompatible formatting variants across vendors; SMTP’s user@domain was universally readable without a specialist.
Advanced X.400 features like message recall and permanent deletion were physically unenforceable once a message left a vendor’s walled garden – cross-server guarantees were impossible.
X.400 reached 1 million interconnected mailboxes by 1994, yet vendor implementations were mutually incompatible despite sharing the same spec; the standard failed its own interoperability mission.
Exchange Server was built on X.400 and maintained X.400 gateway connections for years after the standard faded from mainstream use.
Hacker News Comment Review
Commenters converged on SMTP’s DNS-based routing as the decisive technical advantage: no routing tables to maintain, any decentralized admin could hook up a new node, and scalability followed automatically.
There was notable pushback on framing X.400’s mutability features as losses – several commenters argued email immutability is a deliberate strength, not a missing feature.
The broader consensus frames this as a repeating internet-vs-telco pattern: ITU/OSI specs required large coordinated deployments; internet RFCs let individuals ship independently, which compounded faster.
Notable Comments
@throwaway_ocr: X.400 still runs live EDI invoice and order networks today on 20+-year-old hardware; parties exchange X.400 addresses via modern email.
@philipstorry: SMTP’s routing piggybacks on DNS lookups at delivery time, eliminating any need to maintain routing tables – the quiet scalability unlock behind the protocol’s dominance.