woods@hao.UUCP (Greg Woods) (01/09/87)
I believe that after beating my head against the wall all day over this, I
have found what appears to be a bug in pathalias. I know the authors have
said that this is an unsupported program so there's no point in asking them
for help, but I'm hoping someone on the net has seen this and either has
a fix or even just a kludge in our map entry to get around the problem.
The trouble comes because we are on three different networks (including UUCP),
and no one machine is on all 3. I am trying to get a database on our UUCP host
(which is also on the second network) together so that I can correctly route
mail destined for the third network via a machine that is on both the second
and third networks. Here is a simplified version of the problem:
first @second(LOCAL)
second .third(LOCAL)
when run through "pathalias -c -l first", produces (cost "LOCAL"=25):
0 first %s
25 second %s@second
4050 .third %s@second # Where the HELL does the extra 4000 come from???
while if I use a right-! connection, I get:
first second!(LOCAL)
second .third(LOCAL)
which, when run through the same "pathalias -c -l first", procudes:
0 first %s
25 second second!%s
50 .third second!%s
In my actual case, the "second" on the first line is really a local network,
and the "second" on the second line is a local host on that network, but
I see the same cost variance either way. So, why the cost difference? Have I
done something stupid, or is this a bug or an undocumented feature? And most
importantly, how can I kludge my map entry so that I get the first case
syntax with the second case cost? The cost is critical, because the first
case cost is so high that when I blend our map entry in with the full mod.map
database, pathalias does not want to use our local connection to .third but
rather tries to use someone else's (which happens to be over a long-distance
uucp link!) In order for the second case syntax to be acceptable I'd have
to make hacks to our sendmail.cf file, which I am trying to avoid because
it would probably come back to bite me later. I checked the map entry for
the people who had a connection to .third, and their cost is normal because
all they have is
theirsite .third(LOCAL)
and the generated path to .third is "LDlink!theirsite!%s".
--Greg
{hplabs, seismo, noao, nbires} !hao!woods
CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPAgreg@ncr-sd.UUCP (Greg Noel) (01/10/87)
In article <486@hao.UUCP> woods@hao.UUCP (Greg Woods) writes: > I believe that after beating my head against the wall all day over this, I >have found what appears to be a bug in pathalias. No, it's not a bug, nor even a feature (this time). It's even documented! But it \is/ an unexpected interaction of two elements. To reprise, the data: >first @second(LOCAL) >second .third(LOCAL) produces: >0 first %s >25 second %s@second >4050 .third %s@second # Where the HELL does the extra 4000 come from??? This last line is really: 4050 .third .third!%s@second but since an element of the path begins with a dot, it is assumed to be a domain name (a form of psuedo-host) and is suppressed in the output. Note that this is actually the dreaded mixed-mode (ambiguious) path. Somewhere the pathalias documentation claims that it will avoid creating such paths; the way that it actually does this is to penalize such paths an extra 4000 in routing cost. The cure is simple -- declare the domain to be @-routed as well: second @.third(LOCAL) which will produce the expected 0 first %s 25 second %s@second 50 .third %s@second # really %s@.third@second -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
woods@hao.UUCP (Greg Woods) (01/13/87)
In article <1292@ncr-sd.UUCP>, greg@ncr-sd.UUCP (Greg Noel) writes: > In article <486@hao.UUCP> woods@hao.UUCP (Greg Woods) writes: > To reprise, the data: > > >first @second(LOCAL) > >second .third(LOCAL) > > produces: > > >0 first %s > >25 second %s@second > >4050 .third %s@second # Where the HELL does the extra 4000 come from??? > > The cure is simple -- declare the domain to be @-routed as well: > second @.third(LOCAL) > which will produce the expected > 0 first %s > 25 second %s@second > 50 .third %s@second # really %s@.third@second Thanks for that information, because it does solve the first problem I had, but unfortunately it brings up another one. This all started because I am trying to install "smail", a back end to sendmail(8) recently posted to mod.sources which supposedly handles domain-based addresses. My experience shows that it would probably drop right in *if* all our connections were via UUCP. Unfortunately they are not, and all the non-uucp links are giving me fits. I'd like to ask those out there who ARE running "smail" for help. The above situation still exists, and now that the pathalias problem is fixed (so that the route to the domain .third via our machine "second", which is connected to "first" via a local Ethernet, is the one that makes it into our database). The problem is that when I mail to "user@host.third", it bounces, and I don't know how to fix it. What happens is that the changes to the sendmail.cf file (which are documented in the information that comes with the smail sources) correctly recognize this as a domain-based address and pass it on to smail. Smail changes this address to host.third!user@second, as per the above pathalias output, but then it doesn't seem to know what to do with it after that. I get the mail bounced with the message that host.third is an unknown host. I would like it to do something sensible, like send it over the ethernet to "second" and let that host deliver it. How do I set it up to do this? Do I have to hack sendmail.cf (gag) to handle all domains that are not reached via UUCP links? If so, what ruleset should that kind of hack go into? Any hints or advice would be appreciated, I will post the final solution in this group if one is ever found (this does not seem like it should be all that uncommon a setup). --Greg {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA Soon? woods@hao.ucar.edu
mb@ttidca.UUCP (Michael Bloom) (01/15/87)
>do with it after that. I get the mail bounced with the message that host.third >is an unknown host. I would like it to do something sensible, like send it >over the ethernet to "second" and let that host deliver it. When I first tried installing smail, it did not recognize any of the hosts on my ethernet. Turned out to be the line containing "/etc/hosts.ether %s" which was preceded by the comment "could just be a link to /etc/hosts". In my case, it couldn't, because the sendmail on the particular machine we talk to the outside world from did not know what to do with the %s. Instead, I had to create /etc/hosts.ether as a file containing all our ethernet hostnames, one per line. We had a similar problem earlier with L.sys, and this kind of solution also did the trick. Michael Bloom mb@ttidca.tti.com, if you are not on arpa, else mb@ttidca.uucp. (We should have our arpa forwarder in about 3 weeks)
greg@ncr-sd.UUCP (Greg Noel) (01/16/87)
In article <489@hao.UUCP> woods@hao.UUCP (Greg Woods) writes: > Thanks for that information, because it does solve the first problem I had, Glad I could help. >but unfortunately it brings up another one. ..... > all the non-uucp links are giving me fits. >..... Smail changes this address to host.third!user@second, >as per the above pathalias output, but then it doesn't seem to know what to >do with it after that. I get the mail bounced with the message that host.third >is an unknown host. .... [He would like to send it over his ethernet to >"second" and let it handle the delivery the rest of the way.] Hmmmmm...... It does seem that this shouldn't be too uncommon. I'm not in a good position to answer this question directly, since we are not running the standard version of smail. We had similar problems, so we added a number of capabilities to smail that allow it to handle this situation easily. (Before you ask, we have sent our changes back to Larry Auton; hopefully, he should eventually include them as part of the standard smail distribution. If you want to see it, talk to him; we are simply not set up to be able to handle such requests.) With our modifications, it is easy to say that the connection to "second" is via a special mailer (in this case, ethernet); it should even be possible to say that the mailer was simply a disguised call on sendmail and send it there for delivery. I suppose that what I'm trying to say is that I don't know if it can be solved with the standard smail, but that there is a version of smail that does solve the problem -- and easily. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
woods@hao.UUCP (01/16/87)
I would like to thank all those who wrote me or posted articles in response
to my questions about pathalias. The two questions and their answers are:
1) Is it a bug in pathalias that appears to make a path like second!third!user
cost less than third!user@second? Answer: No, it is deliberate behavior.
Peter Honeyman (princeton!dwon!honey, one of the authors of pathalias) tried
to explain his reasoning to me, but I'm afraid I did not understand it.
But at any rate, it is a deliberately designed feature, not a bug.
2) It turns out that question #1 was moot in my situation, because question #2
is: can I make smail(8) correctly route messages that are supposed to go
via connections other than uucp? Answer: no, I have to hack sendmail.cf,
and it is a HORRIBLE kludge but it works. The kludge in ruleset S0 involves
defining a class of domains that have to be routed through a different
machine on our local Ethernet. It looks something like this:
# Domains that must gateway via hao-hw
DGcsnet
CGarpa csnet ncarnet
# Class "M" are machines on the NCAR hyperchannel (ncarnet) network
R$=M!$+ $2%$1@hao-hw ntwkhost!user
R$+@$=M $1%$2@hao-hw user@ntwkhost
R$+<@$=M> $1%$2<@hao-hw.LOCAL> u<@ntwkh>
# route CSnet mail via hao-hw
R$+@$+.$=G $1%$2.$3@hao-hw u@Gdomain
R$+<@$+.$=G> $1%$2.$3<@hao-hw.LOCAL> u<@Gdomain>
This converts an address of the form user@ncarhost to user%ncarhost@hao-hw,
and user@host.csnet to user%host.csnet@hao-hw. These addresses are parsed to
be deliver via Ethernet to hao-hw, which is what I wanted. HW knows that '%'
should be converted to '@'.
As Leonard Pinth Garnell would say: Awful, awful, COULDN'T be wuss! RAILLY
sucks! And I must say, I myself programmed this VEDDY badly...
--Greg
--
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu