Path: utzoo!attcan!uunet!deimos.cis.ksu.edu!mccall!tp From: tp@mccall.com Newsgroups: comp.mail.uucp Subject: Re: Question about From: lines Message-ID: <2999.2688d45c@mccall.com> Date: 27 Jun 90 15:44:28 GMT References: <2833.2674c5b3@mccall.com> <14298@ucsd.Edu> <2836.26750678@mccall.com> <14423@ucsd.Edu> <00001FL@cdis-1.compu.com> Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 82 In article <00001FL@cdis-1.compu.com>, tanner@cdis-1.compu.com (Dr. T. Andrews) writes: > In article <14423@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: > ) Right. If the From: line has what looks like a valid RFC822 > ) address in it, you leave it alone. Otherwise, replace it with > ) the bang path ... Note that user@host.UUCP is explicitly NOT a > ) valid RFC822 address in this context. > True, there is no true ".UUCP" domain. However, if you replace the > "From: name@site.UUCP" with a bang path, you have surely made the > mail unreplyable to people who use the "From:" line. Actually, most uucp sites will understand a bang-path on the From: line. If you don't have a valid RFC822 path to put there, a bang path is probably better than nothing. The problem, however, is that if the message goes out over the internet, it will be made RFC822 compliant, usually by making it a mixed mode address (i.e. bang-path@host.domain). If this goes from the internet back to uucp, it will probably be totally useless. On the other hand, what is a better alternative? user@site.uucp has equally severe problems. > If you leave > the "From:" line untouched, it is replyable. While this is often true, it often isn't. It MAY be replyable. If the site is not in the uucp maps, it is NOT replyable. Such a site should send out site!user rather than user@site.uucp, but I think many such sites are precisely the ones that don't know all the issues involved. site@host.uucp is also not replyable if the host trying to use it doesn't have access to uucp maps, such as an internet site with no uucp links. Such a site could reply to bang-path@host.domain, however. Thus in some contexts, preserving host.uucp is specifically a bad thing. > Sites with "smart" mailers are often able to understand "From:" lines > with ".UUCP" addresses, because they look at the (possibly compiled) > maps. This applies almost exclusively to uucp sites with smart mailers. How many internet sites with no uucp links bother to handle the uucp maps? > Since you cause harm by re-writing the "From:" line, and cause no > harm by leaving it untouched, I advocate leaving it untouched. You cause harm either way. Converting to a bang path is bad, because some sites will update it, and some won't. Thus after a few hops the bang path is probably useless (depending on how smart the hosts actually on the path are, often they can route over the hops that didn't update the path). On the other hand, leaving host.uucp in is bad, because internet sites can't reply to it, and it is useless in the first place if the site isn't in the maps. This is one of those cases where you have to make a judgement call as to what is most likely to work. There is no "good" solution, because there is no "good" way to address a host without a domain name in a way that will work from anywhere. UUCP bang-paths always required the user to know a great deal about the layout of the network to make them work. They still do. Domain name solve this problem to the extent that they are used. Trying to squeeze bang-paths into domain names will never work well, because you get the worst of both worlds. The address gets mangled over time, and often still requires a knowlegeable user to be useful. Unfortunately, you MUST do something of this sort, because it is the only way to reach an unregistered host. BTW, before anyone suggests that when a mixed-mode address goes from the internet to uucp, it should be rewritten RFC976-style, this causes problems too. While it solves this particular case, it then means that you are rewriting valid RFC822 addresses, which is the current problem. It screws up registered sites badly. It also violates both RFC822 and RFC976. This is because RFC976 was written to handle registered uucp sites, while providing as much back-compatibility as possible. It simply can't handle this case. The only PRACTICAL solution (i.e. one that works and doesn't require action from lots of people who don't care enough about the problem to do something about it) is for unregistered hosts to get registered. An unregistered host will always have trouble getting mail. To the extent that this is a problem for internet people (for having to answer questions, or figure out how to address mail), they can best help by helping uucp sites get registered. The process is currently cumbersome and problematical enough to discourage many people from doing it. Improvements would be welcome. -- 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