17 ms·

Email could have been X.400 times better

239 points by maguay 5mo ago

jgalt212 5mo ago
> 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
- hilariously 5mo ago
  Not trying to be rude, but If you put your unsubscribe page behind a captcha I am going to mark you as spam and move on.
  - AdamN 5mo ago
    I don't unsubsubscribe unless I explicitly subscribed in the past. If I did not subscribe in the first place then it's spam (exception for small businesses who may not know better in which case I'll delete or unsubscribe).
    - sam_lowry_ 5mo ago
      There are unsubscribe headers that are used by mail user agents like mutt to unsubscribe from mailing list managers like mailman. These are "scanner-proof" so far but support in clients like Outlook or Gmail is non-existent.
      - chuckadams 5mo ago
        Gmail not only understands the List-Unsubscribe header, it requires it for bulk deliverability.
    - kstrauser 5mo ago
      I'll try unsubscribing once if it looks like a legitimate org, like someone I actually did business with but didn't expect them to email me. After that, it's going to the junk box to train the server what spam looks like.
- trollbridge 5mo ago
  No, it’s largely broken because of spam. I don’t want to be signed up to your useless email marketing list, and I want to use an email client that makes unsubscribing as easy as possible.
  - jgalt212 5mo ago
    > I don’t want to be signed up to your useless email marketing list, useless is in the eye of the beholder.
    - dpark 5mo ago
      If I didn’t specifically opt in to receiving marketing emails (and no, failing to opt out is not the same), they are spam. I’ve never heard anyone say “I’m sure glad this company added me to their email list without my request.” The fact that you happen to work on a mailing list product does not change that reality.
      - jgalt212 5mo ago
        I hear what you're saying, but irrespective of how one landed on such a list, the unsubscribe mechanism is broken. e.g. It's entirely possible and likely you've subscribed to one or more marketing lists, newsletters, transaction emails, etc that you want to be on, but your security software inadvertently unsubscribed you (without your permission).
        dpark 5mo ago
        I think this is extremely unlikely. Firstly because I almost never subscribe to newsletters or marketing lists. But also because I don’t believe my security software is submitting POSTs on random forms it finds links to. That would be insane behavior. I can believe someone, somewhere has insane security software that does stuff like that. But I don’t believe it’s common.
        AnimalMuppet 5mo ago
        That I want to be on? No. What usually happens is that I give my email to somebody (an auto repair place, say), for one-time use, and they add me to their marketing mailing list, even though that is not what I gave them my email for. That is not a list that I want to be on and willingly subscribed to.
- cap11235 5mo ago
  If I cannot just click a button and unsubscribe, guess what, you are malicious spam.
  - bombcar 5mo ago
    And if you can't figure out how to make an unsubscribe page that doesn't require a captcha (and is triggered by email scanners) you are incompetent. Claude can figure it out.
    - sam_lowry_ 5mo ago
      > and is triggered by email scanners Did you mean "and is NOT triggered by email scanners"? AFAIU, "email scanners" get more aggressive over time, so there is no once-and-forever solution. I guess AI-enabled email scanners can attempt to solve captchas as well.
      - bombcar 5mo ago
        I mean if your unsubscribe link unsubscribes someone just because Microsoft Email Phishing for Copilot visited the link to see if it was a Virus, then you need to “get gud” as the kids say.
        sam_lowry_ 5mo ago
        The fault lies with Microsoft Email Phishing for Copilot or with the European Commission.
      - lxgr 5mo ago
        Yeah, use `List-Unsubscribe`. Has the additional advantage that I don't need to find the "unsubscribe" link at the bottom of some bloaty HTML, works across languages etc. If the email scanner of your recipient insists on clicking "unsubscribe" on their behalf without that being the desired outcome, that's not on you to prevent them from.
    - jgalt212 5mo ago
- xnx 5mo ago
  > Thanks to email security scanners this feature is largely broken. One person's feature is another's anti-feature. I'm glad it's dead.
- throw0101d 5mo ago
  > You could have been notified when the message was read a full 15 years before email had something similar tacked on. Which spammers and marketers would have loved. I have "load remote content" disabled on my e-mail client so that tracking graphics/pixels do not leak such information to the sender.
  - jgalt212 5mo ago
    > I have "load remote content" disabled on my e-mail client so that tracking graphics/pixels do not leak such information to the sender. Often times that's meaningless as email scanner software will load and inspect all links and images regardless of the human's email client preferences. It basically comes down to can Constant Contact, or similar, detect if a link was clicked by security software or an actual human. And security software wants to look like an actual human because if security software looks like security software it's very easy for bad actors to serve safe payloads to security software and malware payloads to human actors.
- WhyNotHugo 5mo ago
  I think you're referring to things like tracking pixels, whereas the author was likely referring to _actual_ email read receipts, where the sender can request a read receipt, and the receiver's MUA will prompt them to send one.
  - jgalt212 5mo ago
    Yes, same feature, different implementations.
- PunchyHamster 5mo ago
  waiting for inevitable "gmail bad, why it spams my emails so much" rant
- dpark 5mo ago
  Are you saying that email scanners were not only fetching the unsubscribe link but also submitting the “unsubscribe” button/form on the page? I find this hard to believe since everyone else seems to manage this without a Captcha.
  - yencabulator 5mo ago
    I does sound like they made a HTTP GET request have side effects.
    - dpark 5mo ago
      I suspect that’s exactly what they did. And then they “solved” it with a Captcha. Conveniently I bet human unsubscribes also dropped when that was instituted.
- lxgr 5mo ago
  > we have to put our unsubscribe page behind a captcha. Hope you're not ever sending email to EU residents! Have you ever heard of `List-Unsubscribe`? It solves your problem without massively annoying people and breaking accessibility and/or the law.
PunchyHamster 5mo ago
> 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
- msla 5mo ago
  Plus, having to change email addresses when you physically move, in addition to when you change providers, would be immensely annoying.
- giantrobot 5mo ago
  Ah but the solution was an X.500 directory where you just look up the recipient! So you never type the e-mail address, you just look up "Joe Smith" to send them an e-mail. Like looking them up in the phone book. Ignore the fact that the directory may return multiple Joe Smiths at the same large organization, not return Joe Smyth you wanted to message, or that there's not even a hint of anonymity with such directories. Oh yeah the internal organization of a company could be easily enumerated from the outside.
  - mystraline 5mo ago
    But theres a reason why "White Pages" of peoples' phone number books are gone. Its the same reason why fingerd isnt run. And why the LDAP for an org isnt exposed. You do not give information of all your users to the public/enemy. Its the cybersecurity "principle of least privilege" and need to know.
ExoticPearTree 5mo ago
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.
- rjsw 5mo ago
  You were not supposed to type it out, you looked it up using your X.500 directory.
  - bombcar 5mo ago
    All we need is an x.500 directory of all addresses in the world, which won't be abused by anyone at anytime!
    - slackfan 5mo ago
      However did we live during the era of the White Pages phone directory.
      - bombcar 5mo ago
        Spam and scam had to work on a human scale, via locals paid something resembling a living wage, not automated machines sending millions a second or people working for pennies a day. I want a phone that can only ring if the source of the call is within artillery range.
      - toast0 5mo ago
        Sure, but then you have the problem of figuring out which Sarah Connor in Los Angeles. To say nothing of popular names.
        aworks 5mo ago
        My name is not particularly common although I was the first to claim firstname.lastname@gmail.com. I've been getting email intended for other people with the same name for decades. I've seen estimates that there are only 10,000 people with my last name in the US. Back in the days of local telephone directories, I was always the only one with that last name. Internet scaling is an interesting thing. I don't know if I feel less unique or that I'm in an exclusive club.
gadders 5mo ago
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.
elzbardico 5mo ago
Working, free implementations are better than perfect specification barelly supported only incompletely by closed, expensive implementations.
pjc50 5mo ago
>> 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?
- SV_BubbleTime 5mo ago
  As x509 goes. I doubt many could explain it off hand with BER, DER and others being subset to ASN.1 and other obscura. I’ve never been a fan
- ghaff 5mo ago
  And you could add any number of the big standards group-based standards that a great deal of blood, sweat, and tears were poured into. Not universally the case, but more true than false.
- MisterTea 5mo ago
  > 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 deterministic network of pipes. You called a computer as if it were a telephone (or maybe that was Datakit?) and ATM handed the user a byte stream like TCP. Imagine never needing an IP stack or setting traffic priority because the network already handles the QoS. Was it simple to deploy? No. Was it cheap? Nooohooohooohooo. Was Ethernet any of those? YES AND YES. ATM was superior but lost to the simpler and cheaper Ethernet which was pretty crappy in its early days (thinnet, thicknet, terminators, vampire taps, AUI, etc.) but good enough. The funny part is this has the unintended consequences of needing to reinvent the wheel once you get to the point where you need telecom sized/like infrastructure. Ethernet had to adapt to deterministic real-time needs so various hacks and standards have been developed to paper over these deficiencies which is what TSN is - reinventing ATM's determinism. In addition we also now have OTN, yet another protocol to further paper over the various other protocols to mux everything down a big fat pipe to the other end which allows Ethernet (and IP/ATM/etc) to ride deterministically between data-centers.
throwaway_ocr 5mo ago
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.
- roryirvine 5mo ago
  Is that actually true today? When I was doing EDI stuff ~20 years ago, it was mostly done using FTP, with some forward-thinking orgs moving to SFTP or (HTTPS-based) AS2. I see that Wikipedia claims that "X.400 is quite widely implemented[citation needed], especially for EDI services", and that might once have been the case - but I doubt it was particularly widespread even at the time that article was first written. It's worth noting that that [citation needed] tag dates from October 2008!
philipstorry 5mo ago
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.
- rogerbinns 5mo ago
  > ... why it was simpler. In the early 90s I implemented a gateway between Novell email and X.400. What amused me the most was X.400 specified an exclusive enumerated list of reasons why email couldn't be delivered, including "recipient is dead". At the X.400 protocol level this was a binary number. SMTP uses a 3 digit number for general category, followed by a free form line of text. Many other Internet standards including HTTP use the same pattern. It was already obvious at the time that the X.400 field was insufficient, yet also impractical for mail administrators to ensure was complete and correct. That was the underlying problem with the X.400 and similar where they covered everything in advance as part of the spec, while Internet standards were more pragmatic.
computersuck 5mo ago
More like X.400 times convoluted
a-dub 5mo ago
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.
jerjerjer 5mo ago
> 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.
- silon42 5mo ago
  Certainly it should be immutable if read.
- Gigachad 5mo ago
  As a platform for sending invoices and official communications it’s fine. As a way for people to talk with each other it sucks. These days I’m of the opinion that most messaging should just be auto deleted after a month. If there’s something particularly important you want to keep, note it down. Otherwise just let it be forgotten.
- dbbk 5mo ago
  Boy do I have news for you https://amp.dev/about/email https://amp.dev/about/email
EvanAnderson 5mo ago
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.
dreamcompiler 5mo ago
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/ 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.
- beng-nl 5mo ago
  Well said. And similarly, it always seems to be the simple, bottom up, “let’s just build something simple and minimal that works” projects that get iterated on that do can do well, and start to strain when the technical debt and complexity accumulate.
cwillu 5mo ago
“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.
fulafel 5mo ago
For anyone wondering about the rest of the X standards, they're at: https://www.itu.int/itu-t/recommendations/index.aspx?ser=X 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
ogurechny 5mo ago
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 https://jacobfilipp.com/MSJ/1993-vol8/qawindows.pdf By 1995, the “Internet” e-mail address was the only remaining one.
- SllX 5mo ago
  1993 "socials".
- tengwar2 5mo ago
  Just looking back, we were using the hybrid ".uucp" pseudo domain in 1995, e.g. see the contact details for the third author on this papes: https://www.researchgate.net/publication/2291331_Beyond_Hacking_a_Model_Based_Approach_to_User_Interface_Design https://www.researchgate.net/publication/2291331_Beyond_Hack... (not me, a colleague). For those who don't recognise this, .uucp was an unofficial "TLD" used for UUCP-based email systems accessible via an Internet relay by a dial-up modem. The relay would rewrite jlc@bmtech.uucp to bmtech!jlc, a short UUCP bang-path email address.
- ButlerianJihad 5mo ago
  In 1995, I had an AIM screen name, an ICQ UIN, a Jabber thing, which we began consolidating in Pidgin, and my girlfriend was experimenting with Cu-SeeMe and some kind of “microblog” twit thing. You could also reach us by knowing our character names on certain MUDs, which implemented a spectrum of “real time IM” to “leave a message with the bot” to “virtual room full of mailboxes which are also rooms and contain objects that are notes”. I didn’t really use IRC, but everyone else did.
- Tor3 5mo ago
  I used to have a book laying around - it had, or tried to have, all the email addresses in my country. Like a phonebook for email addresses. That approach didn't last long.
foresto 5mo ago
> 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. ;)
pnw 5mo ago
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!
sinnickal 5mo ago
Having PP flashbacks right now.. You weren't there man... you don't know!
addaon 5mo ago
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.
- TZubiri 5mo ago
  Have you heard about hashcash? They propose a novel similar mechanism for postage for email with some interesting theoretical consequences.
