Xref: utzoo comp.sources.bugs:2794 comp.mail.uucp:5737 can.uucp:233 can.usrgroup:684
Path: utzoo!attcan!lsuc!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.sources.bugs,comp.mail.uucp,can.uucp,can.usrgroup
Subject: smail-2.5 fix for domain gateway routing
Summary: the right one!(?)
Message-ID: <1991Jan14.234354.8055@eci386.uucp>
Date: 14 Jan 91 23:43:54 GMT
Reply-To: woods@eci386 (Greg A. Woods)
Organization: Elegant Communications, Inc.
Lines: 101


The following patch for smail-2.5 "correctly" (to the best of my
interpretation) repairs the domain gateway routing problem in
smail-2.5.  This problem has been plauging me for several years, but
finally got me with a commonly used local address.

In November, 1989 a work-around was posted to "ont.uucp" by Dan
Trottier <255EC962.473@maccs.dcss.mcmaster.ca>.  This fix changed the
look-up order such that "name.sub-domain.domain" was found before
".name.sub-domain.domain", which appears to be the wrong thing to do,
and doesn't really fix the problem for "sub-name.name.s-domain.domain".
I never really liked this hack and never installed the patch.  I agree
with the original look-up strategy, since finding the gateway to a
domain seems like the correct first check.

I think there have been several other versions of this patch as well.

For example (this is real, generated on eci386) the following lines
exist for xenitec in our paths file:

	.xenitec.on.ca	lsuc!utai!watmath!%s	100
	xenitec	lsuc!utai!watmath!watcgl!electro!xenitec!%s	100
	xenitec.on.ca	lsuc!utai!watmath!xenitec.on.ca!%s	100

Here's the problem, as told by Mark Moraes <moraes@cs.toronto.edu>:

	When looking up "foo.xenitec.on.ca", first look it up as is.
	If matched, replace the %s in the path with username.  Else,
	remove the first domain component (foo) and look up
	".xenitec.on.ca".  If that matches, replace the %s in the path
	with THE FULL DOMAIN NAME AND username.  I.e:

		lsuc!utai!watmath!foo.xenitec.on.ca!user
	NOT
		lsuc!utai!watmath!user

	smail2.5 interprets it the latter way, which is wrong.

	This point is not very clearly made in the pathalias docs -- I
	had to get Rayan to explain this to me :-)

	I believe dan@maccs.uucp has a fix for this one.

Well, since I didn't like Dan's fix, here's mine.  (BTW, this fix is
effectively a one-liner, and is a bit of a hack, but it tests out
fine for everything I could think of.)

I guess the assumption pathalias is making by emitting such a path is
that the gateway knows how to get to the sub-sub-domain better than
the sub-domain host itself, if there indeed is one.

---------------- cut here and hand to patch ----------------
Index: resolve.c
*** Standard Input	Wed Dec 31 19:00:00 1969
--- resolve.c	Mon Jan 14 17:18:17 1991
***************
*** 224,231 ****
--- 224,234 ----
  /*
  **  Try to get the path for successive components of the domain.  
  **  Example for osgd.cb.att.uucp:
+ **	.osgd.cb.att
  **	osgd.cb.att
+ **	.cb.att
  **	cb.att
+ **	.att
  **	att
  **	uucp ( remember stripping top level? )
  **	SMARTHOST
***************
*** 232,239 ****
  **  Returns with error if we find no path.
  */
  	for(step = 0; (step < domains); step++) {
! 		if((getpath(domainv[step]-1, path, cost) == EX_OK) /* w/ dot */
! 		|| (getpath(domainv[step]  , path, cost) == EX_OK))/* no dot */
  			break;
  	}
  
--- 235,250 ----
  **  Returns with error if we find no path.
  */
  	for(step = 0; (step < domains); step++) {
! 		if(getpath(domainv[step]-1, path, cost) == EX_OK){/* w/ dot */
! /*
! ** fool the call to build() below, i.e. make sure it uses UUCP as the
! ** form of address such that the domain is appended the path
! */
! 			if(!step) step++;
! 			break;
! 		}
! 		if(getpath(domainv[step], path, cost) == EX_OK)/* no dot */
! 			/* pathalias includes domain in path */
  			break;
  	}

-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL