TIP: Click on subject to list as thread! ANSI
echo: dos_internet
to: Charles Angelich
from: mark lewis
date: 2003-04-17 15:44:42
subject: little boys

SH>>> I'll remember that if the problem arises. But what does
SH>>> one do if some of the members have no netmail capacity?
SH>>> Stew?:-)

ml>> FWIW: /everyone/ in fidonet has netmail capability... some
ml>> systems and sysops just don't implement it due to other
ml>> factors... the most major of those factors being lack of
ml>> education on its operation and workings...

 CA> I _may_ be mis-remembering this

not so much mis-remembering but understanding of what others who didn't
understand were telling... plus a mix of some small part of
"truth"...

 CA> but in the days when BBS charged for access to FIDO on a per
 CA> reply basis (something like $.03 as I recall?)

hunh? fidonet is non-commercial and no one is/was supposed to be charging
for access to fidonet... charging access to the bbs is/was a different
matter... many confused or blended the two... and to charge for replying to
someone(!) oh my!

 CA> all netmail was billed at a higher rate.

yes, this is kinda true... the only time billing was needed to be
implemented on a cash basis (instead of credits to spend/use on the bbs)
was when the bbs system was set to dial directly to the destination
system... even then, it wasn't all that expensive per call and even cheaper
if the sysop actually scheduled his system's dialouts... this was also back
in the day when the routing of netmail was not so commonly done... with
confusion about the rules of privacy and the lack of settings that a sysop
could set to prevent accidental viewing of other's netmail... and that
fidonet is/was a hobby and some didn't want to have to be professional
about their fidonet activities...

 CA> I think all netmail was what is called 'crash mail' now?

"crach mail" is a flavor of netmail... there are actually three
flavors plus a couple of extra sides...

  normal (aka routed) == sent to next system for further processing
  direct == sent directly to destination system when schedule allows
  crash  == sent directly to destination system right now

in routed netmail, there are the "extra sides" to mix
metaphors... there is hub routed, host routed, echomail routed (travels
along with echomail bundles... most common used today) and possibly one or
two more... the sender has no real control over the route that routed
netmail may take in getting to the destination... the receiver has some
control only in that they can ask that their stuff be made available at a
certain system for them to gather from there (generally their echomail hub)
and at any system in the route, the "flavor" of the netmail may
change based on that intermediate system's netmail policies...

 CA> It was sent directly to the BBS via long distance land lines
 CA> and not routed through normal FIDO nodes?

this is where many had problems offering netmail to their users... they
thought that they HAD to send netmail direct/crash when they didn't if they
would set up proper routing... echomail routing came from a simple practise
of sending and receiving everything from the systems you connect to... the
idea of upstream and downstream is a misnomer at best but it does work in
certain cases of describing flow...

 CA> Could be that many only remember the 'crash mail'? It also
 CA> seems that netmail is 'lost' more often than normal 'traffic'
 CA> from what I read in the Z1B and NAB echos over some time. :-\

routed netmail has always had small problems and glitches... see above for
a basic listing of why and remember the hobby nature and necessary
professionalism factors... netmail doesn't have quite the problems it used
to... a lot of past routing problems were also (sadly) based in ego
clashes...

)\/(ark

* Origin: (1:3634/12)
SEEN-BY: 633/267 270
@PATH: 3634/12 106/2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.