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

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

 BS> I saw the problem then a node whitch normally have his 
 BS> mail on Hold here, but his internet was down, so i want 
 BS> to route his mail thru by BOSS, but it "routed" the 
 BS> echomail too..

Ah, yes....  that is a "feature" in squish, and the older mail
mashers that squish is based on.  You end up needing seperate runs of
squish if you want to seperate netmail and echomail handling.  :(    

So, I do see where you would like to have a configuration option to change
how that works.....

 BS> I don't know what my boss did about the packages.. I 
 BS> guess it got tossed into NTU (not to us).

  When I had the routed echomail problem, I got contacted and
asked what was going on.  Both ends of the transfer scrached our heads over
that route.cfg error for a while.....  I forget how I finally stumbled on
the solution....  Any way.....

 ...
 BS>>> For poll ?

 BJ>> If I had ILO packets (vs CLO, HLO, DLO and FLO), I could more
 BJ>> easily distingquish between sending something out via BINKD vs
 BJ>> sending out 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?

One other probelm with routing "normal" for binkp is the way
squish handles normal.  For that reason I don't use normal.  I only use
Crash, Hold and Direct for squish's outbound mail packets.

 BJ> Nothing for BinkP, but then Binkley will also try to pick up those
 BJ> packets for delivery.  If you run both dial-up and 
 BJ> IP based mailers on
 BJ> one system like I do, there is a convience of just configuring the
 BJ> mail type in one location (say route.cfg) and have that determine
 BJ> which protocol is used for delivering the mail.

 BS> I would say it's just a question about controling your routing.

Exactly.  Unfortunately, I have to play additional games beyond routing to
handle my routing.....  For nodes like me and one of my major feeds, where
we have proper entry for a POTS connection and also have proper entries for
multiple IP based connections, I have to play games to keep Binkley from
calling out on the phone line..... (or telnet node....)

 ....
 BJ> If I could place all connections typically based on binkp
 BJ> connections in the ILO type, then I wouldn't have to mess with
 BJ> configuring my binkley mailers (that handle telnet 
 BJ> and dial-up) to NOT
 BJ> dial those nodes in a normal situation.  And I could probably handle
 BJ> the occational special message with the route.cfg file.

 BS> Yes, but as my further question was, binkley won't dial 
 BS> on normal (in a C event), so why not route it normal?

 BS> If it's ION you got a double points because their phone 
 BS> number _should_ be unpublished.

I have two problems with using unpublished.  For ION's using unpublished,
the problem becomes that my nodelist processor will substitute the NC's
phone number for the POTS mailer, which you don't want dialed.  And for
nodes like me, where both POTS and IP connectivity can be made, you want to
not dial the phone as long as IP connectivity is good.....  So,
_unpublished_ in the nodelist does not solve the problem....  And
_unpublished_ is the nodelist would be an error for nodes like myself
(1:343/41) or for one of my feeds (1:10/345).

Some day I may write the program I want to automatically generate my
route.cfg file from the nodelist -- so I can directly send netmail to those
who I have no additional cost in calling......  But that's another
story.....

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

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

 BS> ILO should be used as a poll flavour.. Because so far 
 BS> as i understand the flavour, on ILO the mailer should 
 BS> call immetately, and not wait to ensure that no call is 
 BS> inbound, on crash it wait a bit, and then call.

Ok, so you consider the I to be immediate and not internet.  I consider the
C to be crash, to be the equivalent to immediate.....

 BS> Afaik does newer mailers than Binkley act this way.

The only "mailer" that I've seen handle ILO/IUT packets is BinkD.
 But I haven't tried stuff outside of BinkD or later than the last official
release of Binkley (2.60).  

Thanks for the note.

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01