🚀 go-pugleaf

In article <1269@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes:
>> From: hokey@plus5.UUCP (Hokey)
>
>> I am not aware of any sites which cannot handle the cbosgd!cbosgd.ATT.UUCP!...
>> stuff.
>
>I don't think what we're arguing here is the unacceptability of 
>cbosgd!cbosgd.ATT.UUCP by other sites, but the redundancy of the cbosgd.  Reply-
>ing to a message which has the header
>
>>From cbosgd.ATT.UUCP!chris remote from cbosgd
>
>will cause the above to happen, which is handleable, but an eyesore as well.
>
>I did some checking into mail.c (Sys V) and picked out what is supposed to go 
>into the From (not From:) line of a mail message.
>
>From <my_name> <date> remote from <thissys>
>
      ....

That mailer was written in the old days of a small network.  One where
it was possible to know (without referring to any tables) the complete
connectivity of the network.  That's not possible anymore.

We need to have mailers which will route mail around without people
having to know complete paths.  Paths change.  Are hard to discover.
Sometimes are hidden.  Might be broken due to hardware failures.
A lot of things.  But if you do something like the domain style addressing
then there's a whole host of improvements that can be made.

Now.  I agree that cbosgd!cbosgd.ATT.UUCP!chris has redundant information.
But I send mail to cbosgd (and recieve mail and reply to it) all the time.
A month or two ago (when Mark installed his fancy sendmail.cf) I was
having trouble replying to his messages because my sendmail.cf isn't
smart enough to parse a two domain address (cbosgd.ATT.UUCP).  It'd
look up "cbosgd.ATT" as a system name.  And I'd get mail back from
the routing process that it couldn't find cbosgd.ATT.  Now I can respond
to him because he's got that cbosgd in the front.  

Basically it put off some hacking I'd have to do to Big Mail.

Redundancy is sometimes usefull.  Right?


>
>Now I know that there are no rules as far as how the syntax of UUCP addresses
>should be, but perhaps we should at least stick to existing standards -- those
>that have already been set in software.  Otherwise, poor dumb mailers will 
>generate bad addresses unknowingly, and poor users who don't know any better
>will panic when they can't reply to messages.

If we keep using "poor dumb mailers" that's all we'll ever have.
-- 
--- David Herron
--- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> 
---	   or david%ukma.uucp@anl-mcs.arpa
---        Or even anlams!ukma!david@ucbvax.arpa
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david

	"It's *Super*User* to the rescue!"