- halJordan 5mo ago
  The physical usps works because, the usps controls every inbox and every outbox; everyone has to have an inbox/outbox with the single carrier, and no one can actually reject or refuse mail. All the downsides of iMessage but the government reading your email bc it's not an encrypted protocol. Spam exists in the real world, this wouldn't have worked either
  - addaon 5mo ago
    > 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%…
    - 5mo ago
thund 5mo ago
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
- grandinj 5mo ago
  Yeah, as someone who had to implement a protocol stack to talk to a X.400 server, it was not fun at all. Weird encodings, monster spec, all sorts of weird server-specific stuff that you had to do exactly right if you wanted the server to accept your email. Compared to that, when I implemented RFC821/822 (i.e. SMTP) mail, the hardest part was the weird line-encodings, but other than that, the spec was ___so___ nicely readable and pragmatic.
- bigfatkitten 5mo ago
  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.
ChrisMarshallNY 5mo ago
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.
amelius 5mo ago
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.
splootie 5mo ago
Did anyone remember that X.400 providers typically charged a fee per message?
upofadown 5mo ago
>Encryption would have been baked in from the start, rather than waiting for PGP, S/MIME, and TLS to add them later. This comment intrigued me so I did a tiny bit of research. It appears that X.400 uses S/MIME for encryption (see RFC-3854). Alternatively something called STANAG 4406 which provides some sort of centralized control of who sees what for military applications. Neither seems to be "baked in from the start".
saasoffers 5mo ago
[dead]
simonebrunozzi 5mo ago
Reminds me of Token Ring vs Ethernet. Token Ring was arguably superior, but Ethernet was cheaper to license, and over time more investment went into Ethernet and eventually Ethernet won.
1o1o1o1o1 5mo ago
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.

