[...]


 BJ> Without looking at my configs, I believe you got it.  And as a 
 BJ> result, SqaFix can not be run as a single configuration for Fidonet 
 BJ> and for STNnet in your example.....  Which can cause
"fun" when you 
 BJ> have a downlink that is in both nets....  The down link would also 
 BJ> have to make sure that they link to sqafix using their correct zone 
 BJ> based FTN address, or the request wouldn't work....

Exactly.
But this is true no matter what 'AreaFix' software a hub uses, I would think.
If the downlink wants a repsonse invovled zone 111 , then be sure that the
netmail to SqaFix is from their 111: address .... and so on.



 BJ> Actually, I think SqaFix was designed just for a single network...  
 BJ> The way SqaFix is designed, it prevents a user in zone 1 from adding 
 BJ> echos distributed in zone 111 (using Joe's example above)...  Which 
 BJ> is a *good* thing....  Moderators in fidonet would complain if 
 BJ> someone had an out-of-fidonet address in their origin line on a 
 BJ> fidonet echo....  It would also screw up the seen-by information, 
 BJ> possibly causing some systems to not see the message.  [Echomail 
 BJ> routing is *still* 2d for handling mesh routing within a zone.  And 
 BJ> zone 1 operates on a mesh basis....]

Separate the zones, (networks)  into different areas within SqaFix config.
Organize downlinks such that they only have access to certain areas.
Works fine.   :)



 BJ> So, adding additional netmail areas to SqaFix also means SqaFix needs 
 BJ> to be beefed up to keep track of zone number vs echo area and handle 
 BJ> requests accordingly....

I'm sure that there is room for improvement in the realm of keeping track
of zone numbers.   But you all can move that down the list.  :)   We can
work with that, just like it is.

Scanning more than one netmail area ....  now that would be nice.   :)


 BJ> Hmmmmm......

The little wheels are turning, huh?  


Thanks

                                            .....Joe

--- Msged/2 TE 05