🚀 go-pugleaf

Hey, I can answer this one (sort of).

**Warning** **Warning** **Warning** **Warning** **Warning** **Warning**
**                                                                   **
** Lengthy reply follows, Cognoscenti may wish to trash message now! **
**                                                                   **
**Warning** **Warning** **Warning** **Warning** **Warning** **Warning**

First let me explain how it can be correctly parsed, and then go over
the assumptions.

There are three basic forms here:

RFC 822 simple address:   user@host
RFC 822 explicit routing: @relay:user@host
UUCP routing:             host1!host2!...!user

Lets build up the address from its parts:

       hpfcla!hpcnoe!veeger!hpcnou!dat

is a legal UUCP routing address. Since RFC 822 doesn't describe
any substructure for the "user" field, this can be treated as the
"user" portion of a RFC 822 address (user@hplabsd).

       hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

At this point, we can go from an RFC 822 simple address to
an explicit routing address where MIT-MC.ARPA is the relay.

       @MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

Now, UUCP routing doesn't break up user parts either. So we
can treat the above as the user part ofnoscvax!user.

       noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

This address will work as a TO address IF the following are true:

 - The machine originating the message only talks UUCP syntax.
 - noscvax can receive UUCP traffic from the machine sending the mail.
 - noscvax can send RFC822 mail to MIT-MC.ARPA
 - MIT-MC.ARPA either ONLY understands RFC-822, or
   MIT-MC.ARPA always gives RFC822 precedence over UUCP, or
   MIT-MC.ARPA talks to hplabsd using RFC822, but not to hpfcla using UUCP
 - hplabsd must be able to receive RFC822 mail form MIT-MC.ARPA
 - hplabsd must be able to send UUCP mail to hpfcla.
 - hpfcla must be able to send UUCP mail to hpcnoe.
 - hpcnoe must be able to send UUCP mail to veeger.
 - veeger must be able to send UUCP mail to hpcnou.
 - hpcnou must have a local user named dat.
 - no machine tries to short-cut or parse the "user" portion of the
   address when they have it.

The interesting problem of course is what if one or more of the
sites does support both RFC822 and UUCP syntax, without the
explicit precedence rules.

In particular, confusion can arise if:

- MIT-MC.ARPA can talk RFC 822 to hplabsd, *and* UUCP to hpfcla.

If the mail were accidentally UUCP mailed to hpfcla, then
hpcnoe would be told to deliver to dat@hplabsd. If hpcnoe
doesn't talk RFC 822 or doesn't talk to hplabsd then
the mail would fail.  If it does talk RFC 822 to hplabsd then
the mail could be successfully delivered to "dat" there if
that was a legal mail name there.  Obviously the dat@hplabsd
could be a different than the hpcnoe!dat.

It shouldn't matter to noscvax that there are two at-signs in the
address when it sees it, since they are in valid RFC 822 routing format,
so there should be no conflict in whether to send to hplabsd with
the rest being the user field vs. sending to MIT-MC.ARPA. By the rules
of 822 it MUST be sent to MIT-MC.ARPA. Of course, if the mailer is
not completely RFC 822 standard (and many are not) there could be
a problem and the mail could be acccidentally sent to hplabsd instead.
That of course would be disasterous, since the "user" field handed
to hplabsd would be neither valid RFC 822 nor UUCP routing form.

By the way, there is no indication of any BITNET syntax here at all.

The remaining question is left for the user, namely, why is

 >From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985

in an UUCP ">From" line rather than in a RFC 822 "From:" line?:

 From: noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd

            Scott McGregor
           {...!hplabs, ...!hpcea, ...!hpisla}!hpccc!mcgregor
            HP Corporate Computing Center