TIP: Click on subject to list as thread! ANSI
echo: filegate
to: All
from: Janis Kracht
date: 2016-06-10 18:25:52
subject: Hatching...

Hi Folks,

This is important.

I was pretty sure most everyone realized this, but I guess not.

I just want to remind everyone that there is no "open hatching"
on the filegate.

That means ONLY coordinators of specific FDNs are authorized to release
files into the stream...

If you are not a File Distribution Coordinator listed with an FDN in
Filegate.zxx, you should only pass files received from your uplink to your
DOWNLINKS.

You should never use the hatch command to distribute some cool file you
think the world needs.  Send it one of the appropriate coordinators listed
in filegate.zxx.

Or, if you find a cool file you'd like released, check the FDN list in
filegate.zxx to see if that FDN has a "To HeadQuarters" area. 
You ARE allowed to hatch that new file TO THE COORDINATOR only in that
area.. He can test it, fix a long filename problem, and get it out to the
rest of Fidonet.

I have my system set up to protect against just anyone of my downlinks
hatching, however given the way BBBS lets sysops areafix to add file areas,
the specific flag to disallow hatching is not added to the node's entry for
the area requested automatically ( we want it to be "receive
only").

I have to manually add that flag (such as >1:282/xxx) which allows that
node to receive files, but does not allow that node to send out files into
the stream from here.

The way bbbs leaves newly areafixed file areas is to allow hatching and
receiving instead, for example, 1:282/xxx.  So I have to manually change
that nodes' permissions if a new area is requested, etc., from 1:282/xxx to
>1:282/xxx.

Open Hatching (anyone in fidonet hatching files into the stream) is too
impractical, no one takes responsibility for cleaning up mistakes made when
a sysop hatches a "mistake" because the sysop hasn't agreed to do
it, like the FDN Coordinators have.

It can also create dupe file releases and busy up our distribution and
unwarranted dupe releases can tie up our mailers unnecessarily...  Who need
5 versions of the latest door file, or utility coming from multiple systems
multiple times?

We had an instance yesterday that I missed because I'm still fighting this
sinus infection that knocked me out.  It's getting better but it's not gone
yet.

The point is I missed this happening yesterday until Bob Seaborn contacted
me. (Thank you Bob :)

The file sent out was

: not an 8X3 filename

*We cannot release long filenames because many systems cannot deal with them).

*I received a number of complaints from sysops who could not process the file.

I'll be contacting that sysop shortly.  In the meantime, I just wanted to
remind everyone that this was not done intentionally by one of the FileGate
Coordinators and at for that area the permissions are fixed.

When I'm finished with all these meds I'm currently on, I'll go over all
the other file areas in my tick config to make sure this does not happen
again.

Thanks to all for understanding.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)
SEEN-BY: 14/5 18/200 19/33 34/999 90/1 116/18 120/331 123/500 128/187 140/1
SEEN-BY: 218/700 222/2 230/150 240/1120 249/303 250/1 261/38 100 266/404
SEEN-BY: 267/155 280/1027 282/1056 292/907 908 320/119 219 340/400 393/68 70
SEEN-BY: 633/267 280 640/384 712/620 848 770/1 801/161 189
@PATH: 261/38 712/848 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™.