Subj : Compression question To : Bo Simonsen From : Peter Knapper Date : Wed Jul 23 2003 01:19 pm 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 * Origin: Another Good Point About OS/2 (3:772/1.10) .