Hello Peter!

Wed 2003-07-23 12:19, Peter Knapper (3:772/1.10) wrote to Bo Simonsen:

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

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

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

Oh yeah the -t argument afair.

 BS>> Can you explain that a little bit more?

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

..

Yeah i understood, it's just new for me that a tosser can have a
"dynamic" routing table :)

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

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

It works now in the UNIX version, i think the feature still should be
there, for fx. editors like timEd doesn't support ZoneGating (of Netmail),
so it's good the tosser does.

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

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

It's just a good feauture for the node, that a netmail for another zone can
get there so fast as possible.

 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.

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

Yeah it does... 

Regards, Bo

--- timEd/Linux 1.11.b1