239 points by maguay 5mo ago

> 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

hilariously 5mo ago
Not trying to be rude, but If you put your unsubscribe page behind a captcha I am going to mark you as spam and move on.
- AdamN 5mo ago
  I don't unsubsubscribe unless I explicitly subscribed in the past. If I did not subscribe in the first place then it's spam (exception for small businesses who may not know better in which case I'll delete or unsubscribe).
  - sam_lowry_ 5mo ago
    There are unsubscribe headers that are used by mail user agents like mutt to unsubscribe from mailing list managers like mailman. These are "scanner-proof" so far but support in clients like Outlook or Gmail is non-existent.
    - chuckadams 5mo ago
      Gmail not only understands the List-Unsubscribe header, it requires it for bulk deliverability.
  - kstrauser 5mo ago
    I'll try unsubscribing once if it looks like a legitimate org, like someone I actually did business with but didn't expect them to email me. After that, it's going to the junk box to train the server what spam looks like.
trollbridge 5mo ago
No, it’s largely broken because of spam. I don’t want to be signed up to your useless email marketing list, and I want to use an email client that makes unsubscribing as easy as possible.
- jgalt212 5mo ago
  > I don’t want to be signed up to your useless email marketing list, useless is in the eye of the beholder.
  - dpark 5mo ago
    If I didn’t specifically opt in to receiving marketing emails (and no, failing to opt out is not the same), they are spam. I’ve never heard anyone say “I’m sure glad this company added me to their email list without my request.” The fact that you happen to work on a mailing list product does not change that reality.
    - jgalt212 5mo ago
      I hear what you're saying, but irrespective of how one landed on such a list, the unsubscribe mechanism is broken. e.g. It's entirely possible and likely you've subscribed to one or more marketing lists, newsletters, transaction emails, etc that you want to be on, but your security software inadvertently unsubscribed you (without your permission).
      - dpark 5mo ago
        I think this is extremely unlikely. Firstly because I almost never subscribe to newsletters or marketing lists. But also because I don’t believe my security software is submitting POSTs on random forms it finds links to. That would be insane behavior. I can believe someone, somewhere has insane security software that does stuff like that. But I don’t believe it’s common.
      - AnimalMuppet 5mo ago
        That I want to be on? No. What usually happens is that I give my email to somebody (an auto repair place, say), for one-time use, and they add me to their marketing mailing list, even though that is not what I gave them my email for. That is not a list that I want to be on and willingly subscribed to.
cap11235 5mo ago
If I cannot just click a button and unsubscribe, guess what, you are malicious spam.
- bombcar 5mo ago
  And if you can't figure out how to make an unsubscribe page that doesn't require a captcha (and is triggered by email scanners) you are incompetent. Claude can figure it out.
  - sam_lowry_ 5mo ago
    > and is triggered by email scanners Did you mean "and is NOT triggered by email scanners"? AFAIU, "email scanners" get more aggressive over time, so there is no once-and-forever solution. I guess AI-enabled email scanners can attempt to solve captchas as well.
    - bombcar 5mo ago
      I mean if your unsubscribe link unsubscribes someone just because Microsoft Email Phishing for Copilot visited the link to see if it was a Virus, then you need to “get gud” as the kids say.
      - sam_lowry_ 5mo ago
        The fault lies with Microsoft Email Phishing for Copilot or with the European Commission.
    - lxgr 5mo ago
      Yeah, use `List-Unsubscribe`. Has the additional advantage that I don't need to find the "unsubscribe" link at the bottom of some bloaty HTML, works across languages etc. If the email scanner of your recipient insists on clicking "unsubscribe" on their behalf without that being the desired outcome, that's not on you to prevent them from.
  - jgalt212 5mo ago
xnx 5mo ago
> Thanks to email security scanners this feature is largely broken. One person's feature is another's anti-feature. I'm glad it's dead.
throw0101d 5mo ago
> You could have been notified when the message was read a full 15 years before email had something similar tacked on. Which spammers and marketers would have loved. I have "load remote content" disabled on my e-mail client so that tracking graphics/pixels do not leak such information to the sender.
- jgalt212 5mo ago
  > I have "load remote content" disabled on my e-mail client so that tracking graphics/pixels do not leak such information to the sender. Often times that's meaningless as email scanner software will load and inspect all links and images regardless of the human's email client preferences. It basically comes down to can Constant Contact, or similar, detect if a link was clicked by security software or an actual human. And security software wants to look like an actual human because if security software looks like security software it's very easy for bad actors to serve safe payloads to security software and malware payloads to human actors.
WhyNotHugo 5mo ago
I think you're referring to things like tracking pixels, whereas the author was likely referring to _actual_ email read receipts, where the sender can request a read receipt, and the receiver's MUA will prompt them to send one.
- jgalt212 5mo ago
  Yes, same feature, different implementations.
PunchyHamster 5mo ago
waiting for inevitable "gmail bad, why it spams my emails so much" rant
dpark 5mo ago
Are you saying that email scanners were not only fetching the unsubscribe link but also submitting the “unsubscribe” button/form on the page? I find this hard to believe since everyone else seems to manage this without a Captcha.
- yencabulator 5mo ago
  I does sound like they made a HTTP GET request have side effects.
  - dpark 5mo ago
    I suspect that’s exactly what they did. And then they “solved” it with a Captcha. Conveniently I bet human unsubscribes also dropped when that was instituted.
lxgr 5mo ago
> we have to put our unsubscribe page behind a captcha. Hope you're not ever sending email to EU residents! Have you ever heard of `List-Unsubscribe`? It solves your problem without massively annoying people and breaking accessibility and/or the law.

PunchyHamster 5mo ago

> 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

msla 5mo ago
Plus, having to change email addresses when you physically move, in addition to when you change providers, would be immensely annoying.
giantrobot 5mo ago
Ah but the solution was an X.500 directory where you just look up the recipient! So you never type the e-mail address, you just look up "Joe Smith" to send them an e-mail. Like looking them up in the phone book. Ignore the fact that the directory may return multiple Joe Smiths at the same large organization, not return Joe Smyth you wanted to message, or that there's not even a hint of anonymity with such directories. Oh yeah the internal organization of a company could be easily enumerated from the outside.
- mystraline 5mo ago
  But theres a reason why "White Pages" of peoples' phone number books are gone. Its the same reason why fingerd isnt run. And why the LDAP for an org isnt exposed. You do not give information of all your users to the public/enemy. Its the cybersecurity "principle of least privilege" and need to know.

ExoticPearTree 5mo ago

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.

rjsw 5mo ago
You were not supposed to type it out, you looked it up using your X.500 directory.
- bombcar 5mo ago
  All we need is an x.500 directory of all addresses in the world, which won't be abused by anyone at anytime!
  - slackfan 5mo ago
    However did we live during the era of the White Pages phone directory.
    - bombcar 5mo ago
      Spam and scam had to work on a human scale, via locals paid something resembling a living wage, not automated machines sending millions a second or people working for pennies a day. I want a phone that can only ring if the source of the call is within artillery range.
    - toast0 5mo ago
      Sure, but then you have the problem of figuring out which Sarah Connor in Los Angeles. To say nothing of popular names.
      - aworks 5mo ago
        My name is not particularly common although I was the first to claim firstname.lastname@gmail.com. I've been getting email intended for other people with the same name for decades. I've seen estimates that there are only 10,000 people with my last name in the US. Back in the days of local telephone directories, I was always the only one with that last name. Internet scaling is an interesting thing. I don't know if I feel less unique or that I'm in an exclusive club.

gadders 5mo ago

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.

elzbardico 5mo ago

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

pjc50 5mo ago

>> 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?

SV_BubbleTime 5mo ago
As x509 goes. I doubt many could explain it off hand with BER, DER and others being subset to ASN.1 and other obscura. I’ve never been a fan
ghaff 5mo ago
And you could add any number of the big standards group-based standards that a great deal of blood, sweat, and tears were poured into. Not universally the case, but more true than false.
MisterTea 5mo ago
> 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 deterministic network of pipes. You called a computer as if it were a telephone (or maybe that was Datakit?) and ATM handed the user a byte stream like TCP. Imagine never needing an IP stack or setting traffic priority because the network already handles the QoS. Was it simple to deploy? No. Was it cheap? Nooohooohooohooo. Was Ethernet any of those? YES AND YES. ATM was superior but lost to the simpler and cheaper Ethernet which was pretty crappy in its early days (thinnet, thicknet, terminators, vampire taps, AUI, etc.) but good enough. The funny part is this has the unintended consequences of needing to reinvent the wheel once you get to the point where you need telecom sized/like infrastructure. Ethernet had to adapt to deterministic real-time needs so various hacks and standards have been developed to paper over these deficiencies which is what TSN is - reinventing ATM's determinism. In addition we also now have OTN, yet another protocol to further paper over the various other protocols to mux everything down a big fat pipe to the other end which allows Ethernet (and IP/ATM/etc) to ride deterministically between data-centers.

throwaway_ocr 5mo ago

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.

roryirvine 5mo ago
Is that actually true today? When I was doing EDI stuff ~20 years ago, it was mostly done using FTP, with some forward-thinking orgs moving to SFTP or (HTTPS-based) AS2. I see that Wikipedia claims that "X.400 is quite widely implemented[citation needed], especially for EDI services", and that might once have been the case - but I doubt it was particularly widespread even at the time that article was first written. It's worth noting that that [citation needed] tag dates from October 2008!

philipstorry 5mo ago

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.

rogerbinns 5mo ago
> ... why it was simpler. In the early 90s I implemented a gateway between Novell email and X.400. What amused me the most was X.400 specified an exclusive enumerated list of reasons why email couldn't be delivered, including "recipient is dead". At the X.400 protocol level this was a binary number. SMTP uses a 3 digit number for general category, followed by a free form line of text. Many other Internet standards including HTTP use the same pattern. It was already obvious at the time that the X.400 field was insufficient, yet also impractical for mail administrators to ensure was complete and correct. That was the underlying problem with the X.400 and similar where they covered everything in advance as part of the spec, while Internet standards were more pragmatic.

computersuck 5mo ago

More like X.400 times convoluted

a-dub 5mo ago

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.

jerjerjer 5mo ago

> 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.

silon42 5mo ago
Certainly it should be immutable if read.
Gigachad 5mo ago
As a platform for sending invoices and official communications it’s fine. As a way for people to talk with each other it sucks. These days I’m of the opinion that most messaging should just be auto deleted after a month. If there’s something particularly important you want to keep, note it down. Otherwise just let it be forgotten.
dbbk 5mo ago
Boy do I have news for you https://amp.dev/about/email https://amp.dev/about/email

EvanAnderson 5mo ago

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.

dreamcompiler 5mo ago

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/ 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.

beng-nl 5mo ago
Well said. And similarly, it always seems to be the simple, bottom up, “let’s just build something simple and minimal that works” projects that get iterated on that do can do well, and start to strain when the technical debt and complexity accumulate.

cwillu 5mo ago

“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.

fulafel 5mo ago

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

ogurechny 5mo ago

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 https://jacobfilipp.com/MSJ/1993-vol8/qawindows.pdf By 1995, the “Internet” e-mail address was the only remaining one.

SllX 5mo ago
1993 "socials".
tengwar2 5mo ago
Just looking back, we were using the hybrid ".uucp" pseudo domain in 1995, e.g. see the contact details for the third author on this papes: https://www.researchgate.net/publication/2291331_Beyond_Hacking_a_Model_Based_Approach_to_User_Interface_Design https://www.researchgate.net/publication/2291331_Beyond_Hack... (not me, a colleague). For those who don't recognise this, .uucp was an unofficial "TLD" used for UUCP-based email systems accessible via an Internet relay by a dial-up modem. The relay would rewrite jlc@bmtech.uucp to bmtech!jlc, a short UUCP bang-path email address.
ButlerianJihad 5mo ago
In 1995, I had an AIM screen name, an ICQ UIN, a Jabber thing, which we began consolidating in Pidgin, and my girlfriend was experimenting with Cu-SeeMe and some kind of “microblog” twit thing. You could also reach us by knowing our character names on certain MUDs, which implemented a spectrum of “real time IM” to “leave a message with the bot” to “virtual room full of mailboxes which are also rooms and contain objects that are notes”. I didn’t really use IRC, but everyone else did.
Tor3 5mo ago
I used to have a book laying around - it had, or tried to have, all the email addresses in my country. Like a phonebook for email addresses. That approach didn't last long.

foresto 5mo ago

> 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. ;)

