Email could have been X.400 times better

>> SMTP "“didn’t win because it was ‘better,’” he argued, but “just because it was easier to implement."

Yes - and this is actually really important! It's true of most of the important early internet technologies. It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, while internet standards let individual decentralized admins hook their sites together.

Did any of the ITU standards win? In the end, internet swallowed telephones and everything is now VOIP. I think the last of the X standards left is X509?

I still think the missing opportunity with e-mail was for the USPS (back in the US-dominant internet days) to take a leading role and implement "e-stamps." Provide a subscription service that managed a per-user account, cost a 1¢ stamp to send a message, and guaranteed delivery of messages received with a 1¢ stamp on them -- with the received stamp value being put in the user's account, so a user who received more mail than they sent would never spend a penny. (Messages received from other services could be rejected, delivered, or binned for later inspection at the user's discretion.) This would have the obvious downside of centralizing a major early-Internet feature (although federation is certainly possible as well), but it would have the upside of penalizing companies sending millions of e-mails, but not users using it for person-to-person communication, or companies using it for per-(valuable)-customer communication. We could have had a world without spam… and if USPS took 10% off the top (0.9¢ of each incoming message given to the user account), or similar, I could imagine it having a big impact on their budgetary issues.

An article from Microsoft Systems Journal in 1993 ends with a bunch of different electronic mail addresses:

https://jacobfilipp.com/MSJ/1993-vol8/qawindows.pdf

By 1995, the “Internet” e-mail address was the only remaining one.

> If the history of email had gone somewhat differently, the last email you sent could have been rescinded or superseded by a newer version when you accidentally wrote the wrong thing. It could have auto-destructed if not read by midnight.

Immutability is one of the best things about email.

> C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand; G=harald

that would be very annoying way to write e-mail and no less prone to typosquatting (if anything, more)

Both standards lacked hindsight we have today but x.400 would just be added complexity (as years of tacked-on extensions would build upon it) that makes non-error-prone parsing harder

SMTP won because it was simpler, but it's probably good to look at why it was simpler.

SMTP handled routing by piggybacking on DNS. When an email arrives the SMTP server looks at the domain part of the address, does a query, and then attempts transfer it to the results of that query.

Very simple. And, it turns out, immensely scalable.

You don't need to maintain any routing information unless you're overriding DNS for some reason - perhaps an internal secure mail transfer method between companies that are close partners, or are in a merger process.

By contrast X.400 requires your mail infrastructure to have defined routes for other organisations. No route? No transfer.

I remember setting up X.400 connectors for both Lotus Notes/Domino and for Microsoft Exchange in the mid to late 90s, but I didn't do it very often - because SMTP took over incredibly quickly.

An X.400 infrastructure would gain new routes slowly and methodically. That was a barrier to expanding the use of email.

Often X.400 was just a temporary patch during a mail migration - you'd create an artificial split in the X.400 infrastructure between the two mail systems, with the old product on one side and the new target platform on the other. That would allow you to route mails within the same organisation whilst you were in the migration period. You got rid of that the very moment your last mailbox was moved, as it was often a fragile thing...

The only thing worse than X.400 for email was the "workgroup" level of mail servers like MS Mail/cc:Mail. If I recall correctly they could sometimes be set up so your email address was effectively a list of hops on the route. This was because there was no centralised infrastructure to speak of - every mail server was just its own little island. It might have connections to other mail servers, but there was no overarching directory or configuration infrastructure shared by all servers.

If that was the case then your email address would be "johnsmith @ hop1 @ hop2 @ hop3" on one mail server, but for someone on the mail server at hop1 your email address would be "johnsmith @ hop2 @ hop3", and so on. It was an absolute nightmare for big companies, and one of the many reasons that those products were killed off in favour of their bigger siblings.

Yes, messaging apps like WhatsApp have some very desirable features that are missing in e-mail.

I wish someone would write some RFCs and e-mail could get an update.

> The ugly addressing? It “provides solutions to certain problems and is ugly for good reason,” Betanov explains. “Make it less ugly, and it immediately loses functionality. Thus, the solution is not to make addressing nicer, but to hide it from the user,” something both internet email and X.400-powered software could easily do with headers, not so much with addresses.

Reminds me of IPv6. ;)

My first job at college was wrangling campus email, both X.400 and SMTP. As the article points out, SMTP won out because it was simple and developed in the open, not buried in standards committees, and SMTP code was widely available. It was the Cathedral and the Bazaar hypothesis playing out in real time.

Just seeing that X.400 notation is giving me bad memories!

wow, how to romanticize X.400 ...

- poor Internet fit, assuming managed, trusted networks - some promises depended on all participating systems behaving honestly

- once a message reaches another server, you cannot guarantee it isn't copied, backed up, or logged

- X.400 read receipts: more reliable but also more privacy invasive

- X.400 metadata: carries a lot of routing, classification, and organizational info leading to potential privacy leaks

- SMTP is ugly but observable, you don't need a standard specialist to debug issues

X.400 is still in use today for things like sending invoices and orders through EDI.

Yes, it is a pain to manage. Yes, it is all still mostly running on 20+-year-old hardware and software.

It is slightly ironic that the main way we communicate X.400 addresses between parties is through modern email.

For anyone wondering about the rest of the X standards, they're at: https://www.itu.int/itu-t/recommendations/index.aspx?ser=X

For example from 2023: X.1095: Entity authentication service for pet animals using telebiometrics

My first business card when I was working for a tech company had an X.400 address on it. Nobody was memorising that. Or writing it down quickly.

This is an example of how simplicity won over features.

Not even then, when people with access to computers were probably in the thousands, would anyone liked to type "C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand; G=harald" just like in the example of the article.

Working, free implementations are better than perfect specification barelly supported only incompletely by closed, expensive implementations.

Argh. That red book. I may still have my copy around, somewhere.

X.400 was an “all things, to all men” solution; kinda like TIFF, for images.

I worked on an X.400 product, that never got out of the crib.

You could do things like specify the route that the email took, which was important, because there was support for microtransactions, all along the way. You could do things like pay extra for “premium delivery,” and “registered”-like messages.

It was really crazy. It did work, though.

The issue with specs like that, however, is they only ever get partially implemented. If you have an infrastructure, composed of many partial steps, it can be a mess.

“If the history of email had gone somewhat differently, the last email you sent could have been rescinded or superseded by a newer version when you accidentally wrote the wrong thing. It could have been scheduled to arrive an hour from now. It could have auto-destructed if not read by midnight.”

That would have required a lot of changes to computing history beyond simply email, and I doubt many of them would have been improvements.

Having PP flashbacks right now.. You weren't there man... you don't know!

The X.400 world would have had different spam economics because metered usage by your telco (who would be acting as a "Value Added Network" provider and delivering your X.400 mail) would likely have been the norm. As other comments have pointed out, this is still A Thing today with X.400 VANs being used for EDI.

More like X.400 times convoluted

Gall's Law:

"A complex system that works is invariably found to have evolved from a simple system that worked."

https://lawsofsoftwareengineering.com/laws/galls-law/

In my naive youth I always thought top-down design was the sensible way to build systems. But after witnessing so many of them fail miserably, I now agree with Gall.

> You could have been notified when the message was read a full 15 years before email had something similar tacked on.

Thanks to email security scanners this feature is largely broken.

And so are single click to unsubscribe links. So much so that we have to put our unsubscribe page behind a captcha.

rant over

i once did a contract for a company that built a product around connectors for legacy lan e-mail products and an x.400 mta. it was a gigantic steaming pile of shit and made me appreciate the simple internet protocols so much more than i already did.