1 INFO-VAX	Sun, 28 Sep 2003	Volume 2003 : Issue 537       Contents: $$$ PayPal $$$  Re: DS10 vs. DS40 and HP support2 Re: EVA question: How many vdisks should I create?2 Re: EVA question: How many vdisks should I create?@ Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)% Re: Info on Known VMS Exploits/Cracks % Re: Info on Known VMS Exploits/Cracks % Re: Info on Known VMS Exploits/Cracks D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?D Re: Process's PreciseMail AntiSpam Gateway - any experience so far ?* Re: Read VMS Backup *.bck files in Windows Translating COM jobs% Re: [ZIP V2.3] Bad error/return codes   F ----------------------------------------------------------------------  # Date: Sun, 28 Sep 2003 03:24:13 GMT , From: "$$$$powertip$$$$" <powertip@home.com> Subject: $$$ PayPal $$$ J Message-ID: <xvsdb.122573$Lnr1.70685@news01.bloor.is.net.cable.rogers.com>  + This is a multi-part message in MIME format   $ --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit     * read the inserted message to get $$$$$$$$$   -- Posted by News Bulk Poster Unregistered version  $ --=_NextPart_2rfkindysadvnqw3nerasdf' Content-Type: application/octet-stream;           name="$$$ PayPal$$$.txt"! Content-Transfer-Encoding: base64   Content-Disposition: attachment;$         filename="$$$ PayPal$$$.txt"  L Rm9sbG93IHRoZSBkaXJlY3Rpb25zIGJlbG93IGFuZCBpbiB0d28gd2Vla3MgeW91J2xsIGhhdmUgL dXAgdG8NCiQyMDAwMC4wMCBpbiB5b3VyIFBheVBhbCBhY2NvdW50LiBUaGVyZSBpcyBhIHZlcnkgL aGlnaCByYXRlIG9mDQpwYXJ0aWNpcGF0aW9uIGluIHRoZSBwcm9ncmFtIGJlY2F1c2Ugb2YgaXRzL IGxvdyBpbnZlc3RtZW50IGFuZCBoaWdoDQpyYXRlIG9mIHJldHVybi4gSnVzdCAkNS4wMCB0byBvL bmUgcGVyc29uIQ0KDQpUSEFUJ1MgQUxMICEhIQ0KDQpJZiB5b3UgYXJlIGEgc2tlcHRpYyBhbmQgL ZG9uJ3QgdGhpbmsgdGhlIHByb2dyYW0gd2lsbCB3b3JrLCBJIHVyZ2UNCnlvdSB0byBnaXZlIGl0L IGEgdHJ5IGFueXdheSEgSXQgUkVBTExZIFdPUktTISBXaHkgZG8geW91DQp0aGluayBzbyBtYW55L IHBlb3BsZSBhcmUgcHJvbW90aW5nIGl0ID8NCg0KTE9PSyBBVCBJVCBUSElTIFdBWTogSWYgdGhlL IFByb2dyYW0gaXMgYSB0b3RhbCBmYWlsdXJlIGZvciB5b3UgYW5kIHlvdQ0KbmV2ZXIgZ2V0IGV2L ZW4gJDEuMDAgaW4gcmV0dXJuLCB5b3VyIHRvdGFsIGxvc3Mgd2lsbA0KYmUgdGhlICQ1LjAwISBJL ZiB5b3UgYXJlIG5vdCB5ZXQgYSBwYXlwYWwgbWVtYmVyLCB0aGVyZSBpcyBubyByaXNrIGF0DQphL bGwhISEgSWYgdGhlIFByb2dyYW0gaXMgb25seSBtb2RlcmF0ZWx5IHN1Y2Nlc3NmdWwgZm9yDQp5L b3UsIHlvdXIgUGF5UGFsIGFjY291bnQgd2lsbCBoYXZlIHNldmVyYWwgaHVuZHJlZCBkb2xsYXJzL IGRlcG9zaXRlZA0KaW50byBpdCB3aXRoaW4gdGhlIG5leHQgZmV3IGRheXMhIElmIHlvdSBhY3RpL dmVseQ0KcGFydGljaXBhdGUgaW4gdGhlIFByb2dyYW0sIHlvdSBjb3VsZCBoYXZlIHVwIHRvICQyL MCwwMDAuMDAgaW4geW91cg0KUGF5UGFsIGFjY291bnQgd2l0aGluIHR3byB3ZWVrcyENCg0KTm93L IGxldCBtZSB0ZWxsIHlvdSB0aGUgc2ltcGxlIGRldGFpbHMuDQoNCkdldHRpbmcgU3RhcnRlZCEhL DQoNCklmIHlvdSdyZSBub3QgYWxyZWFkeSBhIHVzZXIgb2YgUGF5UGFsLCB0aGUgdmVyeSBmaXJzL dCB0aGluZyB5b3UgbmVlZA0KdG8gZG8gaXMgZ28gdG8gUGF5UGFsIGFuZCBzaWduIHVwLiBJdCB0L YWtlcyB0d28gbWludXRlcw0KYW5kIFBheSBQYWwgd2lsbCBkZXBvc2l0ICQ1LjAwIGluIHlvdXIgL YWNjb3VudCBqdXN0IGZvciBiZWNvbWluZyBhDQptZW1iZXIuIFRoYXQgbWFrZXMgdGhpcyBwcm9nL cmFtJ3MgdG90YWwgY29zdCAkMCEhISBGb2xsb3cNCnRoaXMgbGluayB0byBvcGVuIHlvdXIgUGF5L UGFsIGFjY291bnQ6DQoNCmh0dHBzOi8vd3d3LnBheXBhbC5jb20NCg0KTm93IGxvZyBpbnRvIHlvL dXIgUGF5UGFsIGFjY291bnQsIGFuZCBzZW5kIHRoZSBQYXlQYWwgYWNjb3VudCBvZiB0aGUNCnBlL cnNvbiBsaXN0ZWQgaW4gUG9zaXRpb24gMSAkNS4wMCBQYXlQYWwgd2lsbCBhc2sgeW91IHRvDQpzL ZWxlY3QgdHlwZS4gKFNlbGVjdCAic2VydmljZSIgYW5kIHB1dCAiJDUuMDAgZG9uYXRpb24iIGZvL cg0Kc3ViamVjdC4pIFdoZW4gcGVyc29uIGluIFBvc2l0aW9uIDEgcmVjZWl2ZXMgbm90aWZpY2F0L aW9uIG9mIHlvdXINCnBheW1lbnQsIHlvdSBjYW4gc2ltcGx5IGNvcHkgdGhpcyBwYWdlIGFuZCBjL aGFuZ2UgdGhlIG5hbWVzIGluDQpwb3NpdGlvbiAjMSAmICMyICYgIzMgYXMgaW5zdHJ1Y3RlZC4gL UmVtZW1iZXIsIG9ubHkgdGhlIHBlcnNvbg0KaW4gUG9zaXRpb24gMSBvbiB0aGUgbGlzdCBnZXRzL IHlvdXIgJDUuMDAgZG9uYXRpb24uIFNlbmQgdGhlbSBhDQpkb25hdGlvbiB0aGVuIHJlbW92ZSAjL MVBheVBhbCBhY2NvdW50IGZyb20gdGhlIGxpc3QuIE1vdmUgdGhlDQpvdGhlciB0d28gYWNjb3VuL dHMgdXAgJiBhZGQgeW91ciBQYXlwYWwgYWNjb3VudCB0byAjMyBwb3NpdGlvbi4gQWZ0ZXINCnlvL dSBoYXZlIHJldHlwZWQgdGhlIG5hbWVzIGluIHRoZSBuZXcgb3JkZXIsDQoNCklNTUVESUFURUxZL IHNlbmQgdGhlIHJldmlzZWQgbWVzc2FnZSB0byBhcyBtYW55IHBlb3BsZSBhcyBwb3NzaWJsZS4NL ClBST01PVEUhIFBST01PVEUhIFRoZSBtb3JlIHlvdSBwcm9tb3RlIHRoZSBQcm9ncmFtLCB0aGUNL Cm1vcmUgeW91IHdpbGwgcmVjZWl2ZSBpbiBkb25hdGlvbnMhISBUaGF0J3MgYWxsIHRoZXJlIGlzL IHRvIGl0Lg0KDQpXaGVuIHlvdXIgbmFtZSByZWFjaGVzIFBvc2l0aW9uIDEgKHVzdWFsbHkgaW4gL bGVzcyB0aGFuIGEgd2VlaykgaXQNCndpbGwgYmUgeW91ciB0dXJuIHRvIHJlY2VpdmUgdGhlIGNhL c2guICQ1LjAwIHdpbGwgYmUgc2VudA0KdG8geW91ciBQYXlQYWwgYWNjb3VudCBieSBwZW9wbGUgL anVzdCBsaWtlIHlvdSB3aG8gYXJlIHdpbGxpbmcgdG8gc2VuZA0KJDUuMDAgZG9udGF0aW9uIGFuL ZCByZWNlaXZlIHVwIHRvICQyMCwwMDAgaW4gbGVzcyB0aGFuDQp0d28gd2Vla3MuIEJlY2F1c2UgL dGhlcmUgYXJlIG9ubHkgKDMpIG5hbWVzIG9uIHRoZSBsaXN0IHlvdSBjYW4NCmFudGljaXBhdGUgL ODAlIG9mIHlvdXIgY2FzaCB3aXRoaW4gdHdvIHdlZWtzLg0KDQpBbnl0aW1lIHlvdSBmaW5kIHlvL dXJzZWxmIHNob3J0IG9uIGNhc2gganVzdCB0YWtlIG91dCB5b3VyICQ1LjAwDQpkb25hdGlvbiBwL cm9ncmFtIGFuZCBzZW5kIGl0IHRvIDUwIHByb3NwZWN0cy4gSW1hZ2luZSBpZiB5b3UNCnNlbnQgL aXQgdG8gMTAwIG9yIGV2ZW4gbW9yZS4gTW9zdCBwZW9wbGUgc3BlbmQgbW9yZSB0aGFuICQ1IG9uL IHRoZQ0KbG90dGVyeSBldmVyeSB3ZWVrIHdpdGggbm8gcmVhbCBob3BlIG9mIGV2ZXIgd2lubmluL Zy4NCg0KVEhJUyBQUk9HUkFNIFdPUktTIC0gSlVTVCBUUlkgSVQNCg0KUE9TSVRJT04gIyAxIFBBL WVBBTCBBY2NvdW50OiBqYWJqd2hhdEBhb2wuY29tDQoNClBPU0lUSU9OICMgMiBQQVlQQUwgQUNDL T1VOVDogbGFtc21vQGFvbC5jb20NCg0KUE9TSVRJT04gIyAzIFBBWVBBTCBBQ0NPVU5UOiBwaGFzL dGllQHJvZ2Vycy5jb20NCg0KSW50ZWdyaXR5IGFuZCBob25lc3R5IG1ha2UgdGhpcyBwbGFuIHdvL cmsuDQpQYXJ0aWNpcGFudHMgd2hvIGFjdGl2ZWx5IHByb21vdGUgdGhpcyBwcm9ncmFtIHdpbGwgL YXZlcmFnZSBiZXR3ZWVuICQ4MDAwDQphbmQNCiQxMjAwMCBhbmQgcmVjZWl2ZSB0aGUgZG9uYXRpL b25zIHdpdGhpbiB0d28gd2Vla3MuDQoNClRoaXMgaXMgbm90IGEgY2hhaW4gbGV0dGVyLiBZb3UgL YXJlIHNpbXBseSBtYWtpbmcgYSBkb25hdGlvbiBvZiAkNS4wMA0KdG8gYW5vdGhlciBwZXJzb24uL IFRoZSBQcm9ncmFtIGRvZXMgbm90IHZpb2xhdGUgdGl0bGUNCjE4IHNlY3Rpb24gMTMwMiBvZiB0L aGUgUG9zdGFsIGFuZCBsb3R0ZXJ5IGNvZGUuDQoNClJlbWVtYmVyIC1USU1FIGlzIG9mIHRoZSBlL c3NlbmNlLiBZT1UgY2FuIGNob29zZSB0byBsaXZlDQpQYXljaGVjay10by1QYXljaGVjayBvciBsL aXZlIEZSRUUgZnJvbSBGSU5BTkNJQUwgQk9OREFHRS4gQmVjb21lIGENCnBhcnQgb2YgdGhlIGRvL bmF0aW9uIHByb2dyYW0gYW5kIGhlbHAgcGVvcGxlIGhlbHAgcGVvcGxlLg0KDQpUaGlzIHByb2dyL YW0gaXMgYWJvdXQgaGVscGluZyBlYWNoIG90aGVyIQ0KDQpTdWNjZXNzIGlzIGEgam91cm5leSAtL IE5vdCBhIGRlc3RpbmF0aW9uIQ0KDQpTdGFydCBZb3VyIEpvdXJuZXkgVE9EQVkhISEhDQoNCg0K  & --=_NextPart_2rfkindysadvnqw3nerasdf--   ------------------------------  % Date: Sat, 27 Sep 2003 17:01:09 -0500 ( From: Rich Jordan <duodec@speakeasy.net>) Subject: Re: DS10 vs. DS40 and HP support 2 Message-ID: <3JCdnXY9GtXAleuiXTWc-g@speakeasy.net>  E If you are referring to my post (bashing) I would like to state that  B once I actually got a person (not in India, apparently) they were F helpful.  The additional step of having to speak to an 'engineer' who I asks generally pc-level questions about my VMS system problems (DAT tape  E drive failed in this case), which adds several hours of delay into a  B response is another issue.  I still have my excellent local field 2 service folks, so the last stage is fine except...  H who the heck does HP get to refurb its DAT drives?  Back in '99 we went F through several TLZ06 drives in a row before field dropped in an '07, I which worked for two years.  When it failed, we went through four DOA or  F quick-fail TLZ07's before they gave up and gave us a TLZ09.  That one H failed a couple weeks ago; had two DOA and one quick fail TLZ09 so they C dropped in a TLZ10 (which is not behaving well...).  Maybe they've  + outsourced refurbishing to India as well...   D The problem really is the significant decline in response and 'user H friendliness' when getting support when compared to the DEC days.  Long G hold times, long transfer times getting to the 'engineer', long delays  H for field service because there are not enough of them, poor quality of % replacement parts in the channel.....    Rich     Grealy, Patrick wrote:    @ > Considering all the HP bashing going on, I would like to stateB that I have been very pleased with the software phone support fromA HP/Compaq that we have received during the past year. There seems B to be at least a few old DEC gurus buried away there. And the helpA we received from Darryl Fuller in Colorado Springs in configuring B the specs for our new system was greatly appreciated since we were@ trying to beat a budget deadline. This was especially remarkableB considering that it was a relatively lightweight academic discountA deal for HP. The sad news, however, is that it took us two months @ of being passed from one rep to another before we found one thatA was both interested and knowledgeable. Thus, the deadline crunch.    - Pat G.   ------------------------------  # Date: Sun, 28 Sep 2003 03:24:53 GMT > From: Michael Austin <maustin@no-more-spam.firstdbasource.com>; Subject: Re: EVA question: How many vdisks should I create? ; Message-ID: <9wsdb.2161$Kz6.529@newssvr23.news.prodigy.com>    Mike Naime wrote:   1 > Scott Vieth <svieth@wi.rr.com> wrote in message 9 > news:5a85bce2.0309251309.5f095452@posting.google.com...  >  >>Hi:  >>G >>In one of the EVA-related sessions in Atlanta (HP World) a few months F >>back, there was a discussion about the "queue depth" of various OS'sD >>and that it beneficial to create more vdisks to present to a givenG >>host to increase the throughput that you would see from the EVA.  The , >>chatter centered around Windows and Tru64. >> >>What about VMS?  >>F >>Let's say I've currently got three units from HSG80s presented to myD >>VMS system.  Those three DGAnn: devices hold around forty database8 >>files (that are all accessed by the same application). >  > K > We put on average 3 Oracle production databases on an HSG80. This is on a  > 1GIG SAN.  > 5 > 40 files on 3 LUNS -- what are you wimpering about? ) > How hard are you accessing the files??? A > What is the performance stats from your SAN switches and HSG's?  > H > When we switches from HSG to EVA for backup drives, we saw a jump fromJ > 35GB/hour to 70GB/hour on RMAN backup speed.  We where still reading theM > data from an HSG drive, and writting it to the EVA.  I suspect that if both G > the source and the Backup drive where on the EVA, we would see better 
 > throughput.  >  > C >>When we move to EVA, should I create one large vdisk and move all B >>forty database files onto that new DGAnn: device?  Or is there aE >>performance benefit to creating four vdisks and putting 10 database E >>files on each DGAnn: device?  How about going with eight vdisks and G >>putting five database files on each DGAnn: device? (All of the vdisks G >>will be in the same disk group regardless if we create 1 big vdisk or  >>8 small vdisks)  >  > L > When you are dealing with HSG's, you are managing SPINDLES, and throughputH > to the individual spindle.  When you are dealing with the EVA, you areL > dealing with managing SPACE.  The IO is spread across your disk group thatI > you carve the Virtual disks from.  So, it doesn't really mattter if you M > logically make it one disk, or 4 disks.  It's more important how many disks  > you have in your disk group. > N > Why change your setup?  If you have a setup that works for your application,K > you can transfer it strait from the HSG's to the EVA LUN for LUN, and not N > worry about re-mapping files.  You should even be able to match the LUN ID's > if you are really good!  :-) > L > Unless you would have larger than a 2TB LUN, you could make the one larger > LUN if you really wanted too.  >  > F >>Is there a difference in performance between having *one* vdisk thatE >>holds all of the files and slicing things up among multiple vdisks?  >  > K > Depends on the Disk group size.   Are your VDISKS in the same group?  Are  > they in Different groups?  >  > C >>Everything is on one HSV110 pair.  Should I think about trying to D >>balance between the "top" and "bottom" HSV?  Or should I shoot forE >>four vdisks and have one vdisk on each HSV port (HSV Top Port1, HSV 1 >>Top Port2, HSV Bottom Port1, HSV Bottom Port2)?  >  > J > You still need to consider things like INDEXF.SYS  Just because you haveL > virtualized the storage, you still need to deal with the OS level settings > for the LUNS.  > M > You can SET DEV DGxxx /switch/PATH=xxxx-xxxx-xxxx-xxxn  (xxxx = HSG WWID, n N > = your HSG port #) This would balance your LUNS between the controllers, butI > it may not be necessary.  What Alphaserver do you have pushing the I/O? # > That may be your real bottleneck.  > M > Unless you have 4 HBA's/Fabrics in your SAN, your bottleneck is going to be L > in your host more than it is in the HSV.  Remember to balance between your# > HBA's as well as EVA controllers.  >  > Questions:3 > How many Servers will you have accessing the EVA? < > How much Data/hour are you trying to push to/from the EVA? >  > ? >>What does the OS do when one DGAnn: device gets buried in I/O G >>requests?  Does it recognize that DGA30: is on the same HSV as DGA20: * >>and stop sending I/O requests to DGA30:? >  > N > NO.  You can see what SAN storage device the DGA device is by doing a SH DEV > /MULTI > K > Compare the path strings to the GGA devices below.  If you are smart, you J > will set the command console LUNS to be a uniqe ID # so that you can see > this relationship. > M > Example:  HSG #1 has a ID = 1001   So I see a GGA1001 device that lists the  > WWID of HSG#1  >  > F >>Any enlightenment and useful advice will be greatly appreciated. :^) >>	 >>Thanks,  >>-Scott Vieth >  >     F Bottom line:  create one big disk group (ours is currently 168 *146GB G drives - total usable space is 22TB) and carve as  many 1TB drives out  E of that as you need.  If you are truly worried about I/O bottleneck,  K make sure you convert your SAN to 2GB and I doubt you could keep it busy...    Michael Austin.    ------------------------------   Date: 28 Sep 2003 08:42:15 GMT7 From: yehavi@vms.huji.ac.il (Yehavi Bourvine (58-4279)) ; Subject: Re: EVA question: How many vdisks should I create? % Message-ID: <2003Sep28.084215@hujicc>   H > Bottom line:  create one big disk group (ours is currently 168 *146GB I > drives - total usable space is 22TB) and carve as  many 1TB drives out  G > of that as you need.  If you are truly worried about I/O bottleneck,  M > make sure you convert your SAN to 2GB and I doubt you could keep it busy...   I I had a paper written by DEC/HPQ (don't have it in front of me now) which N states that by experiments they found that adding drives to a group raises theN total throughput up to 20 drives; adding more drives does not change the totalK throughput; hence, I would create disk groups of around 20 disks per group.  Just my thoughts... 0                                        __Yehavi:   ------------------------------  % Date: Sat, 27 Sep 2003 16:13:15 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> I Subject: Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...) ' Message-ID: <3F75FD6B.A617524B@fsi.net>    JF Mezei wrote:  >  > Bill Todd wrote:8 > > > You are assuming all ISPs would charge for emails. > > E > > Yes, because it would be a legal requirement for their operation.  > G > Nop. Go back to the roots of the internet. A collection of *separate* M > interconnected networks. The USA has no jurisdiction over a Korean network. 1 > Getting everyone to agree would not make sense.   2 Many things happen even though they make no sense.  @ Take so-called "opt-in" lists, for example. By using the serviceE generating the list (home delivery of a purchased item, for example), F you are assumed to have opted-into the list and any generated from it.1 Makes no sense, but that's how "the world" works.   G Your other questions are entirely valid, of course. However, as I said: G How do you eat an elephant? One bite at a time. If it happens, it won't E be by unilateral choice or arbitrary action (example to the contrary: E Wal-Mart dictating that products ordered for sale in stores carry the C new RFID chip/tags by a date they dictate: RFID will happen anyway, F Wally World just wants it to happen by their say-so, instead of in theC normal course of events). There will be discussions, agreements and F negotiations, until some nit like BG comes along and tries to dictate.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sat, 27 Sep 2003 13:40:45 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>. Subject: Re: Info on Known VMS Exploits/Cracks) Message-ID: <3F75CB9B.2DB1F18A@istop.com>    Jerry Nezlick wrote:A > I think my VMS server was cracked some time in the past.  I see C > connections opening on strange ports when no one should be on the D > system.  (Outgoing to ports 113, 80, 6667, 6668.  Destinations are > usually in Asia.)       / 113 is ident. I know it is used by IRC servers. T 80 is for WWW (HTTP). Could be used by any user with lynx, mosaic, kermit, netscape.; 6667-6678 are part of the 6665-6669 block allocated to IRC.   V TCPIP SHOW DEV  will provide a list of current connections with a device name (BGnnn:)Q SHOW DEV BGnnn: /FULL then provides you with the owner (username) and the process  id.   J show proc/id=xxxxx /cont will show you what image this process is running.   ------------------------------  # Date: Sun, 28 Sep 2003 00:44:46 GMT 6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net>. Subject: Re: Info on Known VMS Exploits/Cracks: Message-ID: <2aqdb.3937$1S.443@newssvr29.news.prodigy.com>  L Do you have more than one network card?  If so check that no one has enabledL IP forwarding, allowing your system to act as a router between different LAN	 segments.    -- Andy Bustamante  remove the ASCII 95s to reply 4 "Jerry Nezlick" <jnez367@yahoo.com> wrote in message7 news:4f27336e.0309270611.6372563b@posting.google.com... A > I think my VMS server was cracked some time in the past.  I see C > connections opening on strange ports when no one should be on the D > system.  (Outgoing to ports 113, 80, 6667, 6668.  Destinations are; > usually in Asia.)  Is there a source that will list known F > exploits/cracks of VMS?  I have tried CERT and security focus.  Have > not found much.    ------------------------------  % Date: Sat, 27 Sep 2003 21:05:51 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>. Subject: Re: Info on Known VMS Exploits/Cracks) Message-ID: <3F7633EB.710A4078@istop.com>    Andy Bustamante wrote: > N > Do you have more than one network card?  If so check that no one has enabledN > IP forwarding, allowing your system to act as a router between different LAN > segments.   J If that were the case, would a "netstat" or a "tcpip show dev" provide anyL indication of connections that are being routed by that VMS node but did not& originate nor terminate on that node ?   ------------------------------  # Date: Sat, 27 Sep 2003 19:27:21 GMT ' From: Don Sykes <anonymous@pacbell.net> M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ? + Message-ID: <3F75E528.5AA776B7@pacbell.net>    John Santos wrote: > 5 > On Fri, 26 Sep 2003 david20@alpha2.mdx.ac.uk wrote:  > [ > > In article <vn5s22g2nrds0e@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes: 0 > > ><david20@alpha2.mdx.ac.uk> wrote in message( > > >news:bkuhsq$dk3$1@news.mdx.ac.uk...< > > >> In article <3F71D664.D92AAC37@pacbell.net>, Don Sykes$ > > ><anonymous@pacbell.net> writes: > > >> >' > > >> >david20@alpha2.mdx.ac.uk wrote: 	 > > >> >> ? > > >> >> In article <3F70934A.3C36DD45@pacbell.net>, Don Sykes $ > > ><anonymous@pacbell.net> writes: > > >> >> >  > > >> >N > > >> >At this point I'm fairly convinced that the implementation of fees viaO > > >> >central gateways &/or routers is not workable. So I have come up with a L > > >> >protocol that implements e-mail in 2 phases: a meta phase and a dataL > > >> >phase. In phase 1, all the info about the email is sent to the open,J > > >> >listening port of the receiver. Then the link is dropped, by both.J > > >> >Phase 2 must be initiated by the receiver, so they are in completeM > > >> >control of the transmission and final delivery and at that point they  > > >> >can also charge a fee. > > >> >M > > >> >A first draft is available at http://alphase.com/vms/FBEProtocol.html  > > >> >M > > >> >Serious suggestions are more than welcome, but please no nit-picking. ? > > >> >This is a early, early draft. A suggestion, if you will  > > >> > > > >>O > > >> I haven't had a chance to look at your link yet but one thing strikes me 
 > > >aboutK > > >> your suggestion straight away. How are you going to deal with Natt'd  > > >clients ?L > > >> If you drop the connection then there is no guarantee that the public > > >addressP > > >> that the sender first used will still be valid when the receiver tries to > > >> reopen the connection.  > > >> > > > P > > >There is no need to be concerned about NAT.  This proposal is a replacementN > > >for SMTP servers.  They already need special consideration when used with& > > >NAT, as do all listening servers. > > >  > > >  > > S > > It does matter because your example which uses a client on the 10 address space S > > (10.11.12.1) contacting a server on the 21.22 network will not work in general.  > > O > > (As an aside the address of the receiver 21.22.0.0 is invalid since it is a J > > network address - you should never use .0 or .255 in the final octet). > > P > > The 10 address is a private address hence must use NAT to contact systems on > > the public internet. > > S > > So in the real world you have a client on a small home network connecting to an 0 > > ISP using dynamic NAT with port overloading. > > S > > 10.11.12.1  is the clients real address and it opens a connection from its port Q > > 32100 this is mapped to  21.22.5.20 port 7521  on the public side of his home T > > NAT/firewall. (21.22.5.20 is the single public address given out to this user by
 > > his ISP).  > > R > > This connection connects to the IPS's receiver on 21.22.0.10 (10 rather than 01 > > to make it a valid address) for your phase 1.  > > T > > Negotiation proceeds as you describe on your link and the receiver sends back toJ > > say it will contact the sender on port 1398. Then the link is dropped. > > $ > > 10.11.12.1 listens on port 1398. > > R > > Receiver (21.22.0.10) attempts to open connection to  21.22.5.20 on port 1398.I > > Attempt fails. There is  either no entry in the NAT mapping table for R > > 21.22.5.20 port 1398  or if there is it would be accidental and might point at7 > > another machine or port on the user's home network.  > > The connection is dropped. > > P > > With dynamic NAT with port overloading (which is the most common form of NATQ > > used on home networks where the home user has multiple machines hiding behind R > > one external address) there is no preservation of port numbers - unless a portN > > number has been placed in the NAT mapping table by an internally initiatedP > > connection to an external machine having been made or by the user explicitlyN > > setting up a manual mapping then an externally initiated connection cannot > > be made to it. > >  > > Your system falls apart. > L > I don't think I understand the point of the second, reverse connection[1],@ > but in any case, there is an alternate method that might work. > H > Instead of negotiating a port number for the 2nd connection, you couldD > use a well-known port that the NAT firewall forwards to the clientD > system, and negotiate a magic key (perhaps encrypted).  The clientG > listens on the well-known port, the server establishes the call-back, C > and sends the key.  The client can accept the key and continue or % > reject it and close the connection.  > C > Both ends could be behind NAT'ing firewalls, and this would still E > work, since the client could accept connections from anywhere, then A > immediately close those that didn't provide a valid outstanding  > key. > C > Both sides would know who they were talking to because of the key  > exchange.  > C > If you have multiple systems behind a NAT firewall, each could be C > permanently assigned a port, which would be port-forwarded to its G > well-known port, and that port could be included in the negotiations, D > so the server would know what port to connect to.  That port couldC > be statically configured in the NAT box and the client system, or ; > could be configured dynamicly using an extension to DHCP.  > D > [1] Is ths second reverse connection just so the client and serverD > can go away for awhile to meditate on whether to allow the messageD > to propagate, or is it so the actual data message can be postponedC > to a less busy time, if necessary (middle of the night), or is it I > just to allow the server some measure of "control" over the connection?   F It's for ALL 3 reasons and more. But it doesn't allow "some measure ofE control", it gives complete control to the receiver, which is a major E facet of the FBEM protocol. If the receiver decides for ANY reason it E doesn't want to deal with the incoming request, it doesn't have to do * anything and the message dies on the vine.  E * please post future comments on this issue in the thread titled: Fee < Based Email (From Re: Process's PreciseMail AntiSpam...) TIA     --     Have VMS, Will Travel  Wire paladin, San Francisco    (paladinATalphaseDOTcom)   ------------------------------  % Date: Sat, 27 Sep 2003 18:08:14 -0400 . From: Pussy Galore <P.Galore@pussy_galore.com>M Subject: Re: Process's PreciseMail AntiSpam Gateway - any experience so far ? 0 Message-ID: <3F760A4B.C8819E61@pussy_galore.com>   Don Sykes wrote:G > facet of the FBEM protocol. If the receiver decides for ANY reason it G > doesn't want to deal with the incoming request, it doesn't have to do , > anything and the message dies on the vine.  J And with current SMTP specifications, if the received doesn't want to dealN with the incoming request, it can simply send the appropriate error message atN a RCPT TO, DATA or after the end of the DATA phase and the message dies on the
 vine as well.    ------------------------------  % Date: Sat, 27 Sep 2003 16:22:25 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 3 Subject: Re: Read VMS Backup *.bck files in Windows ' Message-ID: <3F75FF91.2EDC929D@fsi.net>    Robert Boers wrote:  > ! > THis is probably what you need: < > http://www.emulatorsinternational.com/en/products_TAPE.htm > M > It can read VMS backup tapes using a SCSI tape drive connected to a Windows G > system. It understands the VMS file and .BCK format and can index and $ > extract VMS directories and files.I > In the same way it can work with VMS file images already present on the  > Windows system.   D The program claims only to read BACKUP savesets on disk and tape. It8 makes no claim about understanding any RMS file formats.  C He may be able to get the files, but using them is another question 	 entirely.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 27 Sep 2003 15:28:31 -0700 From: ptpradeep@yahoo.com (pt) Subject: Translating COM jobs = Message-ID: <1bb28b5a.0309271428.55764876@posting.google.com>    Hi ,F      I'm working on a COM job parser, trying to pick out the logicals," executables and included com jobs.  ; My question is what patterns should in look for in COM jobs   B like for example f$logical("XXXX") translates to the logical XXXX   E Im quite new to Openvms any help would be appriciated in tackling the  issue.  > Is there any tool which will speed up the process, i.e help me9 identify the logicals, executables and included com jobs.    Thanks   ------------------------------  % Date: Sun, 28 Sep 2003 04:06:39 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender). Subject: Re: [ZIP V2.3] Bad error/return codes; Message-ID: <3f76422f.524144494f47414741@radiogaga.harz.de>   7 Peter 'EPLAN' LANGSTOEGER (peter@langstoeger.at) wrote: I > Has anyone an idea how to circumvent the wrong error codes of ZIP.EXE ?  > , > 	"zip warning: could not open for reading"8 > gives	"%NONAME-E-INSFMEM, insufficient dynamic memory" >  > 	"zip error: Nothing to do" 6 > gives	"%NONAME-W-GPTFULL, global page table is full" > , > 	"zip error: Could not create output file"8 > gives	"%NONAME-F-ILLIOFUNC, illegal I/O function code" >  > and so on. > B > Is there a good way to fix the source code ? A formula perhaps ?C > Is there a logical for the change of the behaviour of the C RTL ?   & The code is in [.vms]vms.c:vms_exit():  G    (e == ZE_OK) ? 1 :                     /*   success               */ G    (0x7FFF0000 | (e << 4) | severity)     /*   warning, error, fatal */   4 with e being the ZIP exit code, defined in ziperr.h:  ) #define ZE_OK       0       /* success */ < #define ZE_EOF      2       /* unexpected end of zip file */: #define ZE_FORM     3       /* zip file structure error *// #define ZE_MEM      4       /* out of memory */ 6 #define ZE_LOGIC    5       /* internal logic error */: #define ZE_BIG      6       /* entry too large to split */8 #define ZE_NOTE     7       /* invalid comment format */G #define ZE_TEST     8       /* zip test (-T) failed or out of memory */ ? #define ZE_ABORT    9       /* user interrupt or termination */ 9 #define ZE_TEMP     10      /* error using a temp file */ 4 #define ZE_READ     11      /* read or seek error *// #define ZE_NONE     12      /* nothing to do */ ; #define ZE_NAME     13      /* missing or empty zip file */ 9 #define ZE_WRITE    14      /* error writing to a file */ 8 #define ZE_CREAT    15      /* couldn't open to write */2 #define ZE_PARMS    16      /* bad command line */I #define ZE_OPEN     18      /* could not open a specified file to read */   J And "0x7FFF0000 was chosen (by experimentation) to be outside the range of3 VMS FACILITYs that have dedicated message numbers."   D So it's really just the severity that is sensible on VMS. Apart fromB that, ZIP error codes have nothing to do with VMS condition codes.   cu,    Martin --  A    OpenVMS @ 25      | Martin Vorlaender  |  VMS & WNT programmer .                      | work: mv@pdv-systeme.deE    Still exceeding   |       http://www.pdv-systeme.de/users/martinv/ 5    expectations      | home: martin@radiogaga.harz.de    ------------------------------   End of INFO-VAX 2003.537 ************************                                                                 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46 accepted.  <<< PORT 147,162,156,46,200,346 >>> 200 Port 200.34 at Host 147.162.156.46