>> > uux host!rmail address1 address2 address3 ... addressn
>>
>> Ah! Simple as that, is it? Incidentally, where does the sender's address
>> go? Is it in a From_ line?
>
>Hmm, AFAIK, UUCP does not care about the sender's address. When mail arrives
>at "host" (which is whatever the UUCP host is named), it is generally sent to
>the MTA (sendmail, Exim, qmail, whatever..) and treated like a normal piece of
>mail. So when my system sends UUCP mail to my ISP, the mail is just fed to
>Sendmail and I guess all the info Sendmail needs it gets from the headers. I
>think... :-)
My how times have changed. When I started smail, all sysadmins seemed
to understand most of the subtle nuances of UUCP, including the various
capabilities of the many variants.
Normally, UUCP does not care about the sender address. However, if UUCP
itself encounters an error that requires that IT send mail to the
originator, it needs an address to send to. Very old UUCP sent mail to
the user that queued the request (which it obtained by looking up the
real UID that it runs under). Later, HoneyDanBer (and then all the other
major UUCP variants) added a "-a <sender-address>" option that allowed
the sender address to be specified explicitly. The smail configuration
files are setup to supply the sender address with -a.
As to multiple From_ lines, in traditional V7 Unix, /bin/mail was the
program that handled both local AND remote delivery. When it served
as an intermediate node, it added a From_ line such as:
From uucp date-and-time remote from last-hop-host
It would also put a > in front of all other From_ lines. The first-hop
host added the line:
From username date-and-time
So, this would result in something like the following:
From uucp date-and-time remote from hop3
>From uucp date-and-time remote from hop2
>From tron date-and-time remote from hop1
To: whoever
Subject: whocares
In generating a reply to this, you then take the hops and the username
in the forward order, generating hop3!hop2!hop1!tron.
This is all discussed in RFC976, though the historical issues are not.
--
Ronald S. Karr
tron |-<=>-| tron@???
