In years long sped, one could send an email by listing not only the server that the destination account was hosted on, but all the necessary intermediary machines.
e.g. : MyDepartmentServer!MainServer!BigRouter!TheirDepartmentServer!SpecificServer!jsmith
Eventually, listing the intermediate servers was no longer necessary due to improved routing systems and the @ convention developed.
Can one still use a bang path nowadays? If so, can you just enter it into the “To” field, or do you need a special client that can send the right commands (or do it yourself with a telnet session)? If not, when did bang paths stop working?
Bang paths work if you set up your own little UUCP network, which you can do if you have *nix systems available (the software still exists). You might even be able to coerce the stuff into working on Windows, but I, for one, would pity the person who had to do something that perverse.
Bang paths alone were never able to send mail to the whole, global network: Arpa and BITNET, for example, always used their own addressing schemes, and there were other, less-known networks and email addressing schemes as well. (In micro-land, Fidonet had its own email address scheme, for example.) Having to shuffle mail between networks, each with their own address scheme, lead to really bizarre email addresses to attempt to go from end-to-end. Composing an email address that would actually work was somewhere between a fine art and a bizarre black magic likely involving dead chickens at some really out-of-the-way sites.
The Arpa scheme won, in case you’re wondering: username@hostname, the ‘domainist’ solution, is so universal now that otherwise-clueful people don’t recognise anything else as an email address.
As for when they stopped working, that varies by site but the 1990s was the real watershed decade as far as Internet access was concerned: A huge number of sites finally got to the point where not being on the real Internet was more trouble and expense than it was worth. And, of course, being on the Internet means adopting Internet protocols, Internet-style email foremost among them.
And don’t forget DECNET and its love of double colons. At some point I remember communicating with somebody through an email address about a mile long via three distinct networks which had to be escaped/quoted in some really bizarre manner.
Bang paths are still used in usenet, though not for email addresses nor for routing.
I vaguely recall seeing some Sendmail documentation a few years back that suggested some relics of bang path support were still in place. That could have been removed since then, and I very much doubt it would work in practice, but Sendmail is still in common use.
Right: Each server adds its own name to the Path: header of every message it sees in the classic bang path style. As the message gets passed from machine to machine (Usenet is peer-to-peer), this creates a record of where your news came from.
Of course, this gets abused by spammers who might add a bogus path of some arbitrary length on their own system before sending it out into the world, simply to implicate someone else. They do the same thing with the equivalent email headers. The first through fifth rules of dealing with spammers is “Spammers lie”.
If you have a connected group of systems that forms that complete path, then it might work. You won’t be able to send mail to an arbitary host that way, as the UUCP Maps (the path list between arbitrary nodes) were discontinued in late 2000.
Some organizations were UUCP holdouts and continued to use bang-path addresses long after the rest of the net switched to domain-style addressing. AT&T was a particularly large example.
There are enough remnants of UUCP support that a number of mail transport agents will still know what to do with a reaonably short bang-path as the left part of a domain-style address (for example. a!b@example.com). Similarly, b%a@example.com. Whether any particular mail user agent supports them is less likely, as MUAs are replaced more often than MTAs.
And don’t get me started on the number of web sites that “validate” email addresses simply by declaring certain characters illegal, instead of actually following the RFCs. Particularly when there’s a good, free validator available.
I remember those days (and earlier, when host addresses were a single number like “112”). For a truly gruesome experience, consider what was required to send a message to a UK system (“Coloured Book” - they used to drive on the wrong side of the Internet, too*) from a UUCP host connected to a BITNET host via a DECnet link. Now try to guess what the return address would look like, assuming the message actually arrived at its destination.
The right-hand-side was in the reverse order from normal DNS. What we would normally write as host.example.com, they would write as uk.co.example.host. This, combined with an assumed localpart (if you’re on host “hosta.foo.com”, mail sent to “user@hostb” would be assumed to mean "user@hostb.foo.com) could lead to some wildly mis-routed messages. This was experienced again much later when Ehud Gavron registered edu.com (see RFC 1535).
I still use PMDF on a VMS system (at my house) for email and have been known to respond to HTML-only messages with a scathing “Sorry, I don’t read my email with a web browser” message.
I disagree with this in principle: The only way to correctly validate an email address is by attempting to send mail to it. This also allows you to satisfy the double-opt-in prerequisite, which should be satisfied by all mailing list software.
This is why so much British mail ended up in Czechoslovakia. Dammit, JANET!
An address to a Computer Science department in the UK would look like uk.co.bristol.cs. Czechoslovakia’s TLD was .cs.
Yes, but checking that the address might actually work is a good first step. Otherwise, sending the email asking for confirmation is just going to generate error messages which will either rattle around in the system until being delivered to the [usually-overworked] postmaster or just bitbucketed.
And not all email addresses entered into web forms are used for mailing list subscriptions - some are for things like “email me when my order has shipped”.
The current RFC on email address format permits things that a large fraction of actual email servers will not successfully forward. As such, an algorithm which perfectly implements the RFC (no mean feat itself) will approve addresses which the source mail server can’t actually use to successfully get email all the way to the destination.
Normally I’m a hard-core prescriptivist when it comes standards & validation. But … the email address system is *almost *as badly broken as HTML. The only truly valid email address validation is: “Does it work when I try it?” Anything else risks way too may false negatives and false positives.
For some years I’ve had an email address like myname@mydomain.us. You’d be amazed how many big corporate e-commerce sites in the mid 90s thought the only possible TLDs were .com, .net, and .org. I still occasionally run into a validation dead end with that address today, but only on small sites done by some local Bubba’s House of Bargain Website Design.
My first internet email system was PMDF on VMS, back in 92-93ish. After a few experiments with open SMTP relaying, we asked PMDF for a mail rule that prevented external connections from relaying back out. They had no idea why you would want to prevent such a thing. How things change.
