woods@eci386.uucp (Greg A. Woods) (01/15/91)
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-ORWELLbarrett@Daisy.EE.UND.AC.ZA (Alan P. Barrett) (01/17/91)
In article <1991Jan14.234354.8055@eci386.uucp>, woods@eci386 (Greg A. Woods) writes: > 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. I believe that the right thing to do is this (description taken from the list of changes in my version of smail2.5): | (5) When a line in the paths file starts with a dot then the '%s' has | to be replaced by 'domain!user', not just by the 'user' name. | [apb] | | (12) When looking in the paths file for a route to something like | 'abc.def.ghi,' first try the full name without an initial dot | ('abc.def.ghi'), before trying with an initial dot | ('.abc.def.ghi'). Both might appear in the paths file, and we want | to find the right one first. If that is not found, then continue | as before, looking for '.def.ghi', 'def.ghi', '.ghi' and 'ghi' in | that order. [apb] Greg's patch fixed number 5, but not number 12. Mail addressed to user@abc.def.ghi might be routed differently from mail addressed to user@subdomain.abc.def.ghi. This means that, when mail arrives addressed to user@abc.def.ghi, smail should choose the 'abc.def.ghi' paths line in preference to the '.abc.def.ghi' line. Mail if you are interested in the apb/mje patches. The patch file is about 60k in size, and the feature list appears after my signature. --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa Internet: barrett@ee.und.ac.za (or %ee.und.ac.za@saqqara.cis.ohio-state.edu) UUCP: m2xenix!quagga!undeed!barrett PSI-Mail: PSI%(6550)13601353::BARRETT Changes marked [apb] are mine (Alan Barrett <barrett@ee.und.ac.za>) and changes marked [mje] are originally by Mark Elkins <mje@olsa99.uucp>. There are a few bug fixes: (1) The binary search routines were wrong (in two separate places, dealing with the paths file and the fullnames file). [apb] (2) Addresses that contained characters that are special to the shell were not treated properly. Now the address is quoted in such a way that the shell will never clobber them. (Changed definition of LARG and RARG in defs.h, added calls to sh_quote() in several places.) [apb] (3) There are a few more places where the address should be checked for "postmaster". [apb] (4) The stderr file should be opened in append mode, so that stdout and stderr don't get garbled in the "standard error follows" section of a return-to-sender error message. [apb] (5) When a line in the paths file starts with a dot then the '%s' has to be replaced by 'domain!user', not just by the 'user' name. [apb] There are a few enhancements: (1) You can define FAILPOSTMASTER (in defs.h) to make the postmaster get a copy of all failed mail messages. [apb] (2) You can define DOT_EOF and DOT_EOF_ALL (in defs.h) to modify smail's behaviour when it sees a message that contains a line with only a dot on it. The original version treated it like EOF, but now you can tell the program to (a) always treat a dot line as EOF, (b) treat a dot line as EOF only if input is from a tty, or (c) tell the program to never treat a dot line as EOF. [apb] (3) The arpadate function now returns a string that is legal according to a strict interpretation of RFC822. See the comments in the code for details. [apb] (4) "postmast" is now treated exactly like "postmaster". This is for compatibility with sites that have 8-character user names. [apb] (5) Look for a smart-host even if routing is not set to REROUTE. This may not have been such a good idea, but I like it and it works better now that change number 9 below has also been made. [apb] (6) If we get a local address with a '%' in it, change the '%' to an '@' and try again. [apb] (7) If a path cannot be found in the usual way, check whether the desired domain (or host) name is a truncated version of a known domain name. This will find 'abc.def.ghi' in the paths file if it is looking for 'abc.def'. Controlled by TRUNC_DOM in defs.h. [mje] (8) If that also didn't work, see whether the leftmost part of the desired domain (or host) name matches the leftmost part of any domain (or host) name known to the paths file. This will find 'abc.something.else' or plain 'abc' in tha paths file if it is looking for 'abc.def'. Controlled by TRUNC_DOM_LEFT in defs.h. [mje] (9) If that also didn't work, see if the leftmost part of the desired domain (or host) name matches any of the uucp neighbours reported by the uuname command. This will find 'abc' in your L.sys or Systems file if it is looking for 'abc.def.ghi'. Controlled by UUNAME in defs.h. [mje] (10) Remove all explicit routing through the local system during the alias processing stage, and be much more robust about deciding when a domain name refers to the local system. Now, paths like hostname!hostname.hostdomain!hostname!user will correctly resolve to 'user' instead of being treated as erroneous. There are still some problems that may show up if routing = REROUTE and the local system name appears at the end of a path via other systems. [apb] (11) Try harder to be sensible about quoted local parts in addresses like <"user"@myname>, or even <"user@some.where"@myname.mydom>. [apb] (12) When looking in the paths file for a route to something like 'abc.def.ghi,' first try the full name without an initial dot ('abc.def.ghi'), before trying with an initial dot ('.abc.def.ghi'). Both might appear in the paths file, and we want to find the right one first. If that is not found, then continue as before, looking for '.def.ghi', 'def.ghi', '.ghi' and 'ghi' in that order. [apb] (13) New RLFROM macro in defs.h allows the "From " line in mail from a remote user to a local user to be different from that in mail from a remote user to a remote user. Useful because mail sent via uucp should have 'remote from thishost' in the From line, but you may not want 'remote from otherhost' in the From line of mail delivered locally. [apb] (14) Get real name in the From line even if the person sending the mail is su'ed to another user id. [mje] (15) Make the stderr file unbuffered, to help with debugging. Line buffering would also be fine, on systems where it works. [apb] There are a few gratuitous changes: (1) The version name (in defs.h). (2) The LMAIL macro in defs.h calls /usr/local/bin/deliver, which I prefer because it doesn't chop messages off when it sees a dot line. "deliver" also allows one to do some fancy stuff, but I haven't really tried that. [apb] (3) MAXCLEN in defs.h is much bigger, to allow more addresses to be passed with a single copy of a message. Make sure my value isn't too big for your system, and remember that smail will actually exceed the limit you specify here, so be conservative. [apb] (5) The text of the return-to-sender message is altered. [apb] (6) Indentation has been changed in functions that were creeping off the right hand side of the page. [apb]
gamiddleton@watdragon.waterloo.edu (Guy Middleton) (01/23/91)
In article <1991Jan14.234354.8055@eci386.uucp> woods@eci386 (Greg A. Woods) writes: > 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. I think it would be nicer if the result was lsuc!utai!watmath!xenitec!user That way, I could use smail on watmath to decide that foo.xenitec.on.ca was a local connection, instead of having to embed that information in my sendmail.cf file.
merce@iguana.uucp (Jim Mercer) (01/24/91)
In article <1991Jan23.061830.19719@watdragon.waterloo.edu> gamiddleton@watdragon.waterloo.edu (Guy Middleton) writes: >In article <1991Jan14.234354.8055@eci386.uucp> woods@eci386 (Greg A. Woods) writes: >> 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. > >I think it would be nicer if the result was > > lsuc!utai!watmath!xenitec!user > >That way, I could use smail on watmath to decide that foo.xenitec.on.ca was a >local connection, instead of having to embed that information in my >sendmail.cf file. i think this would be best: lsuc!utai!watmath!xenitec!foo.xenitec.on.ca!user that way xenitec at least has a chance at determining which sub-system "user" is on. otherwise, you have to assume that xenitec has aliases on it for ALL of the users on ALL of it's subdomain. i beleive this was stated in a previous article (woods@eci386 or bdb@becker) where it basically said that: user@sub.registered.domain might find an entry in the paths database like: .registered.domain <appropriate path to .registered.domain MS'er (server)>!%s and that %s would be the full address specified (ie sub.registered.domain!user) -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) (01/24/91)
In article <1991Jan23.061830.19719@watdragon.waterloo.edu> gamiddleton@watdragon.waterloo.edu (Guy Middleton) writes: >In article <1991Jan14.234354.8055@eci386.uucp> woods@eci386 (Greg A. Woods) writes: >> 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 lsuc!utai!watmath!xenitec!foo.xenitec.on.ca!user should be what is produced. >I think it would be nicer if the result was > > lsuc!utai!watmath!xenitec!user > >That way, I could use smail on watmath to decide that foo.xenitec.on.ca was a >local connection, instead of having to embed that information in my >sendmail.cf file. If you aren't the gateway, you shouldn't have to do anything. I understand that IDA sendmail provides much better handling for UUCP/Internet hosts and gateways. (I have the binaries, I'm just scared to install it now with ~75 messages/day going through my system.) The IDA systems seems to prefer rabid-rerouting (it certainly makes it easier) but doesn't seem to insist upon it. -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me Bell: (613) 237-5629 + about joining ocunix.on.ca!
rickert@mp.cs.niu.edu (Neil Rickert) (01/24/91)
In article <1991Jan24.034941.3360@Sandelman.OCUnix.On.Ca> mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) writes: > The IDA systems seems to prefer rabid-rerouting (it certainly makes >it easier) but doesn't seem to insist upon it. This is not true. The standard announced IDA package will not do any rerouting other than deliberately chosen in user databases, and NEVER does 'rabid rerouting' -- i.e. never removes uucp hosts from the address. The package does to header simplification. That is, it will change the header address: uunode1!uunode2!full.domain.name!user to full.domain.name!user (which it may reformat as user@full.domain.name). But this happens on HEADERS, not on the actual destinations which are in the envelope. It is based on the principal of using a simple address as possible, but following the envelope recipient addresses so that manual override is possible where needed. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) (01/29/91)
In article <1991Jan24.114641.5326@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1991Jan24.034941.3360@Sandelman.OCUnix.On.Ca> mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) writes: > >> The IDA systems seems to prefer rabid-rerouting (it certainly makes >>it easier) but doesn't seem to insist upon it. > This is not true. The standard announced IDA package will not do any >rerouting other than deliberately chosen in user databases, and NEVER does >'rabid rerouting' -- i.e. never removes uucp hosts from the address. I got the impression that this was an option. I did not investigate it further. Rabid-rerouting DOES have its place. The whole world isn't the Internet, and there may well be sub-nets and local organisations that are sure they know the right way to do things. >> The package does to header simplification. That is, it will change the >header address: uunode1!uunode2!full.domain.name!user to >full.domain.name!user (which it may reformat as >user@full.domain.name). In other words, it can undo some of the bad effects of some rabid-rerouters --- the desire to rewrite as full.domain.name!user which then gets further munged by the addition of uunode!full.domain.name!user several hops later. Nice! >the envelope. It is based on the principal of using a simple address as >possible, but following the envelope recipient addresses so that manual >override is possible where needed. Good. I appologize for any hints of mad-dog syndrome in IDA. >=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= > Neil W. Rickert, Computer Science <rickert@cs.niu.edu> > Northern Illinois Univ. > DeKalb, IL 60115 +1-815-753-6940 -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me Bell: (613) 237-5629 + about joining ocunix.on.ca!
woods@eci386.uucp (Greg A. Woods) (01/31/91)
In article <1991Jan24.034941.3360@Sandelman.OCUnix.On.Ca> mcr@Sandelman.OCUnix.On.Ca (Michael Richardson) writes: > In article <1991Jan23.061830.19719@watdragon.waterloo.edu> gamiddleton@watdragon.waterloo.edu (Guy Middleton) writes: > >In article <1991Jan14.234354.8055@eci386.uucp> woods@eci386 (Greg A. Woods) writes: > > 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 > > lsuc!utai!watmath!xenitec!foo.xenitec.on.ca!user should be what is > produced. > > In some other article someone else (gamiddleton?) said: > > I think it would be nicer if the result was > > > > lsuc!utai!watmath!xenitec!user And someone else also suggested: lsuc!utai!watmath!xenitec!foo.xenitec.on.ca!user > And (gamiddleton?) continues: > > That way, I could use smail on watmath to decide that foo.xenitec.on.ca was a > > local connection, instead of having to embed that information in my > > sendmail.cf file. > > If you aren't the gateway, you shouldn't have to do anything. Ah, but if I understand the map entries correctly, watmath *IS* the gateway! I'm not sure if it should be the former, (i.e. path!domain!user) or the latter (i.e. path!gate!domain!user). The pathalias output contains only the path segment, and Mark's comments indicate the former is correct (i.e. smail inserts domain!user). It seems to me that the gateway machine should indeed be the one which decides how to route into the domain. Certainly pathalias can't insert the gateway machine into the output (i.e. path!watmath!xenitec!%s), since there's no saying the gateway can be reached by '!' addressing. -- 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
moraes@cs.toronto.edu (Mark Moraes) (02/01/91)
In articles <1991Jan23.061830.19719@watdragon.waterloo.edu>,
<1991Jan24.030228.7639@iguana.uucp>, <1991Jan30.195213.12815@eci386.uucp>
"nicer" paths to xenitec have been suggested, possibly because of a
misunderstanding of what Greg and I were discussing by email. (part of
which was quoted in <1991Jan14.234354.8055@eci386.uucp>).
We weren't discussing the path to xenitec -- we were discussing the way
smail-2.5 interprets (or misinterprets!) what it finds in pathalias
output for domain gateways. xenitec was merely an example -- all data
was being quoted from Greg's pathalias output. To restate my email to
Greg with a little more context:
If the pathalias output contains a line of the form
.xenitec.on.ca lsuc!utai!watmath!%s
then smail-2.5 seems to route the address user@foo.xenitec.on.ca as
lsuc!utai!watmath!user, which is wrong.
For the pathalias output above, smail-2.5 should route
user@foo.xenitec.on.ca as lsuc!utai!watmath!foo.xenitec.on.ca!user.
Whether this is optimal or convenient is beside the point! :-)
Greg's fix was intended to correct the bug in smail2.5.
Mark.red@redpoll.neoucom.edu (Richard E. Depew) (02/01/91)
This discussion seems to have come full circle.
Unless I've misunderstood, Smail 2.5 handles domains correctly, at
least at patchlevel 3.
A paths file entry of:
.site.domain gateway!%s
fed an address of user@foo.site.domain results in a path of:
gateway!foo.site.domain!user
Isn't that what it is supposed to do?
Could it be that the "problem" was already fixed in the first
three patches? A "patched" kit is available by anonymous ftp from
tut.cis.ohio-state.edu. The "smart-host" function also works in this
version, unlike the patchlevel 0 version archived at many places.
Dick Depew
--
Richard E. Depew uunet!aablue!{redpoll,neoucom}!red
Village of Munroe Falls, OH. red@redpoll.neoucom.edu (home)
NEOUCOM, Rootstown, OH. red@uhura.neoucom.edu (work)woods@eci386.uucp (Greg A. Woods) (02/03/91)
In article <1991Feb1.024031.1859@redpoll.neoucom.edu> red@redpoll.neoucom.edu (Richard E. Depew) writes: > > This discussion seems to have come full circle. Well, I do remember posting some questions and complaints way back when I first discovered the problem. Now I've posted the fix. > Unless I've misunderstood, Smail 2.5 handles domains correctly, at > least at patchlevel 3. Fine for those who have access to "Patch #: 03", whatever that is, and if indeed it is "official". I've never heard of it. > A paths file entry of: > .site.domain gateway!%s > fed an address of user@foo.site.domain results in a path of: > gateway!foo.site.domain!user > > Isn't that what it is supposed to do? Yes! That's why I fixed "Patch #: 00" and posted the patch. > Could it be that the "problem" was already fixed in the first > three patches? A "patched" kit is available by anonymous ftp from > tut.cis.ohio-state.edu. The "smart-host" function also works in this > version, unlike the patchlevel 0 version archived at many places. Thanks millions guys for not posting the damn patches to the net in the "proper" places. I've been running smail-2.5 since it came out, and 2.3 before that, and I've been running sites with news all that time too. I've *NEVER* seen official smail patches posted. Mailers are very dear to me, and I can assure you I would remember seeing such patches if they had been posted anywhere such patches should be posted. BTW, smart-host works fine in my "Patch #: 00" version. There are numerous other little problems I have not fixed. There is the outstanding question of lookup order of ".site.domain" and "site.domain", incorrect "Received:" line generation, a few minor portability problems, XENIX incompatibility, etc. Would the keeper of this "patched" kit kindly submit it and/or the patches to comp.sources.unix, comp.sources.bugs and comp.mail.uucp? There has been nothing new for smail in c.s.u since Volume 11, ending Oct. 6, 1987, where the version I'm running was posted. What version is on uunet? Not everyone has access to ftp on the Internet, nor do all of us want it, or find it necessary. Only when something like this happens do I think the Internet clique is out to get me! :-( -- 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
gamiddle@watmath.waterloo.edu (Guy Middleton) (02/09/91)
In article <1991Jan30.195213.12815@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > > > > In some other article someone else (gamiddleton?) said: > > > I think it would be nicer if the result was > > > > > > lsuc!utai!watmath!xenitec!user > > And someone else also suggested: > > lsuc!utai!watmath!xenitec!foo.xenitec.on.ca!user This is probably most correct, I think. > > And (gamiddleton?) continues: > > > That way, I could use smail on watmath to decide that foo.xenitec.on.ca was a > > > local connection, instead of having to embed that information in my > > > sendmail.cf file. > > > > If you aren't the gateway, you shouldn't have to do anything. > > Ah, but if I understand the map entries correctly, watmath *IS* the > gateway! Yes, that's right. At least, we are the Internet MX forwarder. xenitec seems to be the gateway according to the uucp maps. I have some local input to pathalias which now seems to make smail give the correct paths, but that is not the most elegant solution.