Hi Bo,

Please see my message to Jerry, it may help to explain a few things. I
think much of the problem may actually revolve around using SEND and ROUTE
in conjunction with a Flavour other than HOLD...

 BS>> Okey, i haven't seen them in the documentation, would 
 BS>> you be kind to show them?

 PK> Its really a combination of using the Squish control parameters in
 PK> the appropriate way. 

 BS> Ehh, people who doesn't eventbased/automatated tossing 
 BS> have no chance to do that.

I am not sure what you mean? When you run Squish, you can specify a
SPECIFIC Schedule that you want run. From Page 28 of Squish32.Prn, in
particular the second to last sentence -
=======================================================================
 Elementary Routing

 After you have configured the EchoMail areas available on your
 system, your attention should be turned to mail routing.  In
 Squish, routing is based on the idea of schedules and control
 files.  A schedule is simply a set of routing commands which can
 be performed as a single unit.  Schedules can be run either all     !
 day, during certain times of the day only, or on manual request.    !
 Most nodes will only need one schedule, since the majority of
 systems use the same set of routing commands 24 hours a day.
=======================================================================


 PK> Most people seem to forget that the
 PK> commandline parameters provide subtle control, and yet it is
 PK> possible to use them in conjunction with a control file that allows
 PK> very selective processing, as long as thats what you want to do.
 PK> Overall, you may need to perform multiple passes to do things
 PK> exactly as you want. 

 BS> Can you explain that a little bit more?

Say that you run run a single Schedule to process a selected set of mail,
and then use one other Schedule to perform the routing of that mail. Each
schedule can use different commandline parameters.

In particular, take a real close look at the IN and OUT parameters as
discussed in the Documentation. Note that when Squish is in SINGLE PASS
MODE, the OUT function will only scan Echomail Areas touched by the IN
function, and if nothing comes IN, that means only the Netmail is
processed, because it is not an Echomail Area.

 PK> In addition, you can use the SEND and ROUTE commands to process
 PK> traffic for a specific set of nodes, and then the output of those
 PK> commands is NOT included in any other ROUTE statement processing
 PK> that encompass those nodes within a global statement (EG 4:ALL).

 BS> Ehh, You can override the routing table in the commandline?

No, it comes down to HOW Squish processes the Schedule statements and the
fact that I do ALL my processing with mail in HOLD status. I am begining to
suspect this is really the root cause of the problem people are running
into, you may be trying to process mail in a Flavour other than HOLD.
Again, check my reply to Jerry.


 PK>> What doesn't work about Zonegating (with unix), or more specficaly,
 PK>> what part of Zonegating is not working?

 BS>> The gateroute thing, it created a new message, whitch 
 BS>> it marked sent, but it forgot to mark the original 
 BS>> message sent too, to it keeps sending that message...

 PK> Hold on, Zonegating and GateRouting are 2 quite different things,
 PK> are you perhaps trying to mix them? Also note that "A ZoneGate" is
 PK> a specific system, but "ZoneGating" is the act of moving traffic
 PK> between Zones. The first is a Nodelisted system, whereas anyone can
 PK> perform the second. In brief -  

 BS> Well the GateRouting statement is routing mail to other 
 BS> zone to the zonegate, 

but its ONLY to be used for the purposes of reaching non Zoneaware nodes on
the other side, something that does not probably exist today.... From the
Squish Docs -
===============================================================
The GateRoute keyword causes Squish to perform gaterouting
on NetMail messages addressed to the specified gate or any
of the following nodes.  Squish follows the FTS-0001
standard for gaterouting, so the messages produced by this
command should be acceptable to SEAdog and other non-zone-
aware mailers.
===============================================================
Use Caution here, this means Squish MODIFIES the in transit NETMAIL Message
to allow old S/W (that does not understand Zones) to be able to understand
the  output. This is why INTL is not getting passed, it gets dropped BY
DESIGN. I suspect you do not want GATEROUTE at all, you probably want to
use ZONEGATE and even possible specify the official Zonegate for that task.


 BS> Most editors can make the Gating by their self, but fx. 
 BS> if a netmail is sent by maximus it can't.

Maximus generates fully Zone aware Netmail, and performs NO GATING AT ALL,
so I dont understand the problem.


 BS> I should sent a netmail to 4:930/1, i sent it by 
 BS> zonegate but i got on Hold at his ZC, and he wasn't 
 BS> pollable, if i did sent it routed, it got catched up by 
 BS> another node. Whitch was a ip node, there put it on 
 BS> Hold.

This sounds like an issue with moving mail between PSTN and IP nodes that
just happen to be located in different Zones, and nothing to do with
GateRoute or Zonegating itself. 


 PK> ZoneGating reduces message sizes as well. 

 BS> It's _netmail_ zonegating.

Ok, so with this Netmail there are no Seen-by's and there is no 2D aware 
(GateRoute) system change to be done, so its sending mail between zones via
a nominated Zonegate. Still sounds like an issue at the receivers end to
me.

Cheers...............pk.


--- Maximus/2 3.01