Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!akgua!mcnc!philabs!cubsvax!rocky2!rna!cmcl2!floyd!harpo!ulysses!burl!hou3c!solomon@wisc-crys.arpa
From: solomon@wisc-crys.arpa
Newsgroups: net.mail.headers
Subject: Re:  Malformed headers
Message-ID: <488@hou3c.UUCP>
Date: Fri, 20-Apr-84 11:01:01 EST
Article-I.D.: hou3c.488
Posted: Fri Apr 20 11:01:01 1984
Date-Received: Tue, 24-Apr-84 07:13:02 EST
Lines: 31

This has all been said before, so I'll try to be brief, but it keeps
coming up, so I think it's worth repeating.

The problem is conflicting and ambiguous syntax for addresses between
RFC 822 and UUCP.  The UUCP syntax is host!localpart, while the 822
syntax is localpart@host.  When you try to put an address into
"localpart" to simulate source routing, you get ambiguity.  Does
"a!b@c" mean "a!(b@c)" (use UUCP to send to host a, which hopefully is
on Arpanet and can send to b@c), or does it mean "(a!b)@c" (send over
Arpanet to host c, which will forward using uucp).  The ad hoc solution
seems to be context-sensitive parsing, using info like whether I'm on
Arpanet, whether Arpanet contains a host named "c", etc.  Usually some
sort of local kludge can be worked out.  But when a message crosses
back and forth between worlds more than once (as the message in
question seems to have done), I have very little hope that anything
will work.  Some UUCP sites are trying to move to the 822 syntax with
hacks like munging host!user to user@host.UUCP.  Sometimes that helps,
and sometimes it makes things worse.

My own personal opinion is that source-routing is a necessary evil that
will be with us for some time.  The best syntax I've seen is the RFC821
syntax:  <@host1,@host2,...,@hostN-1:user@hostN>.  I've seen some
evidence that more software packages are supporting it, not only in the
SMTP envelope, but in headers and in user agents.

When putting together independantly planned (or unplanned) systems and
trying to make a consistent whole, we must strike a delicate balence:
We must be understanding and sympathetic with sites running obsolete
software, while continuing to urge them and help them to change.
In this case, we can help by moving quickly towards putting the domain
system in place and setting up some sort of "official" UUCP domain.