Text 46256, 80 rader
Skriven 2007-01-01 00:43:47 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 24:01 [02/06]: Matt'S Column - Matt Bedynek
============================================================
=================================================================
                  MATT'S COLUMN - MATT BEDYNEK
=================================================================

              The integrity of mail
            By Matt Bedynek, 1:106/1

As a mail mover, one must do whatever it takes to ensure the smooth
operation of the network at the same time maximize the propagation of
content.  We cannot allow ourselves to become overzealous, nor, under
estimate the vital role we play or the level of responsibility we
shoulder.

We must make decisions that compromise between quality and quantity.
For example, decisions like maximum message size have far reaching
consequences than our own system.  Many of us are still active and
routinely update our hardware and software that extend our
capabilities far beyond our counterparts who do not.  Those
counterparts, our colleagues, may be sysops who simply do not have the
time to invest in changing software, or, they are stranded on a desert
island without the promise of updates for their favorite platform,
that despite these limitations still work well for the scope in which
they were designed.

For example, I run the husky software (hpt and htick) to handle my
echomail and files.  Hpt can handle messages the size of available
memory and htick can handle long file names.  But, having been a fan
of fido software, and used or evaluated every widely used software
package, most of which are dead or dying, I can say that their
limitations are more restrictive for the needs of the era in which
they were designed.  Moreover, while some of these software packages
may have limits similar to mine, the operator may have chosen for
whatever reason to not enable them.

Today, some argue fidonet is no longer as tightly restricted in that
there is no originating point for content.  I agree with that fully.
Fidonet is a peer-to-peer broadcast network in which traffic is passed
on.  And, pride or no pride, whether some of us admit it or not, cheap
availability of 24/7 IP connectivity has opened the door for anyone to
move mail.  Unfortunately, there is no litmus test for those who
volunteer to move mail that says they will uphold any doctrine or
social contract to ensure the quality of the content they forward into
the stream or take responsibility for any problems that originate from
their links.

If such software, capable or incapable, configured or not, receives a
message that tests its upper limit, it might either sideline the
message, the entire packet, or worse, freeze the system of the node
processing it.  If my node forwards you a packet containing 30
messages and one of them is too large for your system to handle the
likely result is that the entire packet is lost and degradation of
quality the result. The damage resulting will be far worse to the
system than to the pride of the hub operator when he is called out for
failing to place checks on the traffic he forwards.

Yes, we are a peer-to-peer network, but hubs still play a vital role
in that they are focal points for the traffic the pass.  They have an
obligation to find, isolate, and notify others of problems.  If this
is not possible, they should attempt to fix those problems themselves
for the benefit of the network.  Sure, in the past, we could simply
blow people off and tell the operator of the system "I will not pass
your broken messages, either switch software or have your messages
lost".  Today, we cannot afford to do this.  I adopt the attitude if I
can save one single message that contributes to the continuation of
the network, I have done my good deed for the day. But, at the same
time, as one hub operator to another, while I will notify my
colleagues of the problem, I do not have an obligation to fix their
system. Collaboration is fine, but if, as a hub operator, one does not
have what it takes to make the cut, they should not shoulder the
burden of handling traffic for other nodes.  They do a disservice to
the network and those they forward traffic for.

If, as a hub operator, you cannot resolve issues on your own, then
perhaps you shouldn't have volunteered.


-----------------------------------------------------------------

--- Azure/NewsPrep 3.0
 * Origin: Home of the Fidonews (2:2/2.0)