jordan@ucb-arpa.ARPA (Jordan Hayes) (12/19/85)
From: hpcnou!dat@hplabsd (Dave Taylor)
>> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd
Simple.
If there's a leading '@', use source-routing. If not, look for
the right-most '@' ... so, send the return message to "hplabsd" ...
Ah, they say -- "but that's not the truth ..."
Humbug.
You can't parse it correctly unless you make some assumptions about
where that address showed up at. If it showed up at a dumb UUCP host
connected to noscvax, you may not have a problem returning it to
there and having noscvax send to mit-mc which would send to hplabsd
which would send to hpfcla!hpcnoe!veeger!hpcnou!dat ... *ugh* !!
However, if the site it came from recieved the message *via* uucp,
but is also an arpanet host (can you say "seismo" "ucbvax" "topaz"
"sdcsvax" "harvard" + a cast of thousands ...), you have a problem,
since it will try to do the "correct" thing I mentioned above about
sending it to hplabsd (BTW: how about your own return address, Dave?)
Such a silly question to ask ... the answer is clear: you can't parse
addresses with multiple (conflicting) syntaxes ... I thought we cleared
this question up a few years ago ... *sigh*
Now: how about the solution? As simple as the answer to Dave's
Question ... uucp needs to use 822 addresses if they expect to get
decent service when getting gatewayed into/out of the Arpanet.
They can do whatever they want between themselves, but when in Rome ...
/jordandat@hplabs.ARPA (12/19/85)
Ken Stone of HP-SDD sent me his copy of my recent note and the return
address is the strangest I've seen yet on this network...
>From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd Tue Dec 17 13:35:41 1985
The question is - how does one parse this? There are a LOT of
ambiguities here ... including two '@' addresses and such. It
seems to me that a decent return address would be parsable in
a unique fashion, rather than this "if the destination machine is
an ARPA gateway then it'll send to (?) hplabsd, if not, then if
it's a BITNET gateway it'll send to MIT-MC.ARPA (through an ARPA
gateway?) else it'll just send it to noscvax and let THEM deal
with it...
Anyone have any pearls of wisdom about all this?
----- for further amusement, the modified From line too...(now wrong) ----
From: noscvax!hpcnou!dat@hplabsd.ARPA (Dave Taylor)
-----
Are we having fun yet?
-- Davemcgregor@HPLABS.ARPA (12/20/85)
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 Centergds@SRI-SPAM.ARPA (Greg Skinner) (12/20/85)
>> From noscvax!@MIT-MC.ARPA:hpfcla!hpcnoe!veeger!hpcnou!dat@hplabsd
Since Dave Taylor said that the message came from someone at hp-sdd,
whic is not on the ARPA Internet as far as I know, and is not
constructing 822 addresses, the From line can be read as such:
hp-sdd <-- noscvax
noscvax <-- mit-mc
mit-mc <-- hplabsd
hplabsd <-- hpcnou (though 4 hops)
The reply works in this case because MIT-MC saw fit to do source
routing, which is probably not a bad idea for mail coming from UUCP.
If the message came from someone on a smart UUCP site that did 822
header munging, or was on both ARPA and UUCP, the rightmost @ would be
favored, that's where the mess begins.
It is possible for UUCP sites to address outside of UUCP using bang
format. For example, the above address could be folded into:
noscvax!hplabsd.arpa!....!hpcnou!dat
Note I left MIT-MC out of the picture. MIT-MC just redistributed the
message -- it did not originate it, and has no right to be included in
reply text. I suspect possible munging of From or From: lines.
However, if you insist on seeing MIT-MC in there,
noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat
Gateways/mail bridges *ought* to do the transformation between ! and 822
formats, that's what they're there for. One of the purposes of a
gateway is to do protocol transformations on messages which is clearly
what is needed here. No one in UUCP need know about @ or any other such
nonsense -- as long as they know the qualified names of the sites they
are sending to, they should be free to construct paths through the
gateways with legal UUCP syntax, with the gateways doing the appropriate
transformations.
--gregbojordan@ucb-arpa.ARPA (Jordan Hayes) (12/20/85)
From: gds@sri-spam.ARPA (Greg Skinner) noscvax!hplabsd.arpa!....!hpcnou!dat Note I left MIT-MC out of the picture. MIT-MC just redistributed the message -- it did not originate it, and has no right to be included in reply text. I suspect possible munging of From or From: lines. However, if you insist on seeing MIT-MC in there, noscvax!mc.mit.lcs.edu!hplabs.arpa!....!hpcnou!dat Gregbo, You clearly have shown your parsing skills, but I think what is missing from this little point you made is the assumption that just because noscvax is on the Internet that it will know about the hp site (by the way, the original said "hplabsd" and you have "hplabsd.arpa" which does not exist ... "hplabsd" is a nick-name for "hplabs.arpa" -- no "d" in the .arpa-ized form. This is because the people running sendmail on that machine have the local name go out on mail, instead of the official name ... *sigh*) Anyways, what i wanted to say was that the reference to mit-mc was in fact necessary, and should indeed be included, unless you are absolutely sure you can get to the hp site by yourself. When an exploder is doing its work, it definately should put itself in the address. What if I on a machine "foo" that is on a local ether with mit-mc send to the list that redistributes to someone on a machine one UUCP hop away from noscvax ... should the return be noscvax!foo!jordan ...? or should it be noscvax!mit-mc.arpa!foo!jordan ...? Although it certainly may be true that noscvax could theoretically have an entry for foo in its /etc/hosts file (nosc, as you recall, is on MILNET and does not need to have resolvers running yet ...) and *could* make the smtp connection to foo itself, it should go back to mit-mc. Manual editing of headers from list exploders is a mail wizards hobby. Not for the children at home ... /jordan