informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1414.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

2496 lines
113 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

F I D O N E W S -- Volume 14, Number 14 7 April 1997
+----------------------------+-----------------------------------------+
| The newsletter of the | ISSN 1198-4589 Published by: |
| FidoNet community | "FidoNews" |
| _ | 1-904-409-7040 [1:1/23] |
| / \ | |
| /|oo \ | |
| (_| /_) | |
| _`@/_ \ _ | |
| | | \ \\ | Editor: |
| | (*) | \ )) | Christopher Baker 1:18/14 |
| |__U__| / \// | |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: FidoNews Editor 1:1/23 |
+----------------------------------------------------------------------+
| MORE addresses: |
| |
| submissions=> cbaker84@digital.net |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies of FidoNews or the internet gateway FAQ |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
POLICY 5 - WILL IT EVER EXIST?
Table of Contents
1. EDITORIAL ................................................ 1
Censorship story a misunderstanding ...................... 1
2. LETTERS TO THE EDITOR .................................... 2
Fido commercials? ........................................ 2
3. COLUMNS .................................................. 3
Lock and Load: Guerilla Marketing for BBSes .............. 3
4. GETTING TECHNICAL ........................................ 6
FSC-0055 - Security Passwords in Nodelist updates ........ 6
FSC-0056 - EMSI/IEMSI Protocol Definitions ............... 7
5. COORDINATORS CORNER ...................................... 29
Nodelist-statistics as seen from Zone-2 for day 094 ...... 29
6. WE GET EMAIL ............................................. 30
Echomail problems in Region 35 ........................... 30
7. NET HUMOR ................................................ 31
Signs your Webmaster is in a cult ........................ 31
8. NOTICES .................................................. 34
Future History ........................................... 34
9. FIDONET SOFTWARE LISTING ................................. 35
Latest Greatest Software Versions ........................ 35
10. FIDONEWS PUBLIC-KEY ..................................... 40
FidoNews PGP public-key listing .......................... 40
11. FIDONET BY INTERNET ..................................... 41
12. FIDONEWS INFORMATION .................................... 43
FIDONEWS 14-14 Page 1 7 Apr 1997
=================================================================
EDITORIAL
=================================================================
A report last week that FidoNews had been censored by an unnamed ZC
turned out to be a difference of opinion on what constitutes a case
of censorship.
When I first started editing FidoNews, I added a FidoNews public-key
section to the newsletter for those who wanted to send things to the
FidoNews privately or clear-signed. ZC1, to whom I feed FidoNews for
worldwide distribution, suggested such an addition be removed due to
the possibility that such an addition might compromise laws in other
countries. I removed the key segment itself and replaced it with the
note about the removal pending a decision by the ZCC on its inclusion.
This was a voluntary act on my part in response to the request by ZC1.
After polling the ZCs, personally, via direct Netmail and receiving a
majority having no problem with the key segment being included in the
FidoNews, I returned the segment to each Issue without fanfare or
complaint.
While the segment was missing from the FidoNews it was available on
FidoNews webpage. I never considered it censorship of any kind. I may
have thought it overly sensitive but I understood the intent and
complied voluntarily. So, no blood, no foul. Case closed.
Speaking of the dreaded Internet, there are several additions to the
Regional listings in today's Issue. The R19 page has changed from the
inactive listing to the working one and R41 [Greece] has been added as
well our first listing in Zone 4 at Net 904 in Argentina. Normally,
Net level listings appear only on the FidoNews webpage but since Zone
4 has no listings at all, Net 904 is there to see if it can stimulate
some action in that area of FidoNet. [grin]
The only Regions missing in Zone 1 are Region 12 and Region 13. Does
anyone out there know if they have webpages? Please point them in
this direction. Thanks.
For those who hate the technical history section, you're really going
to dislike this one. It contains the EMSI standard proposal in toto.
History is good. There are less than 40 to go and all of them are a
lot smaller.
These things that repeat are here in each Issue because any one Issue
may be the only one a newbie sees that might bring them into the fold.
C.B.
-----------------------------------------------------------------
FIDONEWS 14-14 Page 2 7 Apr 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
From Pete Snidal, 1:354/910 - Grand Forks, BC Canada
Excellent ideas expressed in the last FNEWS over redundancy in
technobabble which most of us never read, and also in this great new
letters-to-ed idea.
I write in query to whether anyone else has noticed a disturbing
trend I've been watching going down on CBC (Canadian Broadcasting
System) TV from Montreal. (I get it on my sat dish, and consequently
get to watch CBC Montreal and Toronto as well as Vancouver, even
though I live out West.)
Since I live out west, all I've seen of this trend is a few
commercials on Montreal TV, but it looks like it could be sticky.
What I'm referring to is what appears to be a CelTel provider calling
itself, of all things, FIDO!
That's right! FIDO! The ads started late last summer, just little
shorties, saying nothing but stuff like: "FIDO IS COMING!" Now,
though, they're right into it, announcing how they provide a multitude
of _Communications_ services, of all things! CelTel, voicemail, ISP
perhaps, what's next - AOL-style bulletin board? Hey, that'd be nice!
A little confusing, perhaps, what with their coverage area - whatever
it is (Montreal? Quebec? Canada? North America?) - sure to have a
whole mess of existing FIDO bulletin boards already. (In fact, I
think I saw the word NET in there somewhere in the last FIDO ad or
two.)
So what's happening here? I thought there was a
copyright/trademark/whatever on the FIDO name. Apparently not; they
seem to have gotten past whomever you apply to for corporate monikers.
Do they even know about Fidonet? I don't imagine so. What are they
going to have to say when they discover this upstart network of
computer hobbyists using "their" name? They've obviously spent
too much money already and are too committed to the name to change
themselves.
How did this happen? Where's it going to lead? Has anyone else
noticed this? What the (*&(% is going on?
Sincerely,
Confused.
-----------------------------------------------------------------
FIDONEWS 14-14 Page 3 7 Apr 1997
=================================================================
COLUMNS
=================================================================
Lock and Load: Guerilla Marketing for BBSes
Robert Parson 1:3822/1
After mulling over the idea for several weeks, I have decided, for the
second time in my career, to write a column. I really should have
learned my lesson the first time.
At one time, Fidonet stood on the brink of being THE Network for
international computer based communications. Let's face it, that
opportunity has been lost because of the dynamic growth of the
Internet.
So what.
In my previous column, I wrote something along the lines of "BBSs will
become the convenience stores of electronic information. They'll be
useful for getting some quick information, but you'll have to go to
one of the commercial services if you need if you need to get
serious."
That comment was made about two years before the breakout of the
Internet, but I generally still hold to it, except you probably should
change "commercial services" to "the Internet." Be that as it may,
and I'm sure you agree with me, BBSs still provide a useful and vital
communications link.
There's no reason why BBSs should continue to do their work in
obscurity and be considered the shadowy side of electronic
information. To that end, I'm offering to help through this column.
With "Lock and Load," I hope to give you the ammunition you need to
raise public awareness of your BBS.
You cannot compete with AOL or even your local Internet Service
Provider. You don't have the money or the manpower. I'm going to
look at helping you market your BBS in your community using just a few
hours and less than 20 dollars a month (with a target of Zero dollars
a month!)
What makes me audacious enough to think I should write this column?
That's a fair enough question. First of all, I am a broadcast
journalist with nearly 20 years experience. Secondly, I wrote The
"BBS Guide to Public Relations" some years ago (by the way, it's still
available for download at Jackalope Junction BBS (1:3822/1), but is no
longer being actively supported. Among other things, I need to
completely overhaul the file. Perhaps I'll get to it one day).
Thirdly, I want to be of help.
Now the groundrules. I am going to deal only with Public Relations
and Public Image issues in this column. If you contact me in E-mail
or somehow track down my home phone, I will be happy to discuss
particular issues or problems at no cost. If you send me snail mail,
FIDONEWS 14-14 Page 4 7 Apr 1997
please include a self addressed stamped envelope if you expect a
response (Hint: I love getting BBS newsletters.). I'll print my
mailing address in this column occasionally. Any discussions or
correspondence could become fodder for this column. Unless
specifically requested, your name, BBS name, and node number could be
included in the article. I will NOT be writing this column weekly.
but it will be in every other issue of Fidonews. At least until I run
out of things to say. These groundrules are subject to change. But I
will let you know in advance.
Okay, now with all that out of the way, let's roll up our sleeves and
get to work.
Order some business cards. Nothing fancy. Just the name of your BBS,
your name and title (I suggest System Operator since the average Joe
on the street is not going to know what a Sysop is.), the number of
the BBS and your voice phone.
Sample Business Card:
_______________________________________
Newsbob BBS
Robert Parson
System Operator
XXX XXX XXXX Data Voice XXX XXX XXXX
________________________________________
You can probably get these pretty cheap at the printshop or you can
make your own using a desktop publisher. If you decide to make your
own, you can get blank card stock at just about any office supply
store.
While you're at it, get some letterhead. Order it at the same time
you order your business cards. Again, though, if you decide to make
your own letterhead, you can usually turn it into a template in your
desktop publisher or wordprocessor.
Your BBS may be "Just a hobby." But at the same time it's bit of a
profession. You should present a professional image in any dealings
with the "outside world," even if your BBS is primarily a gaming BBS.
Keep in mind "professional" doesn't mean "not fun."
Now I want you to get out your phone book and get the phone numbers of
the newsrooms for all the newspapers and television and radio
stations. Over the next couple weeks I want you to collect from
newspapers: the names of the Business Editor (if they have one) and
the Editor, the fax number to their newsroom, e-mail address and their
mailing address. From radio and tv stations: the names of the News
Director, Assignment Editor, and Public Service Director (if they have
them), the fax number, e-mail address and their mailing address.
FIDONEWS 14-14 Page 5 7 Apr 1997
In most cases, they will be happy to provide you with the information,
although they may want to know who you are and why you want it. Be
honest. Tell them your name and you would like to send them some
information soon.
In two weeks, we'll discuss what sort of information to send them.
Robert Parson
2501 Phoenix
Fort Smith, AR 72901
Fidonet: 1:3822/1
Net-Tamer V 1.09 Beta - Test Drive
-----------------------------------------------------------------
FIDONEWS 14-14 Page 6 7 Apr 1997
=================================================================
GETTING TECHNICAL
=================================================================
[These FTSC docs are published as part of the FidoNet History series.
They have been reformatted to 70 columns where required. Any tables
included may be askew. Node numbers phone numbers listed may no
longer be accurate.] Ed.
Document: FSC-0055
Version: 001
Revision: 31-Mar-1991
Security Passwords in Nodelist Update Files
Luke Kolin,
1:250/714@fidonet.org, 89:480/210@imex
March 31st, 1991
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is subject
to the restrictions listed below.
Fido and FidoNet are registered marks of Tom Jennings
and Fido Software.
The author grants the FTSC unlimited distribution and
reproduction rights in order to facilitate discussion
of the proposals in this document.
MakeNL is a program by Ben Baker.
SysNL is a program by Luke Kolin.
PURPOSE
This document is intended to explain the format and purpose of
security passwords within nodelist update files, and to inform the
authors of nodelist software about its proper usage.
THE NEED FOR PASSWORDS
Until now, the nodelist update files that *Cs create with
software packages such as MakeNL or SysNL have had no security
passwords inside of them. The only security between the NC and an RC
has been the name of the update file itself. For example, the name
of the Net 250 update file was "Metronet.250". It was quite
conceivable for a sysop, upon discovering this name, to make a
fraudulent update file, also called "MetroNet.250", and send this to
1:12/0. The nodelist processor which created the regional update
file at that end would not know that the file was not genuine, and
FIDONEWS 14-14 Page 7 7 Apr 1997
this would be added to the weekly update for the region.
PASSWORD FORMAT
It seems emminently logical that some sort of security
password should be added to nodelist update files, to prevent the
aforementioned problems from occurring. Therefore, I propose that
nodelist update files have an optional password in the first
(header) line, right after the ";A" general interest flag. The first
character of this case-sensitive password shall be an "at" sign @
(ASCII decimal 64 hex 40). If this character is present, then all
characters after it, until (but not including) the next space (ASCII
decimal 32 hex 20) will be considered part of the password. As well,
no password may be 8 characters or more in length. This is a sample
header line, with a password of ConSoft present:
;A @ConSoft Net 250 nodelist file for Friday, February 22nd : 10344
Please note the password starts right after the first space
(ASCII 32) with the ASCII 64 decimal character, and is case-
sensitive. The following is a sample header, without a password
present:
;A Net 250 nodelist file for Friday, March 1st : 13501
NOTES
It is extremely important that the password be on the first
line of the nodelist update file. It must commence immediately after
the first space (ASCII 32) character, with an ASCII 64 "at" sign.
Remember, it is case-sensitive.
I believe that it is up to the authors of individual nodelist
utilities to deal with the presence of passworded update files as
they believe fit. However, it is my belief that utilities, when
faced with a file with a bad password, retain a copy of a previous
(good) update file, which should be used instead of the bad one, to
prevent the equally nasty problem of a bad update file preventing an
entire network/region from being included.
Please note that I do not participate in either the FTSC or
NET_DEV conferences. I can be reached at 1:250/714@fidonet.org, or
in Imex at 89:480/210@imex.
-30-
-----------------------------------------------------------------
Document: FSC-0056
Version: 001
Date: 03-May-1991
EMSI/IEMSI Protocol Definitions
Joaquim H. Homrighausen
May 3, 1991
FIDONEWS 14-14 Page 8 7 Apr 1997
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r)
community, and requests discussion and suggestions for
improvements. Distribution of this document is subject to the
restrictions specified on the next page.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
(Also known as EMSC-001; Electronic Mail Standards Document
#001)
------------------------------------------------------------------
Copyright 1989-1991 Joaquim H. Homrighausen. All rights reserved.
------------------------------------------------------------------
Notice
==================================================================
This document obsoletes EMSI_003 and any previous document
describing the EMSI, UZAP, and/or IEMSI handshake protocol. I
apologize for the lack of proper state charts. I am currently
under a fairly heavy work-load and thought it would be better to
release something half-decent than not to release anything at all.
Restrictions
==================================================================
EMSI/IEMSI may be used by any developer as long as these
specifications are followed exactly. The IEMSI and EMSI
specifications may be implemented independently of each other.
EMSI/IEMSI may be used free-of-charge by any developer for any
purpose, commercially or otherwise. In creating EMSI/IEMSI, we are
taking the first step towards developing a clear protocol
definition for state-of-the-art E-Mail systems to follow.
This document and its NOTES file (EMSI.NOT) may be freely copied
and distributed, but must NEVER be distributed in a modified form.
If you have an enhancement request, please contact the author of
this document; do not change it yourself.
Permission is hereby granted to the FTSC (Fidonet Technical
Standards Committee) and other technical organisations to
republish this document in its entirety. Librarians may change the
title page and page headers to match their library format as long
as all copyrights and body text remain unaltered. The original
document name and source (EMSC) must be mentioned in any
republished versions of this document.
No organization, company, person, or other being may impose any
fees for any reason for providing this document. This document may
not be sold or otherwise transferred for personal or company gain
under any circumstances.
Layout
==================================================================
This document consists of four major parts; A short introduction
FIDONEWS 14-14 Page 9 7 Apr 1997
and explanation of the EMSI/IEMSI handshake protocol, the EMSI
definitions, the IEMSI definitions, and finally various notes and
credits.
PART I
Introduction
==================================================================
The EMSI/IEMSI handshake protocol allows for maximum flexibility
in E-Mail session start-up and control. The YooHoo (FTS-6)
standard, designed by Wynn Wagner III, was a good idea, but did
not allow sufficient room for growth and cannot be used in 7-bit
environments. EMSI/IEMSI should provide for virtually unlimited
growth and expansion of its own scope. By providing variable-
length packets, EMSI/IEMSI is capable of being as simple or as
complex as necessary and entirely backwards compatible when new
features and/or protocols are added.
All EMSI/IEMSI packets and sequences consists of 7-bit printable
ASCII characters. This format allows us to establish a universal
handshake between "PCs" and "mainframes" alike. The more
complicated the computer system, the more restrictions affect its
I/O; there are many I/O channels that cannot transmit control
characters such as XON and XOFF; for this, we have created a
universal handshake protocol that uses all printable characters.
EMSI/IEMSI does allow control and 8-bit ASCII characters to be
transmitted. This is, however, accomplished by escaping the data
and converting it to 7-bit printable ASCII characters.
Data layer
==================================================================
EMSI/IEMSI is a protocol based on multi-character sequences rather
than single character flow control. There are several advantages
of using several characters rather than just one, but there is
also a drawback. On very poor-quality telephone lines, EMSI will
most likely require several retransmissions of packets since line
noise usually come in bursts. That aside, there is little
advantage in using a protocol based on single characters.
All EMSI/IEMSI sequences are terminated by a single <CR> unless
otherwise specified. This is necessary to force some data
collection equipment to flush their buffers. Appending <CR> to
EMSI/IEMSI sequences in a FidoNet environment is a delicate matter
and it is important that you follow the notes regarding this.
Note regarding file requests
------------------------------------------------------------------
The file request concept mentioned in the EMSI document refers to
WaZOO style file requests as specified in FTS-6. No other file
request mechanism is supported in the EMSI specifications.
Separator usage
------------------------------------------------------------------
To designate the fields within the EMSI/IEMSI packets and retain
complete transparency, both start and stop characters are used.
FIDONEWS 14-14 Page 10 7 Apr 1997
The ASCII1 type is used for all fields within the packet. This
uses the brace characters to delimit the fields. The '{' (ASCII
123) character is the start byte and '}' (ASCII 125) is the stop
byte. If a stop byte is used as literal data within a field, it
must be transmitted twice. The end of a field is designated by a
stop byte that is not followed by another identical stop byte.
The ASCII2 fields are delimited in exactly the same way, but use
the square brackets as delimiters. The '[' (ASCII 91) is the start
byte and ']' (ASCII 93) is the stop byte. ASCII2 is used to
delimit data within the ASCII1 extra_field information.
7-bit data restriction
------------------------------------------------------------------
It is the developer's responsibility to ensure that the software
generates EMSI/IEMSI packets and sequences containing only 7-bit
(00H through 7eH) printable ASCII characters.
It is recommended that all EMSI/IEMSI implementations strip the
high-order bit of all received characters prior to processing the
packet/sequence and prior to calculating CRC values.
CRC values
------------------------------------------------------------------
The polynomial used to calculate a 16-bit CRC is the same
polynomial used in the Xmodem file transfer protocol. The
polynomial used to calculate a 32-bit CRC is the same polynomial
used in the Zmodem file transfer protocol.
Binary values
------------------------------------------------------------------
Since the EMSI environment specifies only 7-bit printable ASCII
characters to be used, binary values, such as CRC and length
descriptors are expressed as a four character hexadecimal string.
The only exception to this is a 32-bit CRC value which is
expressed as an eight character hexadecimal string.
The application must treat them case insensitive, eg. ffaa should
be treated identical to FFAA.
Handling 8-bit data
------------------------------------------------------------------
Although EMSI only uses 7-bit printable ASCII characters, there is
an escape mechanism that allows systems to transmit control and 8-
bit ASCII characters without the requirement of an 8-bit data
link. The escape character is a backslash character ('\') and is
followed by two characters in hexadecimal notation. Eg. "\80" is
the ASCII character 128. To insert an actual backslash character,
two backslashes are used ("\\"), or a backslash followed by the
hexadecimal code for a backslash, eg. "\5c".
The hexadecimal code following a backslash MUST always be two
characters, ie. to insert ASCII 15 (hexadecimail 'f'), the result
would be "0f". All hexadecimal sequences must be treated case
insensitively.
FIDONEWS 14-14 Page 11 7 Apr 1997
PART II - Electronic Mail Standard Idenfitication
Connecting two EMSI capable systems
==================================================================
This assumes that the two systems are connected and that no data
has been transmitted by the Caller.
It should be mentioned that sending/monitoring for the "YooHoo",
"TSYNC", and other protocol start characters is optional and not
required for a strict EMSI implementation.
STEP 1, EMSI INIT
Calling system Answering system +-+---------
----------------------+----------------------------------+
:1: Send <CR> until ANY character : Send EMSI_REQ and possible
:
: : is received. : banner, etc.
: +-+-------------------------------+-----------------------------
-----+
:2: Receive banner, etc. Monitor : Monitor line for the EMSI_INQ
:
: : line for the EMSI_REQ : sequence and if received,
:
: : sequence and if received, : attempt to handshake
immediately.:
: : transmit EMSI_INQ and attempt :
:
: : to handshake immediately. :
: +-+-------------------------------+-----------------------------
-----+
:3: No EMSI_REQ sequence received,: Monitor line for EMSI_INQ and
:
: : send EMSI_INQ twice followed : possible other protocol start
:
: : by possible other protocol : characters and if received,
:
: : start characters. : attempt to handshake
immediately.:
: : :
:
: : Transmit <CR> : Go to step 3.
: +-+-------------------------------+-----------------------------
-----+
:4: If EMSI_REQ sequence received,:
: : send EMSI_INQ and attempt to :
: : handshake immediately, :
: : otherwise repeat step 3. :
+-+-------------------------------+
In steps 1 and 2, both the Calling and Answering system terminate
all sequences with <CR>. In step 3, the Calling system does not
terminate sequences with <CR> as it is explicitly transmitted
after possible protocol start characters. In step 4, the Calling
system once again terminate all sequences with a <CR>.
FIDONEWS 14-14 Page 12 7 Apr 1997
STEP 2A, RECEIVE EMSI HANDSHAKE
At this point, all sequences are terminated with a <CR>.
+-+---------------------------------------------------------------
---+
:1: Tries=0, T1=20 seconds, T2=60 seconds
: +-+-------------------------------------------------------------
-----+
:2: Increment Tries
:
: :
:
: : Tries>6? Terminate, and report failure.
:
: +---------------------------------------------------------------
---+
: : Are we answering system? Transmit EMSI_REQ, go to step 3.
:
: +---------------------------------------------------------------
---+
: : Tries>1? Transmit EMSI_NAK, go to step 3.
:
: +---------------------------------------------------------------
---+
: : Go to step 4.
: +-+-------------------------------------------------------------
-----+
:3: T1=20 seconds
: +-+-------------------------------------------------------------
-----+
:4: Wait for EMSI sequence until EMSI_HBT or EMSI_DAT or any of
the :
: : timers have expired.
:
: :
:
: : If T2 has expired, terminate call and report failure.
:
: +---------------------------------------------------------------
---+
: : If T1 has expired, go to step 2.
:
: +---------------------------------------------------------------
---+
: : If EMSI_HBT received, go to step 3.
:
: +---------------------------------------------------------------
---+
: : If EMSI_DAT received, go to step 5.
:
: +---------------------------------------------------------------
---+
: : Go to step 4.
: +-+-------------------------------------------------------------
-----+
FIDONEWS 14-14 Page 13 7 Apr 1997
:5: Receive EMSI_DAT packet
:
: +---------------------------------------------------------------
---+
: : Packet received OK? Transmit EMSI_ACK twice,
and :
: : go to step 6.
:
: +---------------------------------------------------------------
---+
: : Go to step 2.
: +-+-------------------------------------------------------------
-----+
:6: Received EMSI_DAT packet OK, exit.
: +-+-------------------------------------------------------------
-----+
All processing of the information in the EMSI_DAT packet must be
done after transmitting EMSI_ACK twice to the remote system. It is
recommended that an EMSI_HBT sequence is issued once every seven
seconds while such processing is taking place to avoid unnecessary
handshake collissions. Emitting EMSI_HBT should only be done when
it is obvious that the remote system is waiting for the second
phase of the EMSI handshake to take place.
STEP 2B, TRANSMIT EMSI HANDSHAKE
At this point, all sequences are terminated with a <CR>.
+-+---------------------------------------------------------------
---+
:1: Tries=0, T1=60 seconds
: +-+-------------------------------------------------------------
-----+
:2: Transmit EMSI_DAT packet and increment Tries
:
: :
:
: +---------------------------------------------------------------
---+
: : Tries>6? Terminate, and report failure.
:
: +---------------------------------------------------------------
---+
: : Go to step 3.
: +-+-------------------------------------------------------------
-----+
:3: T2=20 seconds
: +-+-------------------------------------------------------------
-----+
:4: Wait for EMSI sequence until T1 has expired
:
: :
:
: : If T1 has expired, terminate call and report failure.
:
FIDONEWS 14-14 Page 14 7 Apr 1997
: +---------------------------------------------------------------
---+
: : If T2 has expired, go to step 2.
:
: +---------------------------------------------------------------
---+
: : If EMSI_REQ received, go to step 4.
:
: +---------------------------------------------------------------
---+
: : If EMSI_ACK received, go to step 5.
:
: +---------------------------------------------------------------
---+
: : If any other sequence received, go to step 2.
: : +-+-----------------------------------------------
-------------------+
:5: Received EMSI_ACK, exit.
: +-+-------------------------------------------------------------
-----+
EMSI packet and sequence definitions
==================================================================
=====================================================================
EMSI Inquiry
**EMSI_INQ<crc16><CR>
------------------------------------------------------------------
EMSI Inquiry is transmitted by the calling system to identify it
as EMSI capable. If an EMSI_REQ sequence is received in response,
it is safe to assume the answering system to be EMSI capable.
=====================================================================
EMSI Request
**EMSI_REQ<crc16><CR>
------------------------------------------------------------------
EMSI Request is transmitted by the answering system in response to
an EMSI Inquiry sequence. It should also be transmitted prior to
or immediately following the answering system has identified
itself by transmitting its program name and/or banner. If the
calling system receives an EMSI Request sequence, it can safely
assume that the answering system is EMSI capable.
=====================================================================
EMSI Client
**EMSI_CLI<crc16><CR>
------------------------------------------------------------------
EMSI Client is used by terminal emulation software to force a
mailer front-end to bypass any unnecessary mail session
negotiation and treat the call as an incoming human caller. The
EMSI_CLI sequence may not be issued by any software attempting to
establish a mail session between two systems and must only be
acted upon by an answering system.
=====================================================================
FIDONEWS 14-14 Page 15 7 Apr 1997
EMSI Heartbeat
**EMSI_HBT<crc16><CR>
------------------------------------------------------------------
EMSI Heartbeat is used to prevent unnecessary timeouts from
occurring while attempting to handshake. It is most commonly used
when the answering system turns around to transmit its EMSI_DAT
packet. It is quite normal that any of the timers of the calling
system (which at this stage is waiting for an EMSI_DAT packet)
expires while the answering system is processing the recently
received EMSI_DAT packet.
=====================================================================
EMSI Data
**EMSI_DAT<len16><data_pkt><crc16><CR>
------------------------------------------------------------------
EMSI Data is transmitted by both the calling and answering system
at the appropriate time to exchange system information. Following
the header is a four byte number representing the length of
<data_pkt> excluding the CRC and terminating <CR>.
The EMSI_DAT packet is a variable length packet. Since this is a
synchronous protocol, the inbound data buffer should be purged
between transmission of the <data_pkt> and <crc16> fields to
prevent accidental EMSI_NAK sequences, etc.
=====================================================================
EMSI ACK
**EMSI_ACK<crc16><CR>
------------------------------------------------------------------
EMSI ACK is transmitted by either system as a positive
acknowledgement of the valid receipt of a EMSI_DAT packet. This
should only be used as a response to EMSI_DAT and not any other
packet. Redundant EMSI_ACK sequences should be ignored.
=====================================================================
EMSI NAK
**EMSI_NAK<crc16><CR>
------------------------------------------------------------------
EMSI NAK is transmitted by either system as a negative
acknowledgement of the valid receipt of a EMSI_DAT packet. This
should only be used as a response to EMSI_DAT and not any other
packet. Redundant EMSI_NAK packets should be ignored.
The EMSI_DAT packet
==================================================================
The EMSI_DAT packet is the core of an EMSI negotiated session. It
contains information vital to the mail session. The following
pseudo structure shows the layout of the EMSI_DAT packet.
EMSI_DAT
fingerprint, "EMSI"
system_address_list,
password,
link_codes,
compatibility_codes,
mailer_product_code,
FIDONEWS 14-14 Page 16 7 Apr 1997
mailer_name,
mailer_version,
mailer_serial_number: ASCII1;
extra_field_1,
..
..
extra_field_n: EMSI_addon; (optional fields)
end;
The EMSI_addon structure is defined as follows:
EMSI_addon
product_ID,
specific_data: ASCII1;
end;
Following is an example of the actual data transmitted as an
EMSI_DAT packet:
{EMSI}{2:270/17}{}{8N1,PUA}{ZAP,ZMO,ARC,XMA}{44}{AirMail}{0.10}
{Beta-2}{IDENT}{[Advanced Engineering S.A.R.L.][Luxembourg]
[Joaquim Homrighausen][-Unpublished-][9600][MO,XA,HST,V32B,V42B]}
EMSI_DAT field definitions
------------------------------------------------------------------
=====================================================================
Fingerprint
EMSI
------------------------------------------------------------------
The constant "EMSI". There is no need for a revision level since
this basic format cannot change and remain backward compatible.
=====================================================================
System address list
------------------------------------------------------------------
The system address list is a list of system-specific identifiers
for the E-Mail system separated by spaces.
For FidoNet-technology based networks, it is required that
Zone:Net/Node be presented, and .Point be omitted if zero. Zone
and Net must not be zero.
In other networks, an address such as "jhom@csource.oz.au" should
be considered valid.
=====================================================================
Password
------------------------------------------------------------------
For systems using a session level password, it would be passed in
this field. Note that the same password is used for all presented
addresses and that it must be treated case insensitive.
=====================================================================
Link codes
------------------------------------------------------------------
FIDONEWS 14-14 Page 17 7 Apr 1997
Link codes is a string of flags that specify desired connect
conditions. These codes are separated by commas. New codes may be
added with prior approval from the author of this document.
Calling system/answering system options:
8N1,
7E1,
7O2,
etc. Communication parameters.
Calling system options:
PUA Pickup mail for all presented addresses.
PUP Pickup mail for primary address only.
NPU No mail pickup desired.
Answering system options:
HAT Hold ALL traffic.
HXT Hold compressed mail traffic.
HRQ Hold file requests (not processed at this time).
=====================================================================
Compatibility codes
------------------------------------------------------------------
Compatibility codes is a string of flags that specifies the
capabilities and enabled features of the mailer. These codes are
separated by commas. New codes may be added with prior approval
from the author of this document.
The calling system must list supported protocols first and
descending order of preference (the most desirable protocol should
be listed first). The answering system should only present one
protocol and it should be the first item in the
compatibility_codes field.
Protocols
--------------------------------------------------------------
DZA* DirectZAP (Zmodem variant).
ZAP ZedZap (Zmodem variant).
ZMO** Zmodem w/1,024 byte data packets.
JAN Janus.
KER Kermit.
Other codes
--------------------------------------------------------------
NCP No compatible protocols (failure).
NRQ No file requests accepted by this system.
ARC ARCmail 0.60-capable, as defined by the FTSC.
XMA Supports other forms of compressed mail.
FNC Filename conversion. This indicates that any
transmitted files must follow the MS-DOS restrictions
of an eight character file name followed by a three
FIDONEWS 14-14 Page 18 7 Apr 1997
character extension; eg. FILENAME.EXT
(*) DirectZAP is a variant of ZedZap. The difference is that the
transmitter only escapes CAN (18H). It is not recommended to use
the DirectZAP protocol when two systems are connected via a packet
switching network, or via another layer sensitive to control
characters such as XON and XOFF.
(**) The minimum protocol requirement for an EMSI implementation
is to support plain Zmodem (16- or 32-bit CRC, 1,024 byte packets)
which is represented by the ZMO flag in EMSI.
=====================================================================
Mailer product code
------------------------------------------------------------------
The hexadecimal representation of the EMSC product code assigned
to the mailer. Currently, the EMSC codes are the same as the FTSC
assigned codes.
=====================================================================
Mailer name
------------------------------------------------------------------
Specifies the name of the E-Mail system sending the EMSI packet.
=====================================================================
Mailer version
------------------------------------------------------------------
The version number of the mailer software, ie. "1.10", "2.00".
=====================================================================
Mailer serial number
------------------------------------------------------------------
The serial number, distribution source, version information, etc.
This field is usually displayed like:
Name<sp>Version/Serial_number
eg.
AirMail 0.10/Beta-2
=====================================================================
Extra fields
------------------------------------------------------------------
The extra fields make the EMSI handshake protocol extremely
flexible. Any program or mailer may add fields to the end of the
pre-defined structure so that program-specific data may be passed
without the concern of interferring with other systems.
There may be any number of extra fields added to the end of this
structure. Each EXTRA_FIELD contains two ASCII1 strings:
PRODUCT_IDENTIFIER A unique "tag" that defines a specific
program (such as a mailer or a utility).
SPECIFIC_DATA ASCII text that is specific data to the
FIDONEWS 14-14 Page 19 7 Apr 1997
program defined in PRODUCT_IDENTIFIER.
With this structure, any program can add
its own data to the EMSI packet without
affecting other applications.
It is recommended that you contact the author of this document
should you have any EXTRA_FIELDS that you may think worthwhile for
other developers to implement and support.
Predefined extra fields
------------------------------------------------------------------
The following extra fields have been defined to date.
PRODUCT_IDENTIFIER : IDENT
Purpose : General identification of system that
includes all information to generate a St.
Louis-format nodelist entry.
SPECIFIC_DATA : system_name,
city,
operator_name,
phone_number,
baud_rate,
flags: ASCII2;
SYSTEM_NAME The name of the system given by the user.
This would normally be a company name, BBS
name or other identifying text.
CITY The geographical location of the system.
OPERATOR_NAME The name of the person primarily
responsible for the system.
PHONE_NUMBER The telephone number of the system, or
"-Unpublished-" if the telephone number is
unpublished. This MUST be in the standard
format COUNTRY-CITY-NUMBER. Leading zeros
should be stripped from the city code,
ie. Stockholm (Sweden) has a city code of
08, included in an EMSI packet, it would
read 46-8-<number>.
BAUD_RATE The maximum baud rate supported by the
system. This is NOT necessarily the same
as the highest DTE rate.
FLAGS The St. Louis (FTSC) nodelist flags
associated with the system.
PART III - Interactive Electronic Mail Standard Idenfitication
Connecting two IEMSI capable systems
==================================================================
FIDONEWS 14-14 Page 20 7 Apr 1997
Two specific labels are used when discussing the IEMSI
definitions. The Client, which in this case is the Terminal
software, and the Server, which in this case is the interactive
on-line software, such as a BBS package or database system. It is
assumed that the Client and the Server have established a data
link and that no data has been transmitted by the Server.
STEP 1, IEMSI INIT
There is no specific sequence of events in the IEMSI definition.
The Client must monitor incoming data and if the EMSI_IRQ sequence
is detected, it attempts to negotiate an IEMSI session with the
Server. Under no circumstances is the Client allowed to transmit
an EMSI_ICI packet prior to receiving the EMSI_IRQ sequence from
the Server. All IEMSI sequences and EMSI sequences used during an
IEMSI session are terminated by a single <CR>. There are no
exceptions to this.
STEP 2A, Server
+-+---------------------------------------------------------------
---+
:1: Tries=0, T2=60 seconds
: +-+-------------------------------------------------------------
-----+
:2: Transmit EMSI_IRQ sequence
: +-+-------------------------------------------------------------
-----+
:3: T1=20 seconds, increment Tries
:
: :
:
: : Tries>3? Discontinue IEMSI negotiation.
: +-+-------------------------------------------------------------
-----+
:4: Wait for EMSI_ICI packet until any of the timers have expired.
:
: :
:
: : If T2 has expired, discontinue IEMSI negotiation.
:
: +---------------------------------------------------------------
---+
: : If T1 has expired, go to step 2.
:
: +---------------------------------------------------------------
---+
: : If EMSI_ICI seen, go to step 5.
:
: +---------------------------------------------------------------
---+
: : Go to step 4.
: +-+-------------------------------------------------------------
-----+
:5: Receive EMSI_ICI packet
:
FIDONEWS 14-14 Page 21 7 Apr 1997
: +---------------------------------------------------------------
---+
: : Packet received OK? Transmit EMSI_ISI packet, and
:
: : go to step 6.
:
: +---------------------------------------------------------------
---+
: : Packet not received OK? Transmit EMSI_NAK and go to
step :
: : 3.
: +-+-------------------------------------------------------------
-----+
:6: Tries=0
: +-+-------------------------------------------------------------
-----+
:7: T1=20 seconds, increment Tries
:
: :
:
: : Tries>3? Discontinue IEMSI negotiation.
: +-+-------------------------------------------------------------
-----+
:8: Wait for EMSI_ACK/EMSI_NAK until any of the timers have
expired. :
: :
:
: : If T2 has expired, discontinue IEMSI negotiation.
:
: +---------------------------------------------------------------
---+
: : If T1 has expired or EMSI_NAK received, transmit EMSI_ISI
packet :
: : again and go to step 7.
:
: +---------------------------------------------------------------
---+
: : If EMSI_ACK received, go to step 9.
:
: +---------------------------------------------------------------
---+
: : Go to step 8.
: +-+-------------------------------------------------------------
-----+
:9: IEMSI session successfully established, exit.
: +-+-------------------------------------------------------------
-----+
The Server must monitor its incoming data channel for 'normal'
data, ie. data not transmitted as IEMSI sequences, to detect if
the user is attempting to log-in without the use of IEMSI. The
only basic restriction this imposes on the Server is that user
names and/or IDs may not start with the character '*' since all
EMSI/IEMSI sequences start with this character.
All processing of the information in the EMSI_ICI packet must be
FIDONEWS 14-14 Page 22 7 Apr 1997
done after transmitting the EMSI_ISI packet and receiving two
EMSI_ACK sequences in return.
STEP 2B, Client
Note that this assumes that the Client has seen the EMSI_IRQ
sequence transmitted by the Server and that the negotiation is
ready to take place.
+-+---------------------------------------------------------------
---+
:1: Tries=0, T2=60 seconds
: +-+-------------------------------------------------------------
-----+
:2: Transmit EMSI_ICI packet
: +-+-------------------------------------------------------------
-----+
:3: T1=20 seconds, increment Tries
: +-+-------------------------------------------------------------
-----+
:5: Tries>3 or T2 expired? Discontinue IEMSI
negotiation. :
: +---------------------------------------------------------------
---+
: : If T1 has expired, go to step 2.
:
: +---------------------------------------------------------------
---+
: : If EMSI_ISI seen, go to step 6.
:
: +---------------------------------------------------------------
---+
: : Go to step 5.
: +-+-------------------------------------------------------------
-----+
:6: Receive EMSI_ISI packet
:
: +---------------------------------------------------------------
---+
: : Packet received OK? Transmit EMSI_ACK packet
twice, :
: : and go to step 7.
:
: +---------------------------------------------------------------
---+
: : Packet not received OK? Transmit EMSI_NAK and go to
step:
: : 3.
: +-+-------------------------------------------------------------
-----+
:7: IEMSI session successfully established, exit.
: +-+-------------------------------------------------------------
-----+
All processing of the information in the EMSI_ISI packet must be
done after transmitting two EMSI_ACK sequences in return.
FIDONEWS 14-14 Page 23 7 Apr 1997
If either of the ICI or ISI packets are NAK'd three consecutive
times, the session negotiation attempt is terminated and the
Client proceeds as it would have done should the Server not have
supported IEMSI.
IEMSI packet and sequence definitions
==================================================================
=====================================================================
EMSI ACK
**EMSI_ACK<crc16><CR>
------------------------------------------------------------------
EMSI ACK is transmitted by either Client or Server as a positive
acknowledgement of the valid receipt of an IEMSI packet such as
EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
however, be used as a positive acknowledgement for other IEMSI
packets. Redundant EMSI_ACK sequences should be ignored.
=====================================================================
EMSI NAK
**EMSI_NAK<crc16><CR>
------------------------------------------------------------------
EMSI NAK is transmitted by either Client or Server as a negative
acknowledgement of the valid receipt of an IEMSI packet such as
EMSI_ISI and EMSI_ICI. During an IEMSI session, this sequence can,
however, be used as a negative acknowledgement for other IEMSI
packets. Redundant EMSI_NAK sequences should be ignored.
=====================================================================
EMSI IRQ
**EMSI_IRQ<crc16><CR>
------------------------------------------------------------------
Similar to EMSI_REQ which is used by mailer software to negotiate
a mail session. IRQ identifies the Server as being capable of
negotiating an IEMSI session. When the Client detects an IRQ
sequence in its inbound data stream, it attempts to negotiate an
IEMSI session.
=====================================================================
EMSI IIR
**EMSI_IIR<crc16><CR>
------------------------------------------------------------------
The IIR (Interactive Interrupt Request) sequence is used by either
Client or Server to abort the current negotiation. This could be
during the initial IEMSI handshake or during other interactions
between the Client and the Server.
=====================================================================
EMSI ICI
**EMSI_ICI<len><data><crc32><CR>
------------------------------------------------------------------
The ICI packet is used by the Client to transmit its configuration
and Server-related information to the Server. It contains Server
parameters, Client options, and Client capabilities.
=====================================================================
FIDONEWS 14-14 Page 24 7 Apr 1997
EMSI ISI
**EMSI_ISI<len><data><crc32><CR>
------------------------------------------------------------------
The ISI packet is used by the Server to transmit its configuration
and Client-related information to the Client. It contains Server
data and capabilities.
=====================================================================
EMSI ISM
**EMSI_ISM<len><data><crc32><CR>
------------------------------------------------------------------
The ISM packet is used to transfer ASCII images from the Server to
the Client. These images can then be recalled by the Client when
the Server needs to display a previously displayed image. This
will be further described in future revisions of this document.
=====================================================================
EMSI CHT
**EMSI_CHT<crc16><CR>
------------------------------------------------------------------
The CHT sequence is used by the Server to instruct the Client
software to enter its full-screen conversation mode function
(CHAT). Whether or not the Client software supports this is
indicated in the ICI packet.
If the Server transmits this sequence to the Client, it must wait
for an EMSI_ACK prior to engaging its conversation mode. If no
EMSI_ACK sequence is received with ten seconds, it is safe to
assume that the Client does not support EMSI_CHT. If, however, an
EMSI_NAK sequence is received from the Client, the Server must re-
transmit the EMSI_CHT sequence. Once the on-line conversation
function has been sucessfully activated, the Server must not echo
any received characters back to the Client.
=====================================================================
EMSI TCH
**EMSI_TCH<crc16><CR>
------------------------------------------------------------------
The TCH sequence is used by the Server to instruct the Client
software to terminate its full-screen conversation mode function
(CHAT).
If the Server transmits this sequence to the Client, it must wait
for an EMSI_ACK prior to leaving its conversation mode. If no
EMSI_ACK sequence is received with ten seconds, a second EMSI_TCH
sequence should be issued before the Server resumes operation. If,
however, an EMSI_NAK sequence is received from the Client, the
Server must re-transmit the EMSI_TCH sequence.
The EMSI_ICI packet
==================================================================
The following pseudo structure shows the layout of the EMSI_ICI
packet. Note that the information in the EMSI_ICI packet may not
exceed 2,048 bytes.
EMSI_ICI
FIDONEWS 14-14 Page 25 7 Apr 1997
name,
alias,
location,
data#,
voice#,
password,
birthdate,
crtdef,
protocols,
capabilities,
requests,
software,
xlattabl: ASCII1;
end;
EMSI_ICI field definitions
------------------------------------------------------------------
=====================================================================
Name and Alias (or Handle)
------------------------------------------------------------------
The name and possible alias (AKA) of the user (Client). This must
be treated case insensitively by the Server.
=====================================================================
Location
------------------------------------------------------------------
The geographical location of the user, ie. Stockholm, Sweden.
=====================================================================
data# and voice#
------------------------------------------------------------------
Unformatted data and voice telephone numbers of the user.
Unformatted is defined as the full telephone number, including
country and local area code. Eg. 46-8-90510 is a telephone number
in Stockholm, Sweden.
=====================================================================
Password
------------------------------------------------------------------
The password for the user. This must be treated case insensitively
by the Server.
=====================================================================
Birthdate
------------------------------------------------------------------
Hexadecimal string representing a long integer containing the
birthdate of the user in UNIX notation (number of seconds since
midnight, Jan 1 1970). This must be treated case insensitively by
the Server.
=====================================================================
CrtDef
------------------------------------------------------------------
Consisting of four sub-fields separated by commas, this field
contains from left to right: The requested terminal emulation
FIDONEWS 14-14 Page 26 7 Apr 1997
protocol, the number of rows of the user's CRT, the number of
columns of the user's CRT, and the number of ASCII NUL (00H)
characters the user's software requires to be transmitted between
each line of text.
The following terminal emulation protocols are defined:
AVT0 AVATAR/0+. Used in conjunction with ANSI. If AVT0 is
specified by the Client, support for ANSI X3.64
emulation should be assumed to be present.
ANSI ANSI X3.64
VT52 DEC VT52
VT100 DEC VT100
TTY No terminal emulation, also referred to as RAW mode.
=====================================================================
Protocols
------------------------------------------------------------------
The file transfer protocol option specifies the preferred method
of transferring files between the Client and the Server in either
direction. The Client presents all transfer protocols it is
capable of supporting and the Server chooses the most appropriate
protocol.
DZA* DirectZAP (Zmodem variant)
ZAP ZedZap (Zmodem variant)
ZMO Zmodem w/1,024 byte data packets
SLK SEAlink
KER Kermit
(*) DirectZAP is a variant of ZedZap. The difference is that the
transmitter only escapes CAN (18H). It is not recommended to use
the DirectZAP protocol when the Client and the Server are
connected via a packet switching network, or via another layer
sensitive to control characters such as XON and XOFF.
=====================================================================
Capabilities
------------------------------------------------------------------
The capabilities of the user's software. If more than one
capability is listed, each capability is separated by a comma.
The following capability codes are defined:
CHT Can do full-screen on-line conversation (CHAT).
MNU Can do ASCII image download (see ISM packet).
TAB Can handle TAB (ASCII 09H) characters.
ASCII8 Can handle 8-bit IBM PC ASCII characters.
=====================================================================
Requests
------------------------------------------------------------------
The requests field specifies what the user wishes to do once the
initial IEMSI negotiation has been successfully completed. If more
than one capability is listed, each capability is separated by a
comma.
FIDONEWS 14-14 Page 27 7 Apr 1997
The following request codes are defined:
NEWS Show bulletins, announcements, etc.
MAIL Check for new mail.
FILE Check for new files.
HOT Hot-Keys.
CLR Screen clearing.
HUSH Do not disturb.
MORE Page pausing, often referred to as "More".
FSED* Full-screen editor.
XPRS <reserved>.
(*) Note that this allows the Client to request use of a full-
screen editor without requiring that it also supports a full-
screen terminal emulation protocol.
=====================================================================
Software
------------------------------------------------------------------
The name, version number, and optionally the serial number of the
user's software. Eg. {FrontDoor,2.00,AE000001}.
=====================================================================
XlatTabl
------------------------------------------------------------------
Used for character translation between the Server and the Client.
This field has not been completely defined yet and should always
be transmitted as {} (empty).
The EMSI_ISI packet
==================================================================
The following pseudo structure shows the layout of the EMSI_ISI
packet. Note that the information in the EMSI_ISI packet may not
exceed 2,048 bytes.
EMSI_ISI
id,
name,
location,
operator,
localtime,
notice,
wait,
capabilities: ASCII1;
end;
EMSI_ISI field definitions
------------------------------------------------------------------
=====================================================================
ID
------------------------------------------------------------------
The name, version number, and optionally the serial number of the
Server software. Eg. {RemoteAccess,1.10/b5,CS000001}.
=====================================================================
FIDONEWS 14-14 Page 28 7 Apr 1997
Name
------------------------------------------------------------------
The name of the Server system. Eg. {Advanced Engineering
S.A.R.L.}.
=====================================================================
Location
------------------------------------------------------------------
The geographical location of the user, ie. Stockholm, Sweden.
=====================================================================
Operator
------------------------------------------------------------------
The name of the primary operator of the Server software. Eg.
{Joaquim H. Homrighausen}.
=====================================================================
Localtime
------------------------------------------------------------------
Hexadecimal string representing a long integer containing the
current time of the Server in UNIX notation (number of seconds
since midnight, Jan 1 1970). This must be treated case
insensitively by the Client.
=====================================================================
Notice
------------------------------------------------------------------
May contain copyright notices, system information, etc. This field
may optionally be displayed by the Client.
=====================================================================
Wait
------------------------------------------------------------------
A single character used by the Server to indicate that the user
has to press the <Enter> key to resume operation. This is used in
conjunction with ASCII Image Downloads (see ISM packet).
=====================================================================
Capabilities
------------------------------------------------------------------
The capabilities of the Server software. No Server software
capabilities have currently been defined.
Credits and other notes
==================================================================
The original EMSI specifications were designed by Chris Irwin and
Joaquim H. Homrighausen. The original IEMSI specifications were
designed by Joaquim H. Homrighausen and Andrew Milner.
--- end of "emsi.doc" ---
-30-
-----------------------------------------------------------------
FIDONEWS 14-14 Page 29 7 Apr 1997
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 094
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-066|Nodelist-073|Nodelist-080|Nodelist-087|Nodelist-094|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 9405| 9107 -298 | 9088 -19 | 9088 0 | 8900 -188 |33|
| 2 | 16083|15996 -87 |15956 -40 |15923 -33 |15922 -1 |58|
| 3 | 800| 800 0 | 800 0 | 800 0 | 800 0 | 3|
| 4 | 545| 547 2 | 548 1 | 548 0 | 549 1 | 2|
| 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0|
| 6 | 1088| 1088 0 | 1088 0 | 1090 2 | 1090 0 | 4|
+----+------+------------+------------+------------+------------+--+
| 28008|27625 -383 |27567 -58 |27536 -31 |27348 -188 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 14-14 Page 30 7 Apr 1997
=================================================================
WE GET EMAIL
=================================================================
Hi,
We have a problem at Region 35 and I hope you'll be so kind to
mention something about it, and whether anyone can help.
The problem is that we lost the connection to the
international echo areas due to some problems facing the one who was
taking the responsibility of routing these echomail areas. Now we have
a node routing netmail and 1 of the echos, but we still have a problem
with all other ones. Kiril Yugoslavov (2:356/200) is ready to get
these echos by FTP, but we're searching for FTP-echo feeds.
We'll be grateful if you can help (either directly or by
posting the above in the coming issues of FIDONEWS). You can send
information, either to me at zombie@inet.bg or directly to Kiril
Yugoslavov at 2:350/200 (I don't know his e-mail, but I will ask if
needed).
Thanks for your attention and time.
Best wishes
Moh
-----------------------------------------------------------------
FIDONEWS 14-14 Page 31 7 Apr 1997
=================================================================
NET HUMOR
=================================================================
To: cbaker84@digital.net
From: top5@lists.zdnet.com
Subject: Top5 - 3/31/97 - Signs Your Webmaster is in a Cult
Errors-To: top5-errors@lists.zdnet.com
Date: Mon, 31 Mar 1997 20:18:18 MST
================================================================
T H E T O P F I V E L I S T
================================================================
Sponsored by Windows Sources
Windows Sources Expert Answers for MS Office:
Your MS Office 95 and 97 questions answered
instantaneously by M. David Stone.
http://www.winsources.com
================================================================
To forward or repost, please include the following:
[ This list copyright 1997 by Chris White and Ziff Davis, Inc. ]
[ The Top Five List top5@walrus.com http://www.topfive.com ]
The Top Five List for March 31, 1997
The Top 15 Signs Your Webmaster is in a Cult
15> Every link seems to take you to www.amway.com.
14> Repetition of same banner ads: Stoli, Mott's...
Stoli, Mott's...
13> He brings twenty-three wives to the office Holiday Party.
12> Instead of counting up visitors, your site counts down days
to the apocalypse.
11> Suddenly your travel agency's site is featuring inter-planetary
excursions for comet watching and one-way tickets to Guyana.
10> His home page says "Best viewed from the Mothership."
9> Your website's "Hall of Fame" inductees required to do
stint handing out flowers at airport.
8> Your website is honored as the David Koresh Fan Club's
"Site of the Day."
7> She has 38 roommates, yet is oddly stress-free.
6> Insists that Sabbath actually begins when "X-files" ends.
FIDONEWS 14-14 Page 32 7 Apr 1997
5> Frequently mutters about the "Prophet Steve Jobs" returning
to rescue the true believers.
4> Not only does he understand Unix, he *IS* one.
3> Big "N" on your browser replaced by spinning head of
Charles Manson.
2> He only answers to the name, "Doe-bert."
and the Number 1 Sign Your Webmaster is in a Cult...
1> Ugly clothes; insufficient diet; lack of sleep; goofy haircut;
lives in a mansion; has many followe... Hey, wait a minute!
That's Bill Gates!!
Selected from 93 submissions from 33 contributors.
Today's Top Five List authors are:
----------------------------------------------------------------
Marc Cukier, Toronto, Canada -- 1 (1st #1!)
Bruce Ansley, Baltimore, MD -- 2 (Hall of Famer)
David Bryant, Columbia, MD -- 3
Lloyd Jacobson, Washington, DC -- 4
Duncan Carling, San Francisco, CA -- 5, 13
Natasha Filipovic, New York, NY -- 6
Paul Schindler, Orinda, CA -- 7
Tony Hill, Minneapolis, MN -- 8, 9 (Hall of Famer)
Bob Mader, Knoxville TN -- 9
Bill Muse, Seattle, WA -- 10
Steve Hurd, San Ramon, CA -- 11
Marianne Tatom, Austin, TX -- 12
Natasha Filipovic, New York, NY -- 14
Dave Wesley, Pleasant Hill, CA -- 14
Barbara Rush, Tulsa, OK -- 15
Eric Huret, Atlanta, GA -- 15
Chris White, New York, NY -- List owner/editor
----------------------------------------------------------------
Today's Runners Up list, "Scientologists",
can be found at our website: http://www.topfive.com
================================================================
T H E T O P F I V E L I S T
To subscribe: Send mail to top5-on@lists.zdnet.com
To unsubscribe: Send mail to top5-off@lists.zdnet.com
For more information: Send mail to top5@walrus.com
with "INFO" in the *subject* line of the message.
To report a sighting of a Top Five List in other media:
Send mail to top5@walrus.com with "BINGO!" in the *subject*.
================================================================
Ruminations & Ponderances
I was jogging in the park when this COMPLETELY
naked man ran right past me. I thought to myself,
FIDONEWS 14-14 Page 33 7 Apr 1997
"I wonder if I'd run faster barefoot, too?"
(Thanks to Anna Chin-Williams)
================================================================
Sponsored by Windows Sources http://www.winsources.com
This delivery powered by Mercury Mail, Inc. http://www.merc.com
================================================================
-----------------------------------------------------------------
FIDONEWS 14-14 Page 34 7 Apr 1997
=================================================================
NOTICES
=================================================================
Future History
17 May 1997
Independence Day, Norway.
6 Jun 1997
National Commemoration Day, Sweden.
11 Jun 1997
Independence Day, Russia.
1 Jul 1997
Canada Day - Happy Birthday Canada.
9 Jul 1997
Independence Day, Argentina.
13 Oct 1997
Thanksgiving Day, Canada.
1 Dec 1997
World AIDS Day.
10 Dec 1997
Nobel Day, Sweden.
12 Jan 1998
HAL 9000 is one year old today.
22 May 1998
Expo '98 World Exposition in Lisbon (Portugal) opens.
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
1 Jan 2000
The 20th Century, C.E., is still taking place thru 31 Dec.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
1 Jan 2001
This is the actual start of the new millennium, C.E.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 14-14 Page 35 7 Apr 1997
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Well, I'm catching back up. Still waiting to hear about Gecho, though.
Note: At the end of April, I'll be phasing out the old Macintosh
section. As always, I'll be happy to process any information I get,
either before or after it is phased out.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.11 O S Peter Karlsson 2:206/221 ANNOUNCE
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
CheckPnt 1.0a O G Michiel vd Vlist 2:500/9 CHECKPNT
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO
FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
GoldED 2.50 O S Len Morgan 1:203/730 GED
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
Imail 1.75 T S Michael McCabe 1:1/121 IMAIL
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
FIDONEWS 14-14 Page 36 7 Apr 1997
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
JD's CBV 1.4 O S John Dailey 1:363/277 CBV
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H
JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G
MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL
Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP
Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE
PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP
QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP
Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE
Squish 1.11 T P Tech 1:249/106 SQUISH
StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK
StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS
TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG
TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS
WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS
OS/2:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP
BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2
FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
FIDONEWS 14-14 Page 37 7 Apr 1997
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
GoldNODE 2.50 O S Len Morgan 1:203/730 GEN
ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP
PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
FrontDoor APX 1.10 P S Mats Wallin 2:201/329 FDAPXW
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP
BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP
CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR
GoldED 2.50 O S Len Morgan 1:203/730 GEO
GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM
Maximus 3.01 B P Tech 1:249/106 MAXN
Msged/NT 4.10 O G Andrew Clarke 3:635/728 MSGED41W.ZIP
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP
WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP
Unix:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.9 M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX
ifmail-tx.rpm ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO
GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS
Msged 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPDOOR
FIDONEWS 14-14 Page 38 7 Apr 1997
TrapDoor 1.86.b2 M S Maximilian Hantsch
2:310/6 TRAPBETA
TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS
Atari:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY
Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA
Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, F-Fossil, O-Other. Note: Multifunction will
be listed by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems Other Utilities Other Utilities
-------------- Name Version Name Version
-------------------- --------------------
Network Mailers 2DAPoint 1.50* Netsex 2.00b
Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35
-------------------- ARCAsim 2.31 Oliver 1.0a
D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02
Dreamer 1.06 Areafix 1.20 PKInsert 7.10
Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a
Milqtoast 1.00 Crossnet 1.5 QM 1.00a
PreNM 1.48 DOMAIN 1.42 QSort 4.04
SEAdog 4.60 DEMM 1.06 RAD Plus 2.11
SEAmail 1.01 DGMM 1.06 Raid 1.00
TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0
EEngine 0.32 ScanToss 1.28
Compression EMM 2.11* ScMail 1.00
Utilities EZPoint 2.1 ScEdit 1.12
Name Version FGroup 1.00 Sirius 1.0x
-------------------- FidoPCB 1.0s@ SLMail 2.15C
ARC 7.12 FNPGate 2.70 StarLink 1.01
ARJ 2.20 GateWorks 3.06e TagMail 2.41
LHA 2.13 GMail 2.05 TCOMMail 2.2
PAK 2.51 GMD 3.10 Telemail 1.5*
PKPak 3.61 GMM 1.21 TGroup 1.13
PKZip 1.10 GROUP 2.23 TIRES 3.11
GUS 1.40 TMail 1.21
NodeList Utilities Harvey's Robot 4.10 TosScan 1.00
Name Version HeadEdit 1.18 UFGATE 1.03
-------------------- HLIST 1.09 VPurge 4.09e
EditNL 4.00 ISIS 5.12@ WEdit 2.0@
FDND 1.10 Lola 1.01d WildMail 2.00
MakeNL 2.31 Mosaic 1.00b WMail 2.2
Parselst 1.33 MailBase 4.11a@ WNode 2.1
Prune 1.40 MSG 4.5* XRS 4.99
SysNL 3.14 MsgLnk 1.0c XST 2.3e
FIDONEWS 14-14 Page 39 7 Apr 1997
XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00
XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25
MSGTOSS 1.3 ZSX 2.40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BBS Software Macintosh Other Software
Name Version --------- Name Version
-------------------- --------------------
FBBS 0.91 Network Mailers MacArd 0.04
Hermes 1.6.1 Name Version Mantissa 3.21
Mansion 7.15 -------------------- Mehitable 2.0
Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0
Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2
Telefinder Host StuffIt Classic 1.6
2.12T10 Other Software SunDial 3.2
Name Version TExport 1.92
-------------------- TimeStamp 1.6
Point System ArcMac 1.3 TImport 1.92
Software AreaFix 1.6 Tset 1.3
Name Version Compact Pro 1.30 TSort 1.0
-------------------- EventMeister 1.0 UNZIP 1.02c
Copernicus 1.00 Export 3.21 Zenith 1.5
CounterPoint 1.09 Import 3.2 Zip Extract 0.10
MacWoof 1.1 LHARC 0.41
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 14-14 Page 40 7 Apr 1997
=================================================================
FIDONEWS PUBLIC-KEY
=================================================================
[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!
mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO
eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe
Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR
tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS
JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg
FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g
c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB
FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs
1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23
O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+
UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3
8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW
ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY
q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6
3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2
raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB
FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER
vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH
X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9
Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5
toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j
D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt
SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA
AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1
v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB
FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy
WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk
DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh
EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg
+Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/
Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w
aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr
ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg==
=61OQ
-----END PGP PUBLIC KEY BLOCK-----
File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on
the FidoNews homepage listed in the Masthead information.
-----------------------------------------------------------------
FIDONEWS 14-14 Page 41 7 Apr 1997
=================================================================
FIDONET BY INTERNET
=================================================================
This is a list of all FidoNet-related sites reported to the Editor as
of this appearance.
============
FidoNet:
Homepage http://www.fidonet.org
FidoNews http://ddi.digital.net/~cbaker84/fidonews.html
HTML FNews http://www.geocities.com/Athens/6894/
WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
FTSC page http://www2.blaze.net.au/ftsc.html
Echomail http://www.portal.ca/~awalker/index.html
WebRing http://ddi.digital.net/~cbaker84/fnetring.html
============
Zone 1: http://www.z1.fidonet.org
Region 10: http://www.psnw.com/~net205/region10.html
Region 11: http://oeonline.com/~garyg/region11/
Region 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/
Region 16: http://www.tiac.net/users/satins/region16.htm
Region 17: http://www.portal.ca/~awalker/region17.htm
Region 18: http://www.citicom.com/fido.html
Region 19: http://home1.gte.net/bhamilt/index.htm
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm
Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm
Region 20: http://www.fidonet.pp.se (in Swedish)
Region 24: http://www.swb.de/personal/flop/gatebau.html (in German)
Region 25:
http://members.aol.com/Net254/
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (in French)
FIDONEWS 14-14 Page 42 7 Apr 1997
Region 30: http://www.fidonet.ch (in Swiss)
Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish)
REC34: http://pobox.com/~chr
Region 36: http://www.geocities.com/SiliconValley/7207/
Region 41: http://www.fidonet.gr (in Greek and English)
Region 48: http://www.fidonet.org.pl
============
Zone 3: http://www.z3.fidonet.org
============
Zone 4: (not yet listed)
Region 90:
Net 904: http://members.tripod.com/~net904 (in Spanish)
============
Zone 5: (not yet listed)
============
Zone 6: http://www.z6.fidonet.org
============
-----------------------------------------------------------------
FIDONEWS 14-14 Page 43 7 Apr 1997
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:18/14, cbaker84@digital.net
cbaker84@aol.com
cbaker84@msn.com
(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.
voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1997 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSEnn.ZIP] for a
FIDONEWS 14-14 Page 44 7 Apr 1997
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in
size from 48K to 1.4M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/
*=*=*
You may obtain an email subscription to FidoNews by sending email to:
jbarchuk@worldnet.att.net
with a Subject line of: subscribe fnews-edist
and no message in the message body. To remove your name from the email
distribution use a Subject line of: unsubscribe fnews-edist with no
message to the same address above.
*=*=*
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/Athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
FIDONEWS 14-14 Page 45 7 Apr 1997
1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.
*=*=*=*=*
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-30-
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink