Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp From: tp@mccall.com Newsgroups: comp.mail.uucp Subject: Re: Question about From: lines Message-ID: <3000.2688db2b@mccall.com> Date: 27 Jun 90 16:13:30 GMT References: <2836.26750678@mccall.com> <14423@ucsd.Edu> <267E85F1.33B4@tct.uucp> <14495@ucsd.Edu> Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 82 In article <14495@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes: > I said >>>the From: line has what looks like a valid RFC822 address in >>>it, you leave it alone. Otherwise, replace it with the bang path you >>>got from the From_ line. Note that user@host.UUCP is explicitly NOT a >>>valid RFC822 address in this context. > > In article <267E85F1.33B4@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Last I checked, this behavior (transforming "user@host.uucp" into >>"foo!bar!host!user") is *not* sanctioned by RFC976. It *is* rude to >>those sites who want to provide return addresses in the UUCP zone. RFC976 says only this about host.uucp: Names such as "ucbvax.UUCP", consisting of a 6 letter name followed by ".UUCP", previously were domain style references to a host with a given 6 letter name. Such names are being phased out in favor of organizational domain names such as "ucbvax.Berkeley.EDU" It also says this: (The UUCP zone is that subset of the community connected by UUCP which chooses to register with the UUCP project. It represents an administrative entity.) Thus host.uucp, being unregistered is not in the uucp zone, nor is it sanctioned by RFC976. RFC976 is intended to define the standard format for the transmission of mail messages between machines in the UUCP Project. Being "in the UUCP Project", can be infered to mean (if you actually read the RFC), having your site registered, and thus having a domain name (because it requires sites "in the UUCP Project" to conform to RFC822). It explicitly requires From: lines to be RFC822 compliant, and Brian is correct that host.uucp is not an RFC822-compliant domain name. RFC822 requires domain names to be not only syntactically correct, but to actually exist as well, and this would mean MX records, etc... RFC976 doesn't cover unregistered sites, and was not meant to. There is no RFC that does, to my knowlege. You aren't in the UUCP zone, because you aren't registered (according to the definition of the zone given in RFC976, anyway). host.uucp is not sanctioned or protected by any standard, so Brian can legitimately do whatever he wants with it. That's why there are standards, to prescribe what should be done in different cases. In the abscence of a standard, one can do just about anything, and there WILL be problems. Each postmaster will either accept whatever the default is, or will make his own best guess about the correct thing to do. Since they all make different guesses, the result is chaos. I see 2 solutions. You could invent a new standard that would apply to unregistered sites, and get it approved and adopted. I don't know what you could do that would work though. Or you could register a domain. Granted this can be a pain if there is no friendly internet site handy. This part of the process could be made much better/simpler/easier. Unfortunately, the NIC controls the process and requirements for registration, and uucp sites are definitely not their priority concern. I don't know what you could do to improve things. > Yes, that's one of the places where RFC976 is wrong. Someday I'll get > around to updating it in a newer RFC. In what way is it wrong? It doesn't even cover this case. > The UUCP zone is dying. It was only a stopgap until a way to register > non-internet sites in the worldwide domain name system existed, and now > that we have that, it can quietly go away. It was a wonderful thing but > it is clearly time to retire it. Umm... I'm registered in the UUCP zone, n'est-ce pas? I registered through uunet, and I'm a uucp site, or did the zone get defined as something else when I wasn't looking? Are you suggesting that each site deal directly with the NIC? While it saves the $35, most people, including myself, wouldn't even know where to start. You'd also have to dig up some friendly name-servers (if you aren't using those provided by the UUCP Project), which would be MUCH more difficult than finding an MX forwarder. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA