Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site houxm.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!gregbo From: gregbo@houxm.UUCP (Greg Skinner) Newsgroups: net.mail.headers Subject: Re: Why "From cbosgd!cbosgd.ATT.UUCP!chris" isn't stupid Message-ID: <1269@houxm.UUCP> Date: Sat, 8-Jun-85 15:32:45 EDT Article-I.D.: houxm.1269 Posted: Sat Jun 8 15:32:45 1985 Date-Received: Sun, 9-Jun-85 03:36:21 EDT References: <1214@cbosgd.UUCP> <515@down.FUN> <766@plus5.UUCP> Organization: AT&T Bell Labs, Holmdel NJ Lines: 36 > 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 remote from where my_name is obtained from the user's LOGNAME, or the password file if LOGNAME isn't set, and thissys is obtained from a uname(2) call. Now in 4.2, I imagine these fields are obtained by doing similar things (uname replaced by a whoami or something similar) but a name like cbosgd.ATT.UUCP!chris was clearly not obtained by either of the means of obtaining my_name. 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. -- It's like a jungle sometimes, it makes we wonder how I keep from goin' under. Greg Skinner (gregbo) {allegra,cbosgd,ihnp4}!houxm!gregbo gregbo%houxm.uucp@harvard.arpa