informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido1425.nws

2280 lines
97 KiB
Plaintext
Raw 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 25 23 June 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. |
+----------------------------------------------------------------------+
HELP STAMP OUT OSMOSIS!
Table of Contents
1. EDITORIAL ................................................ 1
Are we getting out? ...................................... 1
2. LETTERS TO THE EDITOR .................................... 2
Take the First Amendment Pledge .......................... 2
Internet Regulations ruled Unconstitutional .............. 6
BWE - Blue Wave mail reader for Windows95/NT4 ............ 10
3. ARTICLES ................................................. 11
CRC and the Nodelist ..................................... 11
4. COLUMNS .................................................. 15
Lock and Load: Guerilla Marketing for BBSes .............. 15
5. GETTING TECHNICAL ........................................ 17
FSC-0085 - NOZIP and ERX flags ........................... 17
FSC-0086 - Standard Request Information File proposal .... 18
FSC-0087 - File Forwarding in FTNs ....................... 21
FSC-0088 - Compatibility for EMSI Sessions ............... 27
6. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 33
Announcing the WRESTLING_CHAT Echo ....................... 33
7. NOTICES .................................................. 34
New Area Codes in North FLorida are coming ............... 34
Future History ........................................... 35
8. FIDONEWS PUBLIC-KEY ...................................... 36
FidoNews PGP public-key listing .......................... 36
9. FIDONET BY INTERNET ...................................... 37
10. FIDONEWS INFORMATION .................................... 39
FIDONEWS 14-25 Page 1 23 Jun 1997
=================================================================
EDITORIAL
=================================================================
Yet another email from Zone 2 telling me they've either:
1. never heard of FidoNews;
or
2. don't get FidoNews in their Net/Region.
Isolated incidents? Probably, since the reports are not at flood level
so far. But, of course, if FidoNews is unknown out there, who is going
to know to comment or complain? The last reporter only found FidoNews
during an Infoseek search on the Internet.
I know it gets to ZC2 but what about you Zone 2 RCs? Are you moving
FidoNews out there? Zone 2 NCs? YooHoo.
P4 sez FidoNews is part of the glue that holds us together but glue
doesn't work unless you spread it on all the parts you want to stick.
ZCs, RCs, and NCs can send Netmail to me at 1:18/14 or 1:1/23 or email
to cbaker84@digital.net and let me know how many times they send out
FidoNews to their constituents, if they'd like to help sort out the
black holes of FidoNews distribution.
Otherwise, the news continues. [grin]
C.B.
-----------------------------------------------------------------
FIDONEWS 14-25 Page 2 23 Jun 1997
=================================================================
LETTERS TO THE EDITOR
=================================================================
--- Following message extracted from FIDONEWS @ 1:18/14 ---
By Christopher Baker on Sun Jun 22 14:43:12 1997
From: Mike Bilow
To: Christopher Baker
Date: 20 Jun 97 16:55:06
Subj: ACLU Cyber-Liberties Update, June 19, 1997
* Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2.
* Original dated: Jun 19 '97, 21:33
From: "ACLU Cyber-Liberties Update Owner"@newmedium.com
To: cyber-liberties@aclu.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACLU Cyber-Liberties Update
Thursday, June 19, 1997
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.firstamendment.org/
A new ACLU/EPIC website
Take the First Amendment Pledge
As we all await a Supreme Court decision on the future of free speech
on the Internet, the American Civil Liberties Union and the Electronic
Privacy Information Center launched www.firstamendment.org, a website
dedicated to upholding the First Amendment in cyberspace.
The groups called on President Clinton and members of Congress to be
among the first to "Take the First Amendment Pledge" and cease any
further attempts to draft legislation to censor the Internet in the
event the Supreme Court upholds a lower court decision striking down
government regulation of the Internet as unconstitutional.
The launch of the website comes as Clinton Administration officials
have begun publicly discussing a shift in policy on Internet
regulation, saying that "industry self-regulation" -- not laws
criminalizing certain Internet communications -- is the solution to
shielding minors from online "indecency."
"Attempts to censor the Net will not end with the Supreme Court
decision," said David Sobel, legal counsel for EPIC and co-counsel in
Reno v. ACLU. "Proponents of Internet content regulation have already
indicated their desire to take a 'second bite of the apple' if the
Communications Decency Act is struck down."
In anticipation of such new attempts at online censorship, visitors to
FIDONEWS 14-25 Page 3 23 Jun 1997
www.firstamendment.org are invited to "Take the First Amendment
Pledge," which reads: "I pledge to support free speech and free
expression for all Americans and to urge Congress to uphold the First
Amendment to the United States Constitution and pass no law abridging
our freedom of speech."
People taking the pledge are encouraged to place the "First Amendment
Pledge" GIF their own websites.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Day of Decision Events
As the countdown continues to a Supreme Court ruling in Reno v. ACLU,
the first-ever case to look at how free speech principles are applied
to the Internet, the American Civil Liberties Union is preparing to go
live on the World Wide Web with a cybercast news conference on the
day a decision is reached.
Day of Decision Schedule
1:00 p.m.(E.D.T.) Press Conference and Cybercast
At the ACLU's new national offices at 125 Broad Street in lower
Manhattan. Reno v. ACLU attorneys, co-counsel and plaintiffs will
participate. The live cybercast can be accessed through the ACLU's
website, http://www.aclu.org, and directly through Pathfinder's Netly
News at http://www.pathfinder.com/news/netdecency.
7:00 p.m. (E.D.T.) Live Chat with ACLU Attorneys
A one-hour chat with ACLU attorneys is planned on ECHO.
Instructions:
ECHO chats are open to anyone with Internet access.
Telnet to echonyc.com, or dial 212-292-0910 with your modem.
Login as echolive, and communicate directly with the Attorneys.
Reno v. ACLU challenges censorship provisions of the Communications
Decency Act aimed at protecting minors by criminalizing so-called
"indecency" on the Internet. The government appealed the case to the
Supreme Court after a federal three-judge panel ruled unanimously last
June that the law unconstitutionally restricts free speech. The ACLU
filed a challenge to the law the day it was enacted.
Show your support for the ACLU's challenge to the Communications
Decency in any -- or all -- of the following ways:
1) To be notified of a decision in the case by a change in a graphic
placed on your web site, join our GIF notification Campaign --
instructions can be found at:
http://www.aclu.org/issues/cyber/trial/instructions.html
The image will change when the decision is handed down - notifying
you, and everyone who visits your site.
2) Take the 1st Amendment Pledge at www.firstamendment.org, a joint
FIDONEWS 14-25 Page 4 23 Jun 1997
campaign of the ACLU and the Electronic Privacy Information Center
(EPIC).
3) Subscribe to the Cyber-Liberties Update. Those of you who already
receive the update directly will be notified. Those of you who read
forwarded copies are encouraged to subscribe directly using the
information in the footer of this document.
4) And the most important way you can show your support is to Join the
ACLU. Information is available on our website http://www.aclu.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Setback in Efforts to Secure Online Privacy
FOR IMMEDIATE RELEASE
Thursday, June 19, 1997
WASHINGTON -- A Senate committee today setback legislative efforts to
secure online privacy, approving legislation that would restrict the
right of businesses and individuals both to use encryption
domestically and to export it.
On a voice vote, the Senate Commerce Committee adopted
legislation that essentially reflects the Clinton Administration's
anti-encryption policies.
The legislation approved today on a voice vote by the Senate
Commerce Committee was introduced this week by Senate Commerce
Committee Chairman John McCain, Republican of Arizona, and co-
sponsored by Democrats Fritz Hollings of South Carolina; Robert Kerry
of Nebraska and John Kerry of Massachusetts.
Encryption programs scramble information so that it can only be
read with a "key" -- a code the recipient uses to unlock the scrambled
electronic data. Programs that use more than 40 bits of data to
encode information are considered "strong" encryption. Currently,
unless these keys are made available to the government, the Clinton
Administration bans export of hardware or software containing strong
encryption, treating these products as "munitions."
Privacy advocates continue to criticize the Administration's
stance, saying that the anti-cryptography ban has considerably
weakened U.S. participation in the global marketplace, in addition
to curtailing freedom of speech by denying users the right to "speak"
using encryption. The ban also violates the right to privacy by
limiting the ability to protect sensitive information in the new
computerized world.
Today's committee action knocked out of consideration the so-
called "Pro-CODE" legislation, a pro-encryption bill introduced by
Senator Conrad Burns, Republican of Montana. Although the Burns
legislation raised some civil liberties concerns, it would have lifted
export controls on encryption programs and generally protected
individual privacy.
FIDONEWS 14-25 Page 5 23 Jun 1997
"Privacy, anonymity and security in the digital world depend on
encryption," said Donald Haines, legislative counsel on privacy and
cyberspace issues for the ACLU's Washington National Office. "The aim
of the Pro-CODE bill was to allow U.S. companies to compete with
industries abroad and lift restrictions on the fundamental right to
free speech, the hallmark of American democracy."
"Sadly, no one on the Commerce Committee, not even Senator Burns,
stood up and defended the pro-privacy, pro-encryption effort," Haines
added.
In the House, however, strong encryption legislation that would
add new privacy protections for millions of Internet users in this
country and around the world has been approved by two subcommittees.
The legislation -- H.R. 695, the "Security and Freedom Through
Encryption Act" or SAFE -- would make stronger encryption products
available to American citizens and users of the Internet around the
world. It was introduced by Representative Robert W. Goodlatte,
Republican of Virginia.
"We continue to work toward the goal of protecting the privacy of
all Internet users by overturning the Clinton Administration's
unreasonable encryption policy," Haines concluded
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACLU Cyber-Liberties Update Editor:
Lisa Kamm (kamml@aclu.org)
American Civil Liberties Union National Office
125 Broad Street
New York, New York 10004
To subscribe to the ACLU Cyber-Liberties Update, send a message
to majordomo@aclu.org with "subscribe Cyber-Liberties" in the
body of your message. To terminate your subscription, send a
message to majordomo@aclu.org with "unsubscribe Cyber-Liberties"
in the body.
The Cyber-Liberties Update is archived at
http://www.aclu.org/issues/cyber/updates.html
For general information about the ACLU, write to info@aclu.org.
PGP keys can be found at http://www.aclu.org/about/pgpkeys.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lisa Kamm |To receive the biweekly
kamml@aclu.org |ACLU Cyber-Liberties Update
http://www.aclu.org |email: majordomo@aclu.org
http://www.gilc.org |body of message: subscribe cyber-liberties
take the pledge: http://www.firstamendment.org
Lynn_Decker@aclu.org
Online Programs Coordinator
American Civil Liberties Union
FIDONEWS 14-25 Page 6 23 Jun 1997
125 Broad Street
New York, NY 10004-2400
Visit the ACLU Freedom Network --
http://www.aclu.org ACLU Constitution Hall on
America Online -- keyword ACLU ACLU Supports the
Global Internet Liberty Campaign (GILC)
http://www.gilc.org/gilc
This Message was sent to cyber-liberties
Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8(1:323/107)
-----------------------------------------------------------------
--- Following message extracted from FIDONEWS @ 1:18/14 ---
By Christopher Baker on Sun Jun 22 14:43:29 1997
From: Mike Bilow
To: Christopher Baker
Date: 21 Jun 97 08:35:50
Subj: ACLU Cyber-Liberties Update, Special: June 20, 1997
* Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2.
* Original dated: Jun 21 '97, 00:16
From: "ACLU Cyber-Liberties Update Owner"@newmedium.com
To: cyber-liberties@aclu.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACLU Cyber-Liberties Update
Friday, June 20, 1997
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Georgia, New York Internet Regulations Ruled Unconstitutional
Georgia Ruling available online now, New York summary available now
and Ruling on the way at
http://www.aclu.org/issues/cyber/censor/censor.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACLU Wins First-Ever Challenge to a State
Internet Censorship Law in Georgia
FOR IMMEDIATE RELEASE
Friday, June 20, 1997
ATLANTA -- As the nation awaits a Supreme Court decision on Internet
censorship, a federal district judge here today struck down a state
law criminalizing online anonymous speech and the use of trademarked
logos as links on the World Wide Web.
Ruling simultaneously in ALA v. Pataki, another ACLU challenge to
FIDONEWS 14-25 Page 7 23 Jun 1997
state Internet regulation, a Federal District Judge in New York today
blocked the state from enforcing its version of the federal
Communications Decency Act (CDA).
In ACLU v. Miller, Federal District Court Judge Marvin Shoob today
granted the ACLU's request to enjoin Georgia's statute restricting
free speech in cyberspace and denied the State's request to dismiss
the suit.
The Court agreed with the ACLU, Electronic Frontiers Georgia and
others that the statute is unconstitutionally vague and overbroad
because it bars online users from using pseudonyms or communicating
anonymously over the Internet. The Act also unconstitutionally
restricts the use of links on the World Wide Web which allows users to
connect to other sites.
In the Court's decision, Judge Shoob noted that Georgia's law, "sweeps
innocent, protected speech within its scope." He went on to say that
it, "affords prosecutors and police officers with substantial room for
selective prosecution of persons who express minority viewpoints. . .
. [Moreover,] Georgia already has in place many less restrictive
means to address fraud and misrepresentation."
"The Court's order goes straight to the First Amendment flaws with the
statute." said Scott McClain of Bondurant, Mixson & Elmore,
cooperating attorneys for the ACLU. "Judge Shoob viewed the statute
exactly as the Plaintiffs did: as a vague, overbroad, unconstitutional
restriction on free speech and privacy on the Internet."
"The Court recognized that anonymity is the passport for entry into
cyberspace for many persons," said Gerald Weber, Legal Director of
the ACLU of Georgia. "Without anonymity, victims of domestic violence,
persons in Alcoholics Anonymous, people with AIDS and so many others
would fear using the Internet to seek information and support."
"We are very pleased with the Judge's decision," said Robert Costner,
Executive Director of Electronic Frontiers Georgia. "This injunction
clears the way for Electronics Frontier Georgia to release our
anonymous remailer services on the Internet."
Georgia's lawsuit was the first challenge to state cyberspace laws and
statutes restricting privacy on the Internet.
Today's ruling came as the nation awaits word from the U.S.
Supreme Court in Reno v. ACLU, the ACLU's challenge to Internet
censorship provisions of the federal Communications Decency Act (CDA).
"Today's decisions in New York and Georgia say that, whatever limits
the Supreme Court sets on Congress's power to regulate the Internet,
states are prohibited from acting to censor online expression," said
Ann Beeson, an ACLU national staff attorney and member of the legal
teams in the New York, Georgia and federal cases.
"Taken together, these decisions send a very important and powerful
message to legislators in the other 48 states that they should keep
their hands off the Internet," Beeson added.
FIDONEWS 14-25 Page 8 23 Jun 1997
The Georgia lawsuit was filed on September 24, 1996, by the ACLU on
behalf of 14 plaintiffs. The 14 individual plaintiffs and
organizations named in the ACLU v. Miller are: American Civil
Liberties Union of Georgia; The AIDS Survival Project; the Atlanta
Freethought Society; Atlanta Veterans Alliance; Community ConneXion;
Electronic Frontier Foundation; Electronic Frontiers Georgia; Rep.
Mitchell Kaye; Ken Leebow; Bruce Mirken; Bonnie L. Nadri; Josh Riley;
John Troyer; and Jonathan Wallace.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New York Judge Prohibits State Regulation of Internet
FOR IMMEDIATE RELEASE
Friday, June 20, 1997
NEW YORK -- As the nation awaits a Supreme Court decision on Internet
censorship, a federal district judge here today blocked New York State
from enforcing its version of the federal Communications Decency Act
(CDA).
Ruling simultaneously in ACLU v. Miller, another ACLU challenge to
state Internet regulation, a Federal District Judge in Georgia today
struck down a law criminalizing online anonymous speech and the use of
trademarked logos as links on the World Wide Web.
In ALA v. Pataki, Federal District Judge Loretta A. Preska issued a
preliminary injunction against the New York law, calling the Internet
an area of commerce that should be marked off as a "national preserve"
to protect online speakers from inconsistent laws that could "paralyze
development of the Internet altogether."
Judge Preska, acknowledging that the New York act was "clearly modeled
on the CDA," did not address the First Amendment issues raised by the
ACLU's federal challenge, saying that the Commerce Clause provides
"fully adequate support" for the injunction and that the Supreme Court
would address the other issues in its widely anticipated decision in
Reno v. ACLU. (The Court's next scheduled decision days are June 23,
25 and 26.)
"Today's decisions in New York and Georgia say that, whatever limits
the Supreme Court sets on Congress's power to regulate the Internet,
states are prohibited from acting to censor online expression," said
Ann Beeson, an ACLU national staff attorney who argued the case before
Judge Preska and is a member of the ACLU v. Miller and Reno v. ACLU
legal teams.
"Taken together, these decisions send a very important and powerful
message to legislators in the other 48 states that they should keep
their hands off the Internet," Beeson added.
In a carefully reasoned, 62-page opinion, Judge Preska warned of the
extreme danger that state regulation would pose to the Internet,
rejecting the state's argument that the statute would even be
effective in preventing so-called "indecency" from reaching minors.
FIDONEWS 14-25 Page 9 23 Jun 1997
Further, Judge Preska observed, the state can already protect children
through the vigorous enforcement of existing criminal laws.
"In many ways, this decision is more important for the business
community than for the civil liberties community," said Chris Hansen,
a senior ACLU attorney on the ALA v. Pataki legal team and lead
counsel in Reno v. ACLU. "Legislatures are just about done with their
efforts to regulate the business of Internet 'sin,' and have begun
turning to the business of the Internet itself. Today's decision ought
to stop that trend in its tracks."
Saying that the law would reduce all speech on the Internet to a level
suitable for a six-year-old, the American Civil Liberties Union, the
New York Civil Liberties Union, the American Library Association and
others filed the challenge in January of this year.
The law, which was passed by the New York legislature late last year,
provides criminal sanctions of up to four years in jail for
communicating so-called "indecent" words or images to a minor.
In a courtroom hearing before Judge Preska in April, the ACLU
presented a live Internet demonstration and testimony from plaintiffs
who said that their speech had already been "chilled" by the threat of
criminal prosecution.
"This is a big win for the people of the state of New York," said
Norman Siegel, Executive Director of the New York Civil Liberties
Union. "Today's ruling vindicates what we have been saying all along
to Governor Pataki and legislators, that they cannot legally prevent
New Yorkers from engaging in uninhibited, open and robust freedom of
expression on the Internet."
The ALA v. Pataki plaintiffs are: the American Library Association,
the Freedom to Read Foundation, the New York Library Association, the
American Booksellers Foundation for Free Expression, Westchester
Library System, BiblioBytes, Association of American Publishers,
Interactive Digital Software Association, Magazine Publishers of
America, Public Access Networks Corp. (PANIX), ECHO, NYC Net, Art on
the Net, Peacefire and the American Civil Liberties Union.
Michael Hertz and others of the New York firm Latham & Watkins
provided pro-bono assistance to the ACLU and NYCLU; Michael Bamberger
of Sonnenschein Nath & Rosenthal in New York is also co-counsel in the
case. Lawyers from the ACLU are Christopher Hansen, Ann Beeson and
Art Eisenberg, legal director of the NYCLU.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACLU Cyber-Liberties Update Editor:
Lisa Kamm (kamml@aclu.org)
American Civil Liberties Union National Office
125 Broad Street
New York, New York 10004
To subscribe to the ACLU Cyber-Liberties Update, send a message
to majordomo@aclu.org with "subscribe Cyber-Liberties" in the
body of your message. To terminate your subscription, send a
FIDONEWS 14-25 Page 10 23 Jun 1997
message to majordomo@aclu.org with "unsubscribe Cyber-Liberties"
in the body.
The Cyber-Liberties Update is archived at
http://www.aclu.org/issues/cyber/updates.html
For general information about the ACLU, write to info@aclu.org.
PGP keys can be found at http://www.aclu.org/about/pgpkeys.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lisa Kamm |To receive the biweekly
kamml@aclu.org |ACLU Cyber-Liberties Update
http://www.aclu.org |email: majordomo@aclu.org
http://www.gilc.org |body of message: subscribe cyber-liberties
take the pledge: http://www.firstamendment.org
This Message was sent to cyber-liberties
Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8(1:323/107)
-----------------------------------------------------------------
X-Sender: dima@galactica.it
Date: Thu, 19 Jun 1997 07:05:22 +0200
To: cbaker84@digital.net
From: Michele Di Maria <dima@galactica.it>
Subject: BWExplorer
HI!,
I'd like inform you that BWExplorer: the FIRST Blue Wave (tm) mail
reader especially designed for Windows95/NT4) has been released.
You can download it at Michele's HomePage at:
http://www.geocities.com/siliconvalley/7409
(This is not a mailing list, I found you address at your site and I
hope you will find interesting this new)
Thank you,
Michele
Michele's
Shareware
Site: http://www.geocities.com/SiliconValley/7409
-30-
-----------------------------------------------------------------
FIDONEWS 14-25 Page 11 23 Jun 1997
=================================================================
ARTICLES
=================================================================
CRC and The Nodelist
Has anybody else had problems keeping current? If it's not a missing
DIFF now and then, it's CRC trouble... What is this CRC thing anyway?
I've been trying to find out for over a year now, it's been one of
those things that just keeps coming up now and then. Right now my
NODELIST.164 has an improper CRC. The utility I use to merge the
diffs told me so, and actually added a line at the bottom:
;S This Nodelist file has an improper CRC!
The nodelist seems to be working correctly, but it bugs me to know
something is improper about it. I have all those FSC- and FTS- files
that tell about fido junk, maybe they can help? Maybe someone in the
net knows what's going on? Isn't anybody gonna do something? My
Nodelist has an improper CRC! Help!
I like fido, and it's a good excuse to try writing small programs in
c/c++ that can help me out. I've been sort of working on a small
utility that will take our local netseg and make a BBS list for the
systems not marked HUB, HOST or with a MO flag. Our netseg has that
CRC number on the top line, shouldn't my program insure that the
contents are valid before it tries to use them?
This source will check an input file for a number at the end of the
top line, and use that number if found to compare CRC value with the
rest of the file. There may already be code out there to do this, if
there is, I sure wish I'd had access to it!! I'm very interested in
c/c++, but don't have access to any echos dealing with fido or BBS
programming. There may be plenty of source code out there.
Seems like most good software comes from Zone:2 anyway. If anybody
knows where there is some source code dealing specifically with
fidonet, how about dropping me a line?
If you need a compiled (.EXE) version, F'Req NLCRC.ZIP (35k).
L8r,
bw
/*******************************************: 55734
** NLCRC.C Test a nodelist segment for correct CRC
** 6/97 Brian Wood 1:362/903
** (903!brainwave@river.chattanooga.net)
** thanks to:
** Ross N. Williams, Author:
** A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS
** and:
** The SNIPPETS guy, I think it's Bob Juge or Stout?
** and for FTS-0005:
** The Distribution Nodelist
** Original by Ben Baker Amended by Rick Moore
*/
FIDONEWS 14-25 Page 12 23 Jun 1997
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
unsigned AddCRC(unsigned, char *, unsigned);
main(int argc, char **argv)
{
unsigned crc=0;
unsigned lines=0;
unsigned compare=0;
char szCrc[10];
char topline[200]; /* assuming a nodelist entry */
char oneline[200]; /* will be <= 200 characters */
FILE *f;
if( argc > 1 ) {
if( (f = fopen( argv[1], "rb" ) ) == NULL ) {
printf("\nCan't open %s", argv[1]);
exit(-1);
}
}
else {
printf("\nUsage: NLCRC <nodelist.ext>");
exit(-1);
}
/* Take the CRC from the top line of nodelist */
fgets( topline, sizeof(topline), f);
strcpy(szCrc, &topline[strlen(topline)-8]);
compare = (unsigned)atof(szCrc);
if(compare==0) {
printf("\n%s doesn't seem to be a nodelist!", argv[1]);
exit(-1);
}
/* FTS-0005 says calculate beginning with
** 1st character of second line, and ignore
** EOF(ASCII 26) if present, so.... */
printf("\nReading File...");
while( fgets(oneline, sizeof(oneline), f) != NULL
&& oneline[0] != 26) {
crc = AddCRC( crc, oneline, strlen(oneline) );
lines++;
}
/* Show the results */
printf("\n%s %ld bytes", argv[1], ftell(f));
fclose(f);
printf("\nLinesread = %u", lines);
if(oneline[0] == 26)
printf(" -minus top line and EOF-");
else
printf(" -minus top line- EOF Missing!");
printf("\n%u = compare crc", compare);
printf("\n%u = actual crc", crc);
FIDONEWS 14-25 Page 13 23 Jun 1997
printf("\n");
if(compare==crc)
printf("\nCRC appears OK!");
else
printf("\nCRC Values Do Not Match!");
return 0;
}
/*
** END MAIN */
/************************
** Function: AddCRC(...)
*/
unsigned AddCRC(unsigned crc, char *sz, unsigned len)
{
unsigned CRC16table[] = { /* Polynomial 0x1021 (CITT) */
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6,
0x70e7, 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad,
0xe1ce, 0xf1ef, 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5,
0x4294, 0x72f7, 0x62d6, 0x9339, 0x8318, 0xb37b, 0xa35a,
0xd3bd, 0xc39c, 0xf3ff, 0xe3de, 0x2462, 0x3443, 0x0420,
0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485, 0xa56a, 0xb54b,
0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d, 0x3653,
0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d,
0xc7bc, 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861,
0x2802, 0x3823, 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948,
0x9969, 0xa90a, 0xb92b, 0x5af5, 0x4ad4, 0x7ab7, 0x6a96,
0x1a71, 0x0a50, 0x3a33, 0x2a12, 0xdbfd, 0xcbdc, 0xfbbf,
0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a, 0x6ca6, 0x7c87,
0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41, 0xedae,
0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51,
0x0e70, 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a,
0x9f59, 0x8f78, 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c,
0xc12d, 0xf14e, 0xe16f, 0x1080, 0x00a1, 0x30c2, 0x20e3,
0x5004, 0x4025, 0x7046, 0x6067, 0x83b9, 0x9398, 0xa3fb,
0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e, 0x02b1, 0x1290,
0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256, 0xb5ea,
0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424,
0x4405, 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e,
0xc71d, 0xd73c, 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657,
0x7676, 0x4615, 0x5634, 0xd94c, 0xc96d, 0xf90e, 0xe92f,
0x99c8, 0x89e9, 0xb98a, 0xa9ab, 0x5844, 0x4865, 0x7806,
0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3, 0xcb7d, 0xdb5c,
0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a, 0x4a75,
0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8,
0x8dc9, 0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83,
0x1ce0, 0x0cc1, 0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b,
0xbfba, 0x8fd9, 0x9ff8, 0x6e17, 0x7e36, 0x4e55, 0x5e74,
0x2e93, 0x3eb2, 0x0ed1, 0x1ef0 };
FIDONEWS 14-25 Page 14 23 Jun 1997
while(len--)
crc=(crc<<8)^CRC16table[(crc>>8)^*sz++];
return( crc );
}
/*
** END NLCRC.C */
--- ISR sn 000 at river.chattanooga.net vsn 1.0a unreg
--
|Fidonet: Brainwave 1:362/903
|Internet: 903!Brainwave@river.chattanooga.net
|
| Standard disclaimer: The views of this user are strictly his own.
| River Canyon Rd. BBS <=> Chattanooga OnLine! Gateway to the World.
-----------------------------------------------------------------
FIDONEWS 14-25 Page 15 23 Jun 1997
=================================================================
COLUMNS
=================================================================
Lock and Load: Guerilla Marketing for BBSes
Robert Parson (1:3822/1)
Y'know. One of the things I've always found rather bothersome about
the Internet is its lack of a local identity. Sure, it's got lots of
really spiffy stuff on it. But it still seems rather cold and
distant. Even the sites that are highly personalized are somewhat
remote.
When was the last time you were really able to discuss local issues
with someone on the Internet? Can you vent your indignation about a
city sales tax increase with someone across the country? You could,
but he or she won't have the same empathy as someone across the town
would have.
This is the great power BBSes have. They are the Friendly
Neighborhood Electronic Townhalls. But the users can't come if they
don't know you are there.
When I was just a tad, about 8 or 9 years old, my grandfather and two
uncles opened up a window glass store. Most of their business came
from contractors who called up and said "We've built a house, now we
need windows." But a good chunk of their business was repairing
windows broken in storms, vandals, or the neighborhood baseball games.
One Saturday morning, they armed my brother and me with hundreds of
flyers. We were to go slipping through the neighborhood, tucking
these flyers into doors. The flyers talked about how great the work
of Lawrence Glass Company (In Lawrence IN) was and how inexpensive the
rates were. We earned a whopping 25 cents each (it's amazing how I
can remember things like that, but can't remember how old my wife is).
I'm sure you can see where this is going. How many of your neighbors
know you have a BBS?
Crack open the Desktop Publisher and create a flyer. It doesn't have
to be very elaborate. Make sure it has the name of your BBS and the
data number (you might want to include your voice phone in case
someone wants to ask a question before they dial in), and invite the
neighborhood to call. Print up a jillion of these things.
Then put those preteens to work. If they're like mine, they're aching
to get outside anyway ("But there's a blizzard!" "I don't care! I
wanna go out!"). And don't forget to give them a quarter for their
efforts.
Now, it's quite likely not every house in your neighborhood is going
to have a computer equipped with a modem. I think in my neighborhood
there's an average of one computer per block. But that's unimportant.
What IS important is that you're getting the word out to people that
are likely to be intrigued at the very least.
FIDONEWS 14-25 Page 16 23 Jun 1997
1. They're going to be interested because it's someone they know that
lives near them.
2. They're going to be interested because it's so close to them, there
may be something on the BBS that offers them some sort of local
information.
3. They're going to be interested because it's something
different.
4. They're going to be interested because they want to make sure you
aren't peddling pornography. (or maybe because you are)
5. They're going to be interested because you had the audacity to put
that doggone flyer in their door.
I'm constant amazed at the numbers of small-town weeklies that exist.
They're poorly written, sloppily edited, have messy layouts, and low
page counts. Thy thrive because they publish the little details of
small-town life. Your Friendly Neighborhood BBS can thrive in much
the same way.
Robert Parson
-----------------------------------------------------------------
FIDONEWS 14-25 Page 17 23 Jun 1997
=================================================================
GETTING TECHNICAL
=================================================================
[This is part of the continuing FidoNet History series publishing the
FidoNet Technical Standards and Proposals. FSC-0084 was skipped due
to size. These have been reformatted to 70 columns where required and
tables may be askew as a result. Node numbers and phone numbers may
be out of date. High ASCII characters have been converted or
removed as necessary.] Ed.
| Document: FSC-0085
| Version: 001
| Date: 03 September 1995
|
| Denis Bider, FidoNet#2:380/129.0
/*
Date: 25-Jul-1995
Document: Descriptions of the "NOZIP" and "ERX<n>" nodelist flags
Purpose: To give a system that is about to send some mail to a system
not already defined by its operator in its configuration some idea
about what kind of mail the mentioned destination system accepts
Author: denis bider, ofs->FidoNet#2:380/129.0
The NOZIP nodelist flag and its affects on the MN nodelist flag
======================================================================
Generally, most FTN systems are able to receive compressed mail from
any other FTN system. Up to now, the official compression format
between systems has been ARC. This document, however, puts the ZIP
format to that position.
* A system whose nodelist entry contains neither an "MN" and
neither a "NOZIP" flag is assumed to support both ARC and ZIP.
* A system whose nodelist entry contains an "MN" flag is assumed
not to support any compression at all.
* A system whose nodelist entry contains a "NOZIP" flag is assumed
to support ARC compression, while not supporting ZIP
compression.
* Both "NOZIP" and "MN" flags cannot appear in the same nodelist
entry. If they, by some accident, do, the system should be
assumed not to support any mail compression.
Since the majority of systems support ZIP compression, a flag
indicating that this type of compression is NOT supported has is
proposed instead of a flag indicating that this type of compression IS
supported, the reason being to minimize the amount of changes required
to the nodelist.
The format of the NOZIP flag is, simply, "NOZIP".
The format of the MN flag stays the same.
The ERX<n> nodelist flag
FIDONEWS 14-25 Page 18 23 Jun 1997
======================================================================
The presence of this flag in a system's nodelist entry indicates that
the system is able to process ERX mail packets of level <n>. The
current minimum and maximum values of <n> are both "1", indicating
that the system is able to process ERX packets of level 1, meaning
that the packets can only contain EDX message items. Please refer to
EDX1.TXT for the EDX and ERX specifications.
The format of the "ERX<n>" nodelist flag is
"ERX" <n>
as in "the three letters 'E', 'R' and 'X', immediately followed with
the token <n>", where <n> is a number in decimal notation, with
currently all values but '1' being reserved.
If your system does not support ZIP and you do not yet have a NOZIP
flag in your nodelist entry, or if your system is able to process ERX
packets and you do not yet have an ERX<n> flag, please urge your NC or
RC, whichever appropriate, to update your nodelist entry as soon as
possible.
// EOF */
-30-
-----------------------------------------------------------------
| Document: FSC-0086
| Version: 001
| Date: 03 September 1995
|
| Mirko Mucko, 2:2433/920
Information / Description of a new standard
S tandard
R equest
I nformation
F ile
Copyright (c) 1994,95 by Gordian Schuermann & Mirko Mucko
I Overview
Introduction 0
Description in general 1
Required statements 1.1
Optional statements 1.2
Undefined options 1.3
Implementation 2.0
0. Introduction
In common, more and more mailer are about to implement the ability to
call external request processors. But very soon, we discovered a
command line cannot handle all the information the mailer has and the
ERP needs.
FIDONEWS 14-25 Page 19 23 Jun 1997
To transfer the information in a proper and fast way, we designed and
implemented the S R I F option in the mean it will be a standard
soon.
The structure and idea is protected by copyright law, except these
circumstances:
+ you may distrubute, use and implement this structure for
free
+ you have not to pay any value for usage of these methodes
+ you should note in your documentation the origin of SRIF
1. Description
The SRIF name is the only parameter given from the Mailer to the
External Request Processor. The file is designated as a so called
"plain vanilla ASCII" file, filled with pre-defined, optional and
not-yet defined statemets.
We discussed the possibility of binary files, and of EMSI-like files,
but a plain ASCII control file is more flexible and can be read
faster by various program languages (C, Pascal, Basic, Cobol ect).
In the SRIF, one command plus parameter is allowed per line, the file
is unlimited in length, comments are not allowed.
The SRIF is generated by the Mailer and after the ERP finished its
work, the Mailer is responsible for erasing the SRIF.
1.1 Required statements
The following statements are required for the ERP:
Sysop <Sysop_Name>
This is the name of the remote sysop
AKA <Zone:Net/Node[.Point][@Domain]>
This is the main aka of the remote system in
4D or 5D notation. A zero as point number may
be ommited, the domain with "@" is optional
Baud <Current LINE rate>
This is the effective baud rate, not the fixed
DTE rate
Time <Time in minutes>
This is the time till next event which does
not allow file requests. Use -1 if no limits
RequestList <File of request list>
This is the filename of the list containing
requested files.
ResponseList <File of response list>
This is the filename of the response list.
It must not be equal to RequestList. One file
per line, including drives/pathes to the file.
The first character defines the way the mailer
should act after sending that file:
FIDONEWS 14-25 Page 20 23 Jun 1997
= erase file if sent successfully
+ do not erase the file after sent
- erase the file in any case after session
RemoteStatus <PROTECTED or UNPROTECTED>
Defines whether the session is protected by
password or not
SystemStatus <LISTED or UNLISTED>
Defines whether the remote system is listed in
any current nodelist of system.
1.2 Optional statements
These parameters are already known and defined, but a ERP should run
also without them:
SessionProtocoll <e.g. ZAP,ZMO,XMA
AKA <Zone:Net/Node[.Point][@Domain]>
Additional AKAs. One AKA is required (see
REQUIRED section)
Site <Site Info>
The site info as given e.g. in EMSI handshake
Location <Location and/or ZIP>
The location info as given e.g. in EMSI
handshake
Phone <Phone Number>
The phone number info as given e.g. in EMSI
handshake
Password <Session password>
On protected sessions, the session password.
If no protected session, this parameter must
be ommited!
DTE <Current DTE rate>
The PC<->Modem speed (so call DTE rate)
PORT <COM Port from 1 to 8>
The FOSSIL Communication Port. The Mailer
should leave the fossil "hot" for the Request
Processor
Mailer <Remote's mailer if EMSI>
The Mailer name as defined by FTC
MailerCode <Remote's FTSC code>
The hex code of the remote mailer as defined
by FTC
SerialNumber <Remote's serial number if passed>
The remote mailer's serial number if
transfered
FIDONEWS 14-25 Page 21 23 Jun 1997
Version <Remote's version number if EMSI>
The remote mailer's version number if
transfered
Revision <remote's revision number if EMSI>
The remote mailer's revision number if
transfered
SessionType <may be EMSI, FTSC0001, WAZOO, JANUS, HYDRA or
OTHER>
The session-type, this may be one of the known
session types or "OTHER" if not (yet) defined
OurAKA <AKA which has been called for proper
response>
If the mailer does AKA matching, the AKA of
the mailer being called
TRANX <Tranx Line as 8 digit hex string>
The unix-style time stamp (hexadecimal
notation of seconds since 1.1.1980)
1.3 Undefined options
There may be the need to add new commands / parameters to the SRI
file. If so, they may be added, but inform us to keep the
documentation "up to date" and to share your good ideas with other
autors of software for FIDONet.
2.0 Implementation
SRIF is implemented in these fine products already :
Mailer Request Processor
------------------------------------------------------
McMail xOR
EasyERP
Other products will follow soon !
-30-
-----------------------------------------------------------------
| Document: FSC-0087
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
File Forwarding in Fidonet Technology Networks
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
To document current practices in File Forwarding and the
minimum requirements and known extensions of the TIC file format.
FIDONEWS 14-25 Page 22 23 Jun 1997
Acknowledgements:
The TIC file format was introduced by Barry Geller, in the
MSDOS File Forwarder, Tick. Useful extensions to this format were
introduced by Harald Helms, in the MSDOS FileForwarder, AllFix.
Terminology:
FTN - Fidonet Technolgy Network, such as FIDONET, AMIGANET or
IBMNET. Sometimes used interchangably with the term DOMAIN.
FNC - FileName Conversion, process of converting filenames to
msdos 8.3 format for transmission.
FQFA - Fully Qualified FTN Address, the format is
FTN#Zone:Net/Node.Point
CRC - Cyclic Redundancy Check, method to determine whether some
data has been altered. CRC-32 is used in File Forwarding.
TIC - a file that contains control information for the File
Forwarding system. These files are named xxSTAMP.TIC, where xx
is an abbreviation representing the File Forwarding program
name and stamp is a unixdate stamp truncated to 6 characters.
UTC - Universal Time Coordinated, the time at the 0o
meridian (Greenwich); previously called GMT forwarding - the
process of creating and sending tic files and the associated file
to one's downlinks.
ticking - the processing of reading and verifying a tic file and
it's associated file.
hatching - the process of introducing a new file into a fileecho
cross-hatching - the process of forwarding a file from one
fileecho (ususally restricted) to another
Associated File - The file listed in the FILE field of the TIC
file.
Note that use of UPPERCASE on tic file keywords in this
document in for display purposes only.
Format of a TIC file:
Addressing:
In a tic file any form of FTN address representation from
3d to FQFA may be used. All File Forwarders must understand
the following formats:
zone:net/node - 3D
zone:net/node.point - 4D
zone:net/node@ftn - 5D - point 0 assumed
zone:net/node.point@ftn - 5D
ftn#zone:net/node.point - fqfa
File Forwarders should have configurable options per site as
FIDONEWS 14-25 Page 23 23 Jun 1997
to the type of addressing each of it's downlinks can understand.
Dates:
All dates are expressed in UTC.
TimeDateStamps:
All TimeDateStamps are unix TimeDateStamps (# of seconds
since Jan 1, 1960) in UTC and expressed in hexadecimal notation.
Case Insensitivity:
the format is completely case-insensitive. It is general
practice that the first letter of a keyword is uppercase. This is
not a requirement.
Order Dependancy:
keywords are not order dependant.
Order dependancy is required in some groupings of a keyword,
such as PATH, VIA, DESC and APP.
Modification of address fields on PassThrough:
The forwarding site may modify the addresses in any keyword
field to make them compliant with the addressing limitations of
each downlink.
Stripping of SeenBys:
The forwarding site may strip seenbys to current FTN, ZONE or
NET, when not forwarding outside of current FTN, ZONE or NET. This
does not imply nor permit the stripping of of a direct downlink
which is outside the current strip filter.
Keywords:
There are no colons on keywords.
Each keyword line is terminated with CR LF pair.
The maximum length of a keyword line is 256 characters,
including the CRLF termination. Some keyword lines may have a shorter
limit.
Keywords are separated from their data by a single space.
There is no space if there is no data associated with the keyword.
eg: ReturnReceipt
Keywords are case-insensitive and order independant.
Keywords not understood are to be passed-though.
Known Keywords that are blank should not be passed though.
For example, an empty AREADESC, could be either dropped
or the blank replaced with the proper description.
Most Keywords are passed through when processing.
There are exceptions. In some cases, a site-specific
replacement may be created.
Keywords marked with a ^ should not be passed-through.
FIDONEWS 14-25 Page 24 23 Jun 1997
Keywords marked with a * are REQUIRED when processing a TIC
file. If any of these are missing, the tic file should be
considered as BAD and the associated file not forwarded to downlinks.
Keywords marked with a # are CREATED when hatching or
forwarding.
*# AREA [AreaName]
the TagName of the file area.
AREADESC [description of area] OPTIONAL
a short (80 chars) description of the file area. This
could be the description found in FileBone.NA
*# FILE [File being sent]
the name of the file being sent, no path
the filename must conform to msdos 8.3 format, unless it is
known that the receiving site can handle longer filenames.
^# FULLNAME [original filename before FNC] OPTIONAL FNC
only the original filename (no path) before FileName Conversion
*# CRC [CRC-32 in hex]
crc of the file being sent, 8 hexadecimal characters
^ MAGIC [MagicName] OPTIONAL
Name under which the file can be FREQed from the site
listed in FROM. This is NOT passed though when forwarding,
unless the MAGIC name is the same on the forwarding site. It
can be replaced by the appropriate name.
REPLACES [FileName] OPTIONAL
Filename (no path) of a file hatched in the AREA
that the associated file replaces. If the site expects FNC files,
and the filename does not confrom to msdos 8.3 convention, the
REPLACES name should also be FNC.
# DESC [Description]
Description of the file, limited to 80 characters per line,
including CRLF termination.
If multiple LDESC lines are used, the DESC line must
provide the maximum information. No File Forwadrer is
required to passthough or make use of any extra DESC line
after the first.
# LDESC [multiple lines]
A long description of the file. LDESC does NOT replace
DESC, it is used IN ADDITION to the short description. No File
Forwarder is required make use of LESC lines.
# SIZE [Bytes] OPTIONAL, SHOULD be required
Length of the file in bytes
DATE [TimeDateStamp]
TimeDateStamp of the file. Can be date of creation of
archive.
FIDONEWS 14-25 Page 25 23 Jun 1997
RELEASE [TimeDateStamp]
Date when file is TO BE released. Usually used by SDS, but
can be used by ADS as well.
AUTHOR [name]
Name of the author of the software package being hatched.
This field is obviously not applicable to Newsletters, Nodelists and
Diffs and the like.
SOURCE [authors_address]
FTN address of the Author of the software package being
hatched. Not necessary the same as the ORIGIN hatch site. Does not
have
to be an FTN address.
^ APP [program] [Application Specific Information]
The APP keyword is a keyword known to programs of the
name indicated. APP'S are order dependent and must be passed
though.
*# ORIGIN [Address]
Site where file entered the fileecho
*^# FROM [Address] [Pwd]
Site that is forwarding the file to the next site.
Pwd is optional and rarely used, IF AT ALL. Pwd is NEVER passed
through.
^ TO [Address] OPTIONAL
Site to which this TIC and the assocaited file are being
sent. This keyword is included in the .TIC file when:
a) the file is being routed via another system which
permits such routing.
b) the platform in use does not have any FTN
software independant method of associating a
file and it's destination. eg. platforms that
do not have filenotes that could contain this
information as part of the filesystem.
If the address in the TO line is that of the receiving
site, the field is not passed through when forwarding. If the
address in the TO lines IS NOT that of the receiving site, it
should be forwarded to the TO site, if a routing agreement is in place
with the sending site.
*^# CREATED [by] [Program Banner]
File Forwarder which created the TIC file. This is
generally in the form:
Created [by] program_name version [copyright_info]
VIA [FROM CREATED] OPTIONAL (tracking)
Copy of CREATED line of FROM, with 'Created [by]'
stripped and FROM prepended. Always passed though. The VIA is only
created by the receiving site when forwarding. It is never created
by the hatching site. Therefore, in any TIC file, the addresses
in the FROM and VIA should never be the same.
FIDONEWS 14-25 Page 26 23 Jun 1997
examples:
Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald
Harms (2:281/910)
Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert
Williamson FIDONET#1:167/104.0
*# PATH [Address] [TimeDateStamp] [date and time]
Address of Site which has forwarded the file.
TimeDateStamp, date and time is that of when the Site received and
Processed the file.
* # SEENBY [Address]
Site which has received the file. There are multiple
lines of Seenby and they are unordered.
* PW [password]
Site or Area password. This is case-insensitive and should
be at least 5 characters in length.
PGP [signature]
PrettyGoodPrivacy signature. To be discussed.
^ ReceiptRequest -no data- OPTIONAL
A request to the receiving system to generate a
IsReturnReceipt (attribute word bit 13) messsage, in the same manner
it would if it had received a message with the FileAttach an
ReturnReceipt attributes and a subject of the filename.
There is NO requirement to recognize this keyword. It
should never be passed through.
Transmission of Files:
The associated file, that is, the file Listed in the FILE field
of the TIC file, should always be sent FIRST. In the case of a
failed session, sending the FILE first prevents the orphaning
of the file that is normally caused by the deletion or movement of
the TIC file to BAD.
File Forwarders should not move or delete orphaned TIC files, but
this can neither be relied upon nor mandated.
File Forwaders should be transparent to the renaming of
file by mailers. This means that if the mailer renames a
duplicate file by renaming or bumpinmg a numeric extension, the
File Forwarder should be able to use the size and crc fields of
the TIC to find and properly rename the associated file referred to in
the TIC.
File Forwaders should always delete and dequeue unsent TIC files
when re-hatching the same or updated version of an associated
file. The implementor may wish to allow exceptions for
periodicals such as nodediffs and newsletters.
-to be continued-
-30-
FIDONEWS 14-25 Page 27 23 Jun 1997
-----------------------------------------------------------------
| Document: FSC-0088
| Version: 001
| Date: 31 October, 1995
|
| Robert Williamson FidoNet#1:167/104.0
Compatibility and Link Qualifier Extensions for EMSI Sessions
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Purpose:
The basic purpose of this document is to start discussions which
will hopefully result in an improved handshake negotiation
protocol.
Scope:
Relation of flags to Types of files transferred:
The FSC-0056 EMSI specification (hereafter referred to as
EMSI-I) makes little distinction between ARCmail/packets and
other types of files, such as files attached and TIC'ed files.
In EMSI-I, the term 'Mail' when not used in conjunction with
the term 'compressed', is interpreted to mean ANY file.
This extension (hereafter referred to as EMSI-II) makes
reference to and allows control of types of files in addition to
'compressed mail'. References to 'Mail' are changed to 'File'
where common practice so indicates. The additional qualifier
flags described provide for more control as to the types of files
a system is prepared to receive.
Relation of flags to presented addresses:
The EMSI-I specification does not allow qualification for any
address other than the PRIMARY address. This means that Link
flags are limited in application to either all presented
addresses or to the primary presented address only.
This extension also allows application of Link flags to
specific addresses other than the primary.
Distinctions between Calling and Answering System:
In the EMSI-I spec, the type of flags that may be presented is
limited by the status of the site. Certain flags may only be
presented when the site is the caller and other flags may only
be presented when the site is the answerer. This proposed
extension removes this distinction.
In the EMSI-I spec, certain Link and Capability (a.k.a:
Compatibility) flags are caller-driven, while others are
FIDONEWS 14-25 Page 28 23 Jun 1997
controlled by the answering system. This specification attempts
to harmonize these discrepancies.
A attempt is made to remain somewhat backwards compatible and to
have new flags follow the original flag naming convention.
However, IMHO, it would be preferable to harmonize the flags;
reducing the number of them while retaining the fine type
control, so that the same codes are used in all sessions.
Under both EMSI-I and EMSI-II, any flags that are not
understood, are to be ignored. Therfore, if a site presents
it's flags in EMSI-II format and the other site does not do
EMSI-II, it is permissable for that site to interpret all flags
according to EMSI-I specifications.
Specifics:
Compatibility flags:
Compatibility flags consist of a string of codes that specify
the PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
ARC, XMA
These EMSI-I compatibility flags have no meaning relavant
to the transfer of files and are not to be presented under
EMSI-II. If received, they are to be ignored.
FNC
The FNC EMSI-I compatibility flag has been identified as a
'mistake' by the author of EMSI-I. This is agreeable as that
specification called for the creation of a filename
that was ALWAYS 8.3, not up-to-8.up-to-3. It is not to
be presented under EMSI-II. If received as a compatibility
flag, it is to be ignored.
Protocol Selection:
In the EMSI-I spec, a requirement is placed upon the calling
system to present it's available protocols in order of
preference. A quote follows:
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.
Some mailer authors have interpreted 'the compatibility_codes
field' in the second sentence to mean that of the answering
system, thereby making protocol selection RECEIVER-PREFS driven.
This interpretation makes unnecessary the 'decending order'
requirement placed upon the calling system, so shall be
considered in conflict with that requirement.
Most mailer authors have interpreted that phrase to mean
the 'compatibility_codes field' OF THE CALLER, thereby making
FIDONEWS 14-25 Page 29 23 Jun 1997
protocol selection CALLER-PREFS driven. Since EMSI-I was
intended to be "a clear protocol definition for state-of-the-
art E-Mail systems to follow", they cannot be faulted for
interpretation. Caller-prefs driven selection is state-of-the-
art, receiver-prefs driven selection is older technolgy, such as
Wazoo.
This specification requires that the second
interpretation, CALLER-PREFS driven, be mandatory.
New Compatibilty Flags:
----------------------
EII
Indicates that the system will interpret flags under
this specification, if other end also presents this flag. IF
either or both systems do not present this flag, all
interpretations are done according to EMSI-I.
DFB
Indicates that the system presenting is capabable of fall-
back to FTS1/WAZOO negotiation in the case of failure of EMSI
handshake or no common protocol. Since ZMO is the minimum
required protocol, NCP should only occur if the answering
system presents more than one protocol.. (ie. it's broken)
FRQ
Indicates that the system will accept and process file
requests received during outbound calls. In other words, the
calling system will do a second turnaround for uni-directional
protocols, to send the files requested, at his cost.
NRQ
NRQ should be presented ONLY IF the mailer does not have a file
request server, task or function and cannot accept requests.. It
should NOT be used to indicate that the function is temporarly
disabled.
When examined, No requests will be sent. It would be advisable
that the mailer alert the system operator of this occurance
to prevent continued polling of the remote site.
Protocol Capabilities:
Protocol capability flags are presented in decending
order of preference by the caller. The answering system
selects and presents the FIRST protocol from the callers
list that it supports. The answering system must present only
ONE protocol.
HYD Hydra bi-directional (link flags define parameters)
JAN Janus bi-directional
TZA DirectZap (TrapDoor DirectZap varient)
DZA DirectZap (Zmodem variant, reduced escape set)
ZAP ZedZap (Zmodem variant, upe 8K blocks)
ZMO Zmodem w/1,024 packets (Wazoo ZedZip)
FIDONEWS 14-25 Page 30 23 Jun 1997
SLK SeaLink (no TYSNC, No MDM7, No TeLink)
(8-32k window/ReSync/OverDrive/LongNames)
NCP
This is presented if no compatible protocol can be negotiated
under EMSI. Since in most FTN networks, a common protocol
DOES exist, fallback to WaZoo and FTS1 negotiation is
expected. If these negotiation methods are not available, the
session is terminated.
This condition should never occur under normal
circumstances. It should be considered as a problem with the
design or configuration of one of the mailers involved.
Link flags:
----------
Link flags consist of a string of codes that specify DESIRED
CONNECT CONDITIONS. They apply to the CURRENT SESSION ONLY.
Under EMSI-I, there are four TYPES of link flags: communications
parameters, session parameters, pickup options and hold options.
Under EMSI-II, only three types are used, the communications
parameters type is REMOVED, as it serves no purpose whatsoever in
FTN operations.
Link Session options:
FNC
If either system presents this flag, it is an indication
that the presenting system requires filename conversion
to cp/m-msdos conventions. The other system will convert
filenames to cp/m cpm/msdos 8.3 conventions before sending.
The convention is defined as a filename consisting of
two parts, the filepart and extension. The filepart and
extension are separated by a period ".". The filepart may be
from 1 to 8 characters in length and the extension may be
from 0 to 3 characters. The character set shall be any uppercase
character in the range A-Z and any numeric character in the
range 0-9. If the extension is of zero length, the period may
or may not be present.
RMA
Indicates that the presenting site is able to send and process
multiple file requests. If both sites present this flag, the
caller will send any REQ files found for each AKA presented by the
answering system. The answering system will process each received
REQ.
RH1
Indicates that under the Hydra protocol, batch one contains
file requests only, while batch 2 is reserved for all other files.
(others to be defined)
Pickup and Hold Flags:
Under the EMSI-I specification, Link Pickup flags are only
FIDONEWS 14-25 Page 31 23 Jun 1997
presented when calling (an Outbound Session) and are examined and
processed only when answering (an Inbound Session) and Link
Hold flags are only presented when answering (an Inbound
Session) and are examined and processed only when calling (an
Outbound Session).
With EMSI-II, BOTH Pickup and Hold flags are presented by both
sites during a session. This allows more control for those
systems, for example, which cannot modify addresses presented
or rotate akas to change the primary address presented on a
per-session or per-site basis.
Link Pickup and Hold:
Each system can present one of three (or more) Link options
related to application of addresses. If neither of these flags
are presented, PUA is to be assumed.
Neither PUA nor PUP is to be presented if only one
address was presented.
PUP Pickup FILES for primary address only
/ PUA Pickup FILES for all presented addresses
/ PUn Pickup FILES for address number n in AKA list
one of |
\
\ NPU No FILE pickup desired. (calling system)
HAT Hold all FILES (answering system)
HAn Hold all FILES for address number n in AKA list
Qualifiers:
Qualifiers are processed in the order presented, with any
conflict being resolved by subsequent qualifiers overridding
any conflicting previous qualifier in the list.
Qualifiers may be not be presented with either NPU or HAT and
should be ignored if received with NPU or HAT.
PickUp:
PMO PickUp Mail (ARCmail and Packets) ONLY
PMn PickUp Mail ONLY for address number n in AKA list
NFE No TIC'S, associated files or files
attachs desired
NFn No TIC'S, associated files or file attaches,
for address number n in AKA list
NXP No compressed mail pickup desired
NXn No compressed mail pickup desired,
for address number n in AKA list
NRQ File requests not accepted by caller
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
FIDONEWS 14-25 Page 32 23 Jun 1997
NRn File requests not accepted by caller
for address number n in AKA list
Note that NFE,NPX,NRQ != NPU
Hold:
HNM Hold all traffic EXCEPT Mail (ARCmail and Packets)
HNn Hold all traffic EXCEPT Mail (ARCmail and Packets)
for address number n in AKA list
HXT Hold compressed mail traffic.
HXn Hold compressed mail traffic.
for address number n in AKA list
HFE Hold tic's and associated files
and file attaches other than mail
HFn Hold tic's and associated files
and file attaches other than mail
for address number n in AKA list
HRQ Hold file requests (not processed at this time)
This flag is presented if file request processing
is disabled TEMPORARILY for any reason
HRn Hold file requests (not processed at this time)
for address number n in AKA list
Note that HXT,HRQ,HFE == HAT
-eot-
-30-
-----------------------------------------------------------------
FIDONEWS 14-25 Page 33 23 Jun 1997
=================================================================
ADVERTISE YOUR FREE SERVICE/EVENT
=================================================================
Emanuel Edwards
1:348/963
emanuel@pangea.ca
Hello all Wrestling Fans:
Where else can you find:
All the Latest News, great wrestling scoops and great wrestling
advertisement? You can get it all on the WRESTLING_CHAT. The echo
tag is called WRESTLING_CHAT.
Wrestling Fans in North American and around the world if you want to
hear about all the latest wrestling news and upcoming events this is
the echo to be on. All you sysops request the WRESTLING_CHAT on you
BBS. The Wrestling_chat offer a freedom of speech atmosphere and
there are great wrestling fans on that echo that echo.
Regards
Emanuel Moderator
Barry Laws Jr Co_Moderator
-----------------------------------------------------------------
FIDONEWS 14-25 Page 34 23 Jun 1997
=================================================================
NOTICES
=================================================================
--- Following message extracted from NETMAIL @ 1:18/14 ---
By Christopher Baker on Fri Jun 20 00:18:09 1997
From: Mark Storm @ 1:366/2
To: Christopher Baker @ 1:18/14
Date: 15 Jun 97 12:15:25
Subj: area code changes
* Copied (from: netmail) by Mark Storm using timEd/2 1.10+.
Hello Ken!
effective June 23, 1997 until March 23, 1998 the area codes for the
northwest Florida counties will be in a change mode ... all counties
west of and including Madison and Taylor will change to 850 ... I
getting ready for this change I will be submitting my nets changes
effective 28 June 1997 ...
a listing of the counties effected area as follows:
Escambia
Santa Rosa
Okaloosa
Walton
Holmes
Washington
Bay
Jackson
Calhoun
Gulf
Gadsden
Liberty
Franklin
Wakulla
Leon
Jefferson
Madison
Taylor
A copy of this has been sent to Chris Baker in an improper format for
submission to FidoNews if he feels it is appropriate ... also if you
wish to place it at the bottom of the nodelist feel free ... Mark..
(mstorm@arc.net)
later...
M<ark mstorm@arc.net
-30-
FIDONEWS 14-25 Page 35 23 Jun 1997
-----------------------------------------------------------------
Future History
1 Jul 1997
Canada Day - Happy Birthday Canada.
9 Jul 1997
Independence Day, Argentina.
1 Aug 1997
International FidoNet PENPAL [Echo] meeting in Dijon, France
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.
30 Apr 1998
Queens Day, Holland.
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-25 Page 36 23 Jun 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-25 Page 37 23 Jun 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 13: http://www.smalltalkband.com/st01000.htm
Region 14: http://www.netins.net/showcase/fidonet/
Region 15: http://www.smrtsys.com/region15/ [disappeared?]
Region 16: http://www.tiac.net/users/satins/region16.htm
Region 17: http://www.portal.ca/~awalker/region17.htm
REC17: http://www.westsound.com/ptmudge/
Region 18: http://www.citicom.com/fido.html
Region 19: http://www.compconn.net
============
Zone 2: http://www.z2.fidonet.org
ZEC2: http://fidoftp.paralex.co.uk/zec.htm [shut down?]
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/
FIDONEWS 14-25 Page 38 23 Jun 1997
Region 27: http://telematique.org/ft/r27.htm
Region 29: http://www.rtfm.be/fidonet/ (in French)
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-25 Page 39 23 Jun 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-25 Page 40 23 Jun 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-25 Page 41 23 Jun 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