1 INFO-VAX	Tue, 28 Nov 2006	Volume 2006 : Issue 654       Contents:. Re: A place where non-mention of VMS is good !. Re: A place where non-mention of VMS is good !. Re: A place where non-mention of VMS is good !% CDL VMS fatal drive error Observation ) Re: CDL VMS fatal drive error Observation , Cluster connection lost when one link fails? Re: DECW$SERVER crashes (8.3)  Re: DECW$SERVER crashes (8.3)  Re: DECW$SERVER crashes (8.3) , Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it Re: interested in wombats $ Re: Is HP trying to kill VMS again ? Re: Mouse: thumbwheel support  Re: OpenVMS Support Issues Re: OpenVMS Support Issues Re: optimal drives for HSG80 public-key ssh into VMS 7.3-1 ! Re: public-key ssh into VMS 7.3-1 ? Re: Reloading Alpha drivers, was: Re: Mouse: thumbwheel support 4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC4 Re: Thoughts on the book: DEC is dead, long live DEC [sFTP] Current situation?  Re: [sFTP] Current situation?   F ----------------------------------------------------------------------    Date: 27 Nov 2006 14:29:05 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 7 Subject: Re: A place where non-mention of VMS is good ! 3 Message-ID: <MZq+ygSH0gDe@eisner.encompasserve.org>   d In article <ekeuh1$173v$2@pyrite.mv.net>, Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes: > F >    The original poster is likely referring to LAN traffic involving I > DECnet or (unencrypted IP), or to cluster SCS traffic.  LAN traffic is  I > still sensitive, and it's not encrypted using standard configurations.  # > If you can sniff the local LAN...   E    I know of no situation where SCS transmits usernames or passwords,     can you tell us where it is?   E    As far as using DECnet, LAT, TELNET, ..., I can do all of those on D    my Linux, AIX, HP-UX, ..., boxes, too.  Or I can install point toB    point encrytption hardware.  Or I can use ssh like I do on VMS.  B    And nobody sniffs our LANs without prior authorization.  That's    a basic part of security.   ------------------------------  % Date: Mon, 27 Nov 2006 20:49:23 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>7 Subject: Re: A place where non-mention of VMS is good ! ) Message-ID: <ekg4j4$1iif$1@pyrite.mv.net>    Bob Koehler wrote:f > In article <ekeuh1$173v$2@pyrite.mv.net>, Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes:G >>    The original poster is likely referring to LAN traffic involving  J >> DECnet or (unencrypted IP), or to cluster SCS traffic.  LAN traffic is J >> still sensitive, and it's not encrypted using standard configurations. $ >> If you can sniff the local LAN... > G >    I know of no situation where SCS transmits usernames or passwords, ! >    can you tell us where it is?   H    Cluster SCS traffic must either be secured and/or encrypted, whether G the traffic is on a LAN or a bridge, or you have to assume or posit or  C mandate that there will be no unauthorized access to the datalink.  G Keeping the cluster traffic behind a bridge or router or firewall is a  G reasonable configuration, and obviously restricting physical access is   also goodness.  A    I will avoid describing the details of available or potential  E security attacks here.  Most readers here are certainly not going to  F mis-use security-related information, but some few folks reading this 
 can and will.   G >    As far as using DECnet, LAT, TELNET, ..., I can do all of those on F >    my Linux, AIX, HP-UX, ..., boxes, too.  Or I can install point toD >    point encrytption hardware.  Or I can use ssh like I do on VMS.  :    Yes, you can do insecure things with most any platform.  7    Controller-level encryption would plug the exposure.   A    Some of the more paranoid organizations in existence will use    hardened and/or alarmed conduit.  D >    And nobody sniffs our LANs without prior authorization.  That's >    a basic part of security.  G    Another basic tenet of security is the assumption that the bad guys  ) don't and won't seek prior authorization.    ------------------------------  % Date: Mon, 27 Nov 2006 23:36:20 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: A place where non-mention of VMS is good ! 7 Message-ID: <c4b09$456bbcaa$cef8887a$4384@TEKSAVVY.COM>    Bob Koehler wrote:G >    I know of no situation where SCS transmits usernames or passwords, ! >    can you tell us where it is?   	 How about 
 $MC SYSMAN3 SYSMAN> SET ENV/NODE=DRWHO/USER=ROSE/PASSWORD=TYLER  SYSMAN> DO DIR  L Wouldn't that implicitely send a username/password over SCS ? Or does it go  out unencrypted over decnet ?    ------------------------------    Date: 27 Nov 2006 17:50:54 -0800) From: "kiwi-red" <antonywardle@gmail.com> . Subject: CDL VMS fatal drive error ObservationB Message-ID: <1164678654.342792.20080@l39g2000cwd.googlegroups.com>   Hi  G I've been playing with a CDL (Clariion Disk library ) and an es40 7.3-2   A Its configured to emulate a number of tape silo's, so I have been  trying them out.D I wasn't having much luck, as nearly everytime I would initalize the
 tapes I would F get a fatal drive error. If I managed to initialze a tape then I couldE usually write a backup to it. I was struggling to figure out what the E problem was. I found a case study where the CDL was emulating a P3000  and they had no problems.   < Then I thought it was a LUN issue as I have a number of tapeF devices/silo's zoned to the same HBA. After playing around, off and onD for a week, I think I have found the problem. If I initialize a tapeD with media=compaction then it fails. If the backup command has mediaG =compaction it fails, if the mount command has media=compaction then it  fails.  C So far,  I haven't had a problem. Early days, but it might help out D someone else, rather than giving up. I had been doing some sucessfulA backups to a DX30, but don't remember having the same problem, so G either it accepted media=comp or I wasn't using it. I'm not sure which, D as media=comp is something I seem to type without thinking about it.    C Nice to see some bigger throughput figures now I've nicked some SAN  storage. The 20MB from the# local scsi disks was a bit slow ;-)    cheers     kiwi   ------------------------------  % Date: Mon, 27 Nov 2006 20:47:19 -0600 3 From: David J Dachtera <djesys.no@spam.comcast.net> 2 Subject: Re: CDL VMS fatal drive error Observation0 Message-ID: <456BA337.92D2699A@spam.comcast.net>   kiwi-red wrote:  >  > Hi > I > I've been playing with a CDL (Clariion Disk library ) and an es40 7.3-2  > C > Its configured to emulate a number of tape silo's, so I have been  > trying them out.F > I wasn't having much luck, as nearly everytime I would initalize the > tapes I would H > get a fatal drive error. If I managed to initialze a tape then I couldG > usually write a backup to it. I was struggling to figure out what the G > problem was. I found a case study where the CDL was emulating a P3000  > and they had no problems.  > > > Then I thought it was a LUN issue as I have a number of tapeH > devices/silo's zoned to the same HBA. After playing around, off and onF > for a week, I think I have found the problem. If I initialize a tapeF > with media=compaction then it fails. If the backup command has mediaI > =compaction it fails, if the mount command has media=compaction then it  > fails. > E > So far,  I haven't had a problem. Early days, but it might help out F > someone else, rather than giving up. I had been doing some sucessfulC > backups to a DX30, but don't remember having the same problem, so I > either it accepted media=comp or I wasn't using it. I'm not sure which, F > as media=comp is something I seem to type without thinking about it. > E > Nice to see some bigger throughput figures now I've nicked some SAN  > storage. The 20MB from the% > local scsi disks was a bit slow ;-)   N Well, the library type is not important in this case. What matters is the tapeN drive type being emulated. The target drive must support compaction in the way' that the underlying VMS drivers expect.   E Naturally, neither EMC nor OpenVMS will "support" this configuration.   K FWIW, I have an EMC CDL on my production VMS systems at work. The CDL drive < emulation is SDLT-320 and the library emulation is STK L700.  M We're trying to use (formerly Legato) NetWorker with it. The VMS storage node O software only supports SDLT-110, and not SDLT-320 or LTO-3. We're still waiting M for NetWorker to come out with a new version (for Alpha) with up-to-date tape B drive support, else we'll have to scrap it and try something else.  N Even though this is a pre-beta implementation (none of the vendors is preparedI to support this on VMS at this time), we are, none the less, using it for L production. ...or, trying to. So far it's been one brick wall after another.   *DEFINITELY* *NOT* recommended!   M Oh, yeah: when using a physical library (such as STK L700e) to export virtual M tape volumes, off-siting tapes is not supported if the library is shared with P anything else and the library does not support "parking" tapes in the CAP (L700eL doesn't). That doesn't say it can't be done, just be prepared for a *LOT* of work to make it happen!   E I submitted a case-study session of this to HPTF-06. It was declined.    --   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, 28 Nov 2006 00:26:15 GMT 6 From: "Malcolm Dunnett" <info@cruising-for-a-cause.ca>5 Subject: Cluster connection lost when one link fails? , Message-ID: <HmLah.21839$uj6.19121@edtnps89>  G I have two ES40s clustered together. Each system has two DE500 ethernet = cards in it and SCS traffic runs over both adapters. Normally J I can disconnect the cable on one of the cards from either machine and the= cluster continues running, sending the traffic over the other  adapter.  B I had a strange thing happen yesterday though. The ethernet switch: that one adapter from each system connects to began having9 problems (I suspect a bad power supply as the switch kept 8 rebooting every hour or so).  I would normally have said; "no problem" the cluster will just carry on using the other 8 adapters (which don't appear to be having any problems).5 However several times overnight I got one node or the B other doing the old "Node voluntarily exiting cluster". Presumably8 this means that it lost communication on both links. I'm; 99.9% certain there's no hardware problem on the other link ? and in any case I can't believe they'd both intermittently fail  at the same time.   7 Each time the Cisco switch failed it caused a couple of 4 dozen errors to be logged on the VMS system, similar to the following:   L **** V3.4  ********************* ENTRY 5390 ********************************    , Logging OS                        1. OpenVMS* System Architecture               2. Alpha+ OS version                           V7.3-2 $ Event sequence number           333.9 Timestamp of occurrence              27-NOV-2006 08:02:13 5 Time since reboot                    0 Day(s) 0:05:34 + Host name                            MALVM9   5 System Model                         AlphaServer ES40   B Entry Type                       98. Asynchronous Device Attention     ---- Device Profile ----0 Unit                                 MALVM9$EWB0, Product Name                         UNKNOWN  = ---- UNKNOWN DEVICE ----             ----- Not Decoded -----      >           15--<-12  11--<-08  07--<-04  03--<-00   :Byte OrderE  0000:    08020111  000000CA  00000001  0000000B   *................* E  0010:    00000008  00000003  00001103  00000001   *................* E  0020:    00000000  00000002  00000000  00000000   *................* E  0030:                                  00000000   *            ....*    ----- Software Info ----- 6 UCB$x_ERTCNT                     15. Retries Remaining6 UCB$x_ERTMAX                      3. Retries Allowable+ IRP$Q_IOSB                x0000000000000000 + UCB$x_STS                 x50002010  Online 1                                      Template UCB $ VMS DC$_CLASS                    32.$ VMS DT$_TYPE                     77.4 IRP$L_PID                 x00000000  Requestor "PID"5 IRP$x_BOFF                        0. Byte Page Offset = IRP$x_BCNT                        0. Transfer Size In Byte(s) 5 UCB$x_ERRCNT                      5. Errors This Unit 4 UCB$L_OPCNT                       0. QIO's This Unit/ ORB$L_OWNER               x00010004  Owners UIC , UCB$L_DEVCHAR1            x0C442000  Network.                                      Available2                                      Error Logging5                                      Capable of Input 6                                      Capable of Output    H Is it possible that when these errors occured they "distracted" PEDRIVERE long enough to cause a communication loss? Is it reasonable that this = should happen?  Has anyone else experienced similar problems? B It seems that the value of a redundant link is somewhat reduced if< problems in that link can cause the other link to fail also.  B For the time being I've replaced the Cisco switch with a crossover" cable and the systems are stable.    ------------------------------   Date: 27 Nov 06 18:02:24 EST) From: cook@wvnvms.wvnet.edu (George Cook) & Subject: Re: DECW$SERVER crashes (8.3)! Message-ID: <q6aAVskJ2Gg6@wvnvms>   b In article <tvDah.55803$163.54691@newsfe6-gui.ntli.net>, ChrisQuayle <nospam@devnul.co.uk> writes: > FredK wrote:> >> "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message 4 >> news:65f1e$45662aea$cef8887a$4606@TEKSAVVY.COM... >>  N >> Granted, Mozilla is probably giving the X server a much bigger workout thanH >> any app on VAX. But still, I would expect Mozilla to crash, not the X8 >> server (bringing down all other apps in the process). >>   > H > Netscape Alpha for Tru64 had horrendous memory leaks. If you leave it K > running long enough, it eventually runs the system out memory *and* swap  I > space. It wasn't an X or other system problem, both of which were rock   > solid otherwise...  E Not surprising especially considering the chief developer of Netscape D was also the chief developer of NCSA Mosaic.  After fixing countlessF memory leaks in the original NCSA Mosaic code over the last ten years,B I think NCSA Mosaic could accurately be described as a memory leak posing as a browser.     George Cook  WVNET      ------------------------------  % Date: Mon, 27 Nov 2006 23:06:57 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: DECW$SERVER crashes (8.3)8 Message-ID: <6893a$456bb5c8$cef8887a$21187@TEKSAVVY.COM>   FredK wrote:O > Pixmaps are destroyed either by the application explicitly doing it, or when  : > the "display" connection they were created on is closed.  I OK, so if Mozilla forgets to destroy pixmaps when you close a window but  H keep other widnows opened, it would essentially result in a memory leak 3 with those pixmaps remaining there forever, right ?   K Are there any debugging tools to request info from the DECW$SERVER process  N to get it to  list the connections, windows and pixmaps and other structures ?   ------------------------------  % Date: Tue, 28 Nov 2006 05:39:06 +0100 / From: Paul Sture <paul.sture.nospam@hispeed.ch> & Subject: Re: DECW$SERVER crashes (8.3)J Message-ID: <paul.sture.nospam-FAB87D.05390628112006@mac.sture.homeip.net>  F In article <q6aAVskJ2Gg6@wvnvms>, cook@wvnvms.wvnet.edu (George Cook)  wrote:  G > In article <tvDah.55803$163.54691@newsfe6-gui.ntli.net>, ChrisQuayle   > <nospam@devnul.co.uk> writes:  > > FredK wrote:@ > >> "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message 6 > >> news:65f1e$45662aea$cef8887a$4606@TEKSAVVY.COM... > >>  L > >> Granted, Mozilla is probably giving the X server a much bigger workout 	 > >> than J > >> any app on VAX. But still, I would expect Mozilla to crash, not the X: > >> server (bringing down all other apps in the process). > >>   > > J > > Netscape Alpha for Tru64 had horrendous memory leaks. If you leave it M > > running long enough, it eventually runs the system out memory *and* swap  K > > space. It wasn't an X or other system problem, both of which were rock   > > solid otherwise... > G > Not surprising especially considering the chief developer of Netscape F > was also the chief developer of NCSA Mosaic.  After fixing countlessH > memory leaks in the original NCSA Mosaic code over the last ten years,D > I think NCSA Mosaic could accurately be described as a memory leak > posing as a browser. >   I Is that also true of Mozilla and its relatives? FWIW, I've stopped using  G them (Firefox and Thunderbird) on my Mac as both products were causing   me problems.   --  
 Paul Sture   ------------------------------  + Date: Mon, 27 Nov 2006 19:06:26 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk5 Subject: Re: increase in spam and what to do about it , Message-ID: <ekfcvi$51m$1@south.jnrs.ja.net>  [ In article <4t0o6hF11i1kvU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: - >In article <ekc29h$41a$1@south.jnrs.ja.net>, " >	david20@alpha2.mdx.ac.uk writes:^ >> In article <4ssd5nF110jjhU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:E >>>In article <1164427612.373176.124490@m7g2000cwm.googlegroups.com>,  >>>	davidc@montagar.com writes:  >>>> Bill Gunshannon wrote:  >>>>  J >>>> And I guess I'm still not sure exactly how your method is to actuallyB >>>> work, and how all these agreements are executed and enforced. >>> J >>>By making the users (at least the one's you don't trust) sign a legallyJ >>>binding contract that has the ability to impose real penalties on those >>>who violate it. >>>  >> Two problems  >>  P >> 1) One-to-one agreements aren't scalable with the modern internet unless you O >>    severely restrict who you want to talk to which would be unacceptable for  >>    most organisations.  > B >Actually, among the more serious users, it is probably a lot moreE >acceptable than you think.  Many places don't allow the use of their B >email system for anything but official communications both in andD >outside ot their own house.  (ie. Procter & Gamble).  .mil and .gov= >severly restrict what can be accessed from their networks.     O Any company that has customers (or in the case of education institutions wishes M to recruit students ) needs to expect to receive mail from perfect strangers.        >I wouldA >think that places like this would very much like to have a clean @ >network from which they could contact and conduct business withA >their contractors.  As would many other serious .coms.  The only H >one who seems to be likely to prefer being on the outside are the ISP'sE >with their grandma's and their 9 year old users.  I odn't know about F >you, but I really have no need to contact or to be contacted by them. >  >>   >>    ( P >>     note. Usenet News is not a one-to-one agreement between your organisationQ >>     and the senders. You have one-to-one agreements with your Usenet feeds but P >>     they just pass along ALL those newsgroups you have agreed to accept which: >>     in turn have been passed along from their feeds etcP >>     Any particular Usenet posting will have passed through a large number of P >>     Usenet systems, which you have no direct agreement with, before reaching Q >>     your systems. Usenet is also a broadcast system, unlike email, which makes ! >>     such a structure feasible.  > F >Which is why I used Usenet only as an example of how halfway measuresF >helped.  Considering the volume, Usenet has considerably less spam byE >percentage than most emails today.  I saw no spam messages on Usenet F >over the weekend while even with moderate filtering at the server andE >aggressive filtering at the personal mailbox I still had a real/spam C >ratio of 2/183 just over the last 4 days.  This is handled by spam D >filtering and the UDP.  Not much, but it works.  Peering agreementsD >with the email system can do it to, but they would require a systemB >that eliminates the three primary flaws I have already mentioned.1 >Three flaws that NNTP does not have, by the way.  >  If by the three flaws you mean     1) Anonymous access is allowedB 2) Protocol allows anyone, anywhere to connect to anyone, anywhere= 3) Protocol allows for easy address spoofing which adds to 1)   F then they are totally irrelevent if you want to restrict which systems* can send to you via one-to-one agreements.  O Just use SMTP but set your mail system up so that it just accepts mail from the G IP addresses of the mailservers of the people you have agreements with.  Reject all other connections.   L (Such a setup wouldn't as I indicated above be acceptable to most companies N but there is nothing to stop you setting that up. No need to get rid of SMTP).   ( D Of course NNTP does in fact have at least flaws 1) and 3) since you L have no control over what the systems you peer to have peered with and what " systems those have peered with etc )      >>  : >>     Also, of course, Usenet has it's own problems with % >>     inappropriate postings/SPAM.    > = >See above, not even close to the level found in email today.  > L Depends on the groups and when you look. A while back a number of the vmsnetI groups were almost impossible to use because of binary postings of warez.    >>   >>    )  >>   >>  O >> 2)  Getting organisations to sign legally binding contracts with respect to  9 >>     their emission of SPAM is likely to be difficult.   > D >Again, what the agreement ends out being is left as an exercise for@ >the reader.  If you deal with someone who's AUP you are alreadyA >awar of and you know they enforce it draconianly (ie. .mil) then A >you might not require any kind of formal agreement.  I have said @ >the same thing about "communities" like c.o.v.  Strongly wordedB >binding contracts are more likely going ot be for those you don'tC >trust.  they might show you how deterined to work within the rules B >they are.  if they don't want to agree to paly by the rules, send
 >'em packin'.  >  >>   >>  R >> It looks like there was an attempt to set something like this up which overcame0 >> the first problem via the use of a whitelist. >> If you look on  >>  1 >> http://shopping.declude.com/Articles.asp?ID=97  >>  4 >> you'll find a fairly good list of anti-spam lists >>   >> at the bottom it mentions >>   >>  R >> BONDEDSENDER                        -   A whitelist of E-mail senders that have/ >> 					posted a bond to help prove that their   >> 					E-mail is legitimate.  >>   >>  K >> Sadly, if not particularly unexpectedly,  when you go to the url listed  ( >> http://www.bondedsender.org/ you findL >> that the service has been renamed "Sender Score Certified" and no longer 1 >> seems to mention anything about posting bonds.  > E >But, by not eliminating the three flaws I have already mentioned, it E >was doomed from the beginning.  The current system can not be fixed. C >We can try an already existing method that eliminates these flaws, D >we can create a whole new protocol that elimantes these flaws or weD >can stay with the status quo.  Putting a bandaid and some neosporinC >on a wound isn't going to help if the wound is already gangrenous.  > = More likely the participants found themselves hosting zombied L systems despite their best efforts and that persuaded them that agreeing to K pay out lots of money when they couldn't guarantee that they could stop it  $ happening again was not a good idea.     >>   >>   >>>>  I >>>>> > How do you stop it at the source?  Which is the spammer, himself?  >>>>> M >>>>> True.  You stop it by not giving the spammer a venue from which to send N >>>>> his spam.  The sysadmins all agree (by contract) to not allow spam to beN >>>>> sent from their systems. Penalty: ostracism.  The sysadmins of the localN >>>>> mailsystems have AUP's that carry penalties (which depend on the type ofL >>>>> organization, ie. ISP - include hefty fines in your customer contract,L >>>>> business - employee can be fired, school - expulsion or other academicM >>>>> sanctions, etc.)  Thus, the spammer has no place where he is welcome on  >>>>> the new email network. >>  L >>>> Back in the mid '90's, such things were done.  Erols and other networksL >>>> had fines and such for spammers.  It didn't work.  This again referrersH >>>> to the "whack-a-mole" game of spammer termination.  Also, often theL >>>> spammers would sign up with accounts using credit cards of the clients,# >>>> or even stolen credit cards.    >>> / >>>Ummm....   That's a crime, probably federal.  >>> I >>>>                               So you end up not billing or punishing I >>>> the spammer, anyway.  You kill one spammer account, and they have 10 ' >>>> more waiting to abuse when needed.  >>> G >>>If you make the users identify themselves and sign a legally binding F >>>contract you know who they are and they can't have 10 more accounts >>>waiting.  >>>  >>>>  L >>>> Of course, now much spam is from zombied Windows boxes.  The spam can'tK >>>> be traced back past the zombied PC.  So, do you fine and terminate the J >>>> account of the person with the infected PC?  That's going to sit wellJ >>>> with customers.  What about the Wingate proxy exploitation of severalK >>>> years ago?  The proxy would allow SOCK4-like remote access, making the G >>>> Wingate proxy appear to be the source, but no way to determine who L >>>> initiated the connection.  And the wide variety of formmail.pl web formL >>>> abuse that occured (and actually, I STILL had several dozen attempts byD >>>> some spammer to test my form mail web script on the Hobby Site:L >>>> dinotto2@aol.com and topcopl2@aol.com are their test accounts - may theH >>>> harvesters get them)?  And there are still open SOCK4 proxies, openE >>>> SMTP relays, and any number of other methods people are spamming ; >>>> without using mail servers they are authorized to use.  >>> F >>>And, because my proposal doesn't use SMTP at all, none of the above >>>pose a threat.    >>>  >>  ; >> If your not using SMTP then what are you using (UUCP)  ?  >>   >>  6 >> http://www.rhyolite.com/anti-spam/you-might-be.html >>   >> programmer-11) >>     The FUSSP involves replacing SMTP.  > C >I'll visit the site, but I got the idea from other comments I have G >seen that they post mostly humorous stuff.  maybe I have them confused H >with someone else.  Of course, the last line looks like they agree with >me on at least one point. >  >>   >>   >>>>  J >>>> They are already not using email networks where they are not welcome,$ >>>> so why does your solution work? >>> F >>>How are they "not using email networks where they are not welcome"?D >>>Right now, except for private networks, there is only one networkD >>>and everyone who is exchanging email is using it.  Any Email hostC >>>(and many non-legitimate ones like zombied PC's) can contact any F >>>other and 90% of them will accept the connection and the email from
 >>>any other.  >>>  >>>>  L >>>> Also, how do you require uniform AUP's across ISP of various countries? >>> J >>>It is all based on agreements between individuals.  Regardless of whereH >>>one is I can require whatever I want or refuse to let them play in my >>>sandbox.  >>> K >> Your free to set up your own agreements with whatever companies you wish O >> to accept their mail and reject all other mail. It's easy enough to do with  R >> most mailservers (no need to switch to UUCP just set up your mailserver to onlyJ >> accept mail from specific IP addresses). However such a solution isn't P >> acceptable to most companies who want complete strangers (otherwise known as ) >> customers) to be able to contact them.  > K >Which is why my proposal is to run both simultaneously and let the serious F >user migrate as they see the value of it until eventually all of yourG >serious usrs (read real customers) are on the clean system and you can L >pay much less attention to the garbage.  Let me throw one more example out.J >We have all been spammed by someone who got our address from c.o.v.  ManyJ >people have been forced to munging their address (which poses a burden onJ >anyone who wishes to talk to them because they can no longer just use theL >reply option!) or having other mail accounts on other machines specificallyF >for use in Usenet postings, which is certainly a butrden on the user.I >What if the address you used in your Usenet postings couldn't be reached E >by people outside the group, but could be by those within the group? " >Wouldn't that offer an advantage? >  >>   >>>>  M >>>>> Read what I said up above. The customers of the ISP all sign a contract D >>>>> (I know I had to!)  You put serious penalties in the contract. >>>>   >>  E >>>> Yes, but they really have no teeth, the spammers are often using  >>>> fraudulent information,   >>> J >>>If I don't know/trust the individual, I require them to prove who they K >>>are.  How is that any different than when someone walks into a store and H >>>plops a credit card down?  Fraud is illegal.  As near as I know, that2 >>>applies in pretty much every civilized country. >>> D >>>>                         or on ISP which don't have strong AUP,  >>> I >>>I don't let them join the network until they agree to institute an AUP - >>>that meets the requirements of my network.  >>> J >>>>                                                                or the> >>>> spammers are using network which they are not authorized. >>> K >>>Won't be able to use mine.  I will know who is allowed to access my mail + >>>server and no one else will be able to.   >>>  >>>>  I >>>> You are assuming the spammers are Law Abiding Honest Citizens.  That 8 >>>> may be true of Usenet back in the day, not anymore. >>> E >>>In order to join the nework, they will have to positively identify A >>>themselves.  If they choose to violate the law after they have E >>>positively identified themselves, well, that's what the courts are  >>>for.  :-) >>>  >>  L >> Sorry your system will only work if you can impose such rules on all the L >> ISPs and your only weapon against those who don't comply is to stop them K >> sending you mail. Until the majority of internet sites adopt those rules K >> it is simpler for the ISPs to just ignore your rules and let you isolate  >> yourself. > M >But as long as I continue to accept other emails as well, I am not isolated. M >And, as the users I want to communicat4e with begoin to migrate (assuming my L >idea takes hold, of course) I can slowly begin to more and more agressivelyK >filter their garbage and it is eventually they that will be isolated, in a K >sea of spam.  I don't care about that 98% of garbage that makes up most of K >the INTERNET.  I am sure that most real businesses and acadeics doing real I >research and people like c.o.v who share a common interest are the same. G >Let those who really want to get all that spam stay with their ISP and " >take it all in.  I don't want it. >  >>  6 >> http://www.rhyolite.com/anti-spam/you-might-be.html >>   >> senior-IETF-member-5 R >>     The FUSSP won't be effective until it has been deployed at more than 60% of- >>     SMTP servers and that's not a problem.  > N >Mine takes some point at which it attains critical mass as well.  I will lookL >at this FUSSP stuff, but unless it eliminates the three flaws in SMTP it isL >doomed to failure.  And, if it is yet to be implemented in any usable form,L >my proposal still has the advantage.  Given some number of interested emailJ >system admins I can have the first stages of my network up and running inK >less than 24 hours.  The software is already there and the hardware needed K >to run it (especially int he earlier stages) can be found in most people's 
 >junk box. >   K I think you are misunderstanding the FUSSP (Final Ultimate solution to the  J Spam problem) is a general description of solutions such as yours to SPAM.! The full title of the webpage is  ' "You Might be an Anti-Spam Kook If ..."   
 David Webb Security team leader CCSS Middlesex University         I >And, to add even more fuel to the fire, ever hear of HECnet?  It's there H >and I understand it works.  And it really offers much less utility than >what I offer. >  >bill  >  >-- K >Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves E >bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.  >University of Scranton   | B >Scranton, Pennsylvania   |         #include <std.disclaimer.h>      ------------------------------   Date: 27 Nov 2006 19:47:39 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: increase in spam and what to do about it 0 Message-ID: <4t0tmqF11dlt4U1@mid.individual.net>  , In article <ekfcvi$51m$1@south.jnrs.ja.net>,! 	david20@alpha2.mdx.ac.uk writes: ] > In article <4t0o6hF11i1kvU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: . >>In article <ekc29h$41a$1@south.jnrs.ja.net>,# >>	david20@alpha2.mdx.ac.uk writes: _ >>> In article <4ssd5nF110jjhU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: F >>>>In article <1164427612.373176.124490@m7g2000cwm.googlegroups.com>,  >>>>	davidc@montagar.com writes: >>>>> Bill Gunshannon wrote: >>>>> K >>>>> And I guess I'm still not sure exactly how your method is to actually C >>>>> work, and how all these agreements are executed and enforced.  >>>>K >>>>By making the users (at least the one's you don't trust) sign a legally K >>>>binding contract that has the ability to impose real penalties on those  >>>>who violate it.  >>>> >>> Two problems >>> Q >>> 1) One-to-one agreements aren't scalable with the modern internet unless you  P >>>    severely restrict who you want to talk to which would be unacceptable for >>>    most organisations. >>C >>Actually, among the more serious users, it is probably a lot more F >>acceptable than you think.  Many places don't allow the use of theirC >>email system for anything but official communications both in and E >>outside ot their own house.  (ie. Procter & Gamble).  .mil and .gov > >>severly restrict what can be accessed from their networks.   > Q > Any company that has customers (or in the case of education institutions wishes O > to recruit students ) needs to expect to receive mail from perfect strangers.   J Of course they do.  And, that isa only at one address and they have peopleI paid to wade through the garbage (a kind of wetware spam filter :-).  But N I have better things to do with my time.  And my time costs considerably more.   >  >  > 	 >>I would B >>think that places like this would very much like to have a cleanA >>network from which they could contact and conduct business with B >>their contractors.  As would many other serious .coms.  The onlyI >>one who seems to be likely to prefer being on the outside are the ISP's F >>with their grandma's and their 9 year old users.  I odn't know aboutG >>you, but I really have no need to contact or to be contacted by them.  >> >>>  >>>    (Q >>>     note. Usenet News is not a one-to-one agreement between your organisation R >>>     and the senders. You have one-to-one agreements with your Usenet feeds butQ >>>     they just pass along ALL those newsgroups you have agreed to accept which ; >>>     in turn have been passed along from their feeds etc Q >>>     Any particular Usenet posting will have passed through a large number of  Q >>>     Usenet systems, which you have no direct agreement with, before reaching  R >>>     your systems. Usenet is also a broadcast system, unlike email, which makes" >>>     such a structure feasible. >>G >>Which is why I used Usenet only as an example of how halfway measures G >>helped.  Considering the volume, Usenet has considerably less spam by F >>percentage than most emails today.  I saw no spam messages on UsenetG >>over the weekend while even with moderate filtering at the server and F >>aggressive filtering at the personal mailbox I still had a real/spamD >>ratio of 2/183 just over the last 4 days.  This is handled by spamE >>filtering and the UDP.  Not much, but it works.  Peering agreements E >>with the email system can do it to, but they would require a system C >>that eliminates the three primary flaws I have already mentioned. 2 >>Three flaws that NNTP does not have, by the way. >>  > If by the three flaws you mean >  >   > 1) Anonymous access is allowedD > 2) Protocol allows anyone, anywhere to connect to anyone, anywhere? > 3) Protocol allows for easy address spoofing which adds to 1)  > H > then they are totally irrelevent if you want to restrict which systems, > can send to you via one-to-one agreements. > Q > Just use SMTP but set your mail system up so that it just accepts mail from the I > IP addresses of the mailservers of the people you have agreements with.  > Reject all other connections.   G But that isolates you completely from the rest of the INTERNET which is I something you said was unacceptable.  My system works simultaneously with G regualr SMTP allowing you specifically separate the emails you know you F want to deal with right away while still letting you receive the stuffH that needs further filtering before you decide if it is worth your time.K SMTP was not designed for controlled access.  The protocol expects everyone G to be able to talk to everyone.  It also assumes you can trust everyone F which is why it doesn't have any form of authentication built into it.  I Any solution has to be over and above what we have today.  At least until  we no longer need SMTP.    > N > (Such a setup wouldn't as I indicated above be acceptable to most companies P > but there is nothing to stop you setting that up. No need to get rid of SMTP).  , But that is exactly what I have been saying.   >  > ( F > Of course NNTP does in fact have at least flaws 1) and 3) since you N > have no control over what the systems you peer to have peered with and what $ > systems those have peered with etc > )   K Not at the MTA level.  And, if desired, not at the reader level.  I have to J authenticate in order to post or even read news.  While some servers don't9 require it, the protocol has the ability.  SMTP does not.    >  >  >>> ; >>>     Also, of course, Usenet has it's own problems with  & >>>     inappropriate postings/SPAM.   >>> >>See above, not even close to the level found in email today. >>N > Depends on the groups and when you look. A while back a number of the vmsnetK > groups were almost impossible to use because of binary postings of warez.   @ Bad news admin.  I know it goes on, but on a well run system the@ users won't usually see it.  Of course, some admins, in the nameC of some mistaken notion of "freedom" choose not to filter.  Verizon C seems to be one of them and that is why even though they are my ISP D I choose to read me news elsewhere.  Thus my additional notion that D some entrepreneur might offer clean email accounts available via the	 INTERNET.    >  >>>  >>>    ) >>>  >>> P >>> 2)  Getting organisations to sign legally binding contracts with respect to : >>>     their emission of SPAM is likely to be difficult.  >>E >>Again, what the agreement ends out being is left as an exercise for A >>the reader.  If you deal with someone who's AUP you are already B >>awar of and you know they enforce it draconianly (ie. .mil) thenB >>you might not require any kind of formal agreement.  I have saidA >>the same thing about "communities" like c.o.v.  Strongly worded C >>binding contracts are more likely going ot be for those you don't D >>trust.  they might show you how deterined to work within the rulesC >>they are.  if they don't want to agree to paly by the rules, send  >>'em packin'. >> >>>  >>> S >>> It looks like there was an attempt to set something like this up which overcame 1 >>> the first problem via the use of a whitelist.  >>> If you look on   >>> 2 >>> http://shopping.declude.com/Articles.asp?ID=97 >>> 5 >>> you'll find a fairly good list of anti-spam lists  >>>  >>> at the bottom it mentions  >>>  >>> S >>> BONDEDSENDER                        -   A whitelist of E-mail senders that have 0 >>> 					posted a bond to help prove that their  >>> 					E-mail is legitimate. >>>  >>> L >>> Sadly, if not particularly unexpectedly,  when you go to the url listed ) >>> http://www.bondedsender.org/ you find M >>> that the service has been renamed "Sender Score Certified" and no longer  2 >>> seems to mention anything about posting bonds. >>F >>But, by not eliminating the three flaws I have already mentioned, itF >>was doomed from the beginning.  The current system can not be fixed.D >>We can try an already existing method that eliminates these flaws,E >>we can create a whole new protocol that elimantes these flaws or we E >>can stay with the status quo.  Putting a bandaid and some neosporin D >>on a wound isn't going to help if the wound is already gangrenous. >>? > More likely the participants found themselves hosting zombied N > systems despite their best efforts and that persuaded them that agreeing to M > pay out lots of money when they couldn't guarantee that they could stop it  & > happening again was not a good idea.  D So, I take it you are another of those who think it is impossible toC secure Windows systems.  In spite of the evidence to the contrary.     >  >  >>>  >>>  >>>>> J >>>>>> > How do you stop it at the source?  Which is the spammer, himself? >>>>>>N >>>>>> True.  You stop it by not giving the spammer a venue from which to sendO >>>>>> his spam.  The sysadmins all agree (by contract) to not allow spam to be O >>>>>> sent from their systems. Penalty: ostracism.  The sysadmins of the local O >>>>>> mailsystems have AUP's that carry penalties (which depend on the type of M >>>>>> organization, ie. ISP - include hefty fines in your customer contract, M >>>>>> business - employee can be fired, school - expulsion or other academic N >>>>>> sanctions, etc.)  Thus, the spammer has no place where he is welcome on >>>>>> the new email network.  >>> M >>>>> Back in the mid '90's, such things were done.  Erols and other networks M >>>>> had fines and such for spammers.  It didn't work.  This again referrers I >>>>> to the "whack-a-mole" game of spammer termination.  Also, often the M >>>>> spammers would sign up with accounts using credit cards of the clients, $ >>>>> or even stolen credit cards.   >>>>0 >>>>Ummm....   That's a crime, probably federal. >>>>J >>>>>                               So you end up not billing or punishingJ >>>>> the spammer, anyway.  You kill one spammer account, and they have 10( >>>>> more waiting to abuse when needed. >>>>H >>>>If you make the users identify themselves and sign a legally bindingG >>>>contract you know who they are and they can't have 10 more accounts  >>>>waiting. >>>> >>>>> M >>>>> Of course, now much spam is from zombied Windows boxes.  The spam can't L >>>>> be traced back past the zombied PC.  So, do you fine and terminate theK >>>>> account of the person with the infected PC?  That's going to sit well K >>>>> with customers.  What about the Wingate proxy exploitation of several L >>>>> years ago?  The proxy would allow SOCK4-like remote access, making theH >>>>> Wingate proxy appear to be the source, but no way to determine whoM >>>>> initiated the connection.  And the wide variety of formmail.pl web form M >>>>> abuse that occured (and actually, I STILL had several dozen attempts by E >>>>> some spammer to test my form mail web script on the Hobby Site: M >>>>> dinotto2@aol.com and topcopl2@aol.com are their test accounts - may the I >>>>> harvesters get them)?  And there are still open SOCK4 proxies, open F >>>>> SMTP relays, and any number of other methods people are spamming< >>>>> without using mail servers they are authorized to use. >>>>G >>>>And, because my proposal doesn't use SMTP at all, none of the above  >>>>pose a threat.   >>>> >>> < >>> If your not using SMTP then what are you using (UUCP)  ? >>>  >>> 7 >>> http://www.rhyolite.com/anti-spam/you-might-be.html  >>>  >>> programmer-11 * >>>     The FUSSP involves replacing SMTP. >>D >>I'll visit the site, but I got the idea from other comments I haveH >>seen that they post mostly humorous stuff.  maybe I have them confusedI >>with someone else.  Of course, the last line looks like they agree with  >>me on at least one point.  >> >>>  >>>  >>>>> K >>>>> They are already not using email networks where they are not welcome, % >>>>> so why does your solution work?  >>>>G >>>>How are they "not using email networks where they are not welcome"? E >>>>Right now, except for private networks, there is only one network E >>>>and everyone who is exchanging email is using it.  Any Email host D >>>>(and many non-legitimate ones like zombied PC's) can contact anyG >>>>other and 90% of them will accept the connection and the email from  >>>>any other. >>>> >>>>> M >>>>> Also, how do you require uniform AUP's across ISP of various countries?  >>>>K >>>>It is all based on agreements between individuals.  Regardless of where I >>>>one is I can require whatever I want or refuse to let them play in my  >>>>sandbox. >>>>L >>> Your free to set up your own agreements with whatever companies you wishP >>> to accept their mail and reject all other mail. It's easy enough to do with S >>> most mailservers (no need to switch to UUCP just set up your mailserver to only K >>> accept mail from specific IP addresses). However such a solution isn't  Q >>> acceptable to most companies who want complete strangers (otherwise known as  * >>> customers) to be able to contact them. >>L >>Which is why my proposal is to run both simultaneously and let the seriousG >>user migrate as they see the value of it until eventually all of your H >>serious usrs (read real customers) are on the clean system and you canM >>pay much less attention to the garbage.  Let me throw one more example out. K >>We have all been spammed by someone who got our address from c.o.v.  Many K >>people have been forced to munging their address (which poses a burden on K >>anyone who wishes to talk to them because they can no longer just use the M >>reply option!) or having other mail accounts on other machines specifically G >>for use in Usenet postings, which is certainly a butrden on the user. J >>What if the address you used in your Usenet postings couldn't be reachedF >>by people outside the group, but could be by those within the group?# >>Wouldn't that offer an advantage?  >> >>>    >>>>> N >>>>>> Read what I said up above. The customers of the ISP all sign a contractE >>>>>> (I know I had to!)  You put serious penalties in the contract.  >>>>>  >>> F >>>>> Yes, but they really have no teeth, the spammers are often using >>>>> fraudulent information,  >>>>K >>>>If I don't know/trust the individual, I require them to prove who they  L >>>>are.  How is that any different than when someone walks into a store andI >>>>plops a credit card down?  Fraud is illegal.  As near as I know, that 3 >>>>applies in pretty much every civilized country.  >>>>E >>>>>                         or on ISP which don't have strong AUP,   >>>>J >>>>I don't let them join the network until they agree to institute an AUP. >>>>that meets the requirements of my network. >>>>K >>>>>                                                                or the ? >>>>> spammers are using network which they are not authorized.  >>>>L >>>>Won't be able to use mine.  I will know who is allowed to access my mail, >>>>server and no one else will be able to.  >>>> >>>>> J >>>>> You are assuming the spammers are Law Abiding Honest Citizens.  That9 >>>>> may be true of Usenet back in the day, not anymore.  >>>>F >>>>In order to join the nework, they will have to positively identifyB >>>>themselves.  If they choose to violate the law after they haveF >>>>positively identified themselves, well, that's what the courts are
 >>>>for.  :-)  >>>> >>> M >>> Sorry your system will only work if you can impose such rules on all the  M >>> ISPs and your only weapon against those who don't comply is to stop them  L >>> sending you mail. Until the majority of internet sites adopt those rulesL >>> it is simpler for the ISPs to just ignore your rules and let you isolate
 >>> yourself.  >>N >>But as long as I continue to accept other emails as well, I am not isolated.N >>And, as the users I want to communicat4e with begoin to migrate (assuming myM >>idea takes hold, of course) I can slowly begin to more and more agressively L >>filter their garbage and it is eventually they that will be isolated, in aL >>sea of spam.  I don't care about that 98% of garbage that makes up most ofL >>the INTERNET.  I am sure that most real businesses and acadeics doing realJ >>research and people like c.o.v who share a common interest are the same.H >>Let those who really want to get all that spam stay with their ISP and# >>take it all in.  I don't want it.  >> >>> 7 >>> http://www.rhyolite.com/anti-spam/you-might-be.html  >>>  >>> senior-IETF-member-5S >>>     The FUSSP won't be effective until it has been deployed at more than 60% of . >>>     SMTP servers and that's not a problem. >>O >>Mine takes some point at which it attains critical mass as well.  I will look M >>at this FUSSP stuff, but unless it eliminates the three flaws in SMTP it is M >>doomed to failure.  And, if it is yet to be implemented in any usable form, M >>my proposal still has the advantage.  Given some number of interested email K >>system admins I can have the first stages of my network up and running in L >>less than 24 hours.  The software is already there and the hardware neededL >>to run it (especially int he earlier stages) can be found in most people's >>junk box.  >> > M > I think you are misunderstanding the FUSSP (Final Ultimate solution to the  L > Spam problem) is a general description of solutions such as yours to SPAM.# > The full title of the webpage is  ) > "You Might be an Anti-Spam Kook If ..."   I Like I said, I haevn't been there because I had heard it was not serious. ) Your comments make it seem I was right.      bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 27 Nov 2006 15:06:09 -0800 From: davidc@montagar.com 5 Subject: Re: increase in spam and what to do about it B Message-ID: <1164668769.672570.131610@14g2000cws.googlegroups.com>   Bill Gunshannon wrote:E > In article <1164591391.999832.173820@j44g2000cwa.googlegroups.com>,  > 	davidc@montagar.com writes:J > > See, already you have a wide variety of "procedures" from handshake toJ > > more from every mailhost which with you want to communicate.  That's aI > > lot of agreements to manage, and for companies, you can bet the legal H > > departments are going to get involved.  Once you go to "agreements",J > > especially as you want them to be "legally binding" and have financialH > > penalties, the corporate mavens are going to start to have problems., > > Even most educational institutions, too. > D > Funny, I have to have all kinds of different "agreements" now.  OrE > do you think that INRIA uses the MS boilerplate for their licenses? F > Basicly, the admins (and their organizations) are free to do as theyG > please.  For me, I really see only two different agreements.  One for G > those I know well enough to trust and another for those I know enough  > not to trust.  :-)  @ Who's INRIA?  And don't all those licenses/agreements have to beG reviewed at some point by your legal department?  Most business require  this.   F > And yet, I see much less spam from Usenet than from Email lately.  II > saw not one spam message over this entire weekend while seeing probably J > a thousand messages (no, I don't read all of them beyond maybe the firstG > line or two.)  During the same period I received over 150 messages on J > one account and 5 on another.  The first had 2 real messages and all theJ > rest was spam.  The second, was 1 real and 4 spam.  Sure seems like time > to do something about it!!  C Gee, it wouldn't be that much of the anti-spam procedures that have B been running for over a decade might have something to do with it.E CancelMoose and some of the others really did a good job.  But still, @ your peering agreement with your peers does not prevent spam viaB Usenet.  One node can send one message and have it cross-posted to: mutliple groups and each node will dutifully propogate it.  J > > Okay, but as soon as you do that "at least the one's you don't trust",& > > you open yourself up to a lawsuit. > G > No I don't.  I am free to have whatever agreements I want with anyone G > I want.  As long as I don't discriminate based on one of the specific F > catagories under law.  Last I checked, being a spammer wasn't one ofH > them.  Or are you saying that all businesse treat everyone exactly theJ > same way?  Ever been to hardware store at the same time as a contractor?G > Funny, really, he doesn't pay the same price I pay for anything.  So, J > should I sue?  That's the way contract law works.  I can't force someoneI > to sign the contract, but then, if they don't, I don't have to exchange  > email with them.  G But you still burden the non-spammer with contractual/legal issues.  To = send an e-mail.  It's cheaper to put a stamp on and envelope.   B > > You are 100% correct.  Sad part is that the dollar amounts areJ > > generally so low that there is little chance of getting it prosecuted.C > > These are the people you are trying to require "agreements" and H > > "contracts" - essentially criminals.  They would sign your agreementK > > and then use it to line their bird cage before starting their next spam F > > run.  By the time you find out, they're done and have disappeared. > G > How does a man who put his signatutre on the bottom line "disappear"? G > They get away with it now because so many places are willing to allow H > what is basicly anonymous access to their machines. This is one of the  > first things that needs to go.  G Someone in Texas wants to e-mail peer with you.  Do you require that he E physically visit you, or do you physically visit them?  How does this E peering process work, and how much work does it take?  Is it worth it  to THEM?  D You make not using SMTP overly difficult, and no one will do it.  IfE they don't have UUCP (I don't), they can't do it.  I can't afford the G time to arrange peering agreements with everyone, there's just too many  legitimate peers.   J > > Exactly how do you do that?  And how do you know they are using forged9 > > documents/identity they've phished from someone else?  > H > How do you know that anyone you deal with on any given day is who theyK > say they are?  I don't think three are as many people running around with J > forged documents as you seem to.  They do what they do becasue under theJ > current system they are never required to present any proof if identity.K > They log onto YAHOO and create email accounts.  This is one of the things  > I want to see stopped.  G So, a peering agreement is only executable between people you know, and F people who you actually can meet face-to-face?  There's lots of forgedB information around there, but while it is a minimum, it is used byG spammers.  There's web sites full of people that trade in stolen credit  card information.   K > > A description of that protocol would be nice.  Who's going to implement K > > it?  What vendors are going to back it?  What client software will work  > > with it? > H > As I have said in the past (and you have mentioned at least once, so IK > assume you saw it) it's UUCP with TCPIP as the transport medium.  Already H > implemented and available on ltos of systems.  Used to be available on > VMS, not sure if it still is.    Nope, it's not.   F > > And why would they alter their policies to fit your needs?  Is theJ > > effort and dealing with their legal department worth the effort for an
 > > email? > D > Look at the state of thigs right now.  Then read some of the tradeC > journals you pointed out to me.  Look at what I said about what I F > got over the weekend.  And I use a number of RBL's on my mailserver.B > And, there are entire blocks of foreign IP address blocks that IA > do not even allow to connect to my mailserver.  And those trade B > journals say it is going to get much, much worse.  At what pointE > does email become unusable for anything serious?  Stopping this and G > returning the medium to its previous usefulness seems worth the small E > effort it will take.  Especially when one consider the effort it is - > already taking to try and deal with it now.   E That doesn't really answer the question, does it.  Is AOL, HP, anyone E else, going to alter and negotiate a peering contract with you simple F for the purpose of exchanging e-mail?  Or are you going to do the same8 in order to peer with them?  What if they turn you down?   very civilized country.  > > J > > Spammer often operate illegally.  Many of the techniques that spammersJ > > use are marginally to explicitly illegal - yet they persist.  What youK > > are proposing assumes they aren't.  From what I see, that is one of the G > > biggest problems with your proposal.  You assume honesty, much like  > > Usenet of old. > I > Not really, the methods primarily in use today rely on the three things H > I have mentioned before.  The biggest thing they rely on is anonymity.  0 No, they rely on fraud.  Anonymity has validity.  I > > And what level of effort does that take?  You'll see where I'm coming  > > from on that point later...  > I > Probably depends on the size and political make up of the organization. G > My University already has an AUP which the students all agree to obey # > by virtue of being students here.   G I'm not talking about your AUP, what level of effort would they require / in order to meet your requirements for peering?   H > > Good luck getting it prosecuted, though.  Really.  They find out whoE > > you peer with and get an account  with them, say, AOL.  Then spam K > > through AOL.  Wouldn't be the first time AOL had that happen.  Probably H > > not the last.  Then you either terminate exchange with AOL or put upE > > with AOL playing whack-a-mole on a daily basis.  Which do you do?  > G > Well, I would probably not peer with AOL in the first place.  I don't I > (personally) accept any email from them now.  Anyone who peered with me G > would have to understand they are responsible to ensure the behaviour K > of their users.  I am sure there many who would not want to.  See comment G > above.  How many people posting here have Gmail accounts?  The use of K > an account other than that provided by their ISP is really rather common.   G I get spam with forged gmail accounts, since UUCP doesn't have anything 2 to detect that sort of thing, how is this treated?  A > > YES.  Because they will use fradulent identities to avoid the H > > penalties.  Prosecuting that is not as trivial as you think, anymore" > > than credit card fraud is now. > E > See my comments above about anonymity and the need to eliminate it.   B It's not anonymity - it's various degrees of identity theft.  Your solution doesn't address that.  J > > Good luck.  Unless each INDIVIDUAL is known to you, how can you verifyI > > the true authorship of any mail from someone who may be coming from a  > > trusted host?  > G > Not my responsibility.  It is the responsibility of the mailserver to G > police its users.  I can do that with mine and I expect that everyone F > else can as well.  Some will choose not to. they will not be allowed
 > to play.  C How do you deal with routed UUCP messages (ie. message from someone F routing through the UUCP network which is not a direct peer?)?  Do you stop peering with your peers?   J > > Or yuo determine that you simply cannot completely trust anyone, or so/ > > few that, that your solution doesn't scale.  > 3 > Pretty cynical.  I thought that was my ballywick.   ? Well, you wanted a Devil's Advocate.  And yes, when it comes to D establishing a trust network, I would be remiss for not assuming badC people will try to infiltrate it if it because popular.  Otherwise, $ would any improvement truly be made?   >  I expect I could G > trust most real .edu's.  I think I could trust lots of people here in E > c.o.v.  I'll bet I could trust most serious .com's.  About the only H > people I think I could not trust are most current ISP's and the places; > that currently offer free email accounts on the INTERNET.   E But what about the peering agreements that your students are going to F request, so they can communicate with their parents, grandparents, andG friends which could very easily have accounts on these ISP's?  Are they 4 going to be told to forget it, you have to use SMTP?  9 Or is this basically for your own personal e-mail server?   H > > Do you want to be the ISP that sues a grandmother on a fixed pensionJ > > for several thousand dollars because her PC got hijacked?  How long do) > > you think you would stay in business?  > I > Believe it or not, the ISP has the ability to prevent that hijacking in  > a majority of cases.  @ I think you either overestimate the capabilities of the ISP's or0 underestimate the threat from the virus writers.  E > But, again, as I just said above, I would not trust the ISP's and I D > expect they would opt not to sign such an agreement.  That's fine, > they don't play.   So what do your users do?   G > > No, really.  I mean YOU.  What if YOUR PC get's a 0-day exploit and H > > sends spam.  Are you going to pay the fine?  Or as the mailadmin, do > > you get off? > I > It is not going ot happen to my PC, so it's really a moot point.  Let's  > at least stick to reality.  D How can you be so sure?  What if it does happen?  Really, as I thinkE your response addresses an important point as to the enforcability of 
 the AUP's.  D > > Yes, but as the Hobbyist Program, I get e-mail from a variety ofG > > locations.  I can't just blanket drop entire countries or ISP's.  I D > > certainly don't want to go through the process of getting signedD > > documents between me and some ISP just because someone has a PAKG > > question.  I'm sure there are many other institutions with the same  > > issues.  > J > So, you continue to accept email the old way while also getting involved > with the new system.  F I can't get involved with the new system.  I don't have UUCP software.  5 >     And, hopefully, as more and more people see the J > value in the new system and make the move you need to rely less and lessG > on the dirty email system until eventually, all of the people who use H > email for serious reasons have moved to the clean system.  Heck, seemsJ > to me that the Hobbyist VMS users looks like another very good candidate1 > for whjat I have started calling "communities".   B But they have e-mail addresses at various ISP's and other places -G places you doubt you would peer with.  And would you be willing to peer F with me if I happen to peer with someone that has AUP's that you don'tE agree with?  I don't have time, especially for volunteer efforts like D the Hobbyist program to arrange the legalities of a bunch of peering agreements.   J > > Depends on the RBL, and whether it is used to completely block or flagI > > the message.  In your solution, they would have to contact me outside H > > of email, and negotiate a peering agreement.  Is that worth it for aJ > > single e-mail?  But they time you do that, why use e-mail at all, just+ > > send physical documents or phone calls.  > J > Well, one would assume in most business relationships that there will beI > more than one email.  Or don't you plan on repeat business from the the  > very beginning?   E If you make it a hassle to send that first e-mail, there may not be a  business relationship.  J > > The reactive method assumes honest behaviour, yours burdens the honest > > right up front.  > J > Yes, exactly.  Not requiring honesty up front is what has gotten us intoL > the situation we are in today.  And continuing the status quo is not going > to fix it.  E Again, you are burdening the wrong people.   Most people won't accept  the burden.     I > > Wrong - zombied PC's and JoeJobbing.  How does your system stop that?  > A > How does a zombied PC connect to my mailserver using UUCP and a C > username/passord pair?  Same thing for "JoeJobbing".  Heck, in my A > case I would probably only open up my firewall for UUCP from my A > list of trusted hosts thus eliminating even the chance of a DOS  > attack on the port.   E Doesn't have to.  All it needs to do it connect to one good UUCP host D on the network.  UUCP, as a file transfer protocol, doesn't validateD domains.  And since the TCP session information isn't there, the MTAA can't validate the domain, either.  So, using either method I can B inject a bogus message into a UUCP network and propogate it to any other cooperating UUCP host.  J > Not necessarily thousands, although that is possible.  I wonder how manyJ > UUCP email server clients UUNET had in its peak?  Or even seismo who didJ > it for free.  And the resources available today are far beyond what theyI > were then.  People paid not only for the UUNET service but also for the J > long distance call.  Surely this would be much cheaper and easier today!  E It had a bunch, and it wasn't always consistent.  You couldn't always C resolve a path from your host to all the other hosts, which made it & difficult to send mail to those hosts.  I > > Do the math, let's assume most everyone is going to be good citizens. I > > There are 1,000 mail hosts.  How many agreements are going to need to K > > be managed?  That isn't just the paper contracts, but also the software A > > configuration databased used to keep those.  That's 1,000,000  > > agreements to be executed. > H > Maybe, maybe not.  Like I said, the agreement is going to be dependant > in the level of trust.  B But that's still 1,000,000 UUCP configuration updates, even if you? don't have to get lawyers to read/approve 1,000,000 agreements.   F > > Would you (Bill Gunshannon) pay that bill if your PC got infected? > C > See above, can't happen.  Others can prevent it too.  Let's stick F > to reality.  Someone who is not capable of protecting their computerE > infrastructure is unlikely to sign the agreement int he first place E > because they would be incapable of even understanding what it said.   A Of course it can happen.  You can reduce the risk, but unless you G completely disconnect the box from the network, you can't eliminate the  possibility.  G So what I'm seeing, by your responses here, is that you essentially are G proposing a mail network of UUCP connected hosts - which will basically B only seem to serve a small group of people that run their own mail servers on Unix/Linux systems.  H > > Not at all.  You keep talking about server-to-server peering, but atJ > > some point a user at a PC is going to need to send a message over your% > > network.  It is an attack vector.  > I > And that is a matter between the server and its users.  I can guarantee H > that my users can't do it.  And that none of the PC's under my controlI > get infected.  I have been doing it for years and as I have said, while G > the University constantly has infected machines, I don't.  And, trust J > me, all those other infected machines accross campus spend a lot of timeK > trying to infect mine.  It just doesn't happen.  I know people here don;t F > want to hear it, but Windows boxes can be secured and remain usable.  A Congratualations for your efforts, but most places don't have the E expertise to do what you've done.  And that's something you can't fix C or address across all the peers.  You haven't eliminated the attack ' vector. You've just secured one server.   H > Well, it becomes the serves responsibility to police its users.  ThereJ > are a number of ways to do this already, ranging from procatively tryingF > to protect your users PC's to scanning all the email that comes fromJ > your users looking for spam.  Again, one of the needs to fix the problemJ > is to catch it as close to the origination as possible even if you can'tJ > completely prevent it.  Maybe this will finally drive the development ofC > a better MTA<->MUA protocol to deal with the "last mile" problem.   E You still have the problem of chasing the chain.  I've read plenty of G headers and the only Received header you can depend upon is the one you D provide.  Everything else is potentially forged.  I can craft a UUCPC bang-path that you can't trace back to me.  There is nothing unique ( about UUCP or mail transfered over UUCP.  K > > That's why I'm waiting the class-action against the Company (they won't E > > go after MS, they will go after the company that got comproised).  > H > Well, if I were you, I wouldn't hold my breath.  The only one who willH > get anything out of that will be the lawyers (as usual).  Nothing will
 > chcange.  F True the lawyers will win.  But it's going to take something ilke that> to happen before companies truly take some of this security asD seriously as it needs.  And MS is going to have to be perceived as aD unwarranted legal liability before they actually get security right.  G > > Okay, then I will suggest that for your solution to succeed, at the I > > MINIMUM you will need buy-in from Microsoft.  You will need PC client I > > software and server software available built-in/enhance existing SMTP ; > > servers.  Do you think this is an incorrect suggestion?  > F > No need for buyin from MS.  Who, by the way, would have no incentiveE > to get involved.  It wouldn't put a dime in their posckets and that E > is all they care about.  PC's can remain the last mile.  For people I > who insist on serving their email with Exchange or Outlook or whatever, G > they will likely need another server that can play on the clean email I > network (not unlike the many places that run proxies or DMZed gateways) H > or not play.  All depends on whether or not they see value in being on > the clean email network.  B Then you haven't solved the problem.  The PC is the growing attackB vector.  Unless you can insure the mail going into the server fromD outside the UUCP protocol is clean, you can't insure the mail in the5 UUCP pipe is clean (typical Garbage In, Garbage Out).   J > > True, but your system burdens the mail admin heavily and make them the7 > > central point of focus for each users address book.  > N > We are already burdened.  And that burden is increasing exponentially.  And,K > on top of that, we are loosing ground.  Being an admin, I don't see it as K > that much of a burden  compared to what the gains may be.  Hopefully when J > I get the chacne to spell out everything I propose in detail others will8 > also see that the gain outweighs any percieved burden.  @ I don't see the peering as solving the burden.  And since you'reE implementing a network that requires peer-to-peer agreements, you are " also insuring exponential burdens.  I > > Why?  So far all you've addressed is MTA->MTA, where's the MUA fit in   > > and how is it unexploitable? > L > The user end is already handlable.  I keep my PC's clean.  I am willing toO > bet that so do the majority of serious email users (real businesses, schools, N > etc.)  Has your PC been zombied lately?  Mine never has.  Some of mine can'tI > be.  I do not expect all the grandma's or 9 year olds to play.  I don't H > expect their ISP's to play.  I do expect those who have a real need toH > use email for serious business to play.  And, no, I don't include Ebay > in that catagory.   A Again, you are immediately excluding a large part of the Internet F population, and creating a network of mail admins, pretty much for the use of mail admins.   D > I can take it back to the real original IP address (usually a DHCPG > address from an ISP).  The ISP can (but usually won't without a court E > order) identify the user.  The reason for the box doing what it did A > is not my concern.  If it's your box, your responsiblity.   The ( > courts agree.  (Steve Jackson Games!!)  > That ISP can't unless they log every packet.  The DHCP host isD typically spy-wared and zombied, so STILL do not know where the spam
 came from.  G I'm not sure why are talking about Steve Jackson Games.  They didn't do @ anything.  Some hackers who DID do something liked to play SteveG Jackson Games, and the FBI raided SJG offices and confisacted all their E computers.  Practically put them out of business, which Steve Jackson 4 sued for and won a judgement against the government.  E > > Then I think I can safely say that this is exactly what they will J > > probably do.  Why is someone sending you an e-mail worth getting their> > > legal department involved negotiating a peering agreement? > I > Why does anyone run Oracle?  Legal departments have to get involved for H > that too.  I have to run every license agreement I am required to signI > through our legal people.  If they see value in what they will get from H > signing the agreement, they run it by their legal department.  And, inG > case you are interested, I have had agreements for real products from H > real companies (one very close to our hearts) that my legal departmentF > has said we could not sign.  The options are then negotiate a betterE > agreement that pleases the lawyers or don't play.  There is nothing $ > new in this regard in my proposal.  F But now you're pretty much talking about considering a legal agreementA with everyone in everybodys address book.  I know I have way more F people in my address book alone than the number of software licenses IC have.  And my wife has probably twice the number of people than me.  That's quite a burden.  I > > You're kidding right?  I've run UUCP for years before I got internet, ! > > and it's not a mail protocol.  > G > Of course it's not specifiaclly an email protocol.  It is, however, a F > very good email transport protocol.  When you come right down to it,I > what is email?  Just a text file that needs to be moved from one server H > to another.  Email was moved this way long before SMTP was more than aD > gleam in someone's eye.  The big advantages it has are:  It is not > anonymous,  D Okay, you lost me right there.  It's no less anonymous than SMTP andF just as easily to forge.  Because the Received headers have nothing to
 do with UUCP.   ? > it can move email, it is authenticated, and it already exists  > in a totally functional form.   B It is only "authenticated" by your closest peer.  Beyond that, youF haven't a clue.  And it isn't in a functional form, unless you requireA all mail servers run Unix/Linux - and even then they may not have ? UUCP-over-TCP implemented (unless you open TELNET, which passes  clear-text passwords).  K > > Wrong - UUCP is only a point-to-point file transfer protocol.  It would G > > not be difficult for forge an e-mail to a UUCP host and cause it to  > > forward it.  > I > Only if you can find an open relay that's also a member of the network. G > The actual MTA is going to be the same as what you run now (sendmail, D > postfix, etc.) so if they can relay UUCP through it they can relayD > anything.  I would hope there are very few open email relays left.  > Or PC's local on the network.  Even with relay's denied, localD connections would still be accepted and a trojan snarfing an address@ book would be able to spam you just as easily.  And despite what= happens on your network, it can and does happen in real life.   G > >              Authentication is done via a clear-text password file,  > > too. > H > Maybe, if your still running Ultrix.  But even as far back as my earlyE > SYSV days the files were not readable by anyone anyway.  And, on my E > mailserver no one can even log on so even if it were world readable H > no one could get at it.  Security has cahnged a lot in the past couple@ > decades.  I like to think today's admins have kept up with it.  F Unix/Linux boxes can still get rooted sometimes.  And are these adminsG the same ones you've bemoaned their ability to even get the HELO domain # name correct on their mail servers?       > > No, I think it was spamming. > F > I am not aware of any criminal law against spamming.  Civil law, butD > you can't go to jail for that.  But then, I would have to read theD > court papers (and wade throught he lawyerese) to know the reality.  ' Virginia has had one for several years.   K > > Also, due to smart-hosting, once you can inject a message into one UUCP H > > server, the "trust" network will enable you to spam the entire trust > > network. > J > OK, give me the explicit details about how you, as an outsider are goingJ > to inject your email into my UUCP network.  You are not going to connectI > my UUCP MTA because you can't authenticate and I don't accept anonymous J > copnnections (which is basicly what all SMTP connetctions are).  And, ifI > you are not one of my local PC's, my MTA will not accept your email for G > delivery on the clean email network unless it originated on it.  Now, H > I am sure you are going to say well one of my peers is ifnected, but IF > kind of expect they are all going to be as diligent as I am and that > is not very likely.   A But all it takes is one of your peers to get infected.  Be really C honest - you've already told us how your network comes under attack F from other machines within your own University.  If others at your ownG University (who presumably would be accepting of your assistance) can't G be as diligent, why do you assume that everyone else can and will be as B diligent as you?  A chain is only are strong as it's weakest link.  E As for injection points there have been any number of web-based 0-day ' exploits where a PC could get infected.   K > > The biggest problem what that the routing of Usenet (compiling the UUCP A > > MAPS from Rutgers) was a royal pain in order to determine the G > > routeability from one node to another.  it just doesn't scale well.  > C > I didn't find it to be that big of a problem 20 years ago and the F > resources available today are considerably greater.  Like I said, itE > would be interesting to know how many clients and routes seismo and E > later UUNET handled.  And then equate that to the resources we have G > available today.  Even doing it the old fashioned way would be orders C > of magnitude faster just based ont he difference in hardware, but H > given the chance to rework some of it with modern tools (routes storedH > in MySQL) I think scalability would be less of a problem than you seem > to think.   E 20 years ago (that would be 1986), UUCP wasn't that big.  It got much @ bigger during the early 90's and building the "routing tree" was getting problematic.  D > > They did.  I ran one.  That kind of 1-1 peering arrangement just > > doesn't scale. > D > But it isn't really a one to one peering any more than Usenet NewsB > is.  I don't expect every email user in the world to talk to me.B > I expect hubs to do this.  the big difference between the way it@ > used to be and today is the idea that it would likely never be5 > more than, say, 5-6 hops from one place to another.   C If you go back the the old UUCP, then you are still open, since the E UUCP hubs freely accepted SMTP e-mail as a proxy MX host for the UUCP 1 node.  And you're still back to the same problem.   K > > But here's a big point.  In another post you mention how all these mail H > > admins can't fix mal-configured mail servers, get off RBL lists, fixH > > their users problems even when YOU provide the solution.  So I see aJ > > problem where this pool of mail admins is also the some one you expectB > > to contact you to negotiate peering agreements and update UUCP@ > > configurations to implement this.  These same people, right? > E > No, I am addressing the competent mail admins.  Thise who won't fix E > their systems now are obviously not concerned with the service they E > offer and, apparently their users aren't concerned.  They fall into H > that 98% of non-serious users.  If they have serious users, they will,F > most likely, get an account on another machine that works, much like > they do now.  :-)   C But do those 2% of people have that much of a need to exchange mail D between each other?  So you set up your UUCP peering.  Unless I haveF need to exchange mail with you frequently (and history has not brought this out), why bother?  D Again, it seems the problem you are ending up solving (which I'm notE sure is a "problem") is secure non-spam e-mail between competent mail G admins running Unix/Linux.  But I would venture to say that there isn't ? any spam between competent mail admins, so the net result is no  noticable reduction of spam.  G > > I mean, that is part of the social problem to begin with, isn't it?  > D > No, incompetence is not a social problem, it's much more personal.  D Well, you can fix ignorance, but stupidity is pretty much permanent.  D But really, so far I just don't see the value of your proposal, even though your goal has value.   : 1. It burdens the non-spammers, which are not the problem.B 2. It burdens the mail admins, by having them maintain the peering@ configurations/agreements between people that aren't going to be spamming each other anyway. E 3. Requires army of Bill Gunshannon clones to diligently administrate ! the PC's on the various networks. C 4. Requires software or gateways which may or may not be available.  5. Doesn't scale linearly.@ 6. Still requires SMTP for most e-mail anyway, which still needs filtering, RBL'ing, etc.  E I mean, it would just be easier to institute a whitelist, and include ? the 'good guys" as part of your list of SMTP "inside networks".    ------------------------------   Date: 27 Nov 2006 23:20:12 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: increase in spam and what to do about it 0 Message-ID: <4t1a5cF121gemU1@mid.individual.net>  . I give up.  You win.  Spam can not be stopped.  D "Propose to any Englishman any principle, or any instrument, howeverD admirable, and you will observe that the whole effort of the EnglishD mind is directed to find a difficulty, a defect, or an impossibilityE in it. If you speak to him of a machine for peeling a potato, he will F pronounce it impossible: if you peel a potato with it before his eyes,C he will declare it useless, because it will not slice a pineapple."      Charles Babbage, 1852.     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Mon, 27 Nov 2006 20:52:14 -0600 3 From: David J Dachtera <djesys.no@spam.comcast.net> " Subject: Re: interested in wombats0 Message-ID: <456BA45E.A65AFB1D@spam.comcast.net>   wombat@fancier.net wrote:  > = > Can someone tell me whether Wombats live only in Australia,  > or also on other continents? >  > Apart from zoos, of course.   : In older versions of Datatrieve, see HELP ADVANCED WOMBAT.   --   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, 27 Nov 2006 14:46:12 -0500 * From: "Syltrem" <syltremzulu@videotron.ca>- Subject: Re: Is HP trying to kill VMS again ? 0 Message-ID: <12mmg4baonr7077@corp.supernews.com>  C I'm still waiting for a definitive answer from HP, but here's this:   f http://news.com.com/Oracle+lowers+price+for+some+multicore+chips/2100-1011_3-6002050.html?tag=nefd.top  K Talks about Oracle and IBM and Microsoft, who do not treat cores are CPUs,  ) but we still don't know what HP is doing. L Who had to pay for 4 VMScluster licenses on a 4 CPU machine ? Or 16 on a 16 % CPU box. I'd be very curious to know.   = I hope to get news soon from HP. Kerry Main is on my case :-)    Syltrem    ------------------------------  % Date: Mon, 27 Nov 2006 22:44:01 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Mouse: thumbwheel support8 Message-ID: <6ab6d$456bb068$cef8887a$18672@TEKSAVVY.COM>   FredK wrote:K > By default in Motif CTRL-up/down arrow activates the scroll bar.  Try it  N > with the normal KB and see.  All I did was to effectively implement a Linux M > hack from a while back - to make the thumbwheel generate the up/down arrow   > keys.   N When I look at Mosaic, it has specific preferences for handling of thumbwheel.  J If Linux (and now VMS) handle a thumbwheel by synthetising a normal arrow K key, is it correct to state that Mozilla's handling of thumbwheel is never  	 invoked ?   F In the Window or Mac environments, would the thumbwheel generate very . distinct events ? How about Solaris or HP-UX ?   ------------------------------  % Date: Mon, 27 Nov 2006 17:29:32 -0500 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: OpenVMS Support Issues G Message-ID: <arSdnVEdFvxR-_bYnZ2dnUVZ_vednZ2d@metrocastcablevision.com>    Dave Froble wrote: > Bill Gunshannon wrote: > J >>> So you think yelling and arguing with HP management is going to do any  >>> good? I said *if* you write. >>H >> I didn't say that.  My point is that writing at all is a total wasterF >> of time unless you are one of those multi-million (billion?) dollarD >> accounts.  And even then, at this point in time, I am not sure it >> would have any effect.  >> >> bill  >> > J > Bill, you're just having some fun here, and it's not productive.  (Then ( > again, that's not the purpose of fun.) > E > Any serious businessman always keeps his options open, not burning   > bridges and such.   E Er, I suspect that was Bill's point.  Have you forgotten whom he was  I talking about the futility of dealing with, and what their record (still  < clearly continuing today) is in the area of burning bridges?   - bill   ------------------------------  % Date: Mon, 27 Nov 2006 18:06:23 -0500 ' From: Dave Froble <davef@tsoft-inc.com> # Subject: Re: OpenVMS Support Issues 9 Message-ID: <LdCdnUPxOr3g8vbYnZ2dnUVZ_qOdnZ2d@libcom.com>    Bill Todd wrote: > Dave Froble wrote: >> Bill Gunshannon wrote:  >>K >>>> So you think yelling and arguing with HP management is going to do any ! >>>> good? I said *if* you write.  >>> I >>> I didn't say that.  My point is that writing at all is a total waster G >>> of time unless you are one of those multi-million (billion?) dollar E >>> accounts.  And even then, at this point in time, I am not sure it  >>> would have any effect. >>>  >>> bill >>>  >>E >> Bill, you're just having some fun here, and it's not productive.   / >> (Then again, that's not the purpose of fun.)  >>F >> Any serious businessman always keeps his options open, not burning  >> bridges and such. > G > Er, I suspect that was Bill's point.  Have you forgotten whom he was  K > talking about the futility of dealing with, and what their record (still  > > clearly continuing today) is in the area of burning bridges? >  > - bill  B No, you can be assured that I will never forget that.  I used the H 'burning bridges' term specifically because of the past.  I don't think I much of the people in question as businessmen.  'Gougers' and worse come   to mind.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 27 Nov 2006 16:25:15 -0800 * From: "Tom Linden" <tom@kednos-remove.com>% Subject: Re: optimal drives for HSG80 ) Message-ID: <op.tjo94dy0tte90l@hyrrokkin>   E On Mon, 27 Nov 2006 14:58:12 -0800, Schroeder, AJ <aj1@qg.com> wrote:    > Tom Linden wrote: E >> I am considering replacing the 18GB drives in my HSG80 with larger C >> capacity.  Newer drives vary greatly in performance, e.g., speed 1 >> transfer rate and cache size and therefor cost  >>G >> There are 4 shelves each with 6 drives and mirrored controllers with G >> 256MByte caches, organized as 3 raid arrays.  There are 5 bad drives F >> in the system, so rather than replacing with same, why not upgrade.D >> The controllers are cross-strapped to two 1Gb FC switches  and in( >> their turn to dual HBAs in each node. >>H >> So the question arises what the optimum drive looks like.  Does cacheI >> on the drive do any good?  Too fast a transfer rate would be masked by I >> that of the HSG80.  What about spin rate?  Slower drive I would assume F >> is likely more reliable.  The difference in latency between 10K and2 >> 15K probably wouldn't noticeable in this system >> >> Appreciate your thoughts. >> Tom > H > We had a problem when we started running out of space on some of the  	 > Windoze I > servers connected to our ESAs. What some people did is they created one I > raidset and added two rows of disks to it. <sigh> What happens if you    > lose a
 > channel? > G > FWIW, we used CONCATSETS quite heavily when we still had HSG80 SANs   
 > running.L > The main advantage to using CONCATSETS is that it allows you to "stripe"   > two ' > separate raid sets together - safely.  > J > Anyway, you need to be running a fairly recent firmware and patch level.K > Don't quote me, but I believe you have to be running 8.6 firmware on your  > controllers. > E > Oh, and anything > 10K RPM isn't supported on an ESA with the SBBs.  > H > As our local DEC service tech put it, you would have a "pile of blue  	 > goo" if ! > you put 15K drives in there. :)  > D I am using latest firmware, V88F-4, not using CONCATSETS, have two   stripesets, G each consisting of three mirrorsets and one raidset consisting of 3+1    drives. J But that was not the point of my question.  The HSG80 has limitations, forH example the BA370 shelves have a 40MB transfer rate, each controller hasK 256MB cache and the fibrechannel is 1GB through Compaq (Brocade) switches    toI Emulex LP8000 HBAs in XP1000s, DS10L and ES40s.  So if you start with the E simplest of drives to analyze performance and then consider ever more K sophisticated drives (BTW, I don't intend to get anything beyond 10K rpm)    atE what point do you no longer see any improvement in performance.  An    example,G one I am considering (because I already have some in a BA356 and Dell   
 PowerEdge)K is the ST373405LC  which has 4 MB buffer.  The ST373405LCV has 4 times as    much, J but because of the caches in the controllers I doubt the extra buffer doesK any good.  The drive is narrow profile which should give better airflow for I cooling.  They have an MTBF of 1.2 x 10^6 hours and I can get them with    warranty for about $1.80/GB           --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------    Date: 27 Nov 2006 16:19:26 -0500- From: colonel@monmouth.com (Hoary Hairy Hoax) & Subject: public-key ssh into VMS 7.3-1- Message-ID: <ekfkou$o3j$1@shell.monmouth.com>   C I have installed SSH 1.3 (OpenSSH 0.97) on an Alpha running OpenVMS A 7.3-2.  Try as I may, I cannot set up a public-key login into the A Alpha.  The documentation and web pages on VMS SSH are patchy and D sometimes contradictory.  The VMS OPENSSL tool lets me generate keys; but not to put them in the right format in the right files.   A Would someone please explain to me what files are needed, in what   directories, and in what format?   -:- < 	3. Their computers assured them that Earth will blow itself 	   up by 1990.   , 			"Why the Aliens Have Not Destroyed Earth" --   Col. G. L. Sicherman home: colonel@mail.monmouth.com  work: sicherman@att.com ( web: <http://www.monmouth.com/~colonel/>   ------------------------------  + Date: Mon, 27 Nov 2006 15:39:37 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)* Subject: Re: public-key ssh into VMS 7.3-12 Message-ID: <06112715393723_2020028D@antinode.org>  - From: colonel@monmouth.com (Hoary Hairy Hoax)   E > I have installed SSH 1.3 (OpenSSH 0.97) on an Alpha running OpenVMS C > 7.3-2.  Try as I may, I cannot set up a public-key login into the C > Alpha.  The documentation and web pages on VMS SSH are patchy and F > sometimes contradictory.  The VMS OPENSSL tool lets me generate keys= > but not to put them in the right format in the right files.  > C > Would someone please explain to me what files are needed, in what " > directories, and in what format?  G    TCPIP V5.4 includes SSH.  I've installed OpenSSL (not relevant here, * I believe), but not OpenSSH.  Around here:   alp $ tcpip show version  ;   HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6 D   on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2   alp $ ssh "-V"P alp$dka0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (< V5.5) 3.2.0 on COMPAQ Professional Workstation  - VMS V7.3-2      And on my Solaris system:  
 sol# uname -a : SunOS sol 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-60   sol# ssh -V 6 Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f    =    Yes, the key file formats differ between the TCPIP SSH and  OpenSSH/OpenSSL.  G    From which kind(s) of system(s) are you trying to "ssh" into the VMS 5 system?  (And what sort of "ssh" is available there?)   D    Were you planning to generate keys on the VMS system, or were you@ planning to use keys which were generated on a foreign/differentC system?  (I generated my keys on a VMS system and converted them on E Solaris systems using "ssh-keygen -X" or "ssh-keygen -i" or by manual = editing, but it should be possible to go the other way, too.)   H    Knowing nothing originally, I generated keys on both VMS and Solaris,H and compared the key file formats to discover how they differed, and howG to convert from one to the other.  Later, I learned of the "ssh-keygen" D options which allow the Solaris SSH package to convert the VMS-styleC ("SSH2-compatible") key files.  I don't see anything obvious in the C TCPIP "ssh_keygen -h" output which suggests a conversion capability 8 similar to that in the Solaris (OpenSSL) implementation.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Mon, 27 Nov 2006 22:51:46 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> H Subject: Re: Reloading Alpha drivers, was: Re: Mouse: thumbwheel support8 Message-ID: <bfd49$456bb239$cef8887a$19490@TEKSAVVY.COM>   FredK wrote:M > To do it for real isn't rocket science, but it would require drivers to be  K > modified to quiece the device and "clean up" (delete any dangling memory  M > allocations, etc).  Plus the associated work in sys$load_driver and in the  N > command line interface.  Doing a complete "unload" would be a bit more work + > and require a lot more driver discipline.     L *IF* that had been done, would it implicetely also allow one to solve RWAST J (and other nasty RW states) ?  Wouldn't it implicetely have to be able to 5 cancel all pending IOs safely to quiesce the device ?    ------------------------------   Date: 27 Nov 2006 18:52:17 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)= Subject: Re: Thoughts on the book: DEC is dead, long live DEC 0 Message-ID: <4t0qf1F10pv21U1@mid.individual.net>  H In article <7dd80f60611271010n47106ceco1d0dd9eb34777305@mail.gmail.com>,, 	"Ken Robinson" <kenrbnsn@gmail.com> writes:R > On 11/27/06, Stephen Hoffman <Hoff@hoffmanlabs-removethis-.org> wrote (in part):J >> is always an interesting choice and a tricky decision.)  OpenVMS TCP/IPJ >> got its start in the fall of 1988, which was just after the time of theH >> big-seven TLD transition.   (I'm old enough to have had an ARPA emailD >> address, something now long unknown to most Internet users.)  TheJ >> Internet marketing started in earnest around 1985 -- SNMP didn't appearI >> until 1987.  There were all of 100000 hosts in 1989, up from 28,000 in C >> 1987.  Major Internet backbones were T1 lines.  Though yes, once K >> something reaches critical mass, it's catch-up time -- which is itself a H >> real problem -- if you're not already apace in the game.  OpenVMS wasM >> obviously late to the game, first having TCP/IP (UCX) in the fall of 1988.  > D > I was working at Bellcore (read mostly UNIX on the network) in theH > 1980's (84 - 91) and I remember installing a 3rd party TCP/IP stack onG > VMS. I believe the name was Fusion and it was very UNIX oriented with ? > regard to it's set up. I believe this was in the 1985 or 1986  > timeframe.  A I'll bet it used an Excelan Ethernet Module, too.  :-)  I think I @ still have copies of my Fusion Docs up in the attic.  Of course,> the machines I maintained this on were lost in a plane crash a couple years ago.  ;-)   > C > I, too, once had an email address that was used in the UUCP world E > where you had to know the all the machines in the path between your  > machine and the recipients.   E Not usually, except in the very early days.  There were smart mailers C and maps to take care of that.  And some of us would like to see it  come back.  :-)    bill0 -------- IN THE GOOD OLD DAYS ------------------0 |   UUCP: {philabs}\                           |6 |         {phri   } >!trotter.usma.edu!bill    |      0 |         {sunybcs}/                           |0 ------------------------------------------------   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Mon, 27 Nov 2006 14:16:47 -0500 8 From: Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org>= Subject: Re: Thoughts on the book: DEC is dead, long live DEC ) Message-ID: <ekfdj0$1bjm$1@pyrite.mv.net>    Bill Gunshannon wrote:  G > Not usually, except in the very early days.  There were smart mailers E > and maps to take care of that.  And some of us would like to see it  > come back.  :-)  ... 2 > -------- IN THE GOOD OLD DAYS ------------------2 > |   UUCP: {philabs}\                           |8 > |         {phri   } >!trotter.usma.edu!bill    |      2 > |         {sunybcs}/                           |2 > ------------------------------------------------    8    Whilst we are reminiscing, one should mention DECVAX.I    If you could route your message to there, you could get anywhere.  :-)   !    Ok, coffee break time is over. 7    Time for me to head back into the code mines...  :-)    ------------------------------   Date: 27 Nov 2006 19:31:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)= Subject: Re: Thoughts on the book: DEC is dead, long live DEC 0 Message-ID: <4t0snuF11t9jmU1@mid.individual.net>  ) In article <ekfdj0$1bjm$1@pyrite.mv.net>, ; 	Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes:  > Bill Gunshannon wrote: > H >> Not usually, except in the very early days.  There were smart mailersF >> and maps to take care of that.  And some of us would like to see it >> come back.  :-) > ... 3 >> -------- IN THE GOOD OLD DAYS ------------------ 3 >> |   UUCP: {philabs}\                           | 9 >> |         {phri   } >!trotter.usma.edu!bill    |       3 >> |         {sunybcs}/                           | 3 >> ------------------------------------------------  >  > : >    Whilst we are reminiscing, one should mention DECVAX.K >    If you could route your message to there, you could get anywhere.  :-)  > # >    Ok, coffee break time is over. 9 >    Time for me to head back into the code mines...  :-)   @ Only two hops earlier than what I have above was decwrl.dec.com.> They were also a major hub and gateway between the developing  INTERNET and Usenet.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 27 Nov 2006 14:20:53 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) = Subject: Re: Thoughts on the book: DEC is dead, long live DEC 3 Message-ID: <zyG$StxSTuAf@eisner.encompasserve.org>   b In article <i4Eah.36868$GX2.31291@newsfe7-gui.ntli.net>, ChrisQuayle <nospam@devnul.co.uk> writes: > E > For example ?. Preferably something unique and not something where  G > others offer functional equivalence. Perhaps I should have said "The  % > rest of the world has caught up"...   C    Realtime on a general purpose platform.  Reliablilty.  Security.     (And this list goes on).    ------------------------------    Date: 27 Nov 2006 14:24:05 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) = Subject: Re: Thoughts on the book: DEC is dead, long live DEC 3 Message-ID: <TZ$L+XbHqUSB@eisner.encompasserve.org>   d In article <4t0pp4F11i1kvU3@mid.individual.net>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: > A > There was a person who posted a very big explanation of how his A > company was buying VAXen for internal use in Switzerland.  Once F > the machines arrived in Switzerland the company would do an internalF > corporate transfer to a branch in India.  India had never signed theE > trade restriction agreement against the USSR.  The Indian branch of D > the company would then sell the box to Russia.  The guy was ratherI > proud of the fact that they were pulling this off in front of everyone. I > So, makes you wonder why the Russians would even consider cloning which A > was bound to cost more and always leave them behind the current D > technology in the rest of the world.  Of course, it also brings toF > mind the quote, "With friends like these....." in regards India. :-)D > Couldn't be trusted then, can't be trusted now.  Some things never	 > change.   H    We can all wonder why, but we can't change the record which shows the"    USSR did build clones of VAXen.  G    We can also assume it was in part to keep the smuggled-in VAXen to a 1    sufficiently low volume to keep off the radar.    ------------------------------  + Date: Tue, 28 Nov 2006 05:30:20 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) = Subject: Re: Thoughts on the book: DEC is dead, long live DEC ( Message-ID: <ekghhc$916$1@pcls6.std.com>  * bill@cs.uofs.edu (Bill Gunshannon) writes:  * >In article <ekfdj0$1bjm$1@pyrite.mv.net>,< >	Stephen Hoffman <Hoff@HoffmanLabs-RemoveThis-.Org> writes: >> Bill Gunshannon wrote:  >> ...4 >>> -------- IN THE GOOD OLD DAYS ------------------4 >>> |   UUCP: {philabs}\                           |: >>> |         {phri   } >!trotter.usma.edu!bill    |      4 >>> |         {sunybcs}/                           |4 >>> ------------------------------------------------ >>   >>  ; >>    Whilst we are reminiscing, one should mention DECVAX. L >>    If you could route your message to there, you could get anywhere.  :-) >>  $ >>    Ok, coffee break time is over.: >>    Time for me to head back into the code mines...  :-)  A >Only two hops earlier than what I have above was decwrl.dec.com. ? >They were also a major hub and gateway between the developing   >INTERNET and Usenet.   K Of some interest is that decwrl, and another system, RHEA, were the gateway H from the Digital-internal DECnet network to the outside for a long time.K RHEA:: spoke DECnet and was connected to decwrl via some custom software.   H Email from the internet showed up as "from" RHEA::DECWRL::"foo!bar!user"E or later RHEA::DECWRL::"user@foobar.com", and the MAIL> REPLY command & worked correctly with these addresses.   ------------------------------    Date: 28 Nov 2006 00:09:35 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)" Subject: [sFTP] Current situation?* Message-ID: <456b7e3f$1@ns.langstoeger.at>  9 Now that VMS V8.3 and TCPIP V5.6 is out, may I ask again?   ; What is the current situation with SFTP (and SCP) in TCPIP? C IS TCPIP SFTP server still unable to modify its format of providing J its files so that FILEZILLA (and others) do not show empty VMS directoriesG (btw. what is the reason behind? Is it the uppercase filenames or is it # the version numbers? Or what else?)   F Is TCPware (and PSC's standalone SSH product) still the only solution?  M (I know, a PuTTY psftp does work - while PuTTY pscp did not - but is not GUI)   
 Any comments?    TIA    -EPLAN --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Mon, 27 Nov 2006 15:48:12 -0800 * From: "Tom Linden" <tom@kednos-remove.com>& Subject: Re: [sFTP] Current situation?) Message-ID: <op.tjo8ememtte90l@hyrrokkin>   ? On Mon, 27 Nov 2006 15:09:35 -0800, Peter 'EPLAN' LANGSTOEGER    <peter@langstoeger.at> wrote:   ; > Now that VMS V8.3 and TCPIP V5.6 is out, may I ask again?  > = > What is the current situation with SFTP (and SCP) in TCPIP? E > IS TCPIP SFTP server still unable to modify its format of providing B > its files so that FILEZILLA (and others) do not show empty VMS  
 > directories I > (btw. what is the reason behind? Is it the uppercase filenames or is it % > the version numbers? Or what else?)  > H > Is TCPware (and PSC's standalone SSH product) still the only solution? > L > (I know, a PuTTY psftp does work - while PuTTY pscp did not - but is not   > GUI)  K Well, sort of.  psftp does not drop the version number as does native ftp    onG W2K or XP, I have discovered.  I am using hgftp as the server if that    matters. >  > Any comments?  >  > TIA  >  > -EPLAN       --  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------   End of INFO-VAX 2006.654 ************************