🚀 go-pugleaf

In article <287@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
|In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes:
...
|Easy send it; if it bounces, that's a failure to resolve that path.
| 
|> You don't have the needed information on your machine.  NOBODY does.
|> The only information you have is the UUCP Project database, and that's
|> gauranteed to be at least 1 to 2 months out of date.
|
|Nonsense.  I have much better info than that.  My mailer extracts the
|paths from all incoming mail and puts it (with a timestamp) into the
|database.  I thus have good info on good paths to those people who
|have sent me mail lately.  This is at worst the same data as is used
|by the mailers; it is usually better.

Excuse me, but that's not always the case. Things like the net map are
smart enough to understand that all paths are not bidirectional, or at
least not equal in cost in both directions. Your reversal of the
incoming path may produce an inefficient or inoperative path.

Two real examples:
	The machine sixwed3 connects to machine benway by calling
	at any time. The pathalias cost is DIRECT. The benway machine
	never calls sixwed3, and only passes mail back when called.
	Mail may be rejected after three days. The pathalias cost for
	the reverse link is POLLED. There is a better way via two
	hops, DEDICATED and DIRECT when reach the sixwed3 machine.

	The machine sixhub connects to sixwbn in a nonstandard way,
	and passes all mail to it compressed and batched late at night.
	The pathalias cost is DAILY+LOW. Mail coming back is returned
	on a weekly basis, rather than daily. The cost is WEEKLY+LOW.

  Hopefully this has demonstrated that paths should not be teated as
bidirectional. There are a number of other examples which I could cite,
having to do with backbone machines connected to one-off backbone
machines.

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me