pnw 5mo ago

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!

sinnickal 5mo ago

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

addaon 5mo ago

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.

TZubiri 5mo ago
Have you heard about hashcash? They propose a novel similar mechanism for postage for email with some interesting theoretical consequences.
halJordan 5mo ago
The physical usps works because, the usps controls every inbox and every outbox; everyone has to have an inbox/outbox with the single carrier, and no one can actually reject or refuse mail. All the downsides of iMessage but the government reading your email bc it's not an encrypted protocol. Spam exists in the real world, this wouldn't have worked either
- addaon 5mo ago
  > 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%…
  - 5mo ago

thund 5mo ago

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

grandinj 5mo ago
Yeah, as someone who had to implement a protocol stack to talk to a X.400 server, it was not fun at all. Weird encodings, monster spec, all sorts of weird server-specific stuff that you had to do exactly right if you wanted the server to accept your email. Compared to that, when I implemented RFC821/822 (i.e. SMTP) mail, the hardest part was the weird line-encodings, but other than that, the spec was ___so___ nicely readable and pragmatic.
bigfatkitten 5mo ago
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.

ChrisMarshallNY 5mo ago

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.

amelius 5mo ago

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.

splootie 5mo ago

Did anyone remember that X.400 providers typically charged a fee per message?

upofadown 5mo ago

>Encryption would have been baked in from the start, rather than waiting for PGP, S/MIME, and TLS to add them later. This comment intrigued me so I did a tiny bit of research. It appears that X.400 uses S/MIME for encryption (see RFC-3854). Alternatively something called STANAG 4406 which provides some sort of centralized control of who sees what for military applications. Neither seems to be "baked in from the start".

saasoffers 5mo ago

[dead]

simonebrunozzi 5mo ago

Reminds me of Token Ring vs Ethernet. Token Ring was arguably superior, but Ethernet was cheaper to license, and over time more investment went into Ethernet and eventually Ethernet won.

1o1o1o1o1 5mo ago

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.