[recipient list trimmed]
i guess if i think anything about all that, it is that if NATs are ubiquitous,
we should figure out how to deal with them.
perhaps. but I note that for many of the examples you quoted, "dealing
with them" was not nearly as nice as "not having to deal with them".
for instance, having email gateways was clearly better than not having
any way to exchange mail between Internet/DECnets/BITNET/uucp/CSnet/etc.
at the same time, email gateways never worked as well as we would have
liked. they often required users to know arcane details about addressing
in foreign email systems and how the addressing from different email
systems were combined (things like "ATLAS::BITNET%\"USER(_at_)NODE\""@xxx.yyy
were entirely too common), they introduced many additional kinds of
failure which were difficult to diagnose, non-delivery reports from
foreign systems were unreliable (either going to the wrong place or
not being able to be returned to the sender) and hard to decipher, and
return addresses were often trashed so that replies didn't work. Even
the simple question "what is your email address?" was not simple to
answer - the answer depended on context, and many users honestly didn't
know the answer for anything beyond a very local (to them) context.
Many users couldn't give their email addresses to others.
I'll also note that email gateways were once ubiquitous, but now are
much less common.
we do need NATs in IPv4 to work around the address space shortage
as well as to allow connectivity for networks using private address
space which cannot easily be renumbered, just as we once needed mail
gateways. but just like mail gateways, they don't have to stay around
forever, and NAT use will also decline when better alternatives are
available.
Keith
(who wrote email gateways in a past life)