F I D O N E W S -- Volume 14, Number 13 31 March 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. | +----------------------------------------------------------------------+ THE FIDONET <> INTERNET GATING IS STILL WORKING Table of Contents 1. EDITORIAL ................................................ 1 The uucp Gates STILL work and a NEW Section! ............. 1 2. LETTERS TO THE EDITOR .................................... 2 Letter to the Editor: Comments on Fidonews ............... 2 3. ARTICLES ................................................. 4 Where'd Guucp 1:13/10 go? ................................ 4 AOP Plans Summit '97! .................................... 9 Impressed and Encouraged! ................................ 10 More bugs in MS Internet Explorer & Netscape in Windows .. 13 4. GETTING TECHNICAL ........................................ 18 5. COORDINATORS CORNER ...................................... 34 Nodelist-statistics as seen from Zone-2 for day 087 ...... 34 6. COMIX IN ASCII ........................................... 35 Another Dumb-ASCII Pun ................................... 35 7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 36 Nanet Nodes take note .................................... 36 8. NOTICES .................................................. 37 Future History ........................................... 37 Opus marches on starting 1 May 97! ....................... 38 9. FIDONET SOFTWARE LISTING ................................. 39 Latest Greatest Software Versions ........................ 39 10. FIDONEWS PUBLIC-KEY ..................................... 44 FidoNews PGP public-key listing .......................... 44 11. FIDONET BY INTERNET ..................................... 45 And more! FIDONEWS 14-13 Page 1 31 Mar 1997 ================================================================= EDITORIAL ================================================================= I inadvertently stirred up some panic last week with the news that 1:13/10 was down and the FidoNet - Internet gate was closed. Cancel that panic. [grin] 1:13/10 IS down but I have been informed of hundreds of alternates in action as we read. Burt Juda still operates the FidoNet DNS and although those linked to him for such transfers thru 1:13/10 are now traffickless, those linked to one of the other Gates should still be moving mail. I wouldn't have noticed if I hadn't been a registered user of that particular linkage. There is an article down the pages that applies to the 1:13/10 ops ONLY! It has been updated since it was pre-published in several of the major Sysop Echos. The updated version will likewise appear in those Echos to clear up any excitement and misapprehension. On FidoNews, there is now a Letters to the Editor Section. It is the first Section that appears after the Editorial info areas. There you may rant or rail or wax poetic to me, as Editor, or the rest of FidoNet if you're not in the mood to send your stuff in as an article [.ART]. The new extension for this area is: .LET and the first one appears in today's Issue at the suggestion of that writer. An updated ARTSPEC has already been hatched into the FIDONEWS and SDS SOFTDIST file echos as well as being copied into the FIDONEWS Echo and placed on the FidoNews webpage. [Just happened: The addition of the .LET file extension created a conflict for MAKENEWS so the extension for retractions has just been changed to .RTX and the ARTSPEC doc and .ZIP rehatched.] On another front, any news on the IC election? C.B. ----------------------------------------------------------------- FIDONEWS 14-13 Page 2 31 Mar 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= Letter to the Editor: Comments on Fidonews by Dave Aronson, Sysop of Air 'n Sun, 1:109/120.0 Okay, Chris, you asked a while back for comments on the changes in Fidonews... you got it. Firstly, something I've always disliked about Fidonews. In fact, I have the same bone to pick with lots of shareware authors who do this in their .doc files. This is an electronic publication, so WHY is it formatted for printing ON PAPER? Gimme plain ASCII text, with no formfeeds or page numbering (tho LINE numbering could be useful!) or other junk that's utterly useless for viewing online. Of all such bogosities, especially, NO LEFT MARGINS!!! This thing is being shipped and stored all over the world, plus there are a gazillion trivial little programs out there to *add* a left margin (and even to break into pages and number the pages), so why make us ship and store all that useless empty space? Restricting the RIGHT margin to column 70 is fine --that won't force fugly rewrap on most systems, and gives those who WANT to print it out, some room for a margin. But forcing a LEFT margin on us all??? That might even force fugly rewrap on some BBS systems notorious for not liking text over 72 columns wide.... Secondly, this huge conglomeration of stuff that's essentially the same from week to week. Mostly, that's the lists, like of Fidonet compatible software or of web pages about Fidonet. That could be far more efficiently replaced by a list of CHANGES from last week, and maybe a reference to where we could freq a list. (Yes, FREQ, not ftp, or browse a @#$%^&* web page!) Then there's the boilerplate junk at the end. Come on, do we really need all that every week? Again, just give us the bare bones and tell us how to get the whole megillah. To placate those whining "but freqing is sooooo expensive!", perhaps a "docserver" could be setup, whereby someone would email a given name at a given node, and be emailed back a copy of the document, all of which could take place via cheap netmail routing. The latest version of NetMgr claims to be able to do this, and at the moment, I am trying it; send email to "docserv" (w/o quotes) at 1:109/120.0, with subject line including the word(s) "description", "echolist", "gunflyer", and/or "jewishflyer" (again, w/o quotes), to try it out --it should get you one emailed document back per such message. Thirdly, I dunno about you, but I suspect that the vast majority of even the regular readers have been skipping past the reposted Fidonet Technical Standards. I sure have, aside from an occasional brief skimming of the first couple screens! Stuff like that is why so many call it "da Snooze"! Once again, a summary, plus an announcement of where such things could be freqed or docserved (or, , ftped or browsed) would be a lot more efficient. Perhaps instead if someone who has taken the time to read and understand this stuff could post a brief "review" of each of the standards in turn, including their significance to Fidonet's modern operation, IMHO that could be QUITE FIDONEWS 14-13 Page 3 31 Mar 1997 "newsworthy". Fourthly, I suggest a new "extension", .LET, specifically for "Letters to the Editor". Fifthly... where's all the smart folks, er, articles at? B-) Yeah,I know, I know... some more ASCII art is on the way! ----------------------------------------------------------------- FIDONEWS 14-13 Page 4 31 Mar 1997 ================================================================= ARTICLES ================================================================= [The following is the digest of a conversation between Alan Rackmill and your Editor. He responded to my posting in FIDONEWS Echo asking about the disappearance of 1:13/10 and the fidonet.org Internet Gate. It is published with his permission.] Ed. [This applies to the uucp Gate at 1:13/10 ONLY!! fidonet.org mail IS flowing at other gates according to other sources.] Ed. --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Tue Mar 25 20:38:32 1997 From: Alan Rackmill @ 1:107/101 To: Christopher Baker @ 1:18/14 Date: 25 Mar 97 15:13:10 Subj: FidoNews 1412 is in the can! * Forwarded (from: FIDONEWS) by Alan Rackmill using timEd/2 1.01. * Originally from Alan Rackmill (1:107/101) to Christopher Baker. * Original dated: Mar 25 '97, 14:57 Christopher Baker wrote in a message to All: CB> Where DID Guucp 1:13/10 go and why? CB> Sorry about that. I should have spread the word further than I did. 13/10 as known and loved in the past is dead. During an equipment move, the equipment decided enough was enough and refused to restart when plugged back in. Sort of like a fatal heart attack. At the same time, Burt's personal machine also went south and didn't return. The gateway machine is/was owned by Burt's employer, and the decided to not replace the computer, so 13/10 had nothing to run on. The good news is that we are working on a replacement for the gateway and should have it back up in two or 3 weeks. It will not be physically located where it was, nor will Burt be running it, but it will be the gateway again for internet<>fidonet Email. He is, however, very involved in getting the gateway back in action The usegroups may become available in the future, but that is not certain. I will keep everyone up to date as things develop. FIDONEWS 14-13 Page 5 31 Mar 1997 Alan Team OS/2, Fidonet 1:107/101, ibmNET 40:4371/101, OS2NET 80:135/15 internet: alanrack@ix.netcom.com ___ timEd/2 1.01 - Origin: The Maven's Roost * MAX/2 * WARP * v.34 1-908-821-4533 (1:107/101) --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Tue Mar 25 20:39:04 1997 From: Christopher Baker @ 1:18/14 To: Alan Rackmill @ 1:107/101 Date: 25 Mar 97 19:59:56 Subj: Re: FidoNews 1412 is in the can! > Sorry about that. > I should have spread the word further than I did. are you the Guucp guru now? > 13/10 as known and loved in the past is dead. what happens to fidonet.org mail in the meantime? > During an equipment move, the equipment decided enough was enough > and refused to restart when plugged back in. > Sort of like a fatal heart attack. okay. i've been able to get that much info. > At the same time, Burt's personal machine also went south and didn't > return. conspiracy? [grin] > The gateway machine is/was owned by Burt's employer, and the decided > to not replace the computer, so 13/10 had nothing to run on. been there. > The good news is that we are working on a replacement for the > gateway and should have it back up in two or 3 weeks. and in the meantime? > It will not be physically located where it was, nor will Burt be > running it, but it will be the gateway again for internet<>fidonet > Email. > He is, however, very involved in getting the gateway back in action who is in charge? > The usegroups may become available in the future, but that is not FIDONEWS 14-13 Page 6 31 Mar 1997 > certain. the what? > I will keep everyone up to date as things develop. why you? thanks. can i have this in a FidoNews article after the questions are answered or can i publish the response? QOFM. Chris --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Wed Mar 26 16:21:44 1997 From: Alan Rackmill @ 1:107/101 To: Christopher Baker @ 1:18/14 Date: 25 Mar 97 23:30:21 Subj: FidoNews 1412 is in the can! Christopher Baker wrote in a message to Alan Rackmill: > Sorry about that. > I should have spread the word further than I did. CB> are you the Guucp guru now? No, but Burt called me voice when the crash happened, and I sent out a few messages about it. > 13/10 as known and loved in the past is dead. CB> what happens to fidonet.org mail in the meantime? Unfortunately all mail that went through the gateway is being returned. We are trying to get everything setup so that fidonet.org remains as an entity and get the mail flow back to normal. > During an equipment move, the equipment decided enough was > enough and refused to restart when plugged back in. > Sort of like a fatal heart attack. CB> okay. i've been able to get that much info. > At the same time, Burt's personal machine also went south and didn't > return. CB> conspiracy? [grin] Of course. Or sympathy. ;-)) FIDONEWS 14-13 Page 7 31 Mar 1997 > The gateway machine is/was owned by Burt's employer, and the decided > to not replace the computer, so 13/10 had nothing to run on. CB> been there. > The good news is that we are working on a replacement for the > gateway and should have it back up in two or 3 weeks. CB> and in the meantime? In the meantime, it is like a bridge collapse: nothing gets from one side of the river to the other until the bridge is rebuilt. > It will not be physically located where it was, nor will Burt > be running it, but it will be the gateway again for > internet<>fidonet Email. > He is, however, very involved in getting the gateway back in action CB> who is in charge? Steven Reinen, 107/700 has a dedicated connect to the internet and Burt is working with him to get everything moved over to his system. > I will keep everyone up to date as things develop. CB> why you? Why not? I can get to Burt voice, and I dug up Steven as a replacement for the gateway ** accidently, I must admit ** and I am the new NC here in net 107. And being retired, I have the time to keep up with everything. CB> thanks. can i have this in a FidoNews article after the CB> questions are answered or can i publish the response? You may publish this response, since I am not good at writing "formal" articles. Alan Team OS/2, Fidonet 1:107/101, ibmNET 40:4371/101, OS2NET 80:135/15 internet: alanrack@ix.netcom.com --- timEd/2 1.01 --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Wed Mar 26 16:22:10 1997 From: Christopher Baker @ 1:18/14 To: Alan Rackmill @ 1:107/101 Date: 26 Mar 97 16:16:01 Subj: Re: FidoNews 1412 is in the can! FIDONEWS 14-13 Page 8 31 Mar 1997 > No, but Burt called me voice when the crash happened, and I sent out > a few messages about it. okay. i didn't see any. did you tell ZC1? he was unaware of it until i asked him last week. > Unfortunately all mail that went through the gateway is being > returned. that explains a failure i had last week. > We are trying to get everything setup so that fidonet.org remains as > an entity and get the mail flow back to normal. will Juda maintain that? > In the meantime, it is like a bridge collapse: nothing gets from > one side of the river to the other until the bridge is rebuilt. okay. at least we now know what's going on. > CB> who is in charge? > Steven Reinen, 107/700 has a dedicated connect to the internet and > Burt is working with him to get everything moved over to his system. okay. > Why not? just asking. > I can get to Burt voice, and I dug up Steven as a replacement for > the gateway ** accidently, I must admit ** and I am the new NC here > in net 107. okay. > And being retired, I have the time to keep up with everything. i can relate. > CB> thanks. can i have this in a FidoNews article after the > CB> questions are answered or can i publish the response? > You may publish this response, since I am not good at writing > "formal" articles. thanks. a condensed version of the conversation will appear in FidoNews 1413 next Monday. an Echomail version will appear in FIDONEWS Echo today and will be cross-posted to several major Sysop Echos for information to all in the meantime. QOFM. Chris FIDONEWS 14-13 Page 9 31 Mar 1997 -30- THIS INFORMATION IS CORRECT ONLY AS IT PERTAINS TO THE OPERATIONS OF THE uucp GATE AT 1:13/10. THE EFFECT OF THE DEMISE OF 1:13/10 IS NOT GLOBAL ON THE fidonet.org EMAIL MOVEMENT AT THE OTHER GATES. There are hundreds of other gates linked to the FidoNet DNS that are still functioning without ever having stalled. Burt Juda IS the DNS guru with or without the presence of 1:13/10 at present. My apologies for any undue panic amongst the users of the Internet gates this discussion of 1:13/10 may have caused. Ed. ----------------------------------------------------------------- Submitted by Michele Stewart 1:369/21 Online Summit '97 The AOP 2nd Annual Conference Planned for September 11-14, Online Summit '97 will be held at the Town & Country Resort and Conference Center in San Diego, CA. Senator Ron Wyden (D-OR), the keynote speaker for Online Summit '97 will address Congress' role in the future of the online world and the internet. We are anticipating approximately 500 members to OS'97. Cost for the event is: AOP Members Non AOP-Member Before August 1, 1997 $200 $350 After August 1, 1997 $300 $450 AOP Online Summit '97 Exhibition Rates: AOP Members Non-AOP Members 10' x 10' booths only $250 $1,000 AOP Online Summit Hotel Information and Rates: Garden Rooms $95 East Tower Rooms $105 West Tower Rooms $115 (prices are for single or double occupancy) For room reservations call: Town & Country Resort and Conference Center 500 Hotel Circle San Diego, CA 92108 (800) 542-6082 (inside CA) FIDONEWS 14-13 Page 10 31 Mar 1997 (800) 854-2608 (outside CA) FAX: (619) 291-3584 960 rooms, in-room movies, beauty salon, barber shop, access to Health club, complimentary newspapers 6 days, walk to Fashion Valley shopping. For Conference Registration or information contact: Susan Merkel, Director Member Services ASSOCIATION OF ONLINE PROFESSIONALS 6096 Franconia Road, Suite D Alexandria, VA 22310 703-924-5800 (voice) 703-924-5801 (fax) smerkel@bellatlantic.net (email) Fidonet: 1:109/255 ----------------------------------------------------------------- Impressed and Encouraged! By: Clay Tannacore (1:372/136) I have just recently completed reading FIDONEWS (1412), dated 24 March 97. In a guest editorial by a FidoNet SysOp named Carl Hultay (1:259/546) I believe I detected the traits of the old "comrade in arms" attitude that at one time was prevalent in the FidoNet community. It is possible that I misunderstood his rationalization, but I don't think so. I positively think I have found someone within the association that literally cares about the imminent problems of FidoNet. While I can not agree with his introspection regarding the forecast for FidoNet, I applaud his tenacity. It is heart warming to hear (read) a fellow Fido-Nut (OOPS) SysOp, at least proclaim his convictions as to the forthcoming future of our brotherhood. I can relate to his predicaments concerning the "death of hardware", and the instinctive feeling of doom, when you are faced with the loss of a BBS. I (like many thousands before me) have had to endure similar conditions, on a number of occasions. I sympathize with him regarding the loss of users, especially due to financial obstacles, and especially due to the death of a family member (the computer, and accessories. . .[g] ) However, what disturbs me the most, is his reference to the "loss of users." For this gentleman to believe that he will again be able to boast of a user base near one thousand (or maybe more) without admitting that MANY radical changes will have to be contrived in the way FidoNet is operated, is a very discouraging supposition. At present there are just to many opposing forces in FidoNet, for a restoration to a position once held by this organization. To many "I want" attitudes , as well as to many "I gotta' have more power" points of view. Nothing will ever be the same, not in FidoNet's present mode. Mr. Hultay speaks of the "commercialism" associated with The Internet. What he has apparently dismissed in his attempt to disallow the thought of a FidoNet "doomsday", is that FidoNet is no longer an FIDONEWS 14-13 Page 11 31 Mar 1997 association completely dominated by hobbyist, but has partially fallen into The Internet like, "Profit For Me" temperament. Many, many bulletin boards systems are at the present time directly competitive with the Internet, in that they conclude that a "pay-for- use" system is the way to go. "If the Internet can do it, then so can I" is something that has become an everyday behavior, a behavior which if it is not discontinued, will eventually bring down FidoNet. Mr. Hultay goes on to explain his feelings when his computer (hard drive) developed a *brain fart*, and pooped out. He states that it was at that this in his life that, "I knew that I was a true SysOp. I could not give up. I *WANTED* my BBS." Mister, if that was your *TRUE* sentiment at the time. I SALUTE YOU! However, I believe my old professor (psychology 101) might take exception to that. I tend to believe he would more than likely classify you as (in direct English) a Hilter-like-wannabe. . .[g] Of course, you have to take into consideration that Professor Freedmen, pulled a Dr. Jack, and blew his own brains out about 10 years ago! Another predominate trait that FidoNet SysOps seem to have acquired over the last eight or ten years is the *power for me* temperament. For some reason there seems to be a growing number of SysOps that feel compelled to attain as much power, or influence (ability to intimidate) as possible over their users. Why? I have no idea, except to say what everyone else who has studied this formidable swing in human nature says, that it is a "sign of our times." Of course, this is probably of bunch of horse hockey! Whatever the reason, it is not exclusive of SysOps alone within the FidoNet community. We have an abundance of Network Coordinators with the same, or like, philosophy, not to leave out a number of Regional Coordinators who have become "Hooked On Power", and they think it "Works For Them." Consequently we have a network that will become a little known fleck in history, if "we" do not recognize the problems, and do something about it. Brothers, I beseech you to take a very close look at FidoNet as it is today. Then try to visualize it five or ten years from now. Look into the prospective for FidoNet, if present conditions prevail, and try to visualize it with all these problems confronted, and corrected. I'll tell you right now, I can see a FidoNet similar to the early years, when Tom Jennings and a few more (caring and dedicated) people produced a telecommunications system unequaled from its conception to the present day. The Internet you say is bigger and has many more features. Maybe! Just keep in mind the *GRANDFATHER* who led the way for The Internet, and is still *BIGGER* than that inception. FidoNet was the trailblazer for all the nets which subsequently evolved from it, and with the dedication of those who care about it. It will be again! We can not allow the "me first" people who care for nothing but their own personal gratification to prevail. We can not tolerate those who would bring nothing but hopelessness within the net, to remain. These people *must* be identified by those who care, and be weeded out. By now, most of you people are sick and tired of hearing (reading) me complain about what is faulty with FidoNet. Some would even like to *see* me get off the pot, and make some useful suggestions for the betterment of it. So would I! I could sit hear on my duff, day in and day out spreading my philosophy and criticisms. Chastising the FIDONEWS 14-13 Page 12 31 Mar 1997 *C structure, the SysOps, and most of all, that piece of garbage that is referred to as POLICY 4. I could do all that, and never add to the prosperousness of the Net. The trouble is, *I* could do all these things, but nothing would be gained. NOTHING at all! Nothing that is, without *Y*O*U* making a contribution. I (we) need input of everyone who cares one tiny bit about the future of our association. You (the members) SysOps out there who have been sitting on your opinions, for all these many years, and you Regional Coordinators who *have* opinions for your regions upward movement. The Network Coordinators, who *know* what is wrong within their individual regions, but are to damned worried about their positions as NC to voice those conceptions for fear of retaliation. Those users out there who read FIDONEWS, who would like to be a part of FidoNet, but because of the antiquated rules, procedures and the general *cut throat* mentality that is so obviously prevalent, have been reluctant to join. Now is the time to voice your opinions. Join in this endeavor with those who truly care. Let your voice be heard, by those who must *listen* if FidoNet is to have a reincarnation. Remember, there is safety in numbers, and more importantly, a greater pool of intellect to draw upon. With many voices, there comes many suggestions, and with those many suggestions comes many intelligent and significant recommendations which leads to a aggrandized membership, and a more equable association. If anyone out there has any hesitancy in believing that I intend to accelerate the demise of those who have been responsible for the shortcomings of FidoNet, let them be assured I fully intend to raise enough hell to either cause sufficient change in the way FidoNet operates, or find myself without a node number, again. If there are any inhabitants out there who consider themselves *real* FidoNet people, and would like to join in this crusade, by all means send me some mail (FidoNet, not Internet [gag]) with your suggestions. I am particularly interested in those who have suggestions pertaining to a *NEW* POLICY document. Those who have any complaints about the monitory provisos dictated by EchoMail Coordinators. Anyone who is infuriated with the multitude of Bulletin Boards (BBS) which indulge in the practice of charging users for access. Anyone who has ever had (what you consider) an unfair decision rendered by your NC, or RC, or both, let me know. Let *us* right a wrong that has been going on much to long. Do you have any suggestions concerning the EchoMail Policies in the different Nets you have been associated with? How about a *REAL* EchoMail POLICY for FidoNet, itself? Any ideas on how to better the present procedures or policies? Do you know of any person who is a part of the *C structure of FidoNet (also including SysOps) who have allowed his/her personal opinion of you (or someone else) to influence a rendering of a fair and impartial decision? Have you (or anyone you know) ever been denied a reasonable appeal process by anyone in the position to deny it (NC, RC, SysOp, ZC, et al). These are all questions that must be taken under consideration when attempting to reestablish a network such as FidoNet. I realize with all the criticism I have expressed in this wonderful outlet (FIDONEWS - Thanks, Chris Baker) concerning FidoNet. I have irritated the hell out of the *good-old-boy-network* who in all likelihood will now attempt the FidoNetSqueeze. It may even work! FIDONEWS 14-13 Page 13 31 Mar 1997 But, who cares? I've said my piece, expressed my opinions, got others to take a closer look at what is going on. I have actually received a few positive responses to the articles printed in FIDONEWS, shocking isn't it? Look folks, I'm not the only one with the desire to better this organization, there are many out there who would like to be proud of FidoNet, again. Perhaps some of these people are worried about what sort of retribution would be forthcoming if they were to speak out, or maybe they are just being a little overly circumspect than is absolutely necessary. Or perhaps their reluctance is justified in light of what has been a trend in FidoNet, of late. Whatever the reason, I believe this open challenge and solicitation for help, just may instigate these people to finally stand up and have their convictions noted. ----------------------------------------------------------------- From: "Mike Riddle" To: "Baker, Christopher" Date: Tue, 25 Mar 97 08:20:52 -0600 Reply-To: "Mike Riddle" Subject: Fwd: Warning: Latest Win95, Win97 & NT Browser/Networking Security ==================BEGIN FORWARDED MESSAGE================== Received: from austin.onu.edu (austin.onu.edu [140.228.10.1]) by monarch.papillion.ne.us (8.7.4/8.6.9) with ESMTP id BAA13578 for ; Tue, 25 Mar 1997 01:37:15 -0600 (CST) >Received: from austin.onu.edu (localhost.onu.edu [127.0.0.1]) by austin.onu.edu (8.8.5/8.8.5) with SMTP id CAA35433 for ; Tue, 25 Mar 1997 02:34:14 -0500 Date: Tue, 25 Mar 1997 02:34:14 -0500 Errors-To: david@drw.onu.edu Reply-To: network2d-l@austin.onu.edu Originator: network2d-l@austin.onu.edu Sender: network2d-l@austin.onu.edu From: Jeff Beard To: mriddle@monarch.papillion.ne.us Subject: Warning: Latest Win95, Win97 & NT Browser/Networking Security These security bugs are really starting to bug me -- seriously! IMHO, this one is very disturbing, as it has the very definite potential to compromise security for an entire network. I do apologize in advance that this message is lengthy, because it requires some technical explanation of what SMB is, and how it relates to the latest (and perhaps greatest) security problem. I also included the Wired news site article (at the bottom of this message) that explains it in plainer language. THE SECURITY PROBLEM: If you are running either Win95, Win97, or NT, and use either MS IE 3.xx, Netscape 3.xx, or Netscape Communicator 4.0, there is now yet another bug (a whopping SIX security bugs for IE this month! and I think the second one for Netscape) THAT WILL SEND OUT YOUR WINDOWS LOGIN NAME AND PASSWORD TO A REMOTE SERVER which can FIDONEWS 14-13 Page 14 31 Mar 1997 capture it! And for most network users, their Windows login name and password are also their network login name and password, which of course puts the entire network at risk for break-ins. For example, a person's Win95 login name and password is often the same for their Novell Netware and MS Windows NT server. Cute, huh? First, let me explain briefly what the SMB protocol is, because it is key to the security flaw -- then the rest of the message will make more sense. I compiled the following information from several web sites that did a good job of describing it: It has to do with embedding a link (e.g., an image link) in the web page to an SMB server rather than the normal HTTP server. SMB, which stands for Server Message Block, is a protocol for sharing files, printers, serial ports, and communications abstractions such as named pipes and mail slots between computers. It is a higher level protocol which can be transported over TCP/IP, NetBEUI and IPX/SPX. If TCP/IP or NetBEUI is in use, then the NetBIOS API is being used. If SMB is used over TCP/IP or NetBEUI, then NetBIOS names must be used in a number of cases. NetBIOS names are usually the name of the computer that is running NetBIOS. (In many instances, the computer names are referenced by the "\\" prefix to designate a different computer on the network -- this is an important aspect of the security flaw -- read on.) For more info about SMB and its security problems, you can go to: http://samba.anu.edu.au/cifs/docs/what-is-smb.html (Describes SMB) http://www.sur.fr.net/ftp/supports/96/netbios-3.html (re: Security Problems) (I'm sure there are a lot of other great SMB sites too, but these were among the first two I found using Alta-Vista when researching this.) Okay, enough of the SMB explanations. Now that you know what SMB is, here's how the security flaw/bug works: In a web page, the webmaster can insert a link reference uses a combination of the "file://" URL command followed by the "\\" reference that Win 95, 97, and NT use to refer to and access other servers (as I mentioned above). Then, because your browser sees this link (e.g., an image tag) as a reference to a different server (the SMB server), Win95, 97 & NT automatically send your Windows login name and password to the remote server to log in (the "\\" makes it think that the other PC is part of its network), ALL BEHIND THE SCENES, so the user has no idea whatsoever that this is happening!!! Basically the guy discovered this security flaw by combining different things that were in the previous IE bug reports this month -- very clever. The article below tells network administrators how to block this on their firewall setup, to block access to the SMB server. It appears that the rest of us using Win 95, 97 and NT are just out of luck for now. The article posted at the end of this message is from the Wired news site, at: FIDONEWS 14-13 Page 15 31 Mar 1997 http://www.wired.com/news/technology/story/2702.html The web site referred to in the article is authored by the guy who discovered the bug, and gives a lot more info about it, as well as demonstrating the bug in real time to you. WARNING!!! IF YOU GO TO THE FOLLOWING WEB SITE USING WIN95, 97, OR NT, IT *WILL* MOST LIKELY CAPTURE YOUR LOGIN NAME AND PASSWORD, AND THE SITE POSTS A TABLE SHOWING THE LAST 10 CAPTURED LOGIN NAMES, PASSWORDS (but only shows the beginning of the password for your protection), HOST NAME AND IP ADDRESS, SO YOU CAN SEE IF YOU ARE VULNERABLE, AND THEN TELLS YOU TO CHANGE YOUR LOGIN AND PASSWORD ASAP TO PROTECT YOURSELF! I used my standalone Win 3.1 laptop with no problem (hey, right now Win 3.1 apps are more secure on the Net, IMHO -- so don't knock it ). BTW, the "bug" web site mentions that "Notice that the most common account & password I get is 'Administrator' ". So it's capturing administrator logins and passwords as network administrators hear about the bug and visit his site -- full access, good grief. If any of you would like to read the full text from the site without going there, send me an e-mail and I will send it to you, since my Win 3.1 laptop system does not support that security flaw. The URL for the bug site, if you are curious, is (but remember my WARNING!): http://www.ee.washington.edu/computing/iebug/ (The following URL is okay to go to:) http://www.wired.com/news/technology/story/2702.html Another Windows Networking Bug Discovered by Toxic 11:56am 21.Mar.97.PST Yet another security-related browser bug has been uncovered, the sixth to affect Microsoft Internet Explorer this month. This latest bug, in the file sharing protocol of both Windows 95 and Windows NT, allows someone to set up a rogue Web site that obtains your username and Windows network password. Windows NT users of all versions of Microsoft Internet Explorer and many versions of Netscape are vulnerable to this attack - which is not addressed by Microsoft's 12 March browser fix. As with the rash of recent Internet Explorer security bugs and holes, Aaron Spangler, the bug's discoverer, has created a Web page to demonstrate the vulnerability. "My bug is twofold," said Spangler, a systems administrator at the University of Washington. "It takes advantage of two exploits. The elegance lies in putting the two together to come up with grabbing people's passwords. That's a pretty scary thing," he said. Spangler has captured more than 940 passwords, many from administrator accounts using weak passwords such as "horse" and "dog." Spangler said both bugs have affected IE for some time. He first tried contacting both Microsoft and Netscape on 13 March, and created his Web page the next day. He says he received a note from FIDONEWS 14-13 Page 16 31 Mar 1997 Microsoft saying that they were working on the bug. "But every time I send any more email they don't respond," he says. "They're completely ignoring me. It's frustrating." Netscape sent an auto-generated response to his email, but has not contacted him since, he said. The attack relies on the file structure of the Windows operating system, and the behavior of a browser when it encounters a URL that begins with the "file://" scheme. When Windows sees a file: URL, it attempts to read the specified file from the user's local hard disk. For example, file://C:\temp\foo.html will open C:\temp\foo.html from your local hard drive. However, the Windows file system is designed such that filenames that begin with a double backslash actually reside on another machine. If you take these two factors and combine them, you realize that the file in the example above could also be referenced as a URL, as in file://\\bar.wired.com\temp\foo.html. When a user attempts to access a file through this method, his Windows machine will connect to the specified server - bar.wired.com in the above example. The server will then attempt to authenticate the user by asking for a username and password. Windows will automatically send the information entered by a user when they logged into their own Windows network, which is what most users do when they first boot their machine. Windows will only prompt the user for a password if the values entered at startup are not accepted by the remote server. Spangler's demo page contains an "" tag that references an image stored on his SMB server instead of his Web server. When you load his page, your browser will attempt to load the image. It will connect to Spangler's Windows file server, and when requested, automatically send your username and password. You will receive the image, and Spangler will receive your password. Everything appears perfectly normal to the Web surfer. Spangler says the fix is really trivial. "All [Netscape and Microsoft] have to do is make it so their Web browser will not accept URLs that come from an SMB server. It's a little statement that they can put in their code," he said. Network administrators can protect users on their network by blocking TCP port 139 on their outgoing firewall (port 139 is the SMB port). An outgoing firewall configured in this manner will not allow traffic from a protected network to reach port 139 of any machine on an outside, untrusted network, and will thus thwart this kind of attack. "Microsoft is checking into all bug reports and taking them very seriously," said a Microsoft spokesperson. "If it is something [engineers] need to change, they will do something about it." Netscape could not be reached for comment. ______________________________________________________________ FIDONEWS 14-13 Page 17 31 Mar 1997 Good grief!!! Now we have to stand in line to report browser/OS security flaws! John L., I think this is a pretty good illustration of our discussion re: increasingly serious security flaws, don't you? Jeff _____________________________________________ Jeffrey J. Beard, Esq. Legal Systems Consultant MicroLaw, Inc., Milwaukee, WI E-mail: jbeard@microlaw.com Web Site: http://www.microlaw.com _____________________________________________ ===================END FORWARDED MESSAGE=================== ----------------------------------------------------------------- FIDONEWS 14-13 Page 18 31 Mar 1997 ================================================================= GETTING TECHNICAL ================================================================= FSC-0054 - The CHARSET Proposal [This is part of a continuing series of FTSC docs republished as part of FidoNet History. It has been reformatted to 70 columns where required.] Ed. Document: FSC-0054 Version: 004 Date: 27-May-1991 The CHARSET Proposal A System-Independent Way of Transferring Special Characters, Character Sets and Style Information in FIDO Messages. Fourth Release Duncan McNutt 2:243/100@fidonet Status of this document: This is a finished specification, it is used in several FIDO products. This FSC suggests a protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unrestricted. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Contents: --------- Purpose History Pros & Cons The Present System The Proposed System Technical Details Examples Summary Implementation Sample Purpose: -------- This document is a proposal for a FIDO standard. This document describes a method of allowing international and other non-standard ASCII characters to be transferred via a network and FIDONEWS 14-13 Page 19 31 Mar 1997 interpreted by the receiving systems. It also allows for expansion to multiple character sets and character sets that require more than one byte storage space per character. Further the capability to include style and font changes are part of this proposal. This proposal is based on the ISO standard character sets. It defines a mechanism to switch between all of the defined ISO sets. Further it defines switches that allow style and font changes. The FSC-0054 standard also coexists with the extensions of the ISO LATIN-1 characters set as defined in FSC-0051. FSC-0054 and FSC-0054 use the same identifier (CHRS: LATIN-1 2) to indicate the LATIN-1 character set. FSC-0051 (draft 3 and above) defines the codes unused in LATIN-1 for additional characters. At present these are the numeric super and subscripts as well as Polish characters. History ------- All in all the author is aware of 6 initial proposals for including additional characters in FIDO messages, most of them did not get the critical mass to achieve widespread use. Three of them actually managed to get FSC numbers. FSC-0054 and FSC-0051 effectively merged as of this document. FSC-0054 is backwardly compatible to FSC-0050. Another standard that was used in Denmark is no longer in discussion. The initial proposal was FSC-0050. It had several drawbacks, most notably it was too limiting and it was based around a particular hardware platform. Because of its implementation in Opus, FSC-0054 tries to recognize the messages produced by that system. There are several incompatible "flavors" of FSC-0050 floating around, so FSC- 0054 can not always produce perfect results when translating FSC-0050 messages. Implementations that allow for FSC-0050 can use the same code for FSC-0054 but may need to generate different kludges and will need to be expanded a to make full use of the extra features. A second proposal FSC-0051 had the advantage of hardware independence but lacked (on its own) expandability as it only allows for roman characters (ie: western languages). Because the FSC-0051 and FSC-0054 methods both contain the LATIN-1 character set as the base set for western countries the authors agreed on a common identifier to allow the two systems to coexist. FSC-0051 allows you to add Polish characters to the Latin-1 character set without necessitating compliance to FSC-0054 Level 3. FSC-0051 is mainly used in Sweden. The system described in this document gives the maximum in capability without breaking the FIDO message format. It allows hardware independence and internationalization of FIDO software. To further enhance the capabilities of FIDO beyond what is described here a new message document format must be defined. The author suggests this be done in connection with a type-3 format and that the Open Document Architecture (ODA) be included as the standard for that format. ODA is the agreed standard for commercial mail systems and is being implemented by X.400 messaging systems. Conformance to that standard would allow transfer between FIDO and other nets without translation. ODA contains formatted text as well as graphics and FIDONEWS 14-13 Page 20 31 Mar 1997 sound. Pros and Cons: -------------- Any form of non standard ASCII extension to the present messages must respect the following criteria. It should: o be simple o be backwards compatible o be expandable o be transparent o allow for multiple levels of support o allow for translation to the least common denominator Earlier proposals had several problems: 1) They inserted non ASCII characters in the PRESENT stream of messages. 2) They did not allow for an easy to read "standard ASCII" represen- tation on areas that do not support their special encoding scheme. 3) They increased the size of messages by a larger amount than is necessary. 4) They were hardware dependant. 5) The implementation sample were too slow to be effective (a minor point). 6) They limited the possibilities. They only allowed for a limited amount of graphic or other special purpose characters. They did not allow for character sets that require storage space that are larger than one byte per character. They were not expandable. The advantages of the system proposed here are: It does not have any of the failings of the prior systems (points 1- 5). 1) It does not insert any non ASCII characters in the present stream of messages. 2) It allows for an easy to read standard ASCII representation. 3) It does not increase message size. It only includes the charset kludge in messages that use non-ascii characters (e.g.: Kanji). 4) The presented algorithm is efficient. 5) The presented algorithm is efficient. FIDONEWS 14-13 Page 21 31 Mar 1997 6) It support ALL international characters as well as graphic and other special characters. It allows for character sets that require storage space that is greater than one byte per character. It allows for future expansion. 7) It allows for a simple method of converting non-standard characters to standard ASCII in present systems. 8) It allows for character set coherence in message areas without double processing. 9) It allows multiple levels of compliance. 10) It concerns itself with gateway filtering of messages. 11) The implementation allows non "charset kludge" aware programs to display and edit messages. 12) It concerns itself with network representation as well as local storage. The present system: ------------------- The present system "normally" only uses standard ASCII, unless an echomail conference moderator explicitly allows non ASCII characters. If a user does not conform to this and writes non standard ASCII in a message, then other users with different systems get garbage on their screens. This can be (and in some areas is) a major problem. At present there is no way to display non Roman characters in FIDO messages. The proposed system: -------------------- The proposed system will be able to help with messages that do NOT have the CHARSET kludge in them on an area by area basis. However manual intervention by the user will allow it to translate the alien codes to the local ASCII extensions. It will also allow editors to more easily make standard ASCII representations of extended character sets. Which hopefully will make more users conform to standard ASCII. For messages with the charset kludge the method described below allows using extended character sets. There are multiple levels of support: Level 0: STANDARD message (no charset kludge). This method adds an option to convert non standard ASCII to ASCII. Level 0 is straight forward: don't change anything, except remapping non standard ASCII to ASCII. This should be the initial default for any CHARSET message writer. Level 1: INTERNATIONALIZATION, accents and other language specific FIDONEWS 14-13 Page 22 31 Mar 1997 characters are supported. This is needed for echomail areas that go through gateways to other systems that have a limited character set. Level 1 can be supported by ALL types of computers! It translates the standard US ASCII codes to the foreign ISO codes and back. Most software only needs to READ this type of message. This is easily done with the sample implementation that is available via SDS. Most software should directly support level 2. Level 2: Support for Level 1 plus EXTENDED CHARACTERS, included are graphic characters and special characters from other character sets such as Greek (for mathematical discussions for example). This is intended to allow the different personal computer, workstation, mini and mainframe users to converse in text mode. The default for level 2 messages should be the LATIN-1 character set. It is still compatible with the present stream of messages. This is the most common level of support for most software. It is also what the sample implementation concerns itself with most. Level 3: Support for MULTIPLE CHARACTER SETS. This requires a greater effort in implementation. Level 3 is (of course) not backwards compatible. It is easiest to support level 3 if you use a pixel based display, it is probably not worth implementing on a text only display. For example: if you have an X-Windows, Microsoft Windows, Macintosh or similar display then you should have no trouble implementing level 3. Level 4: Support for 16 BIT CHARACTER SETS. Software authors that support products that are intended for use in Asia should concern themselves with this specification. The implementation algorithm which has been developed is a pop-in module that allows present message editor/display programs to offer Level 2 support for the 5 most popular systems (ASCII, IBM, APPLE, ISO Latin-1, VT100). The Atari now uses the IBM character set, the Amiga and the VT200 displays use the ISO Latin-1 (ISO 8859-1) character set. This implementation is also usable as a filter for fast translation of messages in gateway software or for a packet translator. See the notes at the end of this document for further details. Levels 1 & 2: Levels 1 and 2 are based on a remapping system. The following must be supported: o Level 1: remapping of non standard ASCII foreign characters, remaps characters that are less than decimal 128. FIDONEWS 14-13 Page 23 31 Mar 1997 o Level 2: additional remapping of special characters and graphic characters, remaps characters over decimal 127 (i.e.: characters with the most significant bit set). o [optional] a style mechanism (bold, underline...) o [optional] font switching (times, helvetica...) Characters below decimal 32 are reserved for special use (e.g.: the SOH character is used for message kludges). Note: Basically a lot of international message areas contain a certain amount of messages with international characters. These characters have the same codes on all systems, they are most likely known to you through your printer manual, VT100 foreign symbols, or as IBM codepages. The only reason these codes are not displayed correctly is that your message reader can not know which of these character sets is used. Levels 1 and 2 will mark the message with an ID that will let your message reader change the environment in such a way that the characters are displayed correctly. The style mechanism and the font switching are fully transparent and backwards compatible. Style changes are easy to support, even VT100 and Hercules (on IBM-PCs) displays support underline and boldfaced characters. Remapping of foreign codes may take one of two forms selected by the user: 1) remap to character set supported by this system 2) remap to ASCII Level 1 remaps 98% on all systems, Level 2 remaps with a "best match" algorithm. It may be that results are not perfect but they should be recognizable. See the Technical Description below for some examples. Levels 3 & 4: Levels 3 and 4 require additional support that is non trivial. However, it is not as complicated as it might seem at first. The following must be supported: o a character set switching mechanism, o multiple character sets (Roman, Greek, Cyrillic...), o character set remapping (fairly simple), o [optional] transliteration (not simple), Transliteration (converting words and symbols to another representa- tion or language) is an optional feature that is supported by some operating systems (OS/2 and Macintosh as well as some UNIX systems). Transliteration is not really part of this proposed standard but is mentioned to bring the technical possibility to mind. If your operating system supports it then transliteration is usually just a simple function call, if it doesn't then forget it. Levels 5 & 6: FIDONEWS 14-13 Page 24 31 Mar 1997 Do not exist and are not (presently) proposed. I was thinking about B&W bitmaps for level 5 and color graphics for level 6, however that is not suitable for Fido messages until ISDN becomes the standard medium of transport. The physical (not logical) limit of 25000 bps on regular telephone systems is just not fast enough to allow the cost effective transfer of such large data amounts for a privately operating individual. Even supposing a 10 to 1 compression of graphics, would not be nearly enough (color pictures could still easily be larger than 2 megabytes). Technical Description --------------------- This description gives a complete specification of levels 0 through 4. If you have needs that go beyond the specification of levels 3 and 4 as they are put forward here then please write the author. As mentioned before the proposed method for levels 0 through 2 relies on remapping. Remapping is fairly straight forward on almost all hardware plat- forms. It is easiest on graphically oriented systems such as the UNIX X-Windows, Apple machines, Commodore Amiga, Atari ST and IBM Presentation Manager or Windows systems. But even on text only displays such as IBM DOS, VT100 and Commodore 64 machines the most used characters are fairly easily available. Helpful in this endeavor is that the foreign characters and additional special characters are often the same on different hardware platforms, even if they do not have the same ordinal value. Examples are the ISO characters such as the English pound symbol and other common symbols such as the international quotes ("<<" and ">>") or the Yen symbol. The proposed remapper remaps non standard ASCII characters to the character set options of the present system. Remapping may be one character to one character, one character to two characters or one character to multiple characters. The latter requires extra implementation effort. Example: The uppercase "A" with the accent grave "`" above it, will remap on all systems that support at least the ISO foreign characters or similar character sets. It will remap to the uppercase "A" in standard ASCII. The user could be allowed the option to view an approximation of the original by displaying the "A" followed by the "`", but this choice is left to the implementor. The following two kludges are proposed ( and ). The kludge syntax is described in BNF below, comments are in curly brackets, terminal symbols are in double quotes. Case is important. ::= "^aCHARSET:" | "^aCHRS:" FSC-0054 only writes the CHRS kludge, but for backwards compatibility with older methods allows CHARSET as a valid kludge. FIDONEWS 14-13 Page 25 31 Mar 1997 Note: up to the end of the charset kludge, all characters must be standard ASCII. Keywords are in English. ::= "1" | "2" |