Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP Path: utzoo!watmath!clyde!cbosgd!ncr-sd!greg From: greg@ncr-sd.UUCP (Greg Noel) Newsgroups: net.mail Subject: Re: Pathalias/uumail: some algorithms and questions Message-ID: <404@ncr-sd.UUCP> Date: Mon, 10-Feb-86 18:46:59 EST Article-I.D.: ncr-sd.404 Posted: Mon Feb 10 18:46:59 1986 Date-Received: Wed, 12-Feb-86 06:23:38 EST References: <122@delftcc.UUCP> <400@ncr-sd.UUCP> Reply-To: greg@ncr-sd.UUCP (Greg Noel) Organization: NCR Corporation, San Diego Lines: 67 In article <400@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >I think there should be a forum for the discussion for the algorithms, the >computational model, and for the interchange of code. ..... > >OK, domain mailer gurus, how about it? Would you participate in a mailing >list to develop the underlying algorithms and thereby reduce the distance >between your separate implementations? I've gotten some replies to this; it seems that there is some interest in such a mailing list. I'm still collecting names; if anybody is intested in participating in such a list, drop me a line. One of the respondants was J. Eric Roskos, who points out that the following could be interpreted as somewhat gratuitious: >Oh, to answer some of your questions, smail has a much better nomenclature >for describing the types of mail routing; most of your variations are >included, as well as some others. Well, I didn't intend it that way, but under the cirumstances (there was a very pretty lady blowing in my ear so I was, um, under some pressure to finish the reply quickly) I was a little briefer than I could have been. In any event, I will expand a bit on how smail describes it. Smail allows you to determine how each address is evaluated. (The following is an over-simplification, and uses the names from the Beta version -- the distribution names were cleaned up, presumably to protect the guilty.) There are four ways in which an address is considered; one at-based scheme and three bang-based schemes: a. The at-based scheme is well defined in RFC-822, so I won't go into it. (Although it didn't handle @host,@host:user@host; I hope this was fixed in the production release.) b. NORMAL bang-routing is just to pass the mail to the left-most host. If the left-most host is not directly connected, it is an error. Actual routing is performed only if the left-most host is a domain name (i.e., it has dots in it). You can consider this mode to be a replacement for rmail without being too far wrong. c. PUSHY bang-routing routes (i.e., looks up the path) to the left-most host. The documentation claims that this is so you can impress your friends with how many sites you can reach. d. BULLY bang-routing starts at the \right/-most host and works to the left. It routes to the first host it finds to which it can do PUSHY routing. The choice of algorithm is done by flags, so hybrid addresses are treated by whatever is the dominant mode; smail doesn't try to make the decision. If the address mode is wrong (i.e., no @-signs in an address being at-routed), it will try the other mode. If that fails, it will route it to a local delivery agent. At-routing is essentially treated as a PUSHY bang-routed address. If routing was done, the new full-path address is ROUTED, which is essentially the NORMAL bang-routing case above, and a delivery agent (uux or sendmail) is invoked to do the transmission to the next site. (The choice of delivery agent is wired in at compile time; it must be either uux or sendmail.) The point of all this is that the nomenclature is independent of the particular implementation. In fact, I would argue that the algorithms implied above are tactical routines that all of the domain mailers use in one form or the other, and that the major difference between them is at the level of strategy -- which fragment to use in which order, and what kind of external hints can be used to better the routing process. I would like to see the development of a common set of routines shared between the various mailers/routers; then we could talk rationally about the actual differences in strategy without the obscuring cloud of implementation considerations. Enuf soapboxing! Anybody else want to talk about it on a mailing list? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA