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.
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
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.
>> 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?
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 standards body happy (ie, has enough info to make it worthwhile to purchase the specification), and not revealing the secret sauce in their implementation.
I've done it, and it's an absolute nightmare. The IETF RFCs are a breath of fresh air in comparison. Not only can you read the source, there are example implementations!
And if you think that didn't lead to a better outcome, you're kidding yourself. The ITU process naturally leads to a small number of large engineering orgs publishing just enough information so they can interoperate, while keeping enough hidden so the investment discourages the rise of smaller competitors. The result is, even now I can (and do) run my own email server. If the overly complicated bureaucratic ITU standards had won the day, I'm sure email would have been run by a small number of CompuServe like rent seeking parasites for decades.
> IETF wants a working open source implementation before standardising.
I don't think that's IETF policy. Individual IETF working groups decide whether to request publication of an RFC, and the availability of open source implementations is a strong argument in favour of publication, but not a hard requirement.
If the IETF standards are sometimes useful, it's more a matter of culture than of policy.
I have been told that ITU specifications are deliberately confusing so that they can sell consulting services.
However, I think DER is good (and is better than BER, PER, etc in my opinion). (I did make up a variant with a few additional types, though.)
OID is also a good idea, although I had thought they should add another arc for being based on various kind of other identifiers (telephone numbers, domain names, etc) together with a date for which that identifier is valid (to avoid issues with reassigned identifiers) as well as possibility of automatic delegation for some types (so that e.g. if you register an account on another system then you can get a free OID from it too; there is a bit of difficulty in some cases but it might be possible). (I have written a file about how to do this, although I did not publish it yet.)
It's not so much that SMTP won, it's that X.400 lost because it suuuuucked. Anyone who's ever had to work with that piece of s*t, as opposed to rhapsodising over what it could theoretically do, can tell you stories about this. It made Microsoft Mail and Lotus Notes look good in comparison. Notes actually did X.400, so imagine Notes but even suckier.
X.25 and other ITU specs won out massively in aviation, and they are just recently starting to go through the slow painful process of moving to IP. We'll probably see it hanging around for at least another 15 years in that sector.
LDAP might have won over DAP, but it's still heavily based on the X.500-family of standards. Unlike SMTP (which is a completely different standard), LDAP is strongly based on DAP and other X.500 family standards.
Besides LDAP and X.509, you've got old standards that were very successful for a while. I'm perhaps a little bit too young for this, but I vaguely remember X.25 practically dominated large-scale networking, and for a while inter-network TCP/IP was often run over X.25. X.25 eventually disappeared because it was replaced by newer technology, but it didn't lose to any contemporary standard.
And if you're looking for new technology, CTAP (X.1278) is a part of the WebAuthn standard, which does seem to be winning.
I'm pretty sure there are other X-standards common in the telco industry, but even if we just look at the software industry, some ITU-T standards won out. This is not to say they weren't complex or that we didn't have simpler alternatives, but sometimes the complex standards does win out. The "worse is better" story is not always true.
The OP article is definitely wrong about this:
> “Of all the things OSI has produced, one could point to X.400 as being the most successful,
There are many OSI standards that are more successful than X.400, by the seer virtue of X.400 being an objective failure. But even putting that aside, there are X-family standards that are truly successful and ubiquitous.X.500 and X.509 are strong contenders, but the real winner is ASN.1 (the X.680/690 family, originally X.208/X.209).
ASN.1 is everywhere: It's obviously present in other ITU-T based standards like LDAP, X.509, CTAP and X.400, but it's been widely adopted outside of ITU-T in the cryptography world. PKCS standards (used for RSA, DSA, ECDSA, DH and ECDH key storage and signatures), Kerberos, S/MIME, TLS. It's also common in some common non-cryptographic protocols like SNMP and EMV (chip and pin and contactless payment for credit cards). Even if your using JOSE or COSE or SSH (which are not based on ASN.1), ASN.1-based PKCS standards are often still used for storing the keys. And this is completely ignoring all the telco standards. ASN.1 is everywhere.
The rivalry continues in the fibre era, with ITU's GPON and successors competing with IEEE EPON etc. ITU does seem to have lost out comprehensively at layer 3. They do some stuff like OAM which is only interesting at Telco scale, although in the mobile era bodies like ETSI are more relevant.
The other difference from that era, and even the early internet era, is how much is no longer standardised at all, but decided by global monopolies. Back then it was a given that
Everything would at least need to interoperate at the national level. But we may be returning to that .
In the US at least the fiber standards are shaking out to telco vs. cable. Fiber providers who used to be telephone companies (AT&T, Verizon, and the smaller former Bells) are hitching to ITU standards in products developed and sold by vendors who have always sold to the Bells (Nokia via Alcatel via Lucent). Many of the startup fiber providers fall into this category, too (Google Fiber, Sonic, etc--oftentimes because they started as DSL companies riding on physical last mile networks of the telephone companies)
ISPs and providers (fiber or not) that started out as cable companies (Comcast, Charter) are hitching to SCTE/CableLabs standards and equipment from their traditional vendors (Commscope, wherever Cisco's Scientific Atlanta business lines ended up)
In the US there is little need for interoperability since networks don't have to be unbundled or support any kind of competition, outside of cable networks have to allow a customer to bring their own CPE (and only for copper networks, when they move to fiber all bets are off)
The only benefit interoperability brings is pricing--if a vendor can sell their platform to many ISPs, they get an economy of scale. This doesn't mean standards win, even in the cable world in DOCSIS 4.0 there are two flavors, with Comcast being just about the only company that has picked one flavor, with the rest of the industry picking the other
Everyone likes Wireguard over OpenVPN for many reasons, and one of those reasons is that OpenVPN requires a certificate pair while Wireguard uses a 40-character private and public key you can generate by running "wg genkey" with no parameters and copy/pasting.
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.
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!
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.
At the time of bang paths, smtpd was just one of several email protocols in use. And X.400 was absolutely a competitor at the time.
A decade or two later, when it was clear that smtp had become the least common denominator between all email systems, then smtp absolutely used DNS and even had its own record type, MX.
So I don't think it is wrong to say a large part of why it won out on all other protocols was that you didn't have to mess with email routing once MX records was universally accepted.
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.
> 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.
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.
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.
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.
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.
“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.
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_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.
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 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.
> 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.
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!
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.
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.
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.
>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.
62 comments
[ 1.7 ms ] story [ 104 ms ] threadThanks 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
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.
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.
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
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.
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?
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 standards body happy (ie, has enough info to make it worthwhile to purchase the specification), and not revealing the secret sauce in their implementation.
I've done it, and it's an absolute nightmare. The IETF RFCs are a breath of fresh air in comparison. Not only can you read the source, there are example implementations!
And if you think that didn't lead to a better outcome, you're kidding yourself. The ITU process naturally leads to a small number of large engineering orgs publishing just enough information so they can interoperate, while keeping enough hidden so the investment discourages the rise of smaller competitors. The result is, even now I can (and do) run my own email server. If the overly complicated bureaucratic ITU standards had won the day, I'm sure email would have been run by a small number of CompuServe like rent seeking parasites for decades.
I don't think that's IETF policy. Individual IETF working groups decide whether to request publication of an RFC, and the availability of open source implementations is a strong argument in favour of publication, but not a hard requirement.
If the IETF standards are sometimes useful, it's more a matter of culture than of policy.
However, I think DER is good (and is better than BER, PER, etc in my opinion). (I did make up a variant with a few additional types, though.)
OID is also a good idea, although I had thought they should add another arc for being based on various kind of other identifiers (telephone numbers, domain names, etc) together with a date for which that identifier is valid (to avoid issues with reassigned identifiers) as well as possibility of automatic delegation for some types (so that e.g. if you register an account on another system then you can get a free OID from it too; there is a bit of difficulty in some cases but it might be possible). (I have written a file about how to do this, although I did not publish it yet.)
Using ITU voice codecs!
Besides LDAP and X.509, you've got old standards that were very successful for a while. I'm perhaps a little bit too young for this, but I vaguely remember X.25 practically dominated large-scale networking, and for a while inter-network TCP/IP was often run over X.25. X.25 eventually disappeared because it was replaced by newer technology, but it didn't lose to any contemporary standard.
And if you're looking for new technology, CTAP (X.1278) is a part of the WebAuthn standard, which does seem to be winning.
I'm pretty sure there are other X-standards common in the telco industry, but even if we just look at the software industry, some ITU-T standards won out. This is not to say they weren't complex or that we didn't have simpler alternatives, but sometimes the complex standards does win out. The "worse is better" story is not always true.
The OP article is definitely wrong about this:
> “Of all the things OSI has produced, one could point to X.400 as being the most successful,
There are many OSI standards that are more successful than X.400, by the seer virtue of X.400 being an objective failure. But even putting that aside, there are X-family standards that are truly successful and ubiquitous.X.500 and X.509 are strong contenders, but the real winner is ASN.1 (the X.680/690 family, originally X.208/X.209).
ASN.1 is everywhere: It's obviously present in other ITU-T based standards like LDAP, X.509, CTAP and X.400, but it's been widely adopted outside of ITU-T in the cryptography world. PKCS standards (used for RSA, DSA, ECDSA, DH and ECDH key storage and signatures), Kerberos, S/MIME, TLS. It's also common in some common non-cryptographic protocols like SNMP and EMV (chip and pin and contactless payment for credit cards). Even if your using JOSE or COSE or SSH (which are not based on ASN.1), ASN.1-based PKCS standards are often still used for storing the keys. And this is completely ignoring all the telco standards. ASN.1 is everywhere.
The other difference from that era, and even the early internet era, is how much is no longer standardised at all, but decided by global monopolies. Back then it was a given that Everything would at least need to interoperate at the national level. But we may be returning to that .
ISPs and providers (fiber or not) that started out as cable companies (Comcast, Charter) are hitching to SCTE/CableLabs standards and equipment from their traditional vendors (Commscope, wherever Cisco's Scientific Atlanta business lines ended up)
In the US there is little need for interoperability since networks don't have to be unbundled or support any kind of competition, outside of cable networks have to allow a customer to bring their own CPE (and only for copper networks, when they move to fiber all bets are off)
The only benefit interoperability brings is pricing--if a vendor can sell their platform to many ISPs, they get an economy of scale. This doesn't mean standards win, even in the cable world in DOCSIS 4.0 there are two flavors, with Comcast being just about the only company that has picked one flavor, with the rest of the industry picking the other
Maybe X.500 - also known as LDAP, and widely deployed across enterprises in the form of Active Directory.
So it must have been preferable to reduce the workload per email for the server and client.
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.
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!
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.
Who can forget addresses like "utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!rms@mit-prep"
1. smtp predates dns. or really even most of the internet. It was originally designed to work over uucp.
2. early smtp used bang paths (remember those) where the route or partial route is baked into the path.
At the time of bang paths, smtpd was just one of several email protocols in use. And X.400 was absolutely a competitor at the time.
A decade or two later, when it was clear that smtp had become the least common denominator between all email systems, then smtp absolutely used DNS and even had its own record type, MX.
So I don't think it is wrong to say a large part of why it won out on all other protocols was that you didn't have to mess with email routing once MX records was universally accepted.
Immutability is one of the best things about email.
"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.
That would have required a lot of changes to computing history beyond simply email, and I doubt many of them would have been improvements.
For example from 2023: X.1095: Entity authentication service for pet animals using telebiometrics
https://jacobfilipp.com/MSJ/1993-vol8/qawindows.pdf
By 1995, the “Internet” e-mail address was the only remaining one.
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.
Reminds me of IPv6. ;)
Just seeing that X.400 notation is giving me bad memories!
You might have had an American walled garden, but I don't see this being accepted internationally.
- 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 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.
I wish someone would write some RFCs and e-mail could get an update.
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".