Email could have been X.400 times better • Hacker News Board

Re: Email could have been X.400 times better

#191

Post by handoflixue » Sat, Apr 25, 2026, 6:38 PM UTC

pembrook wrote: post #106

addaon wrote: post #99

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 ma…

Not sure it was a big missed opportunity to create a communication protocol that...financially penalizes communication? Sounds like a really fast way to kill a network instead of grow it into a 4B daily active user staple like email is today. You'd basically ensure that email would ONLY be spam, because marketers would be the only ones willing spend money to reach people. Every time I see someone suggest micropayment…

Agreed. In particular, I'd say that most social media relies on highly prolific posters: the people who produce the most content are also naturally the most valuable for making people want to be in-network.

If you charge to read, it's hard to build an audience. If you charge to SEND, there's not going to be anything for the audience in the first place.

Re: Email could have been X.400 times better

#192

Post by rightbyte » Sat, Apr 25, 2026, 6:40 PM UTC

petcat wrote: post #162

addaon wrote: post #120

Earlier quoted context omitted.

> Spam exists in the real world, this wouldn't have worked either. A two-or-more order-of-magnitude reduction in a problem seems like a good start and a worthwhile step, not something to disregard because it's not 100%…

The USPS is paid by spammers to ensure delivery of their physical spam. You doing think they wouldn't have also accepted payment from spammers to ensure delivery of their internet spam?

Physical spam is way way more expensive for the sender than for the receiver.

Re: Email could have been X.400 times better

#193

Post by sheepscreek » Sat, Apr 25, 2026, 7:39 PM UTC

pjc50 wrote: post #14

>> 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 decentralize…

Especially in that age when compute was precious, and scaling horizontally looked nothing like how it does today. This is a time before the Intel 386 which ran at either 16Mhz or 33Mhz :)

So it must have been preferable to reduce the workload per email for the server and client.

Re: Email could have been X.400 times better

#194

Post by tzs » Sat, Apr 25, 2026, 7:40 PM UTC

kstrauser wrote: post #92

convolvatron wrote: post #81

Earlier quoted context omitted.

note that it was 'tolerable latency without echo cancellation in France', most other places had long enough latency anyways that they needed to have it anyways. and of course now everything needs echo cancellation. I think standards are important, and I'm sad that no one bothers anymore, but stuff like this and the inclusion of interlace in digital video for that little 3 year window when it might have mattered does…

I'd forgotten about the French connection here. BTW, I searched Kagi for "tolerable latency without echo cancellation in France" and saw your comment. Wow. I didn't realize web crawlers were that current these days.

LLMs too. A few months ago I posted a comment here in a thread where I speculated on the reasons an old law might have been written the way it was.

A couple hours later I asked Perplexity and the reasons it gave matched my speculation. I then clicked its link to its source--and it was my HN comment.

Re: Email could have been X.400 times better

#195

Post by bigbuppo » Sat, Apr 25, 2026, 7:51 PM UTC

pjc50 wrote: post #25

MisterTea wrote: post #24

Earlier quoted context omitted.

> 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, Anyone remember the promise of ATM networking in the 90's? It was telecom grade networking which used circuit switched networking that would handle voice, video and data down one pipe. Instead of carelessly flinging packets into the ether like an savage, you had a…

> Ethernet had to adapt to deterministic real-time needs Without being able to get too into the telco detail, I think the lesson was that hard realtime is both much harder to achieve and not actually needed . People will happily chat over nondeterministic Zoom and Discord. It's both psychological and slightly paradoxical. Once you let go of saying "the system MUST GUARANTEE this property", you get a much cheaper, bet…

You're thinking about normal end user scenarios. Try doing that in a studio environment or perhaps a live production. Even in my home studio I have to use a dedicated Dante network or normal lan broadcast traffic will ruin the day.

Re: Email could have been X.400 times better

#196

Post by bigbuppo » Sat, Apr 25, 2026, 7:57 PM UTC

rstuart4133 wrote: post #67

pjc50 wrote: post #14

>> 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 decentralize…

Doh! Of course it was easier to implement. IETF wants a working open source implementation before standardising. Have you ever tried to implement an ITU standard from just reading the specs? It's hard. Firstly you have to spend a lot of money just to buy the specs. Then you find the spec is written by somebody who has a proprietary product, and is tiptoeing along a line that reveals enough information to keep the sta…

ITU recommendations are free.

Re: Email could have been X.400 times better

#197

Post by bigfatkitten » Sat, Apr 25, 2026, 10:00 PM UTC

thund wrote: post #124

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 leadin…

For the use cases where it found adoption, such as in air traffic management, formal military messaging, diplomatic cables etc, these are all mostly desirable properties.

Re: Email could have been X.400 times better

#198

Post by 1o1o1o1o1 » Sat, Apr 25, 2026, 10:28 PM UTC

Baking in encryption would have been a terrible idea since encryption gets broken over the years and then you would have to update the entire protocol. Read receipts are an invasion of privacy.

Re: Email could have been X.400 times better

#199

Post by pixl97 » Sat, Apr 25, 2026, 11:09 PM UTC

slackfan wrote: post #31

bombcar wrote: post #15

Earlier quoted context omitted.

All we need is an x.500 directory of all addresses in the world, which won't be abused by anyone at anytime!

However did we live during the era of the White Pages phone directory.

White pages were for a city/phone company area. If you dug up all of them you'd have to have a pretty damned big room. Also, it took a long time to search.

Re: Email could have been X.400 times better

#200

Post by pseudohadamard » Sun, Apr 26, 2026, 4:15 AM UTC

otabdeveloper4 wrote: post #161

pseudohadamard wrote: post #134

Earlier quoted context omitted.

X.500 was stripped down to form LDAP No, LDAP was a student project from UMich that somehow gained mindshare because (a) it wasn't ISO, and (b) it cleverly had an 'L' in front of it. It's now more complex and heavyweight than the original DAP, but people think it isn't because of that original clever bit of marketing.

It's still lightweight. I implemented a working implementation on a literal weekend.

That's certainly possible, you can get a basic implementation that uses it as a database lookup, "search" with baseObject/scope fixed, filter is your search string, return the attribute you want, done without too much effort. In fact a number of early LDAP databases were actually DBMSes underneath, so you take your SQL-style query (select emailAddress where name = "John Doe"), convert it into baseObject/scope/filter/attributes and send it over the wire, the other side converts it back into an SQL query and queries the Ingres database that's doing the actual work, and everyone gets to pat themselves on the back over how well "a bunch of networking types reinventing 1960s database technology" (Marshall Rose, I think) works.

However when you need to implement the whole HDAP protocol, that's when you wish you'd taken up some easier job, like maintaining the bank's COBOL accounting code.