🚀 go-pugleaf

In <Karl's last article> karl@cis.ohio-state.edu (Karl Kleinpaste) writes:
 >edguer@alpha.ces.cwru.edu writes:
 >>   Hmm.  Yes, the RFC974 algorithm may require a reroute of the first
 >>   hop at each relay point along the path to the destination.  Note,
 >>   however this is only a reroute of THE FIRST HOP and thus would be
 >>   the same as passive rerouting, not active (rabid) rerouting.
 >>   RFC974 does not say to look down the list trying to find known
 >>   hosts, it merely says to look at the first domain (host) in the
 >>   path and try to reach it.
 >
 >If:
 >	I have a connection to system aaaaa;
 >	I advertise the connection to aaaaa as _very_ expensive so
 >		that it doesn't get used by others as a relay much,
 >		in fact, so expensive that my own paths file contains
 >		the line
 >			aaaaa	bbbbb!ccccc!aaaaa!%s
 >	I nonetheless expect and accept that the occasional piece of
 >		mail bound for aaaaa should still go straight there, 
 >		because it's known to my Systems file...
 >Then:
 >	An incoming piece of mail specifying
 >		aaaaa!user
 >	will have to be rerouted:
 >		bbbbb!ccccc!aaaaa!user
 >	because of the requirement, with pathalias as MX, that I
 >		reroute the first hop, _before_ a direct attempt.
 >
 >This is morally incorrect.
Hmm.  You have a point, I just don't feel you are addressing it properly.

I do not feel that the behavior you described is incorrect (morally or not).
I maintain it did exactly what you wanted (or at least what you
told it to do).  If you wanted mail to go directly to aaaaa rather than 
bbbbb!ccccc!aaaaa when sent locally, then you should have either:
	a) Put the system name in brackets in your published map entry to
	   indicate a "terminal link" and that further links are heavily 
	   penalized [see pathlias(1)]. 
		Example: <aaaaa> (DEMAND) 
	   This will cut down on pass through traffic.
OR		
	b) Publish "aaaaa (DEAD)" but put "aaaaa (DEMAND)" in your 
	   paths.local file.  This will over-ride the higher cost entry 
	   when generating your local maps (or any of your friends maps).
	   This will allow you to use it to route to other sites also.
OR
	c) Put "<aaaaa> (DEMAND)" only in your paths.local file and do
	   not list the connection in your published map entry or list
	   it as (DEAD).
	   This will prevent anyone else (who does not know about it)
	   from using the link, but will permit you to use it for direct
	   mail, and help prevent you from generating paths though it.

I would hold that resolving hosts in the L.sys file first and then trying
to lookup unknown hosts in the pathalias database file (while not preferred)
is OK.  All you are doing is "fixing" a problem you created yourself (by not
making your local map data better).

 >Making such a reroute into a requirement is Wrong.
 >(Making it optional is my business and no one else's, as the
 >link may be genuinely of high cost.)
The requirement is only that your local map entries be correct.
Thus it is entirely optional and within your control.  If someone really
WANTS the behavior you have implied is morally right, they CAN do it.
If they do not want it, they can avoid it.

 >Whatever the reason, I want the connection to be available and
 >used on demand, without most people actually putting it to such use.
 >Say, just for my pals, who are "in the know" about the connection.
If your local map information is correct then the connection is available
on demand.  The point is that MX records in SMTP land could cause the
same problems.  What if I wanted to send to mxed.host.domain directly?
I can't within a mailer.  The rules don't let me and the program won't
let me (yes, I know I can telnet directly to the port.  I can also directly
put a piece of mail in the UUCP mail queue).  But I could make a local
change to the Domain Name Server (see RFC974)!  I continue to see the 
parallels between "!" paths and source-routes as being very high.

But enough beating a dead horse...
To be honest, as with all analogies, pathalias records are only like MX
records in some ways.
One reason why I cannot say that pathalias records are MX records is that
(as Karl has pointed out) they are never _specifically_ mentioned in the 
RFCs we have been discussing.  I can only claim that they logically should 
be included (thanks to RFC976).
The second reason why I cannot say that pathalias records are MX records
is that in at least one major mailer (IDA-sendmail), MX records and
pathalias paths are used in two different parts of the mailer.
MX records are used during the delivery phase and do not affect the address.
Pathalias records are used during the name resolution phase and do affect
the address.

None of the RFCs however contain anything to support active rerouting,
(i.e. looking beyond the first hop in a chain), and I will continue to
call active (rabid) rerouters, impolite, if not broken.

Aydin Edguer		+1 216 368 6123		edguer@alpha.ces.cwru.edu
Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.