Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!ihnp1!ihnp4!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.mail Subject: Re: Mail routing -- problems showing up Message-ID: <1423@peora.UUCP> Date: Sat, 10-Aug-85 00:31:00 EDT Article-I.D.: peora.1423 Posted: Sat Aug 10 00:31:00 1985 Date-Received: Tue, 6-Aug-85 09:57:42 EDT References: <1383@peora.UUCP> <9546@ucbvax.ARPA> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 66 In my previous posting, I promised to suggest an approach to simplifying the UUCP routing problem. Here it is. The following are a set of basic principles I think would help make the UUCP network work better. I hope you can comment constructively on them, rather than just arguing some more. The following discussion assumes that you have received a piece of mail via UUCP. 1) Do not modify any routing information you have already been given. I.e., if in your uux'ed command you received from the previous site, there is some a!b!c... path, do not try to "optimize" it. Assume that, for whatever reason, the information you have been given is correct. If it's not, it is a problem of the site that generated the routing. Giving unsolicited help only complicates the problem. 2) In the routing information you have been given, if the next site on the path is adjacent to you, deliver the message via UUCP to that site. (Remember, this assumes it came via UUCP. If it came by another transport mechanism, you should use that transport mechanism's delivery rules.) 3) If the next site on the path is NOT adjacent to you, this is a nameserver request. This is the alternate case to #1 above; i.e., this constitutes a REQUEST for help, which you can give if you are able. If the named next site does not contain a ".", generate a path to the site and prepend it to the path you've been given, if you can. If you can't, return the mail as undeliverable. If it contains a ".", or is an RFC-style address with no remaining "!", forward it to the site that is the nameserver for the designated domain, unless you can generate the path yourself (in which case you ARE a nameserver for the designated domain). Some corollary rules: a) Don't read the message header (the To:, etc) unless there is no other choice. Use the routing information you were given by the remote command invocation. b) NEVER edit existing lines in the message header. This doesn't mean you can't add lines (e.g., "Received:" lines, etc.), but you should not make transformations in the syntax of the addresses in the header, etc. [I have seen dozens of these transformations made in mail that gets returned to me for one reason or another; they are almost invariably WRONG.] The originating mailer should provide a unique and unambiguous return address (not path) telling who the message is from; if it doesn't, it is the originating mailer's problem, not yours. (Note that I guess this means that I differ somewhat from Peter Honeyman's proposal in that regard, in that I think this return address should be an RFC-style address, i.e., that all networks should try to adhere to a uniform address syntax. Again, note that this has nothing to do with routing -- it's just the syntax of what's in the From: line on the message.) c) Treat all routing information provided via the UUCP network as having the syntax !. This solves your ambiguity problems, and eliminates the need for complicated syntax transformations at gateways. (Unless, of course, you have a path that cannot be expressed in the current routing language; I think this is a shortcoming of the languages, though, and is the strong point of the proposed all-! language, eventhough I tend to doubt that language is practical for other reasons related to the need to know all other route-specifying languages at the gateways, which is an unreasonable requirement in the real world.) -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Vg frrzf yvxr hc gb zr."