Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site plus5.UUCP Path: utzoo!linus!decvax!decwrl!amd!dual!zehntel!ihnp4!plus5!hokey From: hokey@plus5.UUCP (Hokey) Newsgroups: net.mail Subject: Re: parsing host1!user@host2 - a new idea Message-ID: <501@plus5.UUCP> Date: Tue, 16-Oct-84 23:47:42 EDT Article-I.D.: plus5.501 Posted: Tue Oct 16 23:47:42 1984 Date-Received: Fri, 19-Oct-84 05:42:52 EDT References: <691@sunybcs.UUCP> <1606@nsc.UUCP> <1608@nsc.UUCP> Distribution: net Organization: Plus Five Computer Services, St. Louis Lines: 75 I was hoping I could stay out of this. Where do you want to use these headers? In the transport address (the stuff sent to rmail)? what about the addresses used in the From: and To: lines? The uucp-mail project has addresses these issues in gory detail. I will tell you the decisions that have been reached. I hope I don't get a lot of mail on this issue because I need to get the new mail software out in a hurry. I believe the issues should be aired ASAP. Many of the others on the project would rather wait until the software is ready before mouths are opened. I am not always wasy to work with. Many are concerned that rehashing these issues will unnecessarily delay the project. I hope I am not the only one from the project addressing these issues, because I have code to write. First, all addresses sent *from* the new software across uucp will be in strictly bang format. Mail to user@dom.ain will be converted to dom.ain!user. This works for almost all of the cases (the exception being explicitly routed RFC822 addresses across gateways, near as I can tell). Mail sent *to* the new software will accept non-hybrid addresses only, because of the parsing ambiguity. This means mail to a!b@c.d will be rejected by the new rmail. This is necessary because the mail must go through, and If, Someday, we all end up with RFC mailers, the parsing of addresses will change and then we are all in trouble again. Sendmail sites should leave the From: and To: lines *alone*. There is a difference between an address and a route. Non-RFC mailers won't look at these lines for replies, and they certainly won't update them when the mail passes through their site! These addresses should be in RFC822 format *if you are using an RFC mailer*. If a non-RFC mail message passes through an RFC mailer, it *might* add a From: line and an Apparently-to: line. The >addresses< on these lines should probably take the form "a!b!c"@thissite and thissite should be qualified (site.UUCP) if the site is registered with the Uucp Site Registry (lauren@vortex.UUCP). This implies that the mailers invoked by sendmail should be able to handle routing to non-neighbors, by using things like pathalias. Note that routing information is added, the addresses are not changed. Rob Warnock wrote a very clear discussion on the issue of route optimization which clearly states the conditions under which paths may be rerouted. Sites like ihnp4 optimize paths because many people do not have access to RFC mailers or routing software, so when people reply to news articles the mail goes along a path which is usually absurd. My solution to the problem of Path: replies to mail is for (at least) the first "smart" registered site in the path to use its fully-qualified name. This means it is safe for any other "smart" mailer to optimize directly to the last fully-rooted machine on the path. This may be enough to prevent the "optimization" of explicitly specified paths. Chuqui can still send out his looping paths to check path validity and the speed with which the message travels, without worrying that the path will be "fixed" for him. This also means that these smartmailers will handle mail to other domains as well as recognizing subdomains. Just think, no more problems with the duplicate named machines gang, vortex{.DEC,.UUCP}, rigel{.sun.UUCP, .oddjob.UUCP}, regina{.DEC,.UUCP}, and a host (no pun...) of others! Leaves you kind of breathless, huh? This also means that you could send mail to, say, ucbvax!site.CSNET!user and not have to worry about the hilarious contortions with csnet-relay. Specifically, you would only have to address the mail to *any* convenient smarthost!do.ma.in!user and it will get there (assuming the addressee exists!). I have left out a lot of points in my discussion. These ideas have been gone over quite thoroughly by many people, and I have done a mediocre job of covering the issue. Many of the problems must be solved in specific places. The use of parentheses in an address will mess up most sendmail sites in the universe. We can leave most of the routing software alone if we have user-interface mailers which do the job they are supposed to do, specifically, produce an *appropriately* formatted mail message with the help of the user. This stuff must be easy to use, and should not get in our way. We are getting there. -- Hokey ..ihnp4!plus5!hokey 314-725-9492