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!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.mail Subject: Re: More thoughts on mail relays Message-ID: <1761@peora.UUCP> Date: Fri, 1-Nov-85 08:35:40 EST Article-I.D.: peora.1761 Posted: Fri Nov 1 08:35:40 1985 Date-Received: Sun, 3-Nov-85 05:01:04 EST References: <1813@umcp-cs.UUCP> <1746@peora.UUCP> <909@plus5.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 141 > JER, I'm sorry you spent 2 weeks making MH.5 run under SysV. MH.6 requires > almost no effort, and should be out very soon. You've obviously never tried to order an outside piece of software from within a large software organization! It was no problem, really... much of the time was spent in porting our router and nameserver. I had promised earlier to write an article on porting MH.5, but then Mr. Rose wrote and told me that MH.6 was coming out soon, so I decided not to. Anyway, to turn to the issues you raised... I can certainly appreciate the arguments against using "@'s" in UUCP routing strings. I strongly disagree with calling them "hybrid addresses," however, because they are not addresses, they are routes, and they are not hybrid, since "@" doesn't mean anything to any but a few modified Unix sites. > I wonder who else has tried to sway you toward our perception of reality. No one. The funny thing is, it seems to be a vocal minority who advocate giving "@" special status in the routing language. Thus the only people who have tried to convince me (other than the folks at Seismo) are the ones who have written in here. > Implementation #1: Permit hybrid routes, and make everybody parse them > the same way. > Problems: Doesn't work at gateways. It does, too. But we've been over this so many times, algorithms and all, that I'm tired of reiterating it. > Requires smart mailers in lots of places, or requires users to know > how to specify the route. No it doesn't... it doesn't require any more smartness to write in one routing language than the other... what's the difference between (assuming a site that only has Unix mail and no router) writing petsd!vax135!ucbvax!sam@slowvax.ARPA or petsd!vax135!ucbvax!slowvax.ARPA!sam It just involves permuting the last two name tokens, and replacing the last @ with a !. > Falls apart when a site decides to become a gateway, because the > routing rules change for everybody who passed mail through that site. No it doesn't... this site presently is not a gateway, however it is a domain nameserver and a site many people route through here in Florida. However, I wrote the router with the intent that someday it would become a gateway, since we have machines here that are not on the UUCP network. If we ever make that conversion, I will have to add the change to rmail which the person at NCR in Torrey Pines recommended awhile back, whereby the domain table also specifies the program to run to exit the UUCP network (there's even an unused field in the domain table for that purpose... many people have been trying to guess what it's for). Presently it's much simpler; since the original code didn't support the ..!slowvax.ARPA!... syntax (although I agree that that is a good addition) it was not necessary to give any special handling, so when the "!'s" ran out, I would route it out of the network and into the inter-network delivery program. The model I presently use is that the local mail system is a separate network; under this model, all sites are "gateways", and this is entirely reasonable, very regular and orthogonal. With the new syntax, when it does a domain lookup it needs to also decide whether it's time to leave the UUCP network, which there's a field but no code for yet. But the syntax will not change. > Requires *everybody* who is accepting either ! or @ mail to make sure > they follow the "rules", and possibly change the way they parse. This > last bit means work for the admin, and an overall education program for > lots of people. It has not been demonstrated that this implementation > is even workable, due to the problems of routing *through* gateway sites. In fact, this is exactly the problem with the no-@ approach. Presently everyone follows the "rules" automatically, except at a few sites; and Gene Spafford just posted a Sendmail configuration file that makes the sendmail sites work too. However, now it is being proposed to distribute a new program that imposes new rules (an excellent program, I understand, and not one I am criticizing except on this one minor point). There also should be no problem with routing through gateway sites. The problem you are alluding to, I think, is the one in which some gateway sites route all their mail through Sendmail, and have sendmail always give "@" precedence. As for requiring additional education for people... people are now using a particular syntax to reach the ARPAnet, for example. Soon it won't work any more, and they will have to be >reeducated<. > Implementation #2: Permit hybrid routes, and make every site which accepts > ! or @ make an "intelligent" choice about what the sender really wants. But not an artificially intelligent choice, you understand... :-) > Problem: Pathparse has't been released yet. When it is released, it > will require an "appropriately" sized database, which must be maintained. > Maintenance is not a big issue. I've stated repeatedly here that the *sender* should write RFC822 addresses, which should be parsed with "@" precedence, and that sites along the way should give "!" precedence. Pathparse is a very good enhancement that allows the user to have more flexibility in writing what he or she wants to be the destination of the message, but I am making an argument on behalf of sites that have no special software at all. > Extra Protection: Keep the From: line in ! format in UUCP land. This way, > sites which prepend their name will take b!a and produce c!b!a or b!a@c, > either of which is "correct". I don't like this approach, and I wish we could discuss this, or some other topic, instead of going over and over the @-precedence issue. Presently the many strange ways sendmail sites macerate the routing stamps on the fronts of the messages cause a lot of problems generating replies. If you are going to argue in favor of RFC822 compliance (which I think you should), then you shouldn't compromise on these issues. > I have it on good authority that sendmail source can be put on any system > licensed for SysV or 4.2 (or later) BSD. These sources seemed to think > that there is a 99% chance that sites with 32V, V7, or SysIII licenses > would also be able to have sendmail. 4.1BSD was not mentioned, but I doubt > there would be a problem. I don't see the point to this. Why would other sites want to install Sendmail? I recall what they told me when I first started working on the mail system here... "Don't even think of installing Sendmail." Why should your average site install sendmail? It was written for use at gateways. I get all the advantages of Sendmail, even a nice "Received:" line on the message, with much simpler software, since I don't need to make any of the transformations that Sendmail makes in the headers. If I was at a gateway, and the other network(s) didn't take the RFC822 syntax, then I would probably be interested in Sendmail. (Though I wouldn't change the current transport software for UUCP.) Now let's talk about something new. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642