Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site plus5.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!plus5!hokey From: hokey@plus5.UUCP (Hokey) Newsgroups: net.mail Subject: Re: More thoughts on mail relays Message-ID: <909@plus5.UUCP> Date: Wed, 30-Oct-85 20:08:43 EST Article-I.D.: plus5.909 Posted: Wed Oct 30 20:08:43 1985 Date-Received: Sat, 2-Nov-85 04:18:42 EST References: <1813@umcp-cs.UUCP> <1746@peora.UUCP> Reply-To: hokey@plus5.UUCP (Hokey) Organization: Plus Five Computer Services, St. Louis, MO Lines: 74 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 also state that after privately debating with MRH the viability of hybrid routes (due to the ambiguity problem), the two of you reached "an impasse". Gee, whiz! I tried to explain the problem to you as well. The conversation sort of died on the vine. I wonder who else has tried to sway you toward our perception of reality. Problem #1: ! vs. @ parsing ambiguity in the UUCP transport layer. Solution: resolve the ambiguity Implementation #1: Permit hybrid routes, and make everybody parse them the same way. Problems: Doesn't work at gateways. Requires smart mailers in lots of places, or requires users to know how to specify the route. Falls apart when a site decides to become a gateway, because the routing rules change for everybody who passed mail through that site. 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. Implementation #2: Permit hybrid routes, and make every site which accepts ! or @ make an "intelligent" choice about what the sender really wants. 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. Implementation #3: Prohibit hybrid routes. Problem: Unless a site has a mailer which can handle minimal routing, users who wish to *initiate* (*not* reply to net articles) have to know how to specify the path to the nearest smart machine. This implementation has the dubious advantage of breaking things no more than once. It brings to a head the issue of education. Problem #2: Many sendmail sites *always* prepend their name to the From: line. This is especially nasty since @ has clear precedence over ! in this field, and changing a@b to c!a@b means b->c->a, *not* c->b->a. Solution: Find them, and fix them. Implementation: Get the offender to correct it. 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". The To: line is used by mailers to build the recipient list. This includes "traditional" dumb mailers (binmail). Problem #3: Dumb mailers will produce hybrid routes if any recipient has an @ in his address. Solution: Keep recipient fields in ! format. Implementation: Do it! Anyway, you go on to state (correctly, I believe) the problem lies with the relatively difficult job of making sendmail work in the UUCP environment. Yes, if people didn't run sendmail, we wouldn't have the problem. However, people use sendmail. (Unfortunately, the major solutions you propose *require* people to change their software. Additionally, I *think* your solutions will not work at gateway sites.) Sendmail.cf files are not easy for everybody to handle. I know I have problems with them. HOWEVER, newer versions of sendmail make it *much* easier to write config files, and several people are writing versions which are capable of supporting a wide variety of system configurations with very little maintenance effort. 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. -- Hokey ..ihnp4!plus5!hokey 314-725-9492