INFO-VAX Tue, 19 Jun 2007 Volume 2007 : Issue 331 Contents: Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: Another opportunity Re: Anyone know why the Alpha market is so so quiet? help set host/scsi Re: help set host/scsi Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: How will VMS be killed ? Re: Hubble/OpenVMS to continue thru at least 2013 - 23 years! Itanium hardware Q Re: looking for SWCC software for Raid Array 3000 / HSZ22 NFS - what am I doing wrong? Re: NFS - what am I doing wrong? Re: OpenVMS hobbyist license woes Re: OpenVMS hobbyist license woes OT: another example of evil javascript (MPACK) Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMAS Re: PLUG: PMASg email servers (was: Re: Question about TCPIP$ftp - copy taking a long time Re: Question about TCPIP$ftp - copy taking a long time Re: Question about TCPIP$ftp - copy taking a long time Re: Question about TCPIP$ftp - copy taking a long time Re: Question about TCPIP$ftp - copy taking a long time Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: Question for the Group UCX Printer connection Via LPD Re: UCX Printer connection Via LPD Re: UCX Printer connection Via LPD Re: VMS analogue of FBSD and linux hier(7) man pages Re: Why partitioned disks on VMS would be useful ---------------------------------------------------------------------- Date: 18 Jun 2007 18:06:27 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: 8086 vs patches Message-ID: <5dnvt3F35idjiU4@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >> >> I know that at one time the shuttle had computers (5 of them, all >> identical, I believe) with core memory (i.e. the tiny metal rings with >> wires running through them). Until when was that the case? > > Core memory has a lot of advantages in space flight that are not > relavent on the ground. I don't know if the shuttle program ever > got rid of thiers. I do know at least one instance of core memory > currently in use in space. It's not by any chance in the Russian computers on the Space Station, is it? :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 18 Jun 2007 14:44:03 -0400 From: Rich Alderson Subject: Re: 8086 vs patches Message-ID: koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > The critical computers on the Space Shuttle are far older and far > more reliable than 486. The first shuttle launch predates the > original 808x based PC, for example. Depends on how you define "launch" and how you define "PC" and how you solve for _x_. Construction on _Enterprise_ began in October 1974, but it did not begin operational testing (glides from the back of a 747) until February 1977. It never went into space. So 8080 systems were well under way before it started flying. Construction on _Columbia_, the first space-worthy shuttle, began in 1975 and it moved to Kennedy in 1979. Its first launch was on 12 April 1981, when S-100 bus 8086 systems were available from people like CompuPro (running Seattle Computing's QDOS, a port of CP/M-80, or Digital Research's own CP/M-86), as well as 8080 and 8085 systems. So no, neither the IBM PC (8088) nor the DEC Rainbow (8086 and Z80) were on the market yet, but so what? -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: 18 Jun 2007 14:46:12 -0400 From: Rich Alderson Subject: Re: 8086 vs patches Message-ID: koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , Ron Johnson > writes: >> Even the 80486 is surely fast enough to do railway switching. >> There's no GUI involved, just a lot of bytes to read and process. > I knew somebody who worked in that business. She never saw a PDP-11 > that was too slow for railway switching. I think there are still PDP-11 systems in use in the DC Metro switching system. I'll ask Tim Shoppa. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: Mon, 18 Jun 2007 14:18:38 -0500 From: Ron Johnson Subject: Re: 8086 vs patches Message-ID: On 06/18/07 12:00, Bob Koehler wrote: > In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >> I know that at one time the shuttle had computers (5 of them, all >> identical, I believe) with core memory (i.e. the tiny metal rings with >> wires running through them). Until when was that the case? > > Core memory has a lot of advantages in space flight that are not > relavent on the ground. I don't know if the shuttle program ever > got rid of thiers. I do know at least one instance of core memory > currently in use in space. And, being static, allows you to restart your program from where it left off when the power failed. *Very* handy. (If, like the NCR 499 that my grandfather's company used to use, it's single user single tasking, no VM, has a hex keypad and you've got the assembler listings of your apps.) -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Mon, 18 Jun 2007 16:08:21 -0400 From: JF Mezei Subject: Re: 8086 vs patches Message-ID: Bob Koehler wrote: > The critical computers on the Space Shuttle are far older and far > more reliable than 486. The first shuttle launch predates the > original 808x based PC, for example. They were upgraded to 386s in the 1990s. NASA had a batch of hardened 386s made for the shuttle. They also increased RAM to allow easier switching between programs during flight. > These computers have not been the source of much trouble. One launch > was delayed when they went into a known low-likelyhood race condition > that a different architecture might eliminate. There was actually one occasion a couple years back when the some of the computers failed during the launch but the commander (Eileen Collins if I recall) kept her cool and continued with the remaining computers still running. These are brute force designs. To move the engine gimbal, there would be 3 pistons, each driven by one of the computers. If one computer "disagrees", then the other 2 can still overpower the other piston. They can "re-string" that 3rd piston to a different computer (there is a 4th computer that looks at all the data to have situational awareness, but does not issue any commands to hardware until it is tasked to do so.) But during a launch sequence, they don't have time to do that. ------------------------------ Date: 18 Jun 2007 15:47:13 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 8086 vs patches Message-ID: In article <5dnvt3F35idjiU4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > It's not by any chance in the Russian computers on the Space Station, > is it? :-) Probably not. The computers supplied by the Russians are not all that old and US built. The Russians just paid for them and employed them in thier module. ------------------------------ Date: 18 Jun 2007 15:49:29 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 8086 vs patches Message-ID: <6g3DmPH$I6pF@eisner.encompasserve.org> In article , Ron Johnson writes: > > And, being static, allows you to restart your program from where it > left off when the power failed. *Very* handy. Not if you were in the middle of a read cycle. Reads are destructive and the data has be refreshed (Wang's patent). ------------------------------ Date: Mon, 18 Jun 2007 18:01:12 -0400 From: JF Mezei Subject: Re: 8086 vs patches Message-ID: Bob Koehler wrote: > Probably not. The computers supplied by the Russians are not all > that old and US built. The Russians just paid for them and employed > them in thier module. http://groups.google.com/group/sci.space.station/msg/4dc4987ae4d1f6a3?dmode=source&hl=xx-elmer They are actually a european contribution to the space station. However, "HP" logo figures prominently on the russian mission control centre due to their participation in the project... Note that on the US segment, the actual command&control computers are called MDMs. Based on 8086 architecture (80386SX models) running proprietary OS. These have no user interface. User interface s given by IBM Thinkpads running Solaris whith the military network interface to connect to the MDMs. NASA was in fact instrumental in convincing Sun to reverse its decision to abadon Solaris on the 8086 back in late 1990s. All other stuff on the US segmemnt is on IBM thinkpads running WINDOWS. Those lack the hardware to connect to the MDMs. And they do crash very often. (this is where those RAS features show their value because cosmic rays often cause glitches in the hardware and a poor hardrware combined with poor OS (windows) causes the system to freeze. ------------------------------ Date: Mon, 18 Jun 2007 15:03:21 -0700 From: "Tom Linden" Subject: Re: 8086 vs patches Message-ID: On Mon, 18 Jun 2007 10:00:55 -0700, Bob Koehler wrote: > In article , helbig@astro.multiCLOTHESvax.de > (Phillip Helbig---remove CLOTHES to reply) writes: >> >> I know that at one time the shuttle had computers (5 of them, all >> identical, I believe) with core memory (i.e. the tiny metal rings with >> wires running through them). Until when was that the case? > > Core memory has a lot of advantages in space flight that are not > relavent on the ground. I don't know if the shuttle program ever > got rid of thiers. I do know at least one instance of core memory > currently in use in space. > I though plated wire replaced core some 25 years ago. I know IBM was still making core (in Böblingen, IIRC) into the early 80's -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Mon, 18 Jun 2007 22:34:55 GMT From: John Santos Subject: Re: Another opportunity Message-ID: Main, Kerry wrote: >>-----Original Message----- >>From: Ron Johnson [mailto:ron.l.johnson@cox.net] >>Sent: June 12, 2007 6:39 PM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Re: Another opportunity >> >>On 06/12/07 17:21, Rich Alderson wrote: >>[snip] >> >>>DEC didn't produce a good TCP/IP stack on *any* architecture, and >> >>DECNET is >> >>>the reason. There are still 36-bit bigots who hate VMS who believe >> >>that >> >>>DECNET should have won the networking wars (and at least one who >> >>thinks that >> >>>the skunkworks ANF-10 should have beat out DECNET. >> >>Reminds me of the people who haven't quite accepted that the North >>won the War. >> >>-- > > > You mean the one where Canada beat the US? > > :-) > No, I think he means the Civil War, not the War of 1812. :-) We're 10 and 1! > > Kerry Main > Senior Consultant > HP Services Canada > Voice: 613-592-4660 > Fax: 613-591-4477 > kerryDOTmainAThpDOTcom > (remove the DOT's and AT) > > OpenVMS - the secure, multi-site OS that just works. > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Mon, 18 Jun 2007 15:35:16 -0400 From: JF Mezei Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: Bill Gunshannon wrote: > As many here have said, education is a necessary cost of doing business. > The cost should not be borne by the employee. However, if you are self employed and pitching your services to a potential customer, it doesn't look good if you want him to not only pay for your courses, but also consider you will be doing work for them during the courses (eg: get paid), especially for very short contracts. ------------------------------ Date: Mon, 18 Jun 2007 17:46:11 -0700 From: "Tom Linden" Subject: help set host/scsi Message-ID: I use this to talk to the HSG80 controllers, why no HELP, it's been arou= nd for a while? HAFNER> sear sys$update:set.cld dbm150/win=3D2 ! X-47 DBM150 David B. Miller 12-Jan-1996 ! Add SET HOST/SCSI for StorageWorks ------------------------------ Date: Mon, 18 Jun 2007 22:14:29 -0500 From: David J Dachtera Subject: Re: help set host/scsi Message-ID: <46774A15.9129E2D7@spam.comcast.net> Tom Linden wrote: > > I use this to talk to the HSG80 controllers, why no HELP, it's been around > for a while? > > HAFNER> sear sys$update:set.cld dbm150/win=2 > ! X-47 DBM150 David B. Miller 12-Jan-1996 > ! Add SET HOST/SCSI for StorageWorks Has not been officially supported for many years now. It is, by the way AEST-able. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 18 Jun 2007 14:26:11 -0500 From: Ron Johnson Subject: Re: How will VMS be killed ? Message-ID: On 06/18/07 12:08, Bill Gunshannon wrote: [snip] > > I would say the biggest threat to VMS in DOD in particular and ther > government in general is the strong move towards COTS. Can't buy VMS And RHEL5 on most all shipping IBM platforms was just awarded EAL4 (with CAPP, RBAC, and LSPP compliance). I've heard rumor that HP is working with RH for the same compliance (since all the s/w is open source). Yes, yes, I know that EAL4 computers can be hacked. But it does mean that knowledgeable sysadmins *can* make them tight. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Mon, 18 Jun 2007 15:54:49 -0400 From: JF Mezei Subject: Re: How will VMS be killed ? Message-ID: <89766$4676e316$cef8887a$28039@TEKSAVVY.COM> Bill Gunshannon wrote: > What contract would that be? The DOD, just like the rest of the > government does not and can not have any "contract" that goes > beyond the end of the next fiscal year. But in this case, it is the other way around. Compaq (or was it Digital at that time) makes the 15 year commitment as part of the sale of goods/services. The government agency has a one time sales contract that makes no commitment beyond currnet fiscal year but that contract includes a 15 year commitment from the vendor which puts no obligation on the government department beyond the current fiscal year. And the wording of the vendor's commitment is probably something akin to "HP agrees to provide yearly support contracts to department X for this equipment and software until at least year 20xx". This doesn't commit the government department to anything beyond the current fiscal year, but garantees that the support will be available should the government department wish to renew the yearly contract. So if at one point, HP cancels VMS support, the government can go back to the original sales contract of 7 years ago, give that one to its lawyers who can then sue HP for breach of contract. ------------------------------ Date: Mon, 18 Jun 2007 16:14:54 -0400 From: JF Mezei Subject: Re: How will VMS be killed ? Message-ID: <4b606$4676e7cb$cef8887a$29134@TEKSAVVY.COM> yyyc186 wrote: > No version of Linux/Unix I have ever looked at has an OS Kernel level > concept of a record. This means you cannot ever cluster. Without the > concept of a record, you cannot have a lock manager. Wouldn't a byte range lock do the same as a record lock ? Don't unixes have the ability to have byte range locks in files ? ------------------------------ Date: 18 Jun 2007 15:53:26 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: How will VMS be killed ? Message-ID: <$lhTDzgID3Qw@eisner.encompasserve.org> In article <5dnsghF32rpkjU3@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > I would say the biggest threat to VMS in DOD in particular and ther > government in general is the strong move towards COTS. Can't buy VMS > off any shelf I am aware of. VMS certainly qualifies as COTS. No physical shelf need apply. ------------------------------ Date: Mon, 18 Jun 2007 18:58:05 -0400 From: "John Smith" Subject: Re: How will VMS be killed ? Message-ID: <1ac79$46770df2$cef883de$9742@TEKSAVVY.COM-Free> JF Mezei wrote: > Any thoughts on how HP will handle VMS' retirement ? > > if IA64 is cancelled, then VMS would probably be handled the same way > as True64. Not ported to the 8086 and HP would complete the next > version of the OS and then put it in maintenance mode for 5 years. In the May 28, 2007 print edition of eWeek, pg. 20, there is an article on IBM's new Power 6 powered servers. In the article (not found online @ eweek.com) there is the following citation: "In its quarterly survey of the server market May 22, Gartner found that RISC-Itanium server shipments fell 15.5 percent in the first quarter of 2007 and revenue dipped 1.5 percent compared with a year ago." So in the RISC-Itanium world we basically have Power, Sparc, and Itanic. Who is falling faster? Also http://www.eweek.com/article2/0,1759,2138107,00.asp but no effort is being made to niche market VMS to new customers. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Mon, 18 Jun 2007 19:01:25 -0400 From: "John Smith" Subject: Re: How will VMS be killed ? Message-ID: Marc Van Dyck wrote: > JF Mezei submitted this idea : >> Any thoughts on how HP will handle VMS' retirement ? >> >> if IA64 is cancelled, then VMS would probably be handled the same >> way as True64. Not ported to the 8086 and HP would complete the next >> version of the OS and then put it in maintenance mode for 5 years. >> >> When you consider those still on VAX at 5.5-2, those would probably >> remain on it for some time to come. But others are rely on 3rd party >> products like Oracle would likely be on some migration to >> IBM/Sun/Dell in a fairly rapid mode (less than 5 years). >> >> Whether Bruden survives as a VMS outfit or not, I do not know, but >> they might become the logical support resoiurce for the remaining >> VMS customer base. (A bit like Parsec with the PDP11 software). >> >> I think that VMS would fairly quickly become defunct, perhaps >> similarly to OS2, with some die hard fans remaining. >> >> VMS skills would instantly become as worthless as DG's AOS-VS >> skills. But a few might get lucky if the remaining VMS shops get >> desperate to find anyone with VMS knowledge and willing to work on >> VMS (aka: legacy worthless skills). >> >> >> Would HP kill VMS before IA64 in the hopes of getting customers to >> move to HP-UX ? (and when IA64 is killed, HP-US might have enough >> customers to pwarrant a port to the 8086). >> >> >> Perhaps one way to cause HP to think twice about killing VMS would >> be if the user community was VERY organised (back to a single DECUS >> name for starters) and made serious (but quiet/private) threaths >> that should HP pull the plug on VMS, the community would mount a >> very public bopycott HP campaign and show HP as a company you cannot >> trust your business to and should avoid. >> >> >> Really, when you think about it, of someone like Stallard/Livermore >> at HP can, at their whim, ruin your own personal carreer and make >> you worthless in society by zapping your skills, what have you got >> to loose by trying to stain HP as much as you can ? > > Didn't H.P. (or Compaq, I don't remenber) sign an agreement with the > U.S. D.O.D. stipulating that they would maintain OpenVMS alive for > 15 years or so ? Laying on a gurney in a persistent vegetative state also counts as 'being alive'. That also is a particularly apt description of some senior HP executives. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Mon, 18 Jun 2007 22:02:04 -0500 From: David J Dachtera Subject: Re: How will VMS be killed ? Message-ID: <4677472C.974F8A18@spam.comcast.net> OldDawg wrote: > [snip] > I'd be more interested in hearing from folks who have changed or are in > the process of the change, and how they've upgraded their skills. Well, in my case, UN*X and I are old acquaintances - back to 1986 thru 1989 or so. It's still "Stone-age computing", but has had a lot of VMS-isms tacked onto it to try and make it more suitable to the Enterprise environment. Multi-path is still a third-party add-on, however (EMC PowerPath, and similar). > One > very important item for us is providing better support for printer > management. Print queue setup and maintenance is always a top priority > for us, and Cerner never does it to suit our critical user need, so we > do it ourselves. It's worked out well, but the move to HPUX is giving us > nightmares - this is road Cerner does not want us to continue on, but > Healthcare needs force us to continue. I'm wondering what happens to SPOOLER.COM/.DAT in the UN*X world. The cold sweats haven't quite set in yet. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 18 Jun 2007 22:05:48 -0500 From: David J Dachtera Subject: Re: How will VMS be killed ? Message-ID: <4677480C.B93B4FB0@spam.comcast.net> yyyc186 wrote: > [snip] > No version of Linux/Unix I have ever looked at has an OS Kernel level > concept of a record. Well, not in the RMS sense of the concept. In UN*X-land, data in the stream up to a null, EOF (CTRL+D) or Line-Feed (CTRL+J) depending constitutes a "record". I agree - it's still "stone-age computing", and underneath the GUI, WhineBloze is no better. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 18 Jun 2007 22:06:20 -0500 From: David J Dachtera Subject: Re: How will VMS be killed ? Message-ID: <4677482C.82292871@spam.comcast.net> JF Mezei wrote: > > yyyc186 wrote: > > No version of Linux/Unix I have ever looked at has an OS Kernel level > > concept of a record. This means you cannot ever cluster. Without the > > concept of a record, you cannot have a lock manager. > > Wouldn't a byte range lock do the same as a record lock ? > > Don't unixes have the ability to have byte range locks in files ? It depends. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 19 Jun 2007 06:24:03 +0200 From: "P. Sture" Subject: Re: How will VMS be killed ? Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article <5dnnluF34qmc8U3@mid.individual.net>, bill@cs.uofs.edu (Bill > Gunshannon) writes: > > > And the governemnt can not > > commit beyond the availability of funding which is the end of the fiscal > > year. > > Some agencies of the US federal government can sign multi-year contracts > and pay in advance for the whole thing. FWIW this is the way large systems are supplied as part of World Bank or EU aid to developing countries. A large spares kit will be included in the order, along with hardware maintenance for fixed number of years. -- Paul Sture ------------------------------ Date: Tue, 19 Jun 2007 07:04:03 +0200 From: "P. Sture" Subject: Re: How will VMS be killed ? Message-ID: In article <$lhTDzgID3Qw@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <5dnsghF32rpkjU3@mid.individual.net>, bill@cs.uofs.edu (Bill > Gunshannon) writes: > > > > I would say the biggest threat to VMS in DOD in particular and ther > > government in general is the strong move towards COTS. Can't buy VMS > > off any shelf I am aware of. > > VMS certainly qualifies as COTS. No physical shelf need apply. But several shelves were required for the Orange/Grey Wall, Sorry, could not resist. -- Paul Sture ------------------------------ Date: Mon, 18 Jun 2007 14:14:46 -0700 From: "Tom Linden" Subject: Re: Hubble/OpenVMS to continue thru at least 2013 - 23 years! Message-ID: On Mon, 18 Jun 2007 10:07:40 -0700, Bob Koehler wrote: > In article , "Tom Linden" > writes: >> On Mon, 18 Jun 2007 05:59:55 -0700, Bob Koehler >> wrote: >> >>> In article <1181924443.013467.207410@q75g2000hsh.googlegroups.com>, >>> sean@obanion.us writes: >>> >>>> Considering that Hubble converted to UNIX by 2000, there wonldn't seem >>>> to be much point. >>> >>> VAXen and Alphas running VMS are alive and well on the Hubble >>> program. >>> >> >> In part thanks to PL/I > > I wasn't aware of that, but now I'm windering what happened to the > Pascal. I suspect UNIX vendors have sufficiently good enough Pascal > compilers for most needs. > I don't think it was so much a case of the language as the OS, and for some applications PL/I was chosen, and BTW, still a couple of large VAX installations, which are expected to run another 16 years! (yes, they have plenty of spares) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Mon, 18 Jun 2007 20:34:48 -0700 From: DeanW Subject: Itanium hardware Q Message-ID: <3f119ada0706182034ge42965aje56dd4c0ce7d788b@mail.gmail.com> A customer just took delivery of an RX3600, which has no DVD drive. While they're getting that sorted and obtaining one (one way or another) can anyone tell me if the one in my RX2600 work (for straightforward "plug and play" values of work, so I can get some software onto this thing? Amongst other things, I need to get some EFI modules onto it... and if I succeed in doing that, I'll have to reload the OS. Any other options? -- Dean Woodward =o&o dean.woodward@gmail.com ------------------------------ Date: Mon, 18 Jun 2007 17:07:24 -0600 From: Jim Mehlhop Subject: Re: looking for SWCC software for Raid Array 3000 / HSZ22 Message-ID: <4677102C.30301@parsec.com> Hans Bachner wrote: > Tim Jackson wrote: > >> I have the H22AGENT V2.0-5 for Alpha available as a .PCSI file if that >> will help. I also still have the "DIGITAL StorageWorks RA3000 >> Controller SW V1.0" CD which contains the HSZ22 Storage Window V2.0 >> Build 26 and StorageWorks Command Console V2.0-035 windows client >> tools. >> >> Let me know if you want them and I can zip them up and email to you. > > It would be great if you could help out with these. My mail address in this > posting works; I can also open up an ftp account so you can simply push the > files over. Please contact me via email for details. > > Many thanks & best regards, > Hans. I've got client and agent for 2.1 if you need it. Command Console V2.1 build 155 ------------------------------ Date: Mon, 18 Jun 2007 12:24:31 -0700 From: Don Subject: NFS - what am I doing wrong? Message-ID: <1182194671.275544.165540@n60g2000hse.googlegroups.com> I am trying to give NFS access to a directory on an ODS-2 disk. In testing the setup, I tried to NFS mount the volume, and got an error message that puzzles me: GREGG> TCPIP TCPIP> MOUNT DNFS0: /PATH="/SCORECARD/USER.DIR.1"/HOST=127.0.0.1 %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS8:[000000] -SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node The TCPTrace shows two UDP messages, one from port 601 to port 110 and a response from port 110 to port 601. There was no other traffic logged for 127.0.0.1 Here is everything I can think of that might be relevant: OpenVMS 8.3 V03.00 on RX3600 LAN_V0500 GREGG> DIR DKA7:[000000]USER.DIR/SEC Directory DKA7:[000000] USER.DIR;1 [SYSTEM] (RWE,RWE,RE,E) Total of 1 file. GREGG> TCPIP TCPIP> SHOW SERVICE Service Port Proto Process Address State FTP 21 TCP TCPIP$FTP 0.0.0.0 Enabled MOUNT 10 TCP TCPIP$MOUNTD 0.0.0.0 Enabled NFS 2049 UDP TCPIP$NFS 0.0.0.0 Enabled PORTMAPPER 111 TCP,UDP TCPIP$PORTM 0.0.0.0 Enabled TELNET 23 TCP not defined 0.0.0.0 Enabled TCPIP> SHOW SERVICE/FU MOUNT Service: MOUNT State: Enabled Port: 10 Protocol: TCP Address: 0.0.0.0 Inactivity: 0 User_name: TCPIP$NFS Process: TCPIP $MOUNTD Limit: 10 Active: 0 Peak: 0 File: TCPIP$SYSTEM:TCPIP$MOUNTD_RUN.COM Flags: Listen Socket Opts: Rcheck Scheck Receive: 64000 Send: 64000 Log Opts: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr File: SYS$SYSDEVICE:[TCPIP$NFS]TCPIP$MOUNTD_RUN.LOG Security Reject msg: not defined Accept host: 0.0.0.0 Accept netw: 0.0.0.0 TCPIP> SHOW DEVICE_SOCKET Port Remote Device_socket Type Local Remote Service Host bg45 DGRAM 111 0 PORTMAPPER * bg46 STREAM 111 0 PORTMAPPER * bg57 STREAM 21 0 FTP * bg61 STREAM 23 0 TELNET * bg93 STREAM 135 0 * bg94 DGRAM 135 0 * bg95 RAW_IP 0 0 * bg148 DGRAM 49152 0 * bg3041 STREAM 10 0 MOUNT * bg4412 STREAM 23 2286 TELNET 10.172.181.154 bg4523 STREAM 23 2376 TELNET 10.172.181.154 bg4786 STREAM 23 2451 TELNET 10.172.181.154 bg17440 STREAM 23 1938 TELNET 10.172.181.142 bg17502 STREAM 23 1144 TELNET 10.172.181.149 bg17504 STREAM 23 1145 TELNET 10.172.181.149 bg18374 STREAM 23 2268 TELNET 10.172.181.154 bg18470 STREAM 23 1731 TELNET 10.172.181.160 bg19064 STREAM 23 2529 TELNET 10.172.181.160 Port Remote Kernel_socket Type Local Remote Service Host 5.1 STREAM 2049 0 * 5.2 DGRAM 2049 0 NFS * TCPIP> Exit GREGG> SHOW DEV/FU BG3041 Device BG3041:, device type unknown, is online, mounted, record- oriented device, network device, mailbox device. Error count 0 Operations completed 5 Owner process "TCPIP$INETACP" Owner UIC [SYSTEM] Owner process ID 0000041B Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL Reference count 1 Default buffer size 256 GREGG> TCPIP TCPIP> SHOW MAP Dynamic Filesystem Map Pathname Logical File System /SCORECARD DKA7: TCPIP> SHOW EXPORT File System Host name /SCORECARD/USER.DIR.1 * TCPIP> SHOW PROXY VMS User_name Type User_ID Group_ID Host_name GREGG OND -2 -2 * ------------------------------ Date: Mon, 18 Jun 2007 22:15:20 +0200 From: "P. Sture" Subject: Re: NFS - what am I doing wrong? Message-ID: In article <1182194671.275544.165540@n60g2000hse.googlegroups.com>, Don wrote: > I am trying to give NFS access to a directory on an ODS-2 disk. In > testing the setup, I tried to NFS mount the volume, and got an error > message that puzzles me: > > GREGG> TCPIP > TCPIP> MOUNT DNFS0: /PATH="/SCORECARD/USER.DIR.1"/HOST=127.0.0.1 > %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS8:[000000] > -SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node Try this instead: MOUNT DNFS0: /PATH="/SCORECARD/USER"/HOST=127.0.0.1 i.e. you don't want the .DIR;1 You might want a /SYSTEM on the end of that command too - I forget it one is necessary. -- Paul Sture ------------------------------ Date: Mon, 18 Jun 2007 17:05:32 -0400 From: JF Mezei Subject: Re: OpenVMS hobbyist license woes Message-ID: Rob Brown wrote: > IF you are logging in at the DECwindows login screen, the login will > silently fail and you will be returned to the login screen if the > user's login directory is not accessible. On alpha, you get thrown into the failsafe mode where you are given one decterm in some indeterminate default directory. VAX does not have the concept of failsafe mode because it doesn't have a button to sleect between decwindows, CDE (new desktop), and failsafe mode. To debug this, login with the system account. Its sys$login is assured to be present since it is created during VMS installation. And from there, you get a DETTERM going, use REPLY/ENABLE command to see error messages. You can then $CREATE/TERM/DETACHED/NOLOGGED which will open up a new decterm with the character cell login. You enter the new username and password and you can then see any error message on the login screen or on the sys$manager window (opcom messages). ------------------------------ Date: Mon, 18 Jun 2007 21:55:44 -0500 From: David J Dachtera Subject: Re: OpenVMS hobbyist license woes Message-ID: <467745B0.2725F089@spam.comcast.net> JF Mezei wrote: > > Michael Moroney wrote: > > VMS is smart enough to figure out that a CD is nonwritable without needing > > to be told with /NOWRITE. > > For a DK device you are right. But with a different type of controller > that makes a CD appear as a DUAx device, VMS doesn't know it is a CD > and the mount will fail without /NOWRITE (sometime between 5.5.-2 and > 7.2 on vax). On Alpha, read-only media are successfully detected as such. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 18 Jun 2007 21:27:02 -0400 From: JF Mezei Subject: OT: another example of evil javascript (MPACK) Message-ID: <9deb3$467730f4$cef8887a$12354@TEKSAVVY.COM> http://blogs.pandasoftware.com/blogs/images/PandaLabs/2007/05/11/MPack.pdf Basically, this is a commercial application from Russia that lets the criminal infect machines from a web server. This past week, many italian sites have been compromised and users of those sites were infected. It uses javascript as well as iframes to direct the victim's browser to the infection site which then downloads the malware to the victim's machine. The MPACK software is sophisticated enough to download different virus depending on the type of machine, browser etc. ------------------------------ Date: 18 Jun 2007 18:02:44 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: PLUG: PMAS Message-ID: <5dnvm4F35idjiU3@mid.individual.net> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > In article <5dnipgF33r1bdU2@mid.individual.net>, bill@cs.uofs.edu (Bill > Gunshannon) writes: > >> > My social solution is to send email only through trusted relay servers, >> > and only receive mail from the same. As soon as enough people start >> > doing this, then it won't be worth it to the spammers to spam. >> >> That's pretty much mine, but I take it a step further by proposing >> the formalization of the process with written and signed agreements >> and basing the trusted email network on something other than SMTP >> in order to eliminate the possibility of leakage. >> >> So, how do you establish your trust and how do your trusted servers >> guarantee no leakage? > > Trusted servers are those not in an RBL. :-) > > The person running the SMTP relay server I use gets money from his > customers to run it. Thus, it is in his own interest to make sure it is > spam-free. Thus, any user who sends too much email within a given time > gets blocked until the problem is resolved. If he gets blacklisted, the > guilty person has to pay. So, you are basicly using a single site that is doing what I have been proposing. But it will take more of them than just one. And that is what I want to see happen. Until the people sending email to you are on trusted servers you will still be missing emails that your system is filtering out. If you are a business, that is not a good thing for you. No one, on the INTERNET or elsewhere, is the sole provider of any product. If you loose a potential customer they will find another provider and the only looser will be you. The choices are to not rely on email for business or fix the problem. Today, the first option is just not viable. It is in the best interests of legitimate businesses to find a solution for this problem. Some people have mentioned the cost of the additional administration but when weighed against the real and potential future loss, I do not think it is as bad as the alternative. > >> > Brad Templeton has an interesting idea which doesn't involve blocking >> > email from non-trusted addresses: delay it somewhat, enough to make >> > spamming not worth the effort but not enough to hurt legitimate mail: >> > >> > http://ideas.4brad.com/node/510 >> >> Now there's a name I haven't heard in ages. Maybe I should be talking >> to people like him about my idea. > > His blog as quite active. I will need to look him up again. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 18 Jun 2007 18:07:44 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: PLUG: PMAS Message-ID: In article <5dnr09F32rpkjU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >In article , > "Tom Linden" writes: >> On Sun, 17 Jun 2007 02:14:38 -0700, Phillip Helbig---remove CLOTHES to >> reply wrote: >> >>> In article <5djfl4F3575eiU1@mid.individual.net>, bill@cs.uofs.edu (Bill >>> Gunshannon) writes: >>> >>>> So, what is the technological solution? >>> >>> ZEN.SPAMHOUSE.ORG. It's an RBL. And it works fine with HP TCPIP (as of >>> version 5.4). >>> >> I have following in MX, and I get very little SPAM >> >> RBL domains to check: >> BL.SPAMCOP.NET >> CBL.ABUSEAT.ORG >> DNSBL.NJABL.ORG >> OPM.BLITZED.ORG >> RELAYS.VISI.COM > >Yes, but here is the big question and take your time and think about >this for at least a few minutes. > >At what point in the conversation does the system reject the mail >and break the connection? During the DATA? After the RCPT TO:? >After the MAIL FROM:? I have looked at mine. It usually makes >its determination by the time of the HELO, before it knows who >the sender, recipient or any of the body of the message is. If >this is the case, how do you know it is not rejecting what could >be legitimate attempts to communicate with you? How much business >can you afford to miss? And all because your potential customer >signed up with a lousy ISP. > You shouldn't really reject mail to postmaster according to the RFCs except for really exceptional circumstances. Although rfc-ignorant decided that the source being in a DNSBL isn't covered by exceptional circumstances they decided that this is unfortunately such a common practise that they won't list you if you break this rule so long as you provide a reason in the DNSBL rejection message. Although not covered in the same way by the RFCs I'd probably also want to allow mail through to abuse. That way those who you have rejected because they are on a DNSBL can still contact you at those addresses to ask what is happening. Hence really you shouldn't reject mail before the RCPT TO:. I also find it useful to be able to record who mail was from and for in the logs. Delaying rejection until this point doesn't use up many resources on your MTA. (I don't believe DEC TCPIP Services MTA can delay the rejection at the moment - but I seem to recall that someone said they would fix that when I raised the issue previously). Whereas if you delay until the data has been received (but not accepted) your MTA has practically done all it's work. Also you can only then increase your acceptance that this is really spam by either running it through a content scanner or by tagging it as potential spam - based on the DNSBL check - and then delivering it for the user to inspect. David Webb Security team leader CCSS Middlesex University >bill > >-- >Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >bill@cs.scranton.edu | and a sheep voting on what's for dinner. >University of Scranton | >Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 18 Jun 2007 19:44:16 +0200 From: Michael Unger Subject: Re: PLUG: PMAS Message-ID: <5do1n1F33os8bU1@mid.individual.net> On 2007-06-18 18:52, "Phillip Helbig---remove CLOTHES to reply" wrote: > But a real person should be able to decipher this: > > The email you sent to user@foo.bar couldn't be delivered because, > correctly or not, email from the address you sent it from is being > blocked by some people because they have reason to believe it is a > source of Spam. Please see http://www.foo.bar/ for more information. > You should contact the support address of your ISP to solve the > problem. Sounds rather familiar ... Michael -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid. ------------------------------ Date: Mon, 18 Jun 2007 14:10:58 -0500 From: Ron Johnson Subject: Re: PLUG: PMAS Message-ID: <6NAdi.124159$vE1.79057@newsfe24.lga> On 06/18/07 10:31, sol gongola wrote: > Ron Johnson wrote: >> On 06/17/07 03:05, P. Sture wrote: >> [snip] >>> My ISP has recently tightened things up, as a couple of months ago the >>> spam volume dropped. Unfortunately, I believe I lost some valid emails >>> as well :-( >> You mean they just *delete* emails they think are spam???? My ISP at >> least sends them to the "Spam" folder where I can see them with web mail. >> >> But I guess people complaines, and now there is a configuration option >> of putting "-- Spam --" in the subject line of emails they score as >> spam. I now get all emails, and filter them into my own Spam folder >> where I can quick-scan for false-negatives. >> > So, you haven't reduced your unwanted spam traffic on your network > and you are still getting all the spam. Maybe it easier to to deal > with them when they are all in the same folder. That's the idea. I eyeball for false-spams then delete all the mails. Very fast and simple. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Mon, 18 Jun 2007 21:53:05 +0200 From: "P. Sture" Subject: Re: PLUG: PMAS Message-ID: In article , "Tom Linden" wrote: > Why not be your own ISP? I am. My 'ISP' only provides me with a T1 pipe. > So I run my own DNS and Mail, in fact, it runs on each node under > loadbroker. > You could do the same even with DSL. > Well, as it happens, I tried just that yesterday :-) Attempting to send a mail to myself at Eisner gives this: 550 5.7.1 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml? which _is_ a helpful message. I've just looked up the price of a fixed IP address, and it appears that I'd have to go to a business account to get one. At 5 times the price, I think I'll pass at the moment. -- Paul Sture ------------------------------ Date: Mon, 18 Jun 2007 21:59:23 +0200 From: "P. Sture" Subject: Re: PLUG: PMAS Message-ID: In article , Kilgallen@SpamCop.net (Larry Kilgallen) wrote: > In article <5dnghmF35551uU3@mid.individual.net>, bill@cs.uofs.edu (Bill > Gunshannon) writes: > > In article , > > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >> In article , david20@alpha1.mdx.ac.uk > >> writes: > >> > >>> By their very nature DNSBLs block all mail whether legitimate or spam > >>> coming from the blocked address. > >> > >> No, by their nature, DNSBLs only _list_ those IP addresses. What happens > >> next depends on the software at the recipient end _using_ the DNSbl: > >> > >> 1. MUA software at best can segregate email from the > >> listed IP address, making it available for possible > >> (but unlikely) review by the recipient. > >> > >> 2. MTA software _can_ do the above, but it can also do > >> the more reliable thing - REJECTing the email in the > >> SMTP dialog, so the sender of legitimate mail knows > >> it did not get through. > > > > Except that that rejection is probablyh meaningless to the originator > > of the mesage resulting in more traffic with no purpose. > > Any legitimate originator will figure out that "something went wrong" > with their email message. The degree to which they investigate will > depend on how important it was to them that the message get through. At this point, I must ask what is recommended for the Friendly/Secure setting in TCP/IP Services. Section "18.6 Configuring SMTP Antispam" of the Management Guide says this: "Security FRIENDLY or SECURE. This value specifies the type of error text sent to the SMTP client when disconnecting a link because of a spam event. A value of SECURE means to send purposely unhelpful error text. A value of FRIENDLY means to send helpful error text. Default: SECURE" -- Paul Sture ------------------------------ Date: Mon, 18 Jun 2007 16:00:52 -0400 From: JF Mezei Subject: Re: PLUG: PMAS Message-ID: <77a42$4676e481$cef8887a$28406@TEKSAVVY.COM> Bill Gunshannon wrote: > And how do you scan them on content? How do you know your users aren't > interested in Viagra and Cialis? How do you know they didn't ask for > those "penny stock" notices? And that is the hard part of content filtering. You can't mention "growing the room by 3" in a discussion with an architect designing your new home anymore for fear that would get caught in spam filters. Also, consider that if one is studying spam to better protect against it, you might wish to include an example message in your conversations with a peer, and that content would then flag the whole message as spam. Personally, if everyone stopped using accepting/sending HTML in their email communications, it would stop a LOT of the spam because those tricks to include images that are used to account how many people read the email wouldn't work anymore. It would also stop phishing shemes because you couldn't have hidden URLs pointing to the scan web site when you display the apparently legitimate bank web site on the HTML page. Microsoft should be blamed for having shipped its products with HTML enabled against established email standards and making a whole generation think HTML emails are acceptable. (or think that sending WORD documents is acceptable and that anyone can read those). ------------------------------ Date: Mon, 18 Jun 2007 16:26:41 -0400 From: JF Mezei Subject: Re: PLUG: PMAS Message-ID: <55d46$4676ea8e$cef8887a$31774@TEKSAVVY.COM> Bill Gunshannon wrote: > Your joking, right? There are some big names currently listed, some > have been on those lists for really long times. Both Videotron (large cable company) and Bell Canada (telco that operates its isp business under the SYMPATICO trademark) at one point of another were blacklisted by RBLs. In the case of Videotron, it was because they never checked their "postmaster" account and the RBLs, when trying to get an ISP to investigate a complaint, never got any response, so they blacklisted the whole ISP. In the case of Sympatico, there were enough spammers, and Bell, being a "civil servant" heaven, was too busy pushing paper and restructuring the company to understand what business they were in. In both cases, what got them moving were newspaper articles that warned the population that the company was blacklisted around the world for not acting or fostering spam. The articles also explained that as a result, regular customer's emails might not get delivered. Those large ISPs then acted quickly to block port 25 and respond to spam complaints. ------------------------------ Date: Mon, 18 Jun 2007 16:30:57 -0400 From: JF Mezei Subject: Re: PLUG: PMAS Message-ID: <70f4e$4676eb8e$cef8887a$32273@TEKSAVVY.COM> John E. Malmberg wrote: > I am curious at what filtering that you are using that is having such a > high false positive rate. The (few) instances I have had of false positives that I was able to know about were due to a large australian ISP (ozemail) not having a reverse DNS for one of their many outgoing SMTP servers. So emails being unlucky to be processed by that server would often be rejected. Similarly, my mobile provider has one of their SMTP servers without reverse DNS (they are a hopeless case). It appears to be a backup server and whenever the first one is overloaded or down for maintenance, emails from my mobile to myself at home don't get delivered. The problem with large companies that provide very public services is that it is next to impossible to reach their network/mail administrators to point to a problem. ------------------------------ Date: Mon, 18 Jun 2007 16:34:22 -0400 From: JF Mezei Subject: Re: PLUG: PMAS Message-ID: <98482$4676ec5b$cef8887a$32682@TEKSAVVY.COM> Bill Gunshannon wrote: > I just did a quick scan of my maillogs since midnight. I see dozens of > sites listed as being "Exploitable Servers". I don't know how to break > this to people but that is frequently just the fault of an incompetent > sys admin and the majority of real users at this sites are legitimate. SPAM exists exactly because of that. Incompetant system adminitrators who do not properly secure their facilities against spam and thus allow spam to be sent from/through their infrastructure. 0 tolerance is the only way to force them to get smart and fix their network. It is only when all comcast users are blocked and the New York Times writes a front page article about Comcast fostering spam and resulting in all comcast users being blocked that compcast (aka: any large ISP) sill start to ask. As long as only a few individual IPs are blocked, Comcast won't care. But blocks all their IPs and they will case pretty quickly. ------------------------------ Date: 18 Jun 2007 15:55:36 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: PLUG: PMAS Message-ID: In article <5dnou8F35gc3pU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> Any legitimate originator will figure out that "something went wrong" >> with their email message. The degree to which they investigate will >> depend on how important it was to them that the message get through. > > You give the average user more credit than I would. And I work with > people very day who one would thnk were more computer savvy than the > average. As I said in another message, I asked the most savvy faculty > member in the CS departmetn and he didn't have a clue what an RBL was. Nor should he have to. But a user whose mail gets rejected should be clueful enough to bring the issue to their local email expert. The exact syntax used to present the rejection, after all, is under the control of the local email administrator. ------------------------------ Date: Mon, 18 Jun 2007 16:58:28 -0400 From: JF Mezei Subject: Re: PLUG: PMAS Message-ID: Bill Gunshannon wrote: > its determination by the time of the HELO, before it knows who > the sender, recipient or any of the body of the message is. If > this is the case, how do you know it is not rejecting what could > be legitimate attempts to communicate with you? How much business > can you afford to miss? And all because your potential customer > signed up with a lousy ISP. Do you have an account that has no spam filtering at all ? If so, take a good look at the type of headers that are used by spammers. In the SMTP dialogue, they may use a legitimate looking header. So if they have a zombie on some italian network, they will have a MAIL FROM: that is from that italian network. It may look legitimate to you, but it is still spam. The newer trend now that is REALLY dangerous is that the zombies are supposedly programmed to look up the user's SMTP configuration to get the name of their ISP's real SMTP server, at which point they start to send the spam via their ISP's SMTP server and this makes their emails legitimate from RBL point of view since the email comes from an official ISP SMTP server instead of some dynamic IP given to individual PCs. If this becomes prevalent, then the whole RBL system may fall apart. Microsoft should be billed big money for everyone of its Windows PCs that tgets infected with this spamming virus. The spammers will always be one step ahead of spam protection to bypass it. Put content filters ? They send images with rasterised text in them. Block dynamic IPs and they start to use the official ISP smtp servers. ------------------------------ Date: 18 Jun 2007 15:59:10 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: PLUG: PMAS Message-ID: In article <5dnpa6F35gc3pU4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article <80R3AqzfeC3y@eisner.encompasserve.org>, > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> But if that message was truly important, there is noting about >> the DNSbl mechanism to keep the originator from reaching the >> recipient by telephone. If the message was important, the >> originator can use other mechanisms, but only if they have >> been informed that the message did not get through. > > You are assuming it is important to the originator. I am more concerned > with the destination. If I need to buy a computer and I can't get through > to the first guy on the list, there are dozens more I can visit. In the > long run, it is not all that important to me where I spend my money. How > important is it to you as the seller? And I can come up with many more > examples of how this badly broken system is affecting some people's ability > to do business. Sadly, it is usually the more competent businesses whor > are trying to do things right who are bearing the brunt of the burden. Businesses exercise the degree of care they feel appropriate, and get the results they deserve. In some cases, missing potential customers who cannot deal with a non-delivery notice might be a benefit. ------------------------------ Date: 18 Jun 2007 21:07:43 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: PLUG: PMAS Message-ID: <5doagvF35ajpjU1@mid.individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <5dnou8F35gc3pU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> In article , >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >>> Any legitimate originator will figure out that "something went wrong" >>> with their email message. The degree to which they investigate will >>> depend on how important it was to them that the message get through. >> >> You give the average user more credit than I would. And I work with >> people very day who one would thnk were more computer savvy than the >> average. As I said in another message, I asked the most savvy faculty >> member in the CS departmetn and he didn't have a clue what an RBL was. > > Nor should he have to. But a user whose mail gets rejected should be > clueful enough to bring the issue to their local email expert. The > exact syntax used to present the rejection, after all, is under the > control of the local email administrator. Ummm.... I have received over 20 Reject: messages today all claiming to be from the mail server "cs.uofs.edu". My server didn't generate any of them. Tell me again how these reject messages are useful tool. If my users came to me with all their "Reject:" messages it would be a fulltime job just telling them to go away. Oh yeah, and I have no idea how many more I would have received if it weren't for SPAM filtering and RBL's. Face it people. The Email system is broken and all these bandaids are not fixing it. They are punishing the victim and just letting the system deteriorate even further. Like it or not, there is going to have to be a major change in the way email is handled or it will loose all utility. And that change is going to have to ceom from and be implemented by the admins who run the system. It has to be totally transparent to and not require any action form the users who are (and should be) totally clueless. The INTERNET is just like cars today. Everybody uses one but very few people know or care what's under the hood. It is up to those like us who can still change sparkplugs (or in some of our cases rebuild the engine from the ground up) to keep them running. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 18 Jun 2007 14:10:23 -0700 From: "Tom Linden" Subject: Re: PLUG: PMAS Message-ID: On Mon, 18 Jun 2007 09:50:56 -0700, Bill Gunshannon wrote: >> Why not be your own ISP? I am. My 'ISP' only provides me with a T1 >> pipe. >> So I run my own DNS and Mail, in fact, it runs on each node under >> loadbroker. >> You could do the same even with DSL. > How does your running your own ISP fix the email for the guy who wants > to do business with you but his ISP is BLed? he will end out taking > his business to someone who runs as shoddy an email system as his own. > Talk about the mediocre winning the battle. That is not what I was responding to, but rather the notion of you being control of the filtering, rather than the ISP. > But, let me throw this out for consideration. You don't have to > answer publicly, just give it some thought. How many customers > do you have? Wouldn't it be better for all concerned if you could > establish a trust relationship such that you could know with 100% > certainty that all of their emails to you and all of yours to them > would get thru? If you knew that all of your existing customers > had a guaranteed pipe into your system wouldn't filtering for new > potential customers be easier than trying to filter for SPAM? > Keywords: PLI PL/I PL1 PL/1 PL-I PL-1 PLM SPL "Subset G" > How much SPAM is likely to match that? Yes I have given that some that some thought, and I do have a solution. With a new website under construction (you may preview it at my site with /kednos/ tacked on to the URL, I can provide customer login and secure mail with SOYmail. With MX as the smtp I am only getting 10 to 20 or so spams a day. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: 18 Jun 2007 21:13:42 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: PLUG: PMAS Message-ID: <5doas6F35ajpjU2@mid.individual.net> In article , Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <5dnpa6F35gc3pU4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> In article <80R3AqzfeC3y@eisner.encompasserve.org>, >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >>> But if that message was truly important, there is noting about >>> the DNSbl mechanism to keep the originator from reaching the >>> recipient by telephone. If the message was important, the >>> originator can use other mechanisms, but only if they have >>> been informed that the message did not get through. >> >> You are assuming it is important to the originator. I am more concerned >> with the destination. If I need to buy a computer and I can't get through >> to the first guy on the list, there are dozens more I can visit. In the >> long run, it is not all that important to me where I spend my money. How >> important is it to you as the seller? And I can come up with many more >> examples of how this badly broken system is affecting some people's ability >> to do business. Sadly, it is usually the more competent businesses whor >> are trying to do things right who are bearing the brunt of the burden. > > Businesses exercise the degree of care they feel appropriate, > and get the results they deserve. > > In some cases, missing potential customers who cannot deal with > a non-delivery notice might be a benefit. How can you say that? Tow (who was the basis of my PLI example) needs to sell compilers. Guys who right business applications in PLI have no need whatsoever to understand how SMTP works. Do you think the carpenter who saws the boards to build your house knows all the physics of the electric motor in his saw? Why would he need to? My wife uses the DVD player all the time. Do you think she has clue how it works? If you are in business it is your responsibility to bring in all the business you can in order to thrive. I doubt any businessman today would agree that the inteligence of their customers should be a deciding factor in whether or not to sell them a widget. Just look at the drivers here in PA. It's obfvious that the car dealers don't take inteligence into consideration. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 18 Jun 2007 17:19:08 -0400 From: "Richard B. Gilbert" Subject: Re: PLUG: PMAS Message-ID: <4676F6CC.1010705@comcast.net> Bill Gunshannon wrote: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >>In article <5dnpa6F35gc3pU4@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> >>>In article <80R3AqzfeC3y@eisner.encompasserve.org>, >>> Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> >>>>But if that message was truly important, there is noting about >>>>the DNSbl mechanism to keep the originator from reaching the >>>>recipient by telephone. If the message was important, the >>>>originator can use other mechanisms, but only if they have >>>>been informed that the message did not get through. >>> >>>You are assuming it is important to the originator. I am more concerned >>>with the destination. If I need to buy a computer and I can't get through >>>to the first guy on the list, there are dozens more I can visit. In the >>>long run, it is not all that important to me where I spend my money. How >>>important is it to you as the seller? And I can come up with many more >>>examples of how this badly broken system is affecting some people's ability >>>to do business. Sadly, it is usually the more competent businesses whor >>>are trying to do things right who are bearing the brunt of the burden. >> >>Businesses exercise the degree of care they feel appropriate, >>and get the results they deserve. >> >>In some cases, missing potential customers who cannot deal with >>a non-delivery notice might be a benefit. > > > How can you say that? Tow (who was the basis of my PLI example) needs > to sell compilers. Guys who right business applications in PLI have no > need whatsoever to understand how SMTP works. Do you think the carpenter > who saws the boards to build your house knows all the physics of the > electric motor in his saw? Why would he need to? My wife uses the > DVD player all the time. Do you think she has clue how it works? > > If you are in business it is your responsibility to bring in all the > business you can in order to thrive. I doubt any businessman today > would agree that the inteligence of their customers should be a deciding > factor in whether or not to sell them a widget. Just look at the > drivers here in PA. It's obfvious that the car dealers don't take > inteligence into consideration. :-) You mean the drivers who seem to have mistaken the Interstate Highway Number for the speed limit? I think that the ONLY reason drivers are not going 276 MPH on the turnpike is that their vehicles are simply not capable of it. :-) On I-95 now. . . . ------------------------------ Date: 18 Jun 2007 21:35:02 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: PLUG: PMAS Message-ID: <5doc46F35ajpjU5@mid.individual.net> In article <4676F6CC.1010705@comcast.net>, "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> >> Just look at the >> drivers here in PA. It's obfvious that the car dealers don't take >> inteligence into consideration. :-) > > You mean the drivers who seem to have mistaken the Interstate Highway > Number for the speed limit? I think that the ONLY reason drivers are > not going 276 MPH on the turnpike is that their vehicles are simply not > capable of it. :-) On I-95 now. . . . That little part of I-95 in PA is nothing compared to down south. My last trip back up from Ft. Gordon I locked the cruise on 85 and stayed there all the way to Ft. Belvoir. I had to stay in the far right-hand lane as I was part of the slow traffic!!! I did get real good gas mileage, though. :-) And anyway, driving fast isn't a problem. If they could actually drive. PA drivers seem to lack a basic understanding of things like red lights, stop signs, yield signs. And then we have the left turn on red. Oh wait, then we have the gal who tried to make a left turn into a one way street and when she saw she couldn't do that she just drove up over the curb and went down the sidewalk. (I am not joking!!!) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 18 Jun 2007 17:42:10 -0400 From: "Richard B. Gilbert" Subject: Re: PLUG: PMAS Message-ID: <4676FC32.5020305@comcast.net> Bill Gunshannon wrote: > In article <4676F6CC.1010705@comcast.net>, > "Richard B. Gilbert" writes: > >>Bill Gunshannon wrote: >> >>> Just look at the >>>drivers here in PA. It's obfvious that the car dealers don't take >>>inteligence into consideration. :-) >> >>You mean the drivers who seem to have mistaken the Interstate Highway >>Number for the speed limit? I think that the ONLY reason drivers are >>not going 276 MPH on the turnpike is that their vehicles are simply not >>capable of it. :-) On I-95 now. . . . > > > That little part of I-95 in PA is nothing compared to down south. My > last trip back up from Ft. Gordon I locked the cruise on 85 and stayed > there all the way to Ft. Belvoir. I had to stay in the far right-hand > lane as I was part of the slow traffic!!! I did get real good gas > mileage, though. :-) > > And anyway, driving fast isn't a problem. If they could actually drive. > PA drivers seem to lack a basic understanding of things like red lights, > stop signs, yield signs. And then we have the left turn on red. > > Oh wait, then we have the gal who tried to make a left turn into a one > way street and when she saw she couldn't do that she just drove up over > the curb and went down the sidewalk. (I am not joking!!!) > > bill > Pennsylvania has no monopoly! I think it was in New York state that I saw a woman who had missed her exit backing up on the interstate! The least she could have done was put her children in a taxi; they only have half her genes. . . . ------------------------------ Date: Mon, 18 Jun 2007 21:56:19 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: PLUG: PMAS Message-ID: In article <5dnrfgF32rpkjU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >In article , > "Tom Linden" writes: >> On Sun, 17 Jun 2007 01:05:55 -0700, P. Sture >> wrote: >> >>> In article <1378kfui13fk00@corp.supernews.com>, >>> Mark Daniel wrote: >>> >>>> Bill Gunshannon wrote: >>>> > In article , >>>> > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to >>>> reply) >>>> > writes: >>>> > >>>> >>In article <1378bo75v2pl6a1@corp.supernews.com>, Mark Daniel >>>> >> writes: >>>> >> >>>> >> >>>> >>>And I thought the SPAM load was moderating (silly me). >>>> >>> >>>> >>>Looking for a specific e-mail I thought I should have received, I >>>> just >>>> >>>opened my PreciseMail Anti-SPAM quarrantined messages page to search >>>> for >>>> >>>it (without success). I don't do this often and haven't for a while >>>> >>>(obviously not since the last upgrade). Towards the top of the >>>> >>>2,967,263 byte report page is a (new to me) item "(Messages: 4605)". >>>> >>>That's four and one half thousand quarrantined SPAM in the past 14 >>>> days! >>>> >>> This is something like 328 per day!! >>>> >> >>>> >>That seems about average. I've resorted to using ZEN.SPAMHAUS.ORG as >>>> an >>>> >>RBL. That gets rid of the lion's share. >>>> > >>> >>> I've just started using that zen.spamhaus.org as well, and the spam on >>> my VMS system has dropped significantly as a result. >>> >>>> > So, how bad does it have to get before I can expect people to start >>>> > looking at my suggestion for a social solution rather than technical >>>> > solutions that may hide the problem but certainly don't reduce it or >>>> > the load it puts on the system? >>>> > >>>> > bill >>>> >>>> Isn't this a little like suggesting a social solution to the problem of >>>> crime :-) I'd guess that as long as there is profit to be made there >>>> will be such activities. >>>> >>>> I have a telephone answering machine primarily to screen tele-marketers. >>>> Best AU$50 I ever spent. But the marketers will continue to call as >>>> long as people respond to those calls (with interest, dollars, etc.) >>>> Those who wish to speak to me leave a message (or I pick-up). Not had a >>>> single message from a marketer or charity asking me to call them back. >>> >>> FWIW, I've discontinued my land line and survive with a cell phone at >>> the moment. That's obviously not an option for everyone, but it's been >>> effective for me. My snail-mail box is now under attack, but that's >>> still nowhere near as bad as it was in the UK a decade ago. >>> >>>> The solution surely will be technological, perhaps digital signatures >>>> and associated PKI, to reduce the effectiveness of general SPAMing thus >>>> reserving the activity for specialised crime rather than the general >>>> mugging we all endure now. >>> >>> My ISP has recently tightened things up, as a couple of months ago the >>> spam volume dropped. Unfortunately, I believe I lost some valid emails >>> as well :-( >>> >>> About 18 months ago they implemented SMTP authentication, but I don't >>> think they were enforcing it for quite a while. >>> >>> The latest development is that the appear to be enforcing the use of my >>> registered address in the From: field. Until recently, I could happily >>> cc a news group posting via email using the munged .nospam sending >>> address you see above, but now that fails unless I use my real address >>> (a bit more research needed here to confirm this theory). >>> >>> Not what I want to keep my real address munged for news groups, but a >>> pretty minor inconvenience if it really does stop zombies connected to >>> my ISP from spewing spam. >>> >> Why not be your own ISP? I am. My 'ISP' only provides me with a T1 pipe. >> So I run my own DNS and Mail, in fact, it runs on each node under >> loadbroker. >> You could do the same even with DSL. > >How does your running your own ISP fix the email for the guy who wants >to do business with you but his ISP is BLed? he will end out taking >his business to someone who runs as shoddy an email system as his own. >Talk about the mediocre winning the battle. > >But, let me throw this out for consideration. You don't have to >answer publicly, just give it some thought. How many customers >do you have? Wouldn't it be better for all concerned if you could >establish a trust relationship such that you could know with 100% >certainty that all of their emails to you and all of yours to them >would get thru? If you knew that all of your existing customers >had a guaranteed pipe into your system wouldn't filtering for new >potential customers be easier than trying to filter for SPAM? >Keywords: PLI PL/I PL1 PL/1 PL-I PL-1 PLM SPL "Subset G" >How much SPAM is likely to match that? > What's that a keyword for every customer ? That's really going to scale. David Webb Security team leader CCSS Middlesex University > >bill > >-- >Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >bill@cs.scranton.edu | and a sheep voting on what's for dinner. >University of Scranton | >Scranton, Pennsylvania | #include ------------------------------ Date: 18 Jun 2007 16:59:23 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: PLUG: PMAS Message-ID: In article <5doas6F35ajpjU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> In some cases, missing potential customers who cannot deal with >> a non-delivery notice might be a benefit. > > How can you say that? Tow (who was the basis of my PLI example) needs > to sell compilers. Guys who right business applications in PLI have no > need whatsoever to understand how SMTP works. But if they have a PLI problem, their ability to follow a logical path (consult their local email specialist) can be quite predictive of their ability to communicate their PLI problem to the vendor. That, in turn, affects the profitability of Kednos. ------------------------------ Date: Tue, 19 Jun 2007 01:24:12 GMT From: "John E. Malmberg" Subject: Re: PLUG: PMAS Message-ID: <0fGdi.109670$n_.91761@attbi_s21> Phillip Helbig---remove CLOTHES to reply wrote: > > Yes, as soon as it is clear what IP address it is coming from, it gets > rejected. > > Again, if I'm blocking him, so are lots of other people, so an > explanatory message helps everyone. And of course the sender will not realize that most of the commercial spam filters are silently deleting their messages. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Tue, 19 Jun 2007 03:13:55 GMT From: "John E. Malmberg" Subject: Re: PLUG: PMAS Message-ID: Bill Gunshannon wrote: > > Believe it or not, this is one of the upsides to my idea. It would, > hopefully, spawn some new businesses specifically to provide "clean" > email sites. But the reality today is that probably 90% of the current > MTA servers are run by clueless sys admins. It is my understanding that all servers by RFC are required to have a valid rDNS. Several major e-mail providers have tried to enforce this check and found that they could not because too many real mail servers that they could not afford to block did not have the basic competency to set an rDNS. A strict rDNS check will eliminate zombies from being able to easily pretend to be real mail servers, and will significantly impact the ability to send spam. Essentially the spam problem is from three points: 1. Network owners that do not act on complaints. 2. Network owners that do not configure their mail server identification correctly according to RFCs. 3. Network owners that are willingly spam havens. A new mail protocol will not eliminate these problems. Some parts of this discussion are becoming repetitive. I have made several points, that have not been refuted, mainly just ignored. 1. The state of the art of automated spam filtering is that over 99% of spam can be removed with out impacting real messages. Just because there are popular spam filters and techniques that do not do it right does not invalidate that point. It just demonstrates that those filters are not state of the art. I have seen nothing posted today or on any other day that disputes point number 1. 2. There is a large misconception and a lot of posts on many forums claiming high error rates of DNSbls. I have seen none backed up with a real example from a mainstream used blocking list. In fact I have not seen an example from an aggressive blocking list known for false Unfortunately it appears here that perception remains with those that previously held it, even though no one has produced any evidence to show a specific real e-mail rejected for being in a mainstream used blocking list. 3. There seems to be a great concern about having a real e-mail accidentally rejected because of a DNSBL, but no concern about it being lost from other causes, including end user spam filters, which can not notify the sender of misclassification. SMTP does not guarantee delivery or notification of non-delivery. The less effective spam filtering is, the higher the odds of e-mail getting lost for other reasons. That is not being taken into account in the criticisms of DNSbls use. -John wb8tyw@qsl.network Personal Opinion Only ------------------------------ Date: Mon, 18 Jun 2007 20:25:08 -0700 From: DeanW Subject: Re: PLUG: PMAS Message-ID: <3f119ada0706182025p72dac32anc9e7d62a23461145@mail.gmail.com> On 6/18/07, Phillip Helbig---remove CLOTHES to reply wrote: > In article > <3f119ada0706180754k73dc90b8yba7e384fa45e6dff@mail.gmail.com>, DeanW > writes: > > > > > 1) Delaying- the first time it sees a message from IP, from USER, to > > > > RECIPIENT, it returns a "temporary failure" and logs the triplet. If > > > > that triplet comes up again in < 5 minutes, it gets rejected again and > > > > logged as a spammer. If more than 5 minutes, then it's considered a > > > > valid sender, and logged as such; future messages are not delayed > > > > (unless it fails one of the subsequent spam checks). If it doesn't > > > > come back in 24 hours, the entry is purged. > > > > > > This is known as greylisting. > > > > Yes, it is frequently called greylisting. ASSP had already been using > > that term for something else, so to avoid confusion, ASSP calls it > > greylisting (at least for now). Yeah, it's the before coffee thing. That should have read "ASSP calls it delaying (at least for now)." They may or may not be trying to reconcile their naming with the rest of the world; it's an Open Source project, with all that implies. :-/ ------------------------------ Date: 18 Jun 2007 16:56:06 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: PLUG: PMASg email servers (was: Message-ID: In article <5doagvF35ajpjU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > Ummm.... I have received over 20 Reject: messages today all claiming > to be from the mail server "cs.uofs.edu". My server didn't generate > any of them. The administrator of cs.uofs.edu should configure it to reject forged messages. ------------------------------ Date: Mon, 18 Jun 2007 14:58:38 -0400 From: "Richard B. Gilbert" Subject: Re: Question about TCPIP$ftp - copy taking a long time Message-ID: <4676D5DE.30906@comcast.net> Chuck Aaron wrote: > Does anyone have an idea as to why a small file might be > taking so long to copy? The client is logging into the system > from outside and then ftp/copying files into the system for > updates. The files are numerous but very small. > > Thanks. I suspect that maybe copying the file is not slow but opening the connection, creating the file, and closing it is adding quite a bit of overhead. To see what I mean, copy a hundred files of one block each and compare the time with that required to copy one file of one hundred blocks. ------------------------------ Date: Mon, 18 Jun 2007 16:50:46 -0400 From: JF Mezei Subject: Re: Question about TCPIP$ftp - copy taking a long time Message-ID: Chuck Aaron wrote: > Does anyone have an idea as to why a small file might be > taking so long to copy? The client is logging into the system > from outside and then ftp/copying files into the system for > updates. The files are numerous but very small. You need to provide more information. You can increase FTP performance with : $DEFINE/SYSTEM TCPIP$FTP_WINDSIZ 4096 Other than that, you need to provide much mroe details about what type of files are being transfered and what the remote client reports as speed of transfers. ------------------------------ Date: Tue, 19 Jun 2007 06:09:26 +0200 From: "P. Sture" Subject: Re: Question about TCPIP$ftp - copy taking a long time Message-ID: In article , JF Mezei wrote: > Chuck Aaron wrote: > > Does anyone have an idea as to why a small file might be > > taking so long to copy? The client is logging into the system > > from outside and then ftp/copying files into the system for > > updates. The files are numerous but very small. > > You need to provide more information. You can increase FTP performance > with : > > $DEFINE/SYSTEM TCPIP$FTP_WINDSIZ 4096 > > Other than that, you need to provide much mroe details about what type > of files are being transfered and what the remote client reports as > speed of transfers. Also check that the NIC in your VMS system is set up correctly. Alphas are typically not very good at auto-negotiating network speeds. I came across an example of this recently, where a NIC was set at the console to "Fast". The resulting network speed appeared to be OK for SSH sessions, but FTP was chugging along at modem speeds. In the particular hardware mix in this case, setting the NIC to FastFD solved the problem. -- Paul Sture ------------------------------ Date: Mon, 18 Jun 2007 23:45:33 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Question about TCPIP$ftp - copy taking a long time Message-ID: <07061823453382_202003EE@antinode.org> From: "P. Sture" > [...] Alphas > are typically not very good at auto-negotiating network speeds. > > I came across an example of this recently, where a NIC was set at the > console to "Fast". The resulting network speed appeared to be OK for SSH > sessions, but FTP was chugging along at modem speeds. And they're particularly bad at auto-negotiating network speeds when the system manager manually sets the network speed instead of letting them auto-negotiate. I've never had any trouble with auto-negotiation, but that's probably due to my state-of-the-art hardware (AlpSta 200 4/233, PWS 500a, XP1000; cheapest, stupidest network swtiches I could find; and so on). ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: 19 Jun 2007 07:47:22 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Question about TCPIP$ftp - copy taking a long time Message-ID: <46778a0a$1@news.langstoeger.at> In article , JF Mezei writes: >Chuck Aaron wrote: >> Does anyone have an idea as to why a small file might be >> taking so long to copy? The client is logging into the system >> from outside and then ftp/copying files into the system for >> updates. The files are numerous but very small. > >You need to provide more information. You can increase FTP performance >with : > >$DEFINE/SYSTEM TCPIP$FTP_WINDSIZ 4096 Remove the "I". That is TCPIP$FTP_WNDSIZ -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 18 Jun 2007 15:46:18 -0400 From: JF Mezei Subject: Re: Question for the Group Message-ID: <7ce15$4676e117$cef8887a$27462@TEKSAVVY.COM> Bill Gunshannon wrote: > How about the fact that it can't be done and that the investment that > wold be needed to do it would be astronomical with little cahnce to > rrecoup the investment as your just not going to displace Windows. I really despise such arguments, and it is probably such arguments used by Stallard/Livermore and company to convince Hurd it isn't worth lifting a finger for VMS. IA64 is out of the small systems and desktops and laptops because it is a failure. Microsoft has totally abandonned desktop IA64s, and partially abandonned IA64 servers (with only a small proprtion of its portfolio planned for those IA64 things). So lack of VMS success on desktop and small systems cannot be blamed on VMS, it should be blamed on IA64. > Other options exist today and they never get more than a tiny percent > of the market dominated by Windows. Correct. But the market is large enough that a tiny percentage can still be quite profitable. And having a presence means that when Microsoft stumbles you can pick up pieces and grow. Apple and Ubuntu/Linux wouldn't forcefully nudge their way in this warket it it were totally useless. And for VMS, returning to small systems and desktops may not immediatly bring Office etc, but it would bring the marketing of VMS being scalable, making it easier for VMS to be used by developpers, and more importantly, allow VMS workstations to be deployed in clusters for serious applications that make workstation management much easier and also make those workstations more reliable and more secure (intrusion and viruses). Consider some specialised stock trading or currency exchange application where you have a single app running on those workstations and you want that app to be 200% reliable. No ISV can commit to a VMS solution as long as VMS management and HP continue to say that there is no room for VMS on the desktop. It is the combination of desktop and servers that make VMS really interesting and truly shines the light on its superior clustering and gives it clustering abilities nobody has. ------------------------------ Date: Mon, 18 Jun 2007 16:12:51 -0400 From: JF Mezei Subject: Re: Question for the Group Message-ID: <95be2$4676e750$cef8887a$29134@TEKSAVVY.COM> AEF wrote: > I thought VMS was a higher-margin product than that. Maybe not. I > think it certainly used to be and people were willing to pay more for > quality. When you are trying to show VMS in a bad light, you will show only the profit margin on hardware sold for VMS. When you are trying to show VMS in a good light, you will show not only the hardware, the software but more importantly, the support/services revenus from that other division which are VMS related. Consider those 100k VAX systems still under support. That is raw profit that goes to the support/services division, it doesn't go to the VMS group. So someone must go beyond the internal dept by dept figures and look at the big picture for VMS to get a good idea of its ecosystem within HP. But to do this, one would need to want to push for VMS within HP, and since the higher ups are not interested, they prefer to just mention the VMS department's low numbers and then brag about how much support revenus are geerated by HP-UX (when in fact a lot of those revenus are produced by VMS customers). ------------------------------ Date: Mon, 18 Jun 2007 16:42:58 -0400 From: JF Mezei Subject: Re: Question for the Group Message-ID: Michael Kraemer wrote: >> WTC success stories. > > And how often should I assume WTC-like events will happen ? As often as there are hurricane/cyclone/typhoon events, as often as there are severe storms/tornadoes, severe flooding etc. And you can add to that the ever popular backhoe, the ultimate terrorist tool designed by terrorists to be used by normal people to inadvertently take out important telecom lines and cause havok. Backhoes have cause far more damage to IT services than any crop duster, yet the uS govt is far more concerned about crop dusters than backhoes :-) Protection from backhoes includes having trustable and accurate underground plans to ensure that when the terrorist tool arrives in your area, you know which section of land to defect against this terrorist. Example: large US home renovation is building a big box store over a section of an older shopping centre. Turns out that the plans on paper had not been followed to the letter when they built the original shopping centre and some water, electrical and telecom conduits had been diverted because the original routing couldn't be used due to the presence of a very large rock. As a result, the backhoes pierced through all of them as they were digging in an area they thought was free of such conduits. ------------------------------ Date: Mon, 18 Jun 2007 22:11:24 GMT From: John Santos Subject: Re: Question for the Group Message-ID: Michael Kraemer wrote: > Bob Koehler schrieb: > >>> >>> This story is as old as 1988. >>> BTW, a possible reason why VMS wasn't affected might by >>> they didn't have TCP back then. Sometimes it seems to be >>> an advantage to be behind. >> >> >> >> We certainly did have IP back then. > > > I think UCX came later, 1989 ? > >> >>> A little googling would reveal that around the same >>> time there certainly were a lot of successful VMS hacks going on, >>> some of them are listed at >>> http://www.geocities.com/SiliconValley/Lab/7378/hacker.htm >>> Wasn't there this easy possiblity to break in with some >>> field engineer password ? >> >> >> >> Knowing a password will allow you to break in to any computer. > > > If it's particularly easy to obtain such passwords, > it is an inherent weakness of that platform. > But I assume they have fixed that by now. Not really, the passwords weren't obtained from the platform, they were obtained from reading the documentation. The problem was the default passwords were listed there, and the installation procedure recommended but did not force you to change them. Anyone who had changed the passwords was totally safe. This was of course fixed almost 20 years ago. (The next version of VMS forced you to change the passwords during the installation and upgrade, and validated them to prevent using trivial passwords.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Tue, 19 Jun 2007 00:25:14 +0200 From: Michael Kraemer Subject: Re: Question for the Group Message-ID: JF Mezei schrieb: > > When you are trying to show VMS in a bad light, you will show only the > profit margin on hardware sold for VMS. > > When you are trying to show VMS in a good light, you will show not only > the hardware, the software but more importantly, the support/services > revenus from that other division which are VMS related. > > Consider those 100k VAX systems still under support. That is raw profit > that goes to the support/services division, it doesn't go to the VMS group. Do you know this for sure ? The way HP Q2 results are presented at openvms.org (certainly not a site inclined to show VMS in a bad light) suggests that all of VMS belongs to BCS. ------------------------------ Date: Tue, 19 Jun 2007 00:33:19 +0200 From: Michael Kraemer Subject: Re: Question for the Group Message-ID: JF Mezei schrieb: > > Apple and Ubuntu/Linux wouldn't forcefully nudge their way in this > warket it it were totally useless. they are a lot better positioned than VMS. For ages. > And for VMS, returning to small systems and desktops may not immediatly > bring Office etc, but it would bring the marketing of VMS being > scalable, making it easier for VMS to be used by developpers, and more > importantly, allow VMS workstations to be deployed in clusters As I have been told by former employee Mr. Hoffmann a couple of posts ago, it was DEC who have opted out of the VMS workstation market, long ago, in the 1990s. > for > serious applications that make workstation management much easier and > also make those workstations more reliable and more secure (intrusion > and viruses). since when are non-M$ workstations vulnerable to viruses ? ------------------------------ Date: Mon, 18 Jun 2007 15:40:46 -0500 From: Chris Subject: UCX Printer connection Via LPD Message-ID: We have a situation where it seems that the LPD prints going to the printer are not RFC1179 compliant. Instead of the traditional Control file / Data file (or Data file / control file) we are getting two data file requests. One is dfA the other is dfB and no control file. This is DEC TCP Services. Anyone have any ideas to force this to follow RFC1179, or is just some other issue? TIA ------------------------------ Date: Mon, 18 Jun 2007 22:13:14 -0500 From: David J Dachtera Subject: Re: UCX Printer connection Via LPD Message-ID: <467749CA.1904B16B@spam.comcast.net> Chris wrote: > > We have a situation where it seems that the LPD prints going to the > printer are not RFC1179 compliant. Instead of the traditional Control > file / Data file (or Data file / control file) we are getting two data > file requests. > > One is dfA the other is dfB and no control file. > > This is DEC TCP Services. > > Anyone have any ideas to force this to follow RFC1179, or is just some > other issue? Huh? Unless it has changed, the exhibited behavior is correct: first the print data is sent, then the control data telling how to print it is sent. The receiver must be prepared to buffer the entire print job so that when the control data is received, the job can be printed as directed. I don't keep up with it, but I've not been previously apprised of any changes to it, either here or in the Solaris/x86 or AIX newsgroups. Up until now, there was, AFAIK, never an RFC to DEFINE the lp protocol, only an RFC that DOCUMENTS existing behavior based on observation and some reverse engineering. If it weren't bed time, I'd look it up myself. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 18 Jun 2007 23:09:37 -0500 From: Chris Subject: Re: UCX Printer connection Via LPD Message-ID: David J Dachtera wrote: > Chris wrote: >> We have a situation where it seems that the LPD prints going to the >> printer are not RFC1179 compliant. Instead of the traditional Control >> file / Data file (or Data file / control file) we are getting two data >> file requests. >> >> One is dfA the other is dfB and no control file. >> >> This is DEC TCP Services. >> >> Anyone have any ideas to force this to follow RFC1179, or is just some >> other issue? > > Huh? Unless it has changed, the exhibited behavior is correct: first the print > data is sent, then the control data telling how to print it is sent. The > receiver must be prepared to buffer the entire print job so that when the > control data is received, the job can be printed as directed. > > I don't keep up with it, but I've not been previously apprised of any changes to > it, either here or in the Solaris/x86 or AIX newsgroups. > > Up until now, there was, AFAIK, never an RFC to DEFINE the lp protocol, only an > RFC that DOCUMENTS existing behavior based on observation and some reverse > engineering. > > If it weren't bed time, I'd look it up myself. > No you are correct, there should be one control file and one Data file not necessarily in that order. I can clearly see TWO data files one that starts with dfA and another that is dfB, and NO control file. I have never seen this behavior out of a UCX print connection. I was called in the deal with this situation, any ideas where to look for any "non-standard" LPD settings in UCX? The only software I have ever seen that can do this is LPRng, but it is only for UNIX, not OpenVMS... Unless I missed something. You are also correct that RFC1179 was a reverse engineer of the BSD printing method and is the poorest RFC in print I think. I have NEVER seen this is 10+ years supporting printing... Any hints are appreciated. Chris, ------------------------------ Date: 18 Jun 2007 14:19:53 -0400 From: Rich Alderson Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article , Rich Alderson >> writes: >>> To most non-VMS/non-Tops-20 people, speaking of a hierarchical filesystem >>> implies a single system-wise filesystem root, a la Multics. >> Nonesense. You speak as if no one has ever seen MS-DOS, or Windows. I've already conceded the point in another post. > Or MacOS 7.5, 8.* and 9.*. The Heirarchical Filesystem (HFS) was introduced to MacOS in version 2.4 or so, as I recall. As a continuous Mac owner since early 1984, I should have known better than to post what I did. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: Mon, 18 Jun 2007 19:25:45 -0700 From: Ken Fairfield Subject: Re: Why partitioned disks on VMS would be useful Message-ID: <5dot92F359qh9U1@mid.individual.net> P. Sture wrote: > In article <5dedvfF354er1U1@mid.individual.net>, > Ken Fairfield wrote: [...] >> However, the biggest problem was booting all 30-or-so VAXstations >> after an upgrade. Even pacing them in groups of 4 at a time, separated >> by 5-10 minbutes, it turned out that "OPCOM storms" were my biggest >> problem. :-( Once I got the correct OPC* logicals figured out, that >> problem pretty much went away. :-) > > You have me wondering there... going back to the first upgrade I did to > V6.2, a pair of Alphas stopped creating OPERATOR.LOG. It appears that > the startup code was changed to say "we've got a graphics head therefore > we are a workstation, and don't need operator logs". That would have > solved your problem, but in our case, that pair of Alphas were servers > where we wanted the logs. That sounds familiar. I'm not even sure you could control the incoming and/or outgoing OPCOM messages before V6.x (not all the OPC$* logicals had been implemented) without disabling OPCOM altogether. -Ken -- Ken & Ann Fairfield What: Ken dot And dot Ann Where: Gmail dot Com ------------------------------ End of INFO-VAX 2007.331 ************************