🚀 go-pugleaf

In article <279@minya.UUCP> jc@minya.UUCP (jc) writes:
	[ Deleted quotation from someone describing their personal
	  algorithm for sending mail ... i.e. Look at the address
	  and determine where the site is, and re-write the address
	  appropriately.  All by hand. ]
>You know, there's an elegant solution to this sort of problem, exemplified
>by the way that Prolog resolves things.  What is needed is a user agent
>that will first try what it thinks is a "best" path, and then, when that
>fails, can be told "try again, with the next-best path".  This could be
>repeated until a good path is found, which could then be made the "best"
>path for the next time.

hmmm ... how are you intending to test the 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.

We can do this "try again until it works" algorithm of yours by hand
right now.  I do this quite often in fact (well, maybe a couple of
times a month -- more often than I really want tho').  You send the
mail, and if it bounces you forward the message through a different
route.

Obviously it's a good algorithm but I don't see the point of making
it "automatic" like you suggest.
-- 
<---- David Herron,  Local E-Mail Hack,  david@ms.uky.edu, david@ms.uky.csnet
<----                    {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- I thought that time was this neat invention that kept everything
<---- from happening at once.  Why doesn't this work in practice?

In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes:
> In article <279@minya.UUCP> jc@minya.UUCP (jc) writes:
> 	[ Deleted quotation from someone describing their personal
> 	  algorithm for sending mail ... i.e. Look at the address
> 	  and determine where the site is, and re-write the address
> 	  appropriately.  All by hand. ]
> [ Deleted rephrasing of Prolog resolution applied to mail paths]
>
> hmmm ... how are you intending to test the path?

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.

> Obviously it's a good algorithm but I don't see the point of making
> it "automatic" like you suggest.

Only because I get tired of doing something by hand when it could be
done better by a computer.  That's why we buy the little beasts, after 
all.

Anyhow, characterizing the Prolog algorithm as "try it again until it
works" is a bit inaccurate.  Hunting around at random is quite a bit
different from a systematic search through a list sorted according to
recent successes.

The current proposals for intelligent forwarders strike me as being
basically an uncoordinated random walk.  This will work, most of the
time, and the mathematics of it all is over a century old.  But there 
are much better algorithms known.  The Prolog approach has the distinct
advantage of being implementable on the originating machine.  But it
does require that the sender be able to dictate the path, and that
other mailers not try to "improve" it.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

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:
>> hmmm ... how are you intending to test the path?
>Easy send it; if it bounces, that's a failure to resolve that path.

ok, I understood that to begin with ... but the point I wanted to make
and apparently didn't, was that this bounce-try-another-path approach
is expensive.

>> 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.

You must be on a well connected site.  hmmm ... that's an interesting
approach, just don't use Path: information from news headers.  Too bad
I don't have the time to try implementing such a thing.

Have you thought about packaging up an rmail (or description of how to
muck up an rmail) which records this information into a database,
and distributing via a sources group?
-- 
<---- David Herron,  Local E-Mail Hack,  david@ms.uky.edu, david@ms.uky.csnet
<----                    {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- I thought that time was this neat invention that kept everything
<---- from happening at once.  Why doesn't this work in practice?

In article <287@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>
>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.

Er, no.  It is never wise to assume that a mail path works both ways.
An example I saw recently: someone was sending mail from Tektronix to
MIT using the path fragment ..!allegra!eddie!athena!user.  It was their
dumb luck that allegra realized that "eddie" was the same machine as
mit-eddie (aka eddie.mit.edu), AND that eddie  would resolve "athena" as
athena.mit.edu (which is mit-athena in the uucp world).

How did I trip over this one?  The recipient was trying to reverse that
path and send along it.  Oops.   Didn't work.  (mit-athena was looking
for the uucp machine eddie, and losing.)

Don't try this one at home...

				AMBAR
{backbones}!mit-eddie!ambar			ambar@eddie.mit.edu

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

> >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.
> 
> Er, no.  It is never wise to assume that a mail path works both ways.
> An example I saw recently: someone was sending mail from Tektronix to
> MIT using the path fragment ..!allegra!eddie!athena!user.  It was their
> dumb luck that allegra realized that "eddie" was the same machine as
> mit-eddie (aka eddie.mit.edu), AND that eddie  would resolve "athena" as
> athena.mit.edu (which is mit-athena in the uucp world).
> 
Er, I hear what you're saying, but my experience is otherwise.  It's
true that some links don't work in both directions equally well.  From 
here, I can get mail to my neighbors within minutes; they must wait for 
my call to deliver mail here.  This is fairly common, but it doesn't
interfere with reversing a path.

Some links are truly one-directional.  In such cases, a path-reversal
simply won't work, unless there's an intelligent forwarder on this
side of the bad link.  

The above example falls into this class, but in a truly original way.
In effect, the link has been made one-way by having one of the machines
lie about its name in the path.  This is truly perverse!  

Despite the efforts of programmers and administrators to make life
difficult, the fact is that in the current email network, path reversal
is still the most effective way to respond.  I have three neighbors
with fairly intelligent forwarders, and when I submit mail with only
"To: target!user" or "To: user@target", the chance of it being delivered
is around 40%.  When I send it through the same hosts with a reversed
path, the success rate is around 90%.  It would be better, but a fair
number of the full paths are subverted and redirected along bogus paths
by some "intelligent" forwarder along the path.  Thus, all four of my
neighbors talk to harvard; if the reverse path goes there, their mailer
rewrites it, and is wrong about as often as it is right.

If all mailers were willing to accept pure bang paths and not question
them, I claim that path reversal would succeed in well over 99% of the
cases.  

It's true that a reversed path will fail some percentage of the time.
But replacing a method that fails 1% of the time with one that fails
60% of the time (at this site) doesn't seem to me to be much of a win.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

||In article <7461@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes:
||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.

In article <7651@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes:
|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.

  Sounds like you need to have a path database and update routes
known to be bidirectional on the basis of usage.  Not an
unreasonable thing for a prolong (oops, prolog) program to do.
Add another rule!

-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.