Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!decvax!harpo!whuxlm!whuxl!houxm!mhuxt!mhuxr!mhuxn!ihnp4!plus5!hokey From: hokey@plus5.UUCP (Hokey) Newsgroups: net.mail.headers Subject: From: and To: in UUCP land Message-ID: <835@plus5.UUCP> Date: Thu, 15-Aug-85 00:02:56 EDT Article-I.D.: plus5.835 Posted: Thu Aug 15 00:02:56 1985 Date-Received: Tue, 20-Aug-85 01:22:51 EDT Organization: Plus Five Computer Services, St. Louis Lines: 108 Keywords: RFC822, reality, anarchy, 42, UUCP It is starting again. Plus Five is seeing bizzare headers, and I would really like to get the beasts to be consistent. For starters, we have suddenly started geting hybrid routes in >From lines. Additionally, different sites are changing their behavior on From: line munging. I have several proposals. I would greatly appreciate constructive feedback. These all pertain to UUCP land only, and are significant because many UUCP sites use sendmail. 1) No @ in UUCP transport layers. I would hope that Arpa gateways would convert the arpa path to ! format relative to their site. I am even advocating the gateway change user%site.csnet@csnet-relay to site.csnet!user. Likewise for Bitnet. 2) No prepending the local site name to the From: line. This is wrong for several reasons. One of the reasons is that not all sites along the route may be able to do this, and a reply along that path may therefore fail. Another reason is that many sites keep this field in @ format, in which case the prepending will result in an erroneous route. Additionally, the From: line must clearly be parsed with @ having higher precedence over !. I suspect a quoting mechanism could be used to avoid this problem, or sites could use 822 source routing, but that seems kinda dull. 3) No @ in From: or To: lines, either. This might be viewed as a radical proposal. I submit it is necessary because many sites violate 2), and even if they don't, Somebody's mailer will do a reply to the recipients and will end up with a hybrid route which has an excellent chance of being mis-parsed. 4) Please don't automatically qualify uucp sites with .uucp, and then either leave this qualification in place, or strip it off. If the mail arrived with a .uucp on an address, leave it there. If it did not arrive with a .uucp, then don't put one there. This request may not apply to gateways. If you want to qualify unqualified uucp sites, please do it with .luucp or .uux, and then *strip it off*. This will still permit you to isolate uucp mail in your .cf file, but it will *not* get out to mess up others. There are several problems for which I have no immediate solution: 1) name qualification. Someday I will try to understand sendmail's C mailer flag. I am told it hardcodes @ format. In sites with one host, it can be pleasant when local users remain unqualified. However, these user names *should* be fully qualified when they leave the local site. At sites with multiple hosts, it can be useful to qualify names to the "gateway" machine, so routing to local users can be performed by the gateway machine. This is also useful if people access several hosts, or if host names change frequently. 2) Binmail explicitly source-routes everything. 822 mailers like to route implicitly. This has ramifications from 1) above. Sites which only use binmail don't need to qualify local recipients, because the explicit source routing of replies will always deliver the mail correctly, although subsequent replies will cause the path to grow and grow... Please note that by qualifying the sender and recipient that explicit source routing will still work. It just means that the generated return path can be optimized a bit. Binmail will generate To: lines if there is more than one recipient. It does not generate a From: line. It is possible that this information could be used to properly qualify unqualified addresses when the message hits a sendmail site. And now for some general points. The domain ! format can be very useful in keeping paths short, and permits sites to route to the best of their ability. The decision to hack the >From line to supply additional routing information can be handled at both the sendING (not the sendER) site or the receiving site. An example will be useful. Let's say user@site.EDU wants to send me mail, and for some reason the route to me goes through seismo to wucs to plus5. If seismo know that wucs is "smart", seismo can use ">From site.EDU!user" instead of "From seismo!site.EDU!user". Similarly, if wucs is smart, and it "knows" seismo is a gateway, wucs can take ">From seismo!site.EDU!user" and remove the "seismo!" portion. Then, wucs can either prepend its name to the >From line or not, based on policy or knowledge. Therefore, if I am a dumb site, a reply from plus5 will route tha mail to wucs. If plus5 is smart and it strips "wucs!" from the route, then a reply will go to site.EDU via the best path from plus5, which happens to be direct to seismo, not via wucs. Note that this scheme will correctly process multiple recipients on different hosts. Since both approaches seem to be equivalent, I suspect the least amount of work will be done if each site prepends its name to the >From line, and smart neighbors decide when to strip off the relay. Note that I am a middle-of-the-road extremist here. I "know" that routes to users on"internal" machines (princeton!down!honey or sun!grodish!guy) have "famous" sites at the head of the chain. In the interests of keeping a minimum number of sites along each address, I maintain these "root" (or bridge/gateway) machines should use a domain name in order to explicitly root the address of the user (even down.fun!honey would be swell). Again, if sites along the route take care to strip relays, paths will stay short. This means, for example, that by the time Mark's mail leaves ihnp4 on its way to me, it won't say "ihnp4!cbosgd!cbpavo.ATT.UUCP!mark", it will say either "cbpavo.ATT.UUCP!mark" or, at worst, "ihnp4!cbpavo.ATT.UUCP!mark". I would like to make two final points. First, I have *no* desire to pick on any of the people or sites I have listed in this article. I am not throwing stones at anybody; I am trying to make (and understand) several issues surrounding mail. Second, I do not believe that implementing my proposals will solve all the problems we face. I do believe that by implementing these proposals we will learn enough to make the effort worthwhile. -- Hokey ..ihnp4!plus5!hokey 314-725-9492