mark,

Friday July 24 2015 11:10, you wrote to me:

 ml> you fell into the same misunderstanding that many others also fell
 ml> into... i did for a long time, as well... then i wised up one day when
 ml> i was rereading some mailer and tosser documentation... the key is
 ml> that the mailer's and tosser's netmail areas are shared between them
 ml> but the sysop's netmail area should be elsewhere to keep his mail from
 ml> being mixed in with that being managed by the mailer and tosser...

This meant running additional tool (i.e netmgr) to move those netmail messages
to/from primary?  I always opt for running the lightest configuration possible
so had natural adversion to doing this.   I just believe netmail should contain
only netmail.  Functional components seperate from administrative components.

 ml> not sure what files you are talking about but if they are/were mail
 ml> bundles, they are left as zero bytes so the tosser can see that
 ml> they've been sent and can increment the extension... using a zero byte
 ml> file on the drive keeps the tosser from having to manage some sort of
 ml> database with this information...

Not needed or an issue with hpt and filebox because bundle names use timestamp
by default.  More available bundle names and no overlap. Additionally, smart
mailers like binkd are capable of incrementing name at receiving end even if
overlap tries to occur.

 ml> true but that's a little much... just send the mail first, then the
 ml> files and finally the tics... there can be no problems with that
 ml> ordering... or am i/we missing something else?

Less of issue these days with high bandwidth links but I remember modem
sessions lasting 30+ minutes.  TIC+FILE pairs would arrive in sequence allowing
processing to begin in background.  If TIC files arrived last then processing
must wait until very end of session.

 ml> directly with its static queue but i don't use that right now... i
 ml> don't recall if fastecho understands FD's static queue to that level
 ml> and would know to place a system's outbound mail in its filebox as
 ml> indicated by the STQ... what i've got works but it is a real PITA to
 ml> add a new system because of the various config files that have to be
 ml> adjusted... missing one breaks things in an ugly way...

What is the FD Static queue?

 ml> definitely primitive... there's a difference between being primitive
 ml> and limited... but there are limits to BSO... it is where the max zone
 ml> number of 4095 comes from... with 8.3 limitations, the zone of the
 ml> outbound can only go up to 0xfff ;) aside from that, BSO is pretty
 ml> well defined and quite capable... AM/FA changed things slightly in
 ml> that they automaticall handle packing and routing of netmail offering
 ml> dynamic routing capabilities whereas BSO is lovingly know as "black
 ml> hole" because the tosser has to pack everything and any rerouting
 ml> changes mean that those packed messages have to be unpacked and
 ml> repacked to the new destination if the current mailer event adjusts
 ml> the routing... knowing what message(s) is in which PKT(s) destined to
 ml> which system(s) to validate proper routing is much harder with BSO...
 ml> AM/FA also allows for one single outbound instead of multiple ones...
 ml> AM/FA mailers are simply a more intelligent mailer... nothing wrong
 ml> with either...

I think zone ~100 was the highest I've ever went.  Also can't recall ever
having to re-route or re-pack any netmail but could simply be fading memory. 
There were things I did not like about either.  Since I use exclusively filebox
that deprecated past is in rearview mirror.

I suppose BSO never bothered me as I wrote my own REXX equivalent of FIFTP when
I ran OS/2.  Whipping together a tool to understand BSO was nothing then though
I suppose it would require some effort today.   Once you go filebox you never
go back.  :-)


Take care,

Matt

---