hokey@plus5.UUCP (Hokey) (08/15/85)
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
lauren@vortex.UUCP (Lauren Weinstein) (08/15/85)
1) There is nothing wrong with putting @'s in the transport layer if you know that the site you're sending to can handle it properly. I keep tables with such knowledge, so that I can choose ! or @ routing as appropriate, based on my knowledge of the hosts. For example, ihnp4 can handle addresses like user@site.UUCP, so I can send them that way for domain-based mail that I'm sending to ihnp4 for non-local resolution. 2) @'s in the To: and From: lines are the ONLY way to maintain 822 compatibility with the outside world, and many smaller machines with limited software are starting to act as gateways and can't be expected to do @/! conversion. I see nothing wrong with @'s in the To:/From: lines so long as the From_ line is valid as a reply address. In the long run, the clue that a site SHOULD NOT futz with the From: line (except in certain gatewaying situations) is the presence of the @, except in certain obvious internet gatewaying situations. My own view is that due to various munging going on, it is important to support replies to both the From: and From_ line as necessary, and to send failed mail to the return addresses derived from internal spool files instead of header parsing. My own decision is to generate my From: lines in @ form, and to generate the To: lines in whatever form best resolves the message as posted by the user. I also allow replies to either the From_ line or the 822 lines. In the latter case, I follow the rules for Sender:/Reply-To:/etc. In the former case, I do a straight UUCP reply, but if an @ is present (on the From_ line) I give the !'s precedence (instead of the @, which has precendence on 822 lines). As a practical matter, even in our extremely mixed-up current environment, I find that I can successfully reply to 99+% of mail, through gateways and local nets, automatically, regardless of the smart or "dumb" hosts in the way. 3) As a general rule, I discourage the use of @'s in From_ lines, but when they occur I've found that my solution in (2) above works as a practical matter in the great majority of cases. --Lauren--
hokey@plus5.UUCP (Hokey) (08/17/85)
Lauren, I basically agree with you in your point (1) about using @ in the transport layer if you "know" how the recipient will handle it. My only concern is that while it may be OK to send a site an "rmail user@site", I would not want to send that site a hybrid recipient. >2) @'s in the To: and From: lines are the ONLY way to maintain > 822 compatibility with the outside world, and many smaller > machines with limited software are starting to act as gateways > and can't be expected to do @/! conversion. I agree with you here, too. The format of mail in 822 land *outside* of UUCP land should be in @ format. *Inside* uucp land it should be in ! format. Notice that the futzing is done at the gateways, another point where we agree. My answer to your point about small machines is to treat them as being *outside* UUCP land if the machines of which you speak use strict 822 mailers, and treat them as *inside* UUCP land if they only handle ! format. This means that mail sent to these machines would have the header put (left) in the correct format by the appropriate gateway (relay) site. If From: and To: lines are left in @ format, dumb mailers will produce hybrid routes which will not always parse correctly when the mail gets to a site which can recognize ! and @. I like to avoid problems by making sure they cannot happen. While we are on the point about >From vs. From: replies, many mailers will still source-route a From: reply (i.e.: given "From: a!b To: c!d", a From: reply at c will send mail to a!b and a!c!d. Very dull.). A related point which I did not mention, recipients should be specified in their shortest form; if somebody sends mail to ihnp4!wucs!plus5!hokey, the To: line should only say plus5!hokey. (Yes, I know this is a bad example because plus5 is not syntactically rooted.) There are nasty ramifications of multiple recipients while the mail heads off via multiple sites. I suspect the solution to this is to always use "short" recipients and put enough smarts into the mailers to pass stuff along to smarter neighbors. Always giving ! precedence over @ in a >From line can produce an erroneous parse. I think rpw once showed a very good hypothetical example of this case, and I believe Peter Honeyman has done likewise. -- Hokey ..ihnp4!plus5!hokey 314-725-9492