Subject: RISKS DIGEST 16.61 REPLY-TO: risks@csl.sri.com Errors-To: risks-request@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 6 December 1994 Volume 16 : Issue 61 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** ***** NOTE, SRI RISKS ARCHIVE SOURCE IS MOVING SOON TO ANOTHER HOST. ***** Contents: Lots of Turkeys (Debora Weber-Wulff) Fun with your phone company (Russell Stewart) Pentium + Spell-Checkers (Paul Fuqua) Pentium FDIV bug (A. Padgett Peterson) Re: Interesting product claim (Mathew Lodge) Virus alert virus alert (Yehuda Berlinger) Re: Mailing list problems... (Errors-To) (David Barr) Mailing-list deadman switch (Steve Losen) "Applied Cryptography" by Schneier (Rob Slade) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 6 Dec 1994 12:01:44 GMT From: weberwu@tfh-berlin.de (Debora Weber-Wulff) Subject: Lots of Turkeys The "Stars and Stripes" (a "small-town" newspaper in English for the military communities in Europe, to which I am also allowed to subscribe in order to read the comics every day...) reports that the payments for the civilian employees in Germany this month were credited to the accounts of the employees twice. Seems that the payroll tape is usually run on the 24th of a month. Someone bright noticed that the 24th is turkey day, and ran the tape on the 23rd. Some other bright person also ran the tape on the 25th since the 24th was a holiday.... Suddenly they noticed that there were about 3.5 million dollars missing (good thing they have a bookkeeping system!). The "turkeys" spent most of Saturday fussing with the system and rolling back the second set of transactions. It is reported that the civilians are hoping for another such windfall at Christmas... Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, 13353 Berlin, Germany weberwu@tfh-berlin.de [Beware of Tur[n]key systems. They can gobble up lots of money. PGN] ------------------------------ Date: Tue, 06 Dec 1994 14:43:08 -0500 From: diamond@RT66.com (Russell Stewart) Subject: Fun with your phone company [foreshortened by PGN] [Russell submitted a longish item on how his phone company cleared a check of his for $150, but did not credit his account. To make a long story short, he had changed his address and phone number from his parents' home, and the $150 was credited to his OLD phone number, which was the number that appeared on his check. His father did not notice the credit on the home account. Apparently his phone company ignores the number on the bill! GROAN. PGN] In other words, that little portion of the bill that you tear off and put in the envelope with your payment is completely useless, because they only check the phone number ON THE CHECK ITSELF. I don't know how many phone companies use this type of a system, but let this serve as a warning to anyone who has recently changed address... Russell Stewart Albuquerque, New Mexico diamond@rt66.com ------------------------------ Date: Tue, 6 Dec 94 11:40:37 CST From: Paul Fuqua Subject: Pentium + Spell-Checkers On December 5, the {Dallas Morning News}, not the most technically-aware newspaper in the world, ran an article from the {San Jose Mercury News} about the recent Pentium FDIV situation. Unfortunately, they ran it through a spell-checker first. The company names "Intel" and "Megatest" became "Until" and "Megadeath," which actually puts an interesting slant on the story. I've only ever seen one writer's byline on computer-related articles in the DMN, so the root problem may be that no one else at the paper knows enough to catch this obvious (to us) error. Paul Fuqua Texas Instruments, Dallas, Texas pf@hc.ti.com [Until Megadeath Do It Part. PGN] ------------------------------ Date: Thu, 1 Dec 94 08:01:42 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Pentium FDIV bug Interlocutor: Why did they call it "Pentium"? Mr. Bones : Because when they added 100 to 486, the answer was 585.994257 ------------------------------ Date: Tue, 06 Dec 94 12:59:28 000 From: Mathew Lodge Subject: Re: Interesting product claim (more Pentium stuff) Mike Kenney wrote > As CPUs get more and more complex, the chance of bugs slipping through will > probably go up. I just hope whichever company it happens to next handles > the problem better than Intel. When Inmos designed the T8 series of Transputers, they used formal methods to prove that the algorithms used in the on-chip FPU were correct. I am frankly amazed that a huge company like Intel relies solely on testing the hell out of a new chip -- which, of course, *proves* nothing. If a small British company like Inmos can prove an IEEE math FPU correct, why can't Intel? Perhaps this recent debacle will convince at least some people that formal methods can be cheaper than mistakes. Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown, Dorset, UK, BH21 7PP lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404 [We have not had any discussions on the appropriateness of formal methods in any systems, let alone critical systems, in a long time. Time to open up the Testing vs Formal Methods wars again? PGN] ------------------------------ Date: Tue, 6 Dec 1994 10:14:47 +0200 From: Yehuda Berlinger Subject: Virus alert virus alert I have been inundated with virus alerts. Somehow, this virus alert has been propagating out of control. It must be a virus in the virus alert. (Note: I don't mean to belittle the alert, but there must be some way of controlling its propagation. I have received it 4 times now from different sources.) >I have just received this message and been asked to take it seriously: >There is a virus on America Online being sent by E-Mail. If you get >anything called "Good Times", DON'T read it or download it. It is a >virus that will erase your hard drive. Forward this to all your >friends. >It may help them alot. [I suppose you are lucky you only got 4 copies. But it appears to be a complete hoax, as suspected by Rob Furr , who was amused at the close timing of the AOL message and Michael Slavitch's item in RISKS-16.60, and who added There are idiots in the world who think it's awfully funny to cry "Wolf" as soon as someone else notices that it's theoretically possible that wolves exist. Rob F. PGN] ------------------------------ Date: Mon, 5 Dec 1994 22:10:38 -0500 From: David Barr Subject: Re: Mailing list problems... > ``A subscriber site that does not honor the "Errors-to:" Except that "Errors-To" was introduced by sendmail, and is not in any RFC, 822 or otherwise. The 822 Police will arrest YOU for false arrest. :-) (The Risk in assuming the most popular implementation of a protocol is The Way Things Are. See also Return-Receipt-To:) The correct way is to set the envelope FROM to the bounce address. On those systems which don't have envelope addresses, it's up to them on how to preserve the bounce address in-band -- which is where much of the problems with mailing loops get started. It's surprising the number of people (and therefore the number of misconfigured mailers and gateways) which don't understand the mail specs. However, it's understandable given that 822 and 821 are 12 years old and are probably one of the most cryptic and vague out there, especially considering how critical they are to the Net. They really need to be updated and clarified. Something like "Precedence: junk" is bad, because there's never any feedback to the system. Addresses which fail simply get tossed, and they never get removed from the list. The list grows linearly, and you waste more and more resources trying to deliver mail to addresses that go nowhere anyway. --Dave [Also noted by brian@nothing.ucsd.edu (Brian Kantor), who said, "If you can find errors-to in RFC822, you've got better coffee than we do."] ------------------------------ Date: Tue, 06 Dec 94 11:03:26 -0500 From: Steve Losen Subject: Mailing-list deadman switch I am a unix system administrator at the University of Virginia and we regularly run across "abandoned" mailboxes that are growing rapidly with messages from busy mailing lists. This is particularly troublesome over the summer break and winter holidays. I have noticed that some mailing lists have what I call a "deadman switch" feature, whereby the listserver periodically sends all subscribers a message requesting that they confirm their subscription by replying. Anyone who fails to reply gets unsubscribed. When a user is unsubscribed in this fashion, the listserver sends a final message with instructions for getting back on the list. I think that some of these lists are smart enough to not send requests for confirmation to members who have posted to the list recently. I think that this is an excellent feature because many folks who subscribe to lists never figure out how to get off them or never bother. Some folks get a new account and never bother to deal with mail still coming to the old one. I encourage anyone who runs a high volume mailing list to consider using a deadman switch to ensure that mail is going to mailboxes that are actually being read. It would also help if mailing list administrators would regularly send out a brief message with information on how to unsubscribe. Steve Losen scl@virginia.edu phone: 804-982-4711 University of Virginia ITC Unix Support ------------------------------ Date: Tue, 06 Dec 1994 15:04:46 EST From: "Rob Slade, Social Convener to the Net" Subject: "Applied Cryptography" by Schneier BKAPCRYP.RVW 941012 "Applied Cryptography", Schneier, 1994, 0-471-59756-2, U$44.95 schneier@chinet.com %A Bruce Schneier %C 22 Worchester Road, Rexdale, Ontario M9W 9Z9 %C 605 Third Avenue, New York, NY 10158-0012 %D 1994 %G 0-471-59756-2 %I John Wiley & Sons, Inc. %O U$44.95 800-263-1590 fax: 800-565-6802 800-CALL-WILEY %O jdemarra@jwiley.com aponnamm@jwiley.com %P 618 %T "Applied Cryptography" For anyone who wants to study cryptography, you can save yourself a lot of time and effort by getting Schneier's book. From the simple Caesar cipher to RSA and beyond, there is nothing the book doesn't at least touch on. Protocols, techniques, algorithms, and even source code are included. A "Real World" section looks both at specific implementations and at the politics of encryption. Schneier notes that his work is *not* a mathematical text. It is difficult to say how much of a shortcoming this is for any given reader, but a safe bet is "not much". For those who do need more rigorous treatments of specific topics, the bibliography lists almost a thousand references, all of which are described and cited within the book text at some point. He also states that the encyclopedic nature of the book detracts from its readability. Not so. The work is both encyclopedic *and* readable. Schneier has done marvelously well with what is normally a dead and dry topic. His examples are ludicrously absurd--and therefore lucid and memorable. (He even uses Monty Python's immortal phrase, "My hovercraft is full of eels" in one illustration.) As course text, research basis or just a (serious) hobbyist's reference, this work is highly recommended. copyright Robert M. Slade, 1994 BKAPCRYP.RVW 941012 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: 23 November 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES ARE MOVING SOON (BEWARE: THE NEW SYSTEM IS CASE SENSITIVE): ftp unix.sri.com cd risks CURRENT ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.61 ************************