Mike:

You understand how Squish works.  You don't understand how the older
software (CONFMAIL) worked, which squish claimed to be compatible with when
it first came out.....  And yes, I use the CHANGE solution to get around
this "bug" / "feature" of squish.  It adds about two
more lines to your route.cfg file for every node you want normal packet
types for to get what used to just work in the older (CONFMAIL, OMMM)
software....

Because of how squish has been working, I would recommend that if this
"bug" / "feature" is corrected, that it be controlled
by an option in the squish.cfg file, and that the default be to run like
squish has been running.....

Take care.....

Bob Jones, 1:343/41


 MT> Hello Bob!

 MT> 18 Jun 03 21:32, Bob Jones wrote to Bo Simonsen:

 BJ> If you try to use "ROUTE NOARC NORMAL 1:234/567.8 1:234/*"
 BJ> and then have a line that does something like default route (from
 BJ> memory, something line "ROUTE CRASH 1:140/1 1:ALL 2:ALL 3:ALL 4:ALL
 BJ> 5:ALL 6:ALL"), then the mail that you packed for 1:234/567.8 gets
 BJ> retargted and sent to 1:140/1 (in this example).  
 BJ> Actually, it doesn't
 BJ> need to be a default route.  It just needs to be a command that ends
 BJ> up reprocessing node 1:234/567.8's outbound mail packets.....

 MT> I don't see the bug.  The first step changes the 
 MT> address but retains the routable flavor.  The new 
 MT> address and existing flavor still meet the criteria 
 MT> specified for the second step.  Using 
 MT>  in Step1 prevents it from being 
 MT> a candidate for being routed to 140/1 in Step2.  You 
 MT> could add Step3:

 MT> CHANGE  NORMAL 1:234/567.8

 MT> to end up with NORMAL again if that's your objective.  
 MT> Instead, you could also use some address with a 
 MT> fictional zone that is not in Step2's criteria, for 
 MT> Step1 and Step3.

 MT> How would you want to change Squish's current behavior 
 MT> to "fix" it?  Prevent more than one routing command 
 MT> from ever being applied to the same mail in the same 
 MT> run?

--- Maximus/2 3.01