BJ> You must be using newer software or software based 
 BJ> on something other than Fido/Fidonet/Confmail, 
 BJ> Opus/(optional)Binkley/Ommm, 
 BJ> Maximus/Binkley/Squish, etc.  I know front door and 
 BJ> dbridge handle some of this differently for 
 BJ> outbound routing, but I haven't played with 
 BJ> those.....
 
I don't know anything about D'Bridge, but ran maximus/intermail/squish and
maximus/frontdoor/squish for awhile, ten years ago.. FWIW, Intermail and
FrontDoor (at least of the 2.x vintages) are basically the same mailer for
our purposes.
 
Frodo/IM don't send echomail from an outbound area; rather, they send only
netmail. The tosser throws netmail file attachments out in the netmail
area, which are compressed FTN packets. I think this style of echomail was
called "Arcmail Attach".  This is why it's also important to
configure software to create *.MSG netmail areas by default, in case
somebody is using that style of routing.
 
(Sorry if that doesn't help much, like I said, it's been a LONG time).
 
 BJ> See above....  Issues are when the mail is not compressed and how 
 BJ> Squish will then reprocess those outbound packets.  
 BJ> :(
 
Here's a possibly creative solution to the problems you've been talking
about. How about we add a new "RouteStop" keyword to Squish,
which behaves like Route, except it means "if this routing keyword did
work, stop processing that packet on this run"?
 
It might seem a little connvoluted from a ruting requirements point of
view, but it should be reatively easy to implement without risking breaking
any other functionality.
 
Wes

--- Maximus/2 3.01