FidoNews · Vol 21, No 51 · 20 Dec 2004
The F I D O N E W S Volume 21, Number 51 20 Dec 2004
+--------------------------+-----------------------------------------+
| |The newsletter of the | | |
| | FidoNet community. | | Crash netmail articles to: |
| | | | Editor @ 2:2/2 (+46-31-944907) |
| | ____________| | |
| | / __ | Routed netmail articles to: |
| | / / \ | Bjorn Felten @ 2:203/0 |
| | WOOF! ( /|oo \ | |
| \_______\(_| /_) | Email attach to: |
| _ @/_ \ _ | bfelten @ telia dot com |
| | | \ \\ | |
| | (*) | \ ))| |
| |__U__| / \// | Editor: Björn Felten |
| ______ _//|| _\ / | |
| / Fido \ (_/(_|(____/ | Newspapers should have no friends. |
| (________) (jm) | -- JOSEPH PULITZER |
+--------------------------+-----------------------------------------+
Copyright 2004 by Fidonews Editor for Fidonews Globally.
Table of Contents
1. FOOD FOR THOUGHT ......................................... 1
2. EDITORIAL ................................................ 2
3. GENERAL ARTICLES ......................................... 3
What is a Bulletin Board? ................................ 3
GENERAL ECHOMAIL POLICY 1 ................................ 5
What is??? ............................................... 16
4. FIDONET BY INTERNET ...................................... 18
Fidonet Related Websites ................................. 18
5. ROBERT COUTURE'S FIDONET SOFTWARE LISTING ................ 20
FIDONet Software References .............................. 20
6. SPECIAL INTEREST ......................................... 25
Nodelist Stats ........................................... 25
7. FIDONEWS INFORMATION ..................................... 27
How to Submit an Article ................................. 27
Credits, Legal Infomation, Availability .................. 29
FIDONEWS 21-51 Page 1 20 Dec 2004
=================================================================
FOOD FOR THOUGHT
=================================================================
I don't think it is realistic to quantify a whole zone based on a few
people you have differences of opinions with.
-- Phil Simpson
-----------------------------------------------------------------
FIDONEWS 21-51 Page 2 20 Dec 2004
=================================================================
EDITORIAL
=================================================================
It seems at least one of our readers understands how to make topics
in the FIDONEWS echo becoming on topic. Thanks Matt!
And to those of you, that keep on whining about messages posted in
the echo being off topic, while constantly keeping on posting exactly
that, I have only three words for you: SHAME ON YOU!
Sorry for this, the very first acid editorial, but I really think
some of the participants of the FIDONEWS echo should seriously
contemplating getting a real life...
To all the kind and friendly readers, I wish you a Merry Christmas,
since the next time you get the Snooze, Christmas will be over. All
the best returns to you all, and may peace, as well as whatever God
you believe in, be with you!
-----------------------------------------------------------------
FIDONEWS 21-51 Page 3 20 Dec 2004
=================================================================
GENERAL ARTICLES
=================================================================
What is a Bulletin Board?
Matt Mc_Carthy, 1:396/45.17
Way back in my military days, there were "Bulletin Boards" all over
most military bases.
There was a "Bulletin Board" in front of the Mess Hall which usually
listed the meals and serving times for the current day.
There was a "Bulletin Board" in front of the Headquarters Building
which usually listed the 'Orders of the Day', the 'Uniform of the
Day', which units were training on which areas of the base on
certain days, as well as listings of coming Parades, Ceremonies, and
hollidays.
There was a "Bulletin Board" in front of the Chapel which listed
Services and times for each of many denominations.
There was a "Bulletin Board" in front of the Exchange which listed
the hours of operation, specific uniform and dress codes required
for admittance, and dozens to hundreds of personal cards for
everything from 'Free Kittens' to 'baby sitting wanted', to cars and
other stuff 'for sale'.
The "Bulletin Board" in front of Headquarters, as well as the
"Bulletin Board" at the Mess Hall were 'Read Only' Boards in as much
as they were covered with glass doors that were kept locked.
The "Bulletin Board" in front of the Exchange and the Chapel were
'Read/Write' Boards, in as much as they were uncovered, and were
open for anyone to post personal notes and messages on.
In the late 1970's when computers began to catch on, several
programmers wrote electronic "Bulletin Board" programs which exactly
duplicated the functionality of the old manual "Bulletin Boards".
I built my own computer and started running a local club's BBS
program on it for the club. All of the functions _exactly_
duplicated the functionality of the manual "Bulletin Boards". I was
amazed that electronics could do that.
By 1983 I began hearing of something called 'Fido' which was
supposed to be a bunch of connected systems, or something like that.
The concept of 'network' still didn't exist. I went to a friend's
and viewed a "FidoNet" system in operation. Needless to say I was
less than enthused. It was NOT a BBS at all, merely a way to send
'private messages' to other friends who were also part of the same
system. Since I didn't know anyone who was in that system, the idea
of sending 'private messages' to an unknown person simply had no
appeal whatever.
FIDONEWS 21-51 Page 4 20 Dec 2004
During 1984 I heard that this "Fido" thing had begun 'Conferences'
which now closely duplicated normal "Bulletin Boards", and again I
had to take a look at it. _NOW_ Fido began to look like a real
"Bulletin Board" system; some conferences were 'closed', read only,
some were 'open', read-write.
That's _my_ definition of a BBS.
-----------------------------------------------------------------
FIDONEWS 21-51 Page 5 20 Dec 2004
GENERAL ECHOMAIL POLICY 1
February 1, 1989
PROLOGUE
This document sets forth policy governing Echomail conferences
and their distribution.
This Policy applies to Zone One Backbone Echomail conferences and
to any other conferences for which the Moderator desires it to be
applicable. Future changes to Echo Policy may be proposed only
by a simple majority vote of the Regional Echomail Coordinators.
Those eligible to vote on any proposals made by the REC structure
will be the ZEC, RECs, NECs, NCs, RCs and IC. Only one vote per
person is allowed. Adoption of changes will require a simple
majority of those voting to pass.
In this document, "a simple majority" means more than 50 percent
of those voting. A good faith attempt must be made to make all
potential voters aware that a vote is occurring and make
available all necessary information.
I. HISTORY
Echomail consists of the sharing of message bases or conferences
between various independent network addresses. The Echomail
concept started with a series of programs by Jeff Rush. Since
the original implementation, many authors have written programs
improving on the original idea. In spite of worries that the
flow of Echomail would increase Netmail traffic to the point that
the Network would collapse under its own weight, Echomail has
been a success. To simplify the distribution of Echomail, a
national Echomail Backbone formed whose primary purpose is the
distribution of Echomail at a national level. Of recent
introduction to the Backbone system has been the generous
contribution of the Echomail Stars. As a result of the growth of
Fidonet and the increase in the volume of Echomail, it has become
necessary to set forth a formal policy governing Echomail.
II. DEFINITIONS
1. ECHOMAIL: The process of sharing message bases between
independent systems with unique net/node addresses.
2. ECHOMAIL CONFERENCES: An Echomail conference is a message
base of forum design distributed under a specified conference
name dealing with a defined area of interest. Notable examples
include TECH, the National Technical Conference and COMM, the
National Telecommunications Conference.
3. MODERATED CONFERENCE: A moderated conference is an Echomail
conference for which a moderator has been appointed to supervise
FIDONEWS 21-51 Page 6 20 Dec 2004
the flow and content of the conference. All conferences carried
on the Backbone must be moderated.
4. SYSOP-ONLY CONFERENCE: A Sysop-Only Conference is one in
which the Moderator has decided that the conference will be made
available only to Sysops and not to users.
5. RESTRICTED DISTRIBUTION CONFERENCES: A restricted
distribution conference is one which is restricted only to
eligible recipients. Notable examples include REGCON, the
Regional Coordinators Conference, COORD, the National Echomail
Coordinators Conference, and MAGICK, a pre-register Echomail
Conference.
6. ZONE ECHOMAIL COORDINATOR (ZEC): This individual is
responsible for coordination of Echomail on a FidoNet Zone level.
7. REGIONAL ECHOMAIL COORDINATOR (REC): This individual is
responsible for coordination of Echomail within his region.
8. NET ECHOMAIL COORDINATOR (NEC): This individual is
responsible for coordination of Echomail at the Local Net level.
9. ECHOMAIL Backbone: The Echomail Backbone consists of
voluntary members who provide services to enhance the national
distribution of Echomail. The Backbone consists of nodes which
handle a high volume of Echomail traffic and are responsible for
distribution of Echomail down to the regional level.
10. NATIONAL ECHOMAIL LIST: The National Echomail List
identifies the available national conferences, the conference
moderator and requirements of the specified conference. The ZEC
will appoint the keeper of the National Echomail List.
11. AUTOMATED CENSORSHIP: The term Automated Censorship refers
to programs which cause messages to be removed from the intended
conference or have their content altered.
12. FIDONET POLICY: The document which governs Fidonet as
adopted by Fidonet. The document as of this writing is Policy3
and is subject to change. This policy is intended to become a
part of general Fidonet policy. Until it is incorporated into
General Fidonet policy, this document shall serve to define
policy violations occurring in Echomail.
13. OPEN ACCESS CONFERENCE: This is a non-restricted conference
open to all users who are willing to follow the posted conference
rules.
14. TERMINAL NODE: A system which does not process echomail for
pickup by another system.
III. DUTIES OF ECHOMAIL COORDINATORS
1. GENERAL: It is the duty of the *ECs to make available to
FIDONEWS 21-51 Page 7 20 Dec 2004
any Fidonet Sysop, any conference which the Sysop is not
prohibited from receiving by not meeting requirements as mandated
by the conference moderator. If for any reason the *EC does not
have access via recognized distribution channels to a specific
conference, they can not be expected to pass it on. If a *EC
fails to make available any conference to qualified lower
distribution levels, this shall be deemed to have violated the
outlined duties of the position held. Such violation is cause
for the removal as provided by this document. Nothing in this
provision requires that a *EC must import any conference to the
extent of adverse economic impact. It is recommended that cost
sharing arrangements be employed. Where financially feasible for
the supplier any conference on the Backbone must be made
available (other than restricted conferences) when requested.
An exception is when a *EC cuts a link to end unauthorized
distribution of a conference. In this case, some otherwise
authorized nodes may temporarily lose their link.
A *EC shall do everything in their power to insure that:
1. All downstream links are educated as to this policy.
2. Downstream links know how to properly link into
conferences.
3. Acceptable and unacceptable behavior in echomail
conferences is explained.
4. Downstream links are not engaging in topologies that
increase the risk of duplicate messages.
2. DUTIES OF ZONE ECHOMAIL COORDINATOR: It is the duty of the
ZEC to coordinate the connections between the Echomail Backbone
on both an inter-Zone and intra-Zone level as well as
coordination of inter-regional connections. The ZEC will
coordinate transmission of Echomail and to provide for routing
in a manner that will avoid the transmission of duplicate
messages within the same conference. It is also the duty of the
ZEC to monitor compliance with this policy on both a national and
international basis.
3. DUTIES OF REGIONAL ECHOMAIL COORDINATOR: It is the duty of
the REC to provide for regional Echomail distribution. In
addition, the REC will coordinate any inter-regional cross-
linking of conference feeds with the REC of the participating
region with the direct knowledge of the ZEC. The REC will
provide for transmission and routing of Echomail within his/her
region in a manner to avoid creation of duplicate messages
within the same conference. It is the duty of the REC to monitor
compliance with this policy at a regional level.
FIDONEWS 21-51 Page 8 20 Dec 2004
4. DUTIES OF NET ECHOMAIL COORDINATOR: It is the duty of the
NEC to coordinate the intra-net Echomail and to cooperate with
the REC and NECs of other nets to arrange for the inter-net
transmittal of echomail. The REC may require the NEC to provide
links for independent (regional) nodes. The NEC shall maintain a
list of available Echomail Conferences within the net as well as
the requirements of each Conference area as supplied by the
conference moderator (Echolist). The NEC shall also monitor
compliance with this policy at a net level.
5. DUTIES OF ECHOLIST COORDINATOR: It is the duty of the
Echolist Coordinator to compile and make available a listing of
national and international Echomail conferences and optionally,
conferences at various local levels. The content and format of
the Echomail listing shall be at the sole discretion of the
Echolist Coordinator, but shall include the conference name and
moderator for each conference. The Echolist Coordinator shall
also maintain a list of requirements applicable to each listed
conference.
6. DUTIES OF ECHOMAIL CONFERENCE MODERATOR: It shall be the
duty of the Echomail Conference Moderator to make in good faith
every reasonable effort to insure that the moderated conference
does not distribute or promote illegal activities or information
as defined below in Section V Paragraph 2. The Moderator shall
be responsible for insuring that messages contained in the
conference corresponds to the conference theme. The Moderator
shall report any violations of this policy to the proper Echomail
coordinators and lodge any appropriate policy complaints as
provided for in policy documents adopted by Fidonet. The
Moderator shall post the conference rules in the conference at
least once a month. The Moderator is to authorize the
disconnection of the conference feed. Any Sysop the moderator
believes is violating policy shall be reported to the offending
node's nearest local echomail coordinator (may be a NEC, REC or
in extreme situations a ZEC); and the moderator shall formally
authorize the feed to the offending node to be severed. The
conference moderator is the sole judge - subject to review only
by the ZEC (or his delegates) if a complaint is filed by the
banished party. The Moderator may request in direct written form
(netmail) that the *ECs disconnect a node from the conference
when that node refuses to follow the published conference rules
after at least 3 warnings. Knowingly feeding a conference to a
node that has been severed by the Moderator is considered a
violation of this echomail policy and is subject to suspension.
The length of this suspension will be determined by a joint
decision of the conference moderator and the nearest local echo
coordinator of the node illegally feeding the conference to the
original offending node or point.
Echo conference complaints from a Sysop should be filed at the
net level (NEC) or if the complaining party is an independent
node then with their REC. The NEC or REC receiving such a
complaint must take action in accordance with the provisions of
FIDONEWS 21-51 Page 9 20 Dec 2004
this echomail policy.
For severe or chronic infractions the NEC, REC or ZEC may file
a complaint under general Fidonet policy for excessively annoying
behaviour.
IV. APPOINTMENT AND ELECTION OF ECHOMAIL COORDINATORS AND
MODERATORS.
1. GRANDFATHER CLAUSE: Those Zone, Regional, and Net Echomail
Coordinators and Echomail Coordinators currently holding these
positions as of the date of acceptance of this Echomail Policy
shall continue to service in said capacity until resignation or
replacement under this policy.
2. ELECTION OF ZONE ECHOMAIL COORDINATOR: The ZEC shall be
elected as follows:
a) upon resignation or replacement of the existing ZEC, the
FidoNet Zone Coordinator (ZC) shall nominate at least five
individuals to be voted upon.
b) 10 days after the nominees are selected, an election
shall be held. The ZEC will be elected by a simple majority
of IC, ZC, RCs, NCs, RECs, and NECs in their Fidonet zone.
An individual holding more than one position can only cast
one vote. That is, if an individual is both a NC and a NEC,
they may cast only one vote.
3. ELECTION OF REGIONAL ECHOMAIL COORDINATOR: The REC shall be
elected as follows:
a) upon resignation or replacement of an existing REC, the
ZEC shall nominate at least 3 individuals for election.
b) 10 days after the nominees are selected, an election
shall be held. The REC will be elected by a simple majority
of the RC, NCs and NECs in their FidoNet Region. An
individual holding more than one position may only cast one
vote.
4. NET ECHOMAIL COORDINATOR: The NEC shall be appointed by the
FidoNet Net Coordinator (NC) or in such alternative manner as
determined by the NC. If a NEC is not appointed within 30 days,
the REC will appoint the NEC.
5. REMOVAL OF A *EC: A *EC may be removed from their position
by a simple majority of those allowed to vote for their
successor. For a NEC, the members of the Net may vote by simple
majority to remove the NEC. The position directly above (in the
*EC structure) will oversee the recall election in the same
manner as prescribed for electing successors.
A *EC may only be subject to recall for failure to properly carry
out their duties described above, or if they are no longer a
FIDONEWS 21-51 Page 10 20 Dec 2004
member of Fidonet. A promise of 'free' echomail delivery from
another source is *not* considered an acceptable reason for
recall.
6. RECOGNITION OF CONFERENCES: The *EC corresponding to the
appropriate leve recognizes a conference at his level. Examples:
The NEC recognizes a conference as local. The REC recognizes a
conference to be regional. A ZEC recognizes a conference to be
zonal. The IC recognizes a conference to be inter-zonal.
7. REMOVAL OF AN ECHOMAIL CONFERENCE MODERATOR: An Echomail
Conference Moderator may be removed from their position by a
three fourths (3/4) vote of the *EC structure voting. This vote
must be carried out in a fair and decent manner while giving at
least ten (10) days notice to the entire *EC structure of the
upcoming vote. Notice mediums acceptable are: Netmail from the
ZEC, usage of international postings in such conferences as
COORD. Or in extreme instances, by REC to NEC written
notification.
An Echomail Conference Moderator may only be subject to recall
for failure to properly carry out their duties described above or
continued pre-meditated violation of this documents section V.
Statement of Policies as seen below. Failing to perform the
above duties of a conference moderator for a period of 3 or more
months and/or failing to designate a proxy in his absence shall
be in violation of this policy and be subject to recall. A vote
may only be callable by the ZEC (or his delegate). This delegate
should not be from the region or net of the affected conference
moderator.
Membership in Fidonet need not be a paramount issue, but is
highly recommended.
V. STATEMENT OF POLICIES
1. BASIC ECHOMAIL POLICY: The basic policy of Echomail is to
promote communication in Echomail Conferences in a lawful,
friendly manner consistent with the general principles of
FidoNet.
2. PROHIBITION ON ILLEGAL ACTIVITIES: Any Node which knowingly
distributes or allows to be entered into echomail conferences any
messages containing or promoting illegal activities or
information shall be deemed to have violated general FidoNet
policy as being excessively annoying. As used in this paragraph,
"illegal activities" includes activities which are a violation of
civil law as well as activities which would result in criminal
prosecution.
3. AUTOMATED CENSORSHIP: The use of Automated Censorship in the
passing or distribution of echomail will be considered a
violation of this policy and will not be tolerated. Disciplinary
action will be as referred to in General Fidonet policy as being
FIDONEWS 21-51 Page 11 20 Dec 2004
excessively annoying.
An exception to this provision shall be the deletion and not
censorship of messages by any Sysop which may lead to legal
action against that Sysop.
No echomail shall be modified in any manner which could
potentially cause duplicates.
4. INTER-NETWORK CONFERENCES: Inter-Net conferences shall
conform to general Fidonet policy as well as the provisions of
this policy document in addition to any foreign network's
provisions.
5. CHARGING FOR DISTRIBUTION: Any entity which makes a profit
from the distribution (passing from system to system) of echomail
shall be deemed to be excessively annoying and in violation of
Fidonet policy subject to enforcement under existing Fidonet
policy. Profit as defined in this paragraph is the charging for
echomail distribution that exceeds actual cost to obtain and
distribute the Echomail over a sustained period. The cost of the
equipment used to obtain and distribute echomail may not be
recovered. A Sysop that charges users for access to their BBS
shall NOT be in violation of this paragraph.
6. RESTRICTED DISTRIBUTION CONFERENCES: Participating Nodes
shall honor and support the restrictions placed upon restricted
distribution conferences. Violation of this restriction by
individual nodes and points shall be a violation of this echomail
policy and result in suspension of the violated echo in
accordance with the above paragraph in Section III Duties of the
Echomail Conference Moderators.
A SYSOP only conference shall be made available only to the
Sysops or Co-Sysops of Fidonet or other nets with which inter-net
conferences exist.
A violation of the restrictions placed on a RESTRICTED
DISTRIBUTION CONFERENCE will be a violation of this policy if and
only if the moderator has posted and specified the restrictions
governing the conference.
7. PATH REQUIRED: The PATHline, originally implemented by SEA
in the MGM package, is required except for terminal nodes. If
your current Echomail scanner supports the pathline you must
enable it NOW. If your current Echomail scanner does not support
the pathline, and if there is no alternative scanner, then
enforcement of this paragraph will be deferred for 60 days.
After that date, the *ECs may refuse to accept/supply echomail to
any node that is not supporting the pathline.
8. SEEN-BY LINE: Under the current technology and topology (the
routing structure of echomail), SEEN-BY lines play an important
part in reducing duplicate messages. Tiny SEEN-BYs will not be
allowed until the respective ZECs feel topology will allow their
use. Nor will the stripping of SEEN-BYs (except Zone-Gates and
FIDONEWS 21-51 Page 12 20 Dec 2004
Inter-Network EchoGates) be allowed unless approved by the ZEC.
Violation of the above shall be excessively annoying behavior
enforceable under general Fidonet policy. Zone-Gates and Inter-
Network EchoGates SHOULD strip the SEEN-BYs of the exporting Zone
or Network to reduce addressing conflicts.
9. COUNTERFEIT MESSAGES: Entering or knowingly distributing
counterfeit messages shall be considered excessively annoying and
a violation of Fidonet policy enforceable under the terms of
Fidonet policy. As used in this paragraph, a counterfeit message
is defined as any message entered using another person's name,
handle or node address with the intent of deceiving others about
the true author of the message. No handles shall be used to
enter messages to knowingly provoke, inflame, or upset
participants in a conference with the purpose of deceiving others
about the true identity of the author.
10. SYSOP'S RESPONSIBILITY: It is the responsibility of each
Sysop to make every reasonable effort to assure that the users on
his board conform to the provisions of this policy document. A
Sysop may be held responsible for the acts of his users unless
the Sysop can show that a reasonable attempt was made to conform
to this policy document.
11. ECHOMAIL SOFTWARE: EchoMail exchanges may consist of any
type of archival storage format agreed upon by both parties.
SEA's ARC 5.1 (non-Squashing) archival storage format will be the
"fallback" if either party is unable or unwilling to support an
alternate method. The continued use of Echomail software without
prior agreement of both the sending and receiving nodes which
interferes with the distribution of echomail shall lead to
disciplinary action as described previously in this document.
See Section III. Examples of prohibited software would include
the use of non-standard echomail packets which can not be
processed by the receiving system. Another example would be the
use of poorly implemented scanners or tossers that cause
duplicates or fail to forward messages to downstream links. A
further example is the use of Tiny seenby options and the use of
^A hidden SEEN-BY lines. Use of Echomail software which does not
conform to the minimum acceptable standards as defined by the
Fidonet Technical Standards Committee (FTSC) shall lead to
disciplinary action as described previously in this document.
The Software Certification Committee is authorized to determine
whether software meets minimum standards for use on the net.
12. HOST ROUTING OF ECHOMAIL: Host routing of Echomail without
the prior consent of both the Sending and Receiving Hosts shall
lead to disciplinary action as described previously in this
document. See Section III.
13. SENDING OF ECHOMAIL DURING ZONE MAIL HOUR: Transmission of
echomail during Zone Mail Hour as defined in Fidonet policy
without the consent of the receiving system shall lead to
disciplinary action as described previously in this document.
See Section III.
FIDONEWS 21-51 Page 13 20 Dec 2004
14. INTER-NETWORK CONFERENCES: It is the general policy of
Fidonet to encourage the development of INTER-NETWORK
CONFERENCES. It shall be the duty of those providing the INTER-
NETWORK CONFERENCE links to remove foreign net distribution
identifiers which will adversely effect the distribution of the
Echomail Conference while in Fidonet. The INTER-NETWORK
CONFERENCE links maintained in Fidonet shall be operated in a
manner not to interfere with the foreign network's distribution
of Echomail.
15. DEFAMATORY POSTING: The posting of any DEFAMATORY MESSAGE
other than in conferences dedicated to this purpose (i.e. FLAME)
shall lead to disciplinary action as described previously in this
document. See Section III. The posting of substantiated facts
shall not be considered a violation under this section.
16. ADDING OR REMOVING CONFERENCES FROM THE Backbone: A
conference may be added to the Backbone only by request of the
RECOGNIZED Conference Moderator. A conference may be removed
from the Backbone by lack of traffic. A committee composed of the
ZEC and 4 RECs shall review the status of backbone echos every 6
months. At which time those echos which have not maintained a
minimum 10 messages a week over the preceeding 6 months will be
noted and their Conference moderators will be contacted. These
conferences will be given 3 months to improve their traffic or
withdraw from Fidonet backbone distribution. The recognized
conference moderator may request removal of their conference from
the Fidonet backbone distribution at their discretion.
17. TOPOLOGY and DUPLICATE MESSAGES: Cross Regional links
should be avoided as they increase the risk of improper linking
and generation of duplicate messages. Cross Regional links may
be established only with the permission of the REC in each
region. Each REC will do their best to make available high speed
hubs, out of state hubs, PC Pursuit hubs, etc, to facilitate the
low cost, efficient movement of mail within their respective
Region. If either REC has reason to believe duplicates are being
introduced into the system, an existing Cross Regional link must
be immediately cut pending resolution.
Any Sysop who willfully and knowingly establishes links that
either create duplicate loops (topology that creates circular
feeds), increase the risk of such loops or who refuses to break
those links upon request by their NEC, REC or ZEC shall be
subject to disciplinary action as described previously in this
document. See Section III.
18. MESSAGE STANDARDS: Until the adoption of a superceding
standard by the Fidonet Technical Standards Committee, the
following Echomail message standards will apply:
a) Eight-bit characters (ASCII 128-255) and non-printing
low-order codes (ASCII 2-31) are prohibited, except the use
of 8Dh(soft <CR> character) per FTS-0004. This is not
intended to discourage participation of foreign zones or
networks, which may permit said characters. Any echomail
FIDONEWS 21-51 Page 14 20 Dec 2004
processor should pass information exactly as it was
received, without stripping any non-standard characters.
b) Origin lines are limited to 79 characters including the
required ending of a proper network address (i.e.
Zone:Net/Node.Point with zone and point being optional).
c) Tear lines are limited to 35 characters including the
required "--- " lead-in. These may ONLY contain packer or
editor program identification. Tear lines for message
editors are discouraged. If an editor adds a tear line, it
should also add an origin line to avoid multiple tear lines.
d) "Extra" origin lines (ZoneGating) are limited to
essential information only. This consists of the required
lead-in plus the network name "Gateway" and optionally the
software ID followed by a Zone:Net/Node address.
Example: " * Origin: FidoNet Gateway (TComm 88:372/666)"
e) SEEN-BY addresses must be in sorted order. Multiple
AKA's are not allowed in SEEN-BY lines unless you have more
than one address which processes mail. Or for one month
during change of an existing address (to avoid duplicates to
the previous address). Node 0 addresses should not be used
for echomail distribution.
f) All current FTSC specifications should be followed.
VI. ENFORCEMENT
Enforcement of this policy document shall be under the provisions
of General FidoNet policy. Complaints concerning Echomail
violations defined under this policy may be filed by the
aggrieved individual, the conference moderator or by any level of
Echomail Coordinator. All complaints made pursuant to this
policy must be made within 60 days of the date of occurrence or
discovery. Complaints shall be filed under the provisions of
Fidonet Policy, with a copy to the respective *EC.
Enforcement is immediate, with any currently existing software
allowed 60 days to conform (from the date EchoPol1 goes into
effect). A 30-day extension may be granted solely at the
discretion of the ZEC if efforts to bring about compliance are
clear. Continued use of aberrant software after this period
shall be deemed excessively annoying.
VII. ADOPTION OF POLICY
1. ADOPTION: This policy shall become effective upon
ratification by a simple majority of those voting. Those
eligible to vote shall be the IC, ZCs, RCs, NCs, ZECs, RECs, and
NECs. Those individuals holding more than one position can cast
only one vote.
FIDONEWS 21-51 Page 15 20 Dec 2004
2. GRANDFATHER CLAUSE: Within 60 days of adoption of this
policy, moderators shall be appointed for all existing Echomail
Conferences which do not now have a moderator. Moderators shall
be appointed by the ZEC from those volunteering as moderator or
if no volunteer is available then the ZEC shall request and
appoint a moderator for the conference. In the case where more
than one individual claims to be the conference moderator and no
agreement can be reached, the ZEC may order the conference
retired and ban the further use of the specific conference name.
Failure of the individuals to retire the conference name shall be
deemed excessively annoying behavior.
VI. BACKBONE STRUCTURE
This section is for information purposes only. It gives a plain
English description of the current structure and operation of the
Backbone. The ZEC may change this structure without amending
this document.
At the top of the Echomail distribution network, there are
systems commonly called Stars. These systems are usually
dedicated to passing Echomail. The stars operate at the
discretion and direction of the ZEC. At the time of this writing
there are 3 stars, each has a backup system/plan in the event of
a failure. In general, the Stars link to one another and feed
the RECs.
The RECs are then responsible for distribution of the echomail
within their Region. Normally, the REC will feed the NECs in
that region.
The NEC is responsible for distribution of Echomail to the
individual Sysops within a net.
Note that the RECs and NECs can appoint Hubs to help in the
distribution of Echomail. That is, they do not have to directly
feed the lower level.
This is the distribution GOAL. Because of less expensive phone
rates and other reasons, this distribution method is not followed
exactly. Any change to the above requires agreement of the *EC's
involved. All *ECs will use all the tools at their disposal,
such as hubs, high speed modems, ROA, Wide Area Calling plans, PC
Pursuit, corporate sponsorship, etc., to provide fast, efficient,
and cost effective movement of echomail.
Echopol Committee
Mike Ratledge
Norm Henke
Rick McWilliams
Barry Shatswell
-----------------------------------------------------------------
FIDONEWS 21-51 Page 16 20 Dec 2004
What is???
Matt Mc Carthy
1:396/45.17
The first paragraph below is taken from the already approved and
functioning document "FidoNet(tm) Internetwork Gateway Policy",
dated July 22, 1990. Added to it represents what I believe to be
"Common Practice" at this time, as stated by many in MODERATOR and
FIDOECHOPOL, with a few of my own ideas included. A few words have
been changed since it's original posting in 1989.
The purpose of this writing is:
1) To define "Echomail"
2) To define "Moderator"
3) To define "EchoList"
4) To assign Moderator responsibilities and limitations
5) To provide a link for review proceedures should this
ever become 'policy'.
"Echomail"
----------
Echomail is the term used within FidoNet to refer to electronic
"Conference Mail" messages that, while possibly containing
the name of a particular individual in the "To:" field, are
copied and distributed to multiple (possibly several hundred)
destination systems. Echomail messages are segregated into
"Conferences" based upon the topic being discussed. Echomail
message content is usually restricted to the topic(s) for which
the particular conference was created.
The originators of each of these Conferences, as well as their
designees and successors are called "Moderators". The "name" of
each Conference is called its "Echotag".
A listing of FidoNet Conferences, their respective Moderator(s),
and those Moderators' electronic addresses, is contained in the
monthly publication of the holder of FidoNet address 1:1/201.
The title of this listing is "ELIST", short for EchoList.
A Moderator is the owner of the Echotag of the respective
Conference, but not its content. A Moderator is empowered to
establish and enforce rules of conduct and topicality to which
users are enjoined to adhere.
A Moderator grants permission to all participants to add the
Moderator's Echotag to messages they post, in so far as the
messages they post follow the rules of conduct and topicality
as set forth in periodic postings by the Moderator.
Each Moderator is solely responsible for insuring the conduct and
topicality of their respective Conferences in consonance with
their published rules. No responsibility or authority beyond the
FIDONEWS 21-51 Page 17 20 Dec 2004
Moderator's respective Conference is intended or implied.
In accordance with this responsibility, a user's failure to adhere
to the published rules of a Moderator is considered grounds for
immediate revocation or restriction from use of said Echotag.
A user who feels he is having a bad time because of a Moderator
should let his local BBS System Operator (SysOp) know. The SysOp
can discuss the situation with the Moderator, resolve the dispute,
or drop the echo in question in cases where the Moderator is
unreasonable.
A Moderator request for action must receive immediate action by
the recipient.
As always, any errors may be subject to normal FidoNet review
proceedures under existing policy, should a complaint be lodged.
(Ver. JJ6)
M.
-----------------------------------------------------------------
FIDONEWS 21-51 Page 18 20 Dec 2004
=================================================================
FIDONET BY INTERNET
=================================================================
Fidonet Related Websites
Thom LaCosta
1:261/1352
One approach to tracking and viewing Fidonet related websites is to
visit webrings that specialize in Fidonet.
A webring is a method where sites having a common theme advertise
other websites with simailar themes. The advantage to the webring
concept is that in theory, the sites have an interest in maintaining
an accuate listing and can modify their own listings on a site by site
basis.
It appears that there are two fidonet webrings....the long-running
system at http://b.webring.com/hub?ring=fidonet and another at
http://www.fidonet.us/fidoring/
The ring at webring.com is larger, but forces the viewer to look at
google ads panels. The smaller ring at fidonet.us does not depend on
adverstising revenue from ads.
Sysops with Fidonet related websites should consider joining one or
both rings.
Ring News
It's a pleasure to welcome two new BBS systems to the
fidonet.us webring:
Pucela BBS (Valladolid, Spain) Sysop: Komunero
The Realm of Darkness BBS Sysop: Ken Bowley
The most current version of the list below can be viewed at
http://www.fidonet.us/fidoring/sitelist.html
WWW.FIDONET.US - WEBRING PARTICIPANTS
BBBS Charlotte and N4RPS.net Home Page
Web Page of N4RPS, Rob Sargeant, and Web portal for BBBS Charlotte,
a Fidonet BBS located in Charlotte, North Carolina USA (1:379/2).
http://www.n4rps.net - 6-November-2003
Fidonet - Net261 - Maryland
Fidonet in Maryland - Net261
http://www.fidonet.us/net261/ - 2-March-2003
Rocasa BBS
Rocasa BBS is a system accessible as both a traditional Bulletin
Board System, via landline or telnet, as well as via the Web for
message and file access. It is also the home of the BBBS FDN.
http://bbs.rocasa.org - 16-June-2003
<<Prism BBS
FIDONEWS 21-51 Page 19 20 Dec 2004
Hq of the IFDC FileGate and the Programmers Distribution Network.
<<Prism has been online since 1989.
http://www.filegate.net:8080 - 11-February-2003
Fidonet.us
The Fidonet Site for all sysops.
http://www.fidonet.us - 10-February-2003
The Realm of Darkness BBS
A Linux based BBS running in Phoenix, AZ
http://www.trod.org/trod.html - 3-December-2004
Pucela BBS (Valladolid, Spain)
BBS located in Spain. The web has a lot of information about BBS's
and FidoNet in Spain, Argentina, Mexico, ... FidoNet: 2:341/201.
Language: Spanish.
http://www.conecta2.org/pucela_bbs/pucelabbs.htm - 18-November-2004
FTN Gate
Fidonet related site; including especially DNS hosting for
z1.fidonet.net domains.
http://www.ftngate.net - 18-September-2004
Fidonet Region 13
Home page for Fidonet Region 13.
http://www.fidonet.us/region13/ - 20-August-2004
FidoNet Primer
An introduction to FidoNet: what it is, how it works
http://www.writebynight.com/fidonet.html - 11-February-2003
RuneKeep BBS
A great place for new sysops to learn about BBSing and getting help
setting things up. A friendly place for people to Play Onlines Games,
Chat, and participate in International Message Forums.
http://runekeep.darktech.org - 10-February-2003
The Elflords' Home
Where the FidoMob meets to exercise it's mysterious control over
Zone 1
http://www.elflords.net/ - 2-March-2003
Fidonet Parody
FidoNet - An Unofficial Page where truth is stranger than fiction,
and humor abounds when the Emperor Has No Clothes.
http://www.fidonet.ro/ - 2-March-2003
Chowdanet BBS
Chowdanet offers mail from several nets, games and a large files base.
Dial up and telnet access.
http://www.chowdanet.com - 11-February-2003
Thom
1:261/1352
-----------------------------------------------------------------
FIDONEWS 21-51 Page 20 20 Dec 2004
=================================================================
ROBERT COUTURE'S FIDONET SOFTWARE LISTING
=================================================================
-=:{ FIDONet Software Reference }:=-
Type: M=Mailer T=Tosser B=BBS D=Door C=Comm/Terminal
P=Points E=Editor I=Internet U=Utility ?=Info
.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -.
|Software: Author |Type |URL, Contact, Ver, Notes Help Node|
`- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -'
Argus |MI |http://www.ritlabs.com/argus/ 2:469/84
| | argus@ritlabs.com Tel: 373-2-246889
| | v3.210 on Mar 20th 2001
BinkleyTerm XE |M |http://btxe.sourceforge.net 1:1/102
| | v2.60XE/Gamma-6 on Nov 11th 1998
BinkD |MI |http://2f.ru/binkd/
| | maloff@corbina.net
| | v0.94 on Jul 24th 2000 (Outdated)
FIDO-Deluxe IP |MPUI |http://www.fido-deluxe.de.vu 2:2432/280
Michael Haase | | m.haase@gmx.net
| | v2.4 on Sep 26th 2003
FrontDoor, FD/APX: |MTPC |http://www.defsol.se 2:201/330
Definite Solutions | | sales@defsol.se 1:1/101
| | v2.26SW & v2.33ml FD, v1.15 APX
Husky Project |MTPUI|http://sf.net/projects/husky/
| | v1.4 RC2 on Sep 22nd 2003
Radius |MI |http://radius.pp.ru 2:5012/38
(based on Argus) | | fido5012@zaural.net Tel: 7-3522-469463
| | v4.009 on Jan 2nd 2003
Taurus |MI |http://taurus.rinet.ru 2:461/701
(based on Radius) | | E-mail: taurus@rinet.ru
| | v5.000 alpha on Oct 11th 2004
Tmail |MI |http://www.tmail.spb.ru v2608
| | Website is in Russian only
WildCat! Interactive |MTBEI|http://www.santronics.com
Net Server, Platinum| | sales@santronics.com
Xpress: Santronics | | Tel: (305) 248-3204
Software, Inc. | | AUP 451.1 on April 26th 2004
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
Fidogate |TUI |http://www.fidogate.org
| | Martin_Junius@m-j-s.net v4.4.10
FMail |T |http://fmail.nl.eu.org
FIDONEWS 21-51 Page 21 20 Dec 2004
| | support@fmail.nl.eu.org v1.60
JetMail: JetSys |TU |http://www.jetsys.de js@jetsys.de
(ATARI ST only) | | v1.01 on Jan 1st 2000
Squish |T |http://maximus.sourceforge.net/
| | Lanuis site redirects to above
| | Squish is part of Maximus.
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
BBBS |BI |http://www.bbbs.net b@bbbs.net
| | v4.00MP on Oct 25th 1999 2:22/222
ELEBBS: The Elevator |B |http://www.elebbs.com
Software Production | | elebbs@elebbs.com
| | v0.10.RC1 on Jun 9th 2002
EZYCom BBS |BT |http://homepages.ihug.com.au/~dcbbs/
| | pjs@optushome.com.au 3:633/104
| | v2.0 on 3 May 2003
Hermes II Project |B |http://www.hermesii.org
| | info@HermesII.org v3.5.9 Beta Final
Maximus BBS |B |http://maximus.sourceforge.net/
| | v3.03
MBSE BBS: |BI |http://mbse.sourceforge.net 2:280/2802
Michiel Broek | | mbroek@users.sourceforge.net
| | v0.60.0 on June 5th 2004
Mystic BBS |B |http://www.mysticbbs.com
| | v1.07.3 on May 13th 2001
Nexus BBS |B |http://www.nexusbbs.net
| | groberts@nexusbbs.net
| | v0.99.41-Beta on Oct 16th 2002
| | [Note: No Longer under active
| | development.]
Proboard BBS |B |http://www.proboard.be
| | v2.17 on Jun 9th 2002
RemoteAccess BBS: |B |http://www.rapro.com 1:1/120
Bruce Morse | | bfmorse@rapro.com
| | v2.62.2SW
Spitfire BBS: Buffalo|B |http://www.angelfire.com/ia/buffalo/
Creek Software | | MDWoltz@aol.com 1:1/150
| | v3.6 on Aug 20th 1999
Synchronet BBS |BT |http://www.synchro.net
| | sysop(at)vert(dot)synchro(dot)net
| | v3.10L Beta
FIDONEWS 21-51 Page 22 20 Dec 2004
Telegard BBS |B |http://www.telegard.net
| | support@telegard.net
| | v3.09g2 SP4
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
Atlantis Software |D |http://www.jimmyrose.com/atlantis/
| | Last Update: August 2004
Cheepware |DU |http://cheepware.midnightshour.org
Sean Dennis | | hausmaus@midnightshour.org 1:18/200
DDS (Doorware |D |http://www.doorgames.org 1:2404/201
Distribution System)| | ruth@doorgames.org
Ruth Argust | |
DoorMUD |D |http://doormud.com
| | v0.98 Jun 1st 2002
| | Website is down after
| | past the splash page.
Jibben Software |D |http://www.jibbensoftware.com
| | scott@jibben.com
| | 1995-99 Release dates
John Dailey Software |D |http://www.johndaileysoftware.com
| | support@johndaileysoftware.com
Shining Star |D |http://www.shiningstar.net/bbsdoors/
| | nannette@shiningstar.net
Sunrise Doors: |D |http://www.sunrisedoors.com
Al Lawrence | | al@sunrisedoors.com
| | Tel: (404) 256-9518
The Brainex System |D |http://www.brainex.com/brainex_system/
| | stanley@brainex.com 1994-99 Releases
Trade Wars |D |http://www.eisonline.com/tradewars/
| | jpritch@eisonline.com
| | v3.09 (DOS-32) in 2002
Vagabond Software: |D |http://www.vbsoft.org 1:124/7013
Bryan Turner | | vagabond@vbsoft.org
| | last update: Jul 17th 2002
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
APoint |PI |http://www.apoint-mail.de
| |http://www.apoint-mail.de/indexe.htm
| | (English Version)
| | dirk.pokorny@apoint-mail.de
| | v1.25 2:2426/1210.13
CrossPoint (XP) |P |http://www.crosspoint.de (German Only)
| | pm@crosspoint.de v3.12d Dec 22nd 1999
FIDONEWS 21-51 Page 23 20 Dec 2004
FreeXP |P |http://www.freexp.de 2:2433/460
| | support@freexp.de
| | v3.40 RC3 Aug 31st 2003 (Snapshot)
OpenXP/32 |PI |http://www.openxp.com 2:248/2004
| | (Site is in German Only)
| | mk@openxp.de v3.8.15 Beta Feb 10th 2004
| | Download Page comes back 404 not found.
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
GoldEd+ |E |http://mik.nu/golded-plus/ 2:203/6600
| | v1.1.5 Snapshot on Feb 28th 2003
SqEd32 |E |http://www.sqed.de
| | v1.15 on Dec 15th 1999
TimEd |E |http://blizzard.dnsalias.org/fidonet
| | mail@ozzmosis.com /timed
| | v1.11.a5 in March 2003 3:633/267
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
GiGo |UI |http://www.gigo.com
| | v0109 on Jan 9th 1997
Internet Rex: |UI |http://members.shaw.ca/InternetRex/
Charles Cruden | | telnet://xanadubbs.ca 1:342/806
(Khan Software) | | v2.29 on Oct 21st 2001
TransNet |UI |http://www.ressl.com.ar/transnet/
| | transnet@ressl.com.ar
| | v2.11 on Jul 18th 1998
TransX: Multiboard |UI |http://www.start.ca/software/multiboard
Communications, Inc.| | Unsure about support now but Free Keys
| | are now available. Donations accepted.
| | v3.5 (Note: KeyGen is a Windows Program)
Ifmail |UI |http://ifmail.sourceforge.net
| | crosser@average.org 2:5020/230
| | Ifmail is a FTN <-> E-Mail/News Gateway
| | Program.
Meltdown-BBS |UI |http://meltdown-bbs.sourceforge.net/
| | meltdown-bbs.project.petkan
| | @spamgourmet.com
| | Fido: 2:350/5
| | Meltdown-BBS is an FTN <->
| | Web/PHP/MySQL BBS forum system.
MakeNL |U | http://hub2000.darktech.org/makenl
| | fidonet.hub2000 [at] gmail [dot] com
| | Fido: 1:229/2000
| | FidoNet Nodelist Processor
FIDONEWS 21-51 Page 24 20 Dec 2004
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
National BBS List |? | http://www.usbbs.org
Hispanic FIDO/BBS's |? | http://www.conecta2.org/pucela_bbs/
(in Spanish only) | | (Extensive software & BBS Listings)
+- - - - - - - - - - -+- - -+- - - - - - - - - - - - - - - - - - - -+
File Archives:
http://archives.thebbs.org http://www.filegate.net
http://sysopscorner.thebbs.org http://www.juge.com
http://www.dmine.com/bbscorner/ http://garbo.uwasa.fi
http://www.simtel.net http://wuarchive.wustl.edu
http://maximus.midnightshour.org http://hobbes.nmsu.edu
Note: most also provide FTP access
(use ftp:// instead of http:// above)
*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*=.=*=-=*
Please send corrections & additions to: Robert Couture, 1:229/2000
E-Mail: rpa4email (at) rogers (dot) com
Telnet: runekeep.darktech.org
(Leave Feedback as Guest or create an account)
Emeritus: Ben Ritchey, Todd Cochrane, Frank Vest, Peter Popovich
-----------------------------------------------------------------
FIDONEWS 21-51 Page 25 20 Dec 2004
=================================================================
SPECIAL INTEREST
=================================================================
Nodelist Stats
Input nodelist nodelist.352
size 832.7kb
date 2004-12-17
The nodelist has 6912 nodes in it
and a total of 9555 non-comment entries
including 6 zones
47 regions
387 hosts
487 hubs
admin overhead 927 ( 13.41 %)
and 1114 private nodes
255 nodes down
347 nodes on hold
off line overhead 1716 ( 24.83 %)
Speed summary:
>9600 = 605 ( 8.75 %)
9600 = 5941 ( 85.95 %)
(HST = 120 or 2.02 %)
(CSP = 0 or 0.00 %)
(PEP = 1 or 0.02 %)
(MAX = 0 or 0.00 %)
(HAY = 1 or 0.02 %)
(V32 = 3105 or 52.26 %)
(V32B = 263 or 4.43 %)
(V34 = 4049 or 68.15 %)
(V42 = 3407 or 57.35 %)
(V42B = 262 or 4.41 %)
2400 = 59 ( 0.85 %)
1200 = 8 ( 0.12 %)
300 = 299 ( 4.33 %)
ISDN = 547 ( 7.91 %)
----------------------------------------------------------
File Req Flag Applicable software Number of systems
----------------------------------------------------------
XA Frontdoor <1.99b 2263
Frontdoor 2.02+
Dutchie 2.90c
Binkleyterm >2.1
D'Bridge <1.3
TIMS
Xenia
--------------------------------------
FIDONEWS 21-51 Page 26 20 Dec 2004
XB Binkleyterm 2.0 9
Dutchie 2.90b
--------------------------------------
XC Opus 1.1 8
--------------------------------------
XP Seadog 6
--------------------------------------
XR Opus 1.03 40
--------------------------------------
XW Fido >12M 283
Tabby
KittenMail
--------------------------------------
XX D'Bridge 1.30 3081
Frontdoor 1.99b
Intermail 2.01
T-Mail
--------------------------------------
None QMM 1222
--------------------------------------
CrashMail capable = 2130 ( 30.82 %)
MailOnly nodes = 3872 ( 56.02 %)
Listed-only nodes = 541 ( 7.83 %)
Other = 369 ( 5.34 %)
[Report produced by NETSTATS - A PD pgm available from 1:106/100]
[ Revised by B Felten, 2:203/208]
-----------------------------------------------------------------
FIDONEWS 21-51 Page 27 20 Dec 2004
=================================================================
FIDONEWS INFORMATION
=================================================================
How to Submit an Article
If you wish to submit an article for inclusion in the Fidonews, here
are some guidelines, if you send it as an attached file; the preferred
method if you want reasonable control over how the published article
will appear in the Fidonews:
a) Plain ASCII text. If you could type it on your keyboard, it's
probably quite OK. No line may be longer than 70 characters.
b) Put a title to the article. Put the title in two times. The first
time, on the first line, with an * before it. The second time, on
the second line, without the * and centered. This will help in the
format since the title with the * is removed and used in the index,
the second line will become the headline. On the third line, put
your name and FidoNet address, present or former. If former, you
may want to add some other address where you can be reached for
personal comments.
c) Deadline for article submission is Sunday, 12:00 UTC.
Help the Editor by following the above guides. Below are some subjects
and the file extension for the article as set in the configuration
file for the making of the Fidonews. Please help by putting the file
extension of the correct subject on the file name if known..
Ideas for Subject areas:
Subject File | Subject File
----------------------------------|----------------------------------
From the *C's *.css | Rebuttals to articles *.reb
Fidonet Regional News *.reg | Fidonet Net News *.net
Retractions *.rtx | General Fidonet Articles *.art
Guest Editorial *.gue | Fidonet Current Events *.cur
Fidonet Interviews *.inv | Fidonet Software Reviews *.rev
Fidonet Web Page Reviews *.web | Fidonet Notices *.not
Getting Fidonet Technical *.ftc | Question Of The Week *.que
Humor in a Fido Vein *.hfv | Comix in ASCII *.cmx
Fidonet's Int. Kitchen *.rec | Poet's Corner *.poe
Clean Humor & Jokes *.jok | Other Stuff *.oth
Fidonet Classified Ads *.ads | Corrections *.cor
Best of Fidonet *.bof | Letters to the Editor *.let
If you don't know or are not sure, send the article anyway. Put a .TXT
on it and I'll try to figure out where it should be in the Fidonews.
If you follow these simple guidelines, there should be little problem
in getting your article published. If your submission is too far out
of specs for the Fidonews, it will be returned to you and/or a message
sent informing you of the problem. This DOES NOT mean that your
article is not accepted. It means that there is something in it that I
can not fix and I need your help on it.
FIDONEWS 21-51 Page 28 20 Dec 2004
Send articles via e-mail or netmail, file attach or message to:
Björn Felten
Fidonet 2:2/2
E-Mail bfelten @ telia dot com
IMPORTANT! If you send the article via e-mail, make sure you put the
word "fidonews" somewhere in the subject line! That way it
will always pass the spam filter, ending up in the proper
folder.
Please include a message, telling me that you have sent an article.
That way I will know to look for it.
-----------------------------------------------------------------
FIDONEWS 21-51 Page 29 20 Dec 2004
Credits, Legal Infomation, Availability
+ -- -- -- -- -- -- -- -- FIDONEWS STAFF - -- -- -- -- -- -- -- +
| |
| Editor: Björn Felten, 2:2/2 |
| Crash mail attached: Editor@2:2/2 |
| E-Mail attached: bfelten @ telia dot com |
| Webmaster: Jim Barchuk, jb@fidonews.org |
| Columnist: Frank Vest - Frank's Column |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
+ -- -- -- -- -- -- -- - EDITORS EMERITI - -- -- -- -- -- -- -- +
| |
| Tom Jennings, Thom Henderson, Dale Lovell, Vince |
| Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees, |
| Christopher Baker, Zorch Frezberg, Henk Wolsink, |
| Doug Meyers, Warren D. Bonner, Frank L. Vest |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
Fidonews is published weekly by and for the members of Fidonet.
Fidonews is Copyright (C) 2004 by Björn Felten, though authors
retain rights to their contributed articles. Opinions expressed
by the authors is strictly their own. Noncommercial duplication
and distribution within Fidonet is encouraged. Authors are
encouraged to send their articles in ASCII text to the Editor
at one of the addresses above.
The weekly edition of Fidonews is distributed through the file
area FIDONEWS, and is published as echomail in the echo FIDONEWS.
These sources are normally available through your Network
Coordinator. The current and past issues are also available from
the following sources:
+ -- -- -- -- -- -- - FIDONEWS AVAILABILITY - -- -- -- -- -- -- +
| |
| File request from 2:2/2: |
| current issue FIDONEWS |
| back issue, volume v, issue ii FNEWSvii.ZIP |
| |
| On the web: |
| http://felten.dyndns.org/fidonews |
| http://www.fidonet.ca/fidonews |
| |
| The Snooze *and* the FIDONEWS echo in your newsreader: |
| news://felten.dyndns.org/FIDONEWS |
| |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
-----------------------------------------------------------------
Download original FidoNews · Volume 21 (2004) · ← Previous · Next →