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