BS>> But does squish not take topdown, until it find what it needed?
 BS>> A thing there annoys me too, is that it use ROUTE.CFG
 BS>> for Echomail packages too.

 BJ> Yes, Squish process the route.cfg file in a top down mannor.

 BS> Hmm.. then i don't see the problem..

CONFMAIL would keep a list of the original outbound, and made sure it only
processed outbound mail on the FIRST match in the route.cfg file.  Squish
processes the outbound for each line read in the route.cfg file and so
processes against ALL lines instead of the FIRST match in the route.cfg
file.  This was a major annoyance till I figured out this difference when I
transitioned to using Squish.  At the time, squish claimed it was directly
compatible with the existing route.cfg file(s) I was using with the older
software.....  Squish wasn't 100% compatible.....

Ok, from your other comments, I think we understand each other, and I
probably should drop further comments for now.  [I assume you now
understand the issue I've had.....  Yes, it is minor....]

 BJ> And as to echomail, remember, echomail is just a special version of
 BJ> netmail.  And like confmail and OMM, squish processes echomail just
 BJ> like netmail....

 BS> Yes, but it's not routable in that way netmail is. 
 BS> Echomail is _exported_ not routed.

Agree that is how echomail should normally be handled, but all the older
mail mashers will allow one to route mail of any type (echomail or
netmail).  And some systems will even pass on such routed mail packets
without reprocessing the packet content.  

 ...
 BS>> For poll ?

 BJ> If I had ILO packets (vs CLO, HLO, DLO and FLO), I could more easily
 BJ> distingquish between sending something out via BINKD vs sending out
 BJ> via Binkley.

 BS> Well it's not the point that Binkley shouldn't touch 
 BS> ILO.. What the problem about route "Normal" to binkp 
 BS> nodes?

Nothing for BinkP, but then Binkley will also try to pick up those packets
for delivery.  If you run both dial-up and IP based mailers on one system
like I do, there is a convience of just configuring the mail type in one
location (say route.cfg) and have that determine which protocol is used for
delivering the mail.  For example, when I loose a my normal connection
method (for what ever reason) and I want to make an attempt at contacting a
system via a different support protocol, it currently requires that I
reconfigure in a number of places.  If I could place all connections
typically based on binkp connections in the ILO type, then I wouldn't have
to mess with configuring my binkley mailers (that handle telnet and
dial-up) to NOT dial those nodes in a normal situation.  And I could
probably handle the occational special message with the route.cfg file.

 BS> I assume that you are running Binkley in the C event.

 BJ> Binkley won't touch the ILO packets, so with binkley
 BJ> configured as a TCP/IP based mailer on my system, I can keep binkley
 BJ> from dialing my BinkP based connections without 
 BJ> nodelist mods (such as
 BJ> tweaking the cost table, which is the method I'm using for now....)

 BS> Yes, but that's not the point about ILO/IUT..

Then what do you see is the point of the ILO/IUT?  

Thanks.

Bob Jones, 1:343/41

--- Maximus/2 3.01