smail-2.5 fix for domain gateway routing
Greg A. Woods
woods at eci386.uucp
Tue Jan 15 10:43:54 AEST 1991
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 at 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 at 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 at 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
More information about the Comp.sources.bugs
mailing list