Archive-Date: Thu, 6 Apr 2000 14:00:42 -0500 Sender: schreiber@process.com Date: Thu, 6 Apr 2000 13:59:53 -0500 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: info-multinet@process.com, info-tcpware@process.com Message-ID: <009E8358.D895FB25.97@process.com> Subject: DECUS/ITUG Europe 2000 - Vienna Austria 4/9/00 - 4/13/00 For those of you in Europe or otherwise planning on attending DECUS Europe 2000. I thought our customers might be interesting in knowing that Process Software will be out there. There will be a seminar on Sunday, and some sessions during the week. We will also try to schedule a TCPware/Multinet customer BOF session where customers can meet and talk about the two products, what they might like to see in the future, or specific problems that they want to try bouncing off Process Software Engineering. Hope I see some of you there! -Jeff Schreiber -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Sat, 8 Apr 2000 08:28:16 -0500 Message-ID: <38EF230D.FDF82C50@SMTP.DeltaTel.RU> Date: Sat, 08 Apr 2000 16:16:13 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: DHCP API? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I would like to have some DHCP API to allow to local applications to get ip addreses from the predefined pool in the DHCPD.conf. For example: DHCPD.CONF: shared-network "NAS-pool" { .... } some protypes: int dhcp$init(); int dhcp$get_ip(pool_name, preffered_ip, option_list) pool_name - pool name (have predefined in the DHCPD.CONF) preffered_ip - preffered IP address option_list - list of options in form described in DHCP/BOOTP RFC int dhcp$cleanup(); TIA, Also I'll greate appreciate any personal oppinions about of possible variants to implementation, and oppinions from PSC about of posibility to put this kind of API to a next release of the TCPWAre-TCP. -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +..... Kick ass VMS solution listening "Nightingales & Bombers" .....+ ================================================================================ Archive-Date: Sun, 9 Apr 2000 06:00:24 -0500 Subject: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <38f05347$1@news.kapsch.co.at> Date: 9 Apr 2000 11:54:15 +0200 To: Info-TCPware@PROCESS.COM This week, I had a lot mails hanging (mostly to .CH addresses) in my MX queue and wondered why. They all had the error message "connection timed out". Contacting the affected mailservers (after a NSLOOKUP -type=MX) by hand (TELNET to TCP port 25) showed no problem. So, I did write a couple of (small) mails and they did hang, too. It seems, it was not a problem with mailsize. I did then write testmails from another node (with UCX) and the mails got through. So, I enabled a UCX node in my cluster to run a few SMTP agents and voila all mails got out (just like the other umpteen hundreds mails per day which gets delivered without problems). Now, I'm a bit of surprised and disappointed. I use MX V5.1-3 (= V5.1-A), TCPware V5.4-3 (with DRIVERS ECO 1.0). Next steps are, I upgrade to the most current versions of MX (which should be no issue) and TCPware ECOs (eg. DRIVERS 2.0), but I also ask here: Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? I remember, having problems with MX deliveries, the first week after upgrading to TCPware V5.4-3 which disappeared without my intervention (this gave a bad feeling then, and again, when I read some days/weeks ago, that other users had strange errors with TCPware V5.4-3 and MX, too). In the meantime, I run a few UCX SMTP agent, too... TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Mon, 10 Apr 2000 04:38:29 -0500 Message-ID: From: "Spijker, Peter (eX)" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: FW: Notification: Inbound Mail Failure Date: Mon, 10 Apr 2000 10:38:26 +0200 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === Onderstaande persoon is niet in dienst, zijn zaken worden nu uitgevoerd door Pietr van de Hulst deze is werkzaam bij C.S.C. Apeldoorn. Peter Spijker Helpdesk CSC / Oss toestel 399 of 0412667310 > -----Oorspronkelijk bericht----- > Van: Helpdesk CSC > Verzonden: zondag 9 april 2000 0:03 > Aan: Helpdesk CSC > Onderwerp: Notification: Inbound Mail Failure > > The following recipients did not receive the attached mail. Reasons are > listed with each recipient: > > F.Kempers@DESSO.NL > MSEXCH:IMS:DESSEAUX:DSXOSS:DESSO4 0 (000C05A6) Unknown Recipient > > The message that caused this notification was: > > <> Message-ID: <20000408220202Z27359-276+1069@frisbee.nl.uu.net> From: Hunter Goatley -- Info-TCPware Owner Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Info-TCPware Digest V100 #59 Date: Sun, 9 Apr 2000 01:00:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Info-TCPware Digest Sat, 8 Apr 2000 Volume 100 : Issue 59 Today's Topics: DHCP API? Send digest submissions to: Info-TCPware@process.com Send add/unsubscribe requests to: Info-TCPware-request@process.com (send HELP for more information) Send problems about the list to: owner-info-tcpware@process.com Info-TCPware WWW home page: http://www.tcpware.process.com/ Info-TCPware FTP archives: ftp://ftp.tcpware.process.com/ Info-TCPware archives: http://www.tcpware.process.com/ ---------------------------------------------------------------------- Date: Sat, 08 Apr 2000 16:16:13 +0400 From: "Ruslan R. Laishev" Subject: DHCP API? Message-ID: <38EF230D.FDF82C50@SMTP.DeltaTel.RU> Hi ! I would like to have some DHCP API to allow to local applications to get ip addreses from the predefined pool in the DHCPD.conf. For example: DHCPD.CONF: shared-network "NAS-pool" { .... } some protypes: int dhcp$init(); int dhcp$get_ip(pool_name, preffered_ip, option_list) pool_name - pool name (have predefined in the DHCPD.CONF) preffered_ip - preffered IP address option_list - list of options in form described in DHCP/BOOTP RFC int dhcp$cleanup(); TIA, Also I'll greate appreciate any personal oppinions about of possible variants to implementation, and oppinions from PSC about of posibility to put this kind of API to a next release of the TCPWAre-TCP. -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +..... Kick ass VMS solution listening "Nightingales & Bombers" .....+ ------------------------------ End of Info-TCPware Digest V100 #59 *********************************** ================================================================================ Archive-Date: Mon, 10 Apr 2000 04:41:24 -0500 Message-ID: From: "Spijker, Peter (eX)" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: FW: Notification: Inbound Mail Failure Date: Mon, 10 Apr 2000 10:41:20 +0200 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === Peter Spijker Helpdesk CSC / Oss toestel 399 of 0412667310 > -----Oorspronkelijk bericht----- > Van: Helpdesk CSC > Verzonden: maandag 10 april 2000 2:14 > Aan: Helpdesk CSC > Onderwerp: Notification: Inbound Mail Failure > > The following recipients did not receive the attached mail. Reasons are > listed with each recipient: > > F.Kempers@DESSO.NL > MSEXCH:IMS:DESSEAUX:DSXOSS:DESSO4 0 (000C05A6) Unknown Recipient > > The message that caused this notification was: > > <> Message-ID: <20000409220158Z28459-272+1197@frisbee.nl.uu.net> From: Hunter Goatley -- Info-TCPware Owner Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: Info-TCPware Digest V100 #60 Date: Mon, 10 Apr 2000 01:00:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Info-TCPware Digest Sun, 9 Apr 2000 Volume 100 : Issue 60 Today's Topics: MX problems since TCPware V5.4-3 Send digest submissions to: Info-TCPware@process.com Send add/unsubscribe requests to: Info-TCPware-request@process.com (send HELP for more information) Send problems about the list to: owner-info-tcpware@process.com Info-TCPware WWW home page: http://www.tcpware.process.com/ Info-TCPware FTP archives: ftp://ftp.tcpware.process.com/ Info-TCPware archives: http://www.tcpware.process.com/ ---------------------------------------------------------------------- Date: 9 Apr 2000 11:54:15 +0200 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: MX problems since TCPware V5.4-3 Message-ID: <38f05347$1@news.kapsch.co.at> This week, I had a lot mails hanging (mostly to .CH addresses) in my MX queue and wondered why. They all had the error message "connection timed out". Contacting the affected mailservers (after a NSLOOKUP -type=MX) by hand (TELNET to TCP port 25) showed no problem. So, I did write a couple of (small) mails and they did hang, too. It seems, it was not a problem with mailsize. I did then write testmails from another node (with UCX) and the mails got through. So, I enabled a UCX node in my cluster to run a few SMTP agents and voila all mails got out (just like the other umpteen hundreds mails per day which gets delivered without problems). Now, I'm a bit of surprised and disappointed. I use MX V5.1-3 (= V5.1-A), TCPware V5.4-3 (with DRIVERS ECO 1.0). Next steps are, I upgrade to the most current versions of MX (which should be no issue) and TCPware ECOs (eg. DRIVERS 2.0), but I also ask here: Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? I remember, having problems with MX deliveries, the first week after upgrading to TCPware V5.4-3 which disappeared without my intervention (this gave a bad feeling then, and again, when I read some days/weeks ago, that other users had strange errors with TCPware V5.4-3 and MX, too). In the meantime, I run a few UCX SMTP agent, too... TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ------------------------------ End of Info-TCPware Digest V100 #60 *********************************** ================================================================================ Archive-Date: Mon, 10 Apr 2000 10:37:29 -0500 Sender: goatley@triton.process.com Return-Path: Date: Thu, 16 Mar 2000 16:53:22 GMT From: babiarz@ENDOR.COM Reply-To: Info-TCPware@process.com To: INFO-TCPWARE@PROCESS.COM Message-ID: <000316165322.6aca6@ENDOR.COM> Subject: smtp reject file, STOPPING RELAY I have been told that my network is open to third party relay. I have closed things up, but still have a problem. I think that the following line may be the cause. ! ! Accept all messages with MAIL FROM:<> (bounce messages) ! <> * * n ! john babiarz interglactic software ================================================================================ Archive-Date: Mon, 10 Apr 2000 10:45:29 -0500 Date: Mon, 10 Apr 2000 9:44:53 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000410094453.202000c5@process.com> Subject: RE: smtp reject file, STOPPING RELAY babiarz@ENDOR.COM writes: > >I have been told that my network is open to third party >relay. I have closed things up, but still have a problem. >I think that the following line may be the cause. > > >! >! Accept all messages with MAIL FROM:<> (bounce messages) >! ><> * * n >! > It could be. You could refine the line by changing it to: <> * *@ENDOR.COM n To accept only bounces aimed for your site. You can't just reject all messages with a MAIL FROM: of "<>", because that's how mail processors avoid generating loops from bounce messages; the method is described in RFC821 as being legit. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Mon, 10 Apr 2000 13:07:48 -0500 Message-ID: <38F1FDC8.15A7AEDC@SMTP.DeltaTel.RU> Date: Mon, 10 Apr 2000 20:14:00 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: DHCP API? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM PSC - you are listening ? Ruslan R. Laishev wrote: > > Hi ! > I would like to have some DHCP API to allow to local applications to > get ip addreses from the predefined pool in the DHCPD.conf. For example: > > DHCPD.CONF: > shared-network "NAS-pool" > { > .... > } > > some protypes: > int dhcp$init(); > int dhcp$get_ip(pool_name, preffered_ip, option_list) > pool_name - pool name (have predefined in the DHCPD.CONF) > preffered_ip - preffered IP address > option_list - list of options in form described in DHCP/BOOTP RFC > int dhcp$cleanup(); > > TIA, Also I'll greate appreciate any personal oppinions about of > possible variants to implementation, and oppinions from PSC about of > posibility to put this kind of API to a next release of the TCPWAre-TCP. > > -- > Regards. > +.....................pure personal opinion..........................+ > Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM > Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 > +..... Kick ass VMS solution listening "Nightingales & Bombers" .....+ -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Mon, 10 Apr 2000 13:30:06 -0500 Date: Mon, 10 Apr 2000 12:29:32 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009E8670.E30B8762.4@goat.process.com> Subject: RE: MX problems since TCPware V5.4-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? > No, I know of nothing that should cause MX problems. >I remember, having problems with MX deliveries, the first week after >upgrading to TCPware V5.4-3 which disappeared without my intervention >(this gave a bad feeling then, and again, when I read some days/weeks >ago, that other users had strange errors with TCPware V5.4-3 and MX, too). > I don't remember those, but the problems sound like DNS response issues and not anything directly related to MX. Did you check the MX_SMTP_LOCK_DIR: directory to see why those messages were not going out? Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Mon, 10 Apr 2000 15:44:05 -0500 Date: Mon, 10 Apr 2000 14:43:32 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000410144332.202000c5@process.com> Subject: ECO rankings Included below is a list of the current TCPware ECOs and a ranking for each. This should help you determine which ECOs you might need or want to install. The ECO database will soon be modified to include these rankings for each ECO. Post here if you have any questions, or contact our technical support group at . Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ -------------------------------------------------------------------------------- Ratings for the current TCPware ECOs The ratings indicate: 1. ECO corrects a problem that could cause failure to multiple components or could lead to a system crash. 2. ECO corrects a problem that could cause the individual component to fail. 3. ECO corrects a specific problem in that component and should only be applied if that problem is being experienced. ECO Rating DHCP_V543P040.ZIP 2 DRIVERS_V543P020.ZIP 1 FTP_V543P040.ZIP 2 NAMED_V543P033.ZIP 2 [End of post] ================================================================================ Archive-Date: Mon, 10 Apr 2000 18:24:13 -0500 Sender: schreiber@process.com Date: Mon, 10 Apr 2000 18:23:37 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009E86A2.59F3198B.26@process.com> Subject: Re: DHCP API? "Ruslan R. Laishev" writes: > >PSC - you are listening ? > Ruslan, I don't mean to be offensive, but yes, of course we're listening. The Info-* lists aren't official support channels, and the fact that you get responses from engineers on nights and weekends is out of our free time. Even the responses from the engineers you get during the day isn't scheduled time, it's time that we choose to spend and have to make up that time later to keep our scheduled tasks on time. You can't expect an immediate answer from through this channel, I'm sorry that is what you have grown to expect from responses in the past, it's not something that can happen on each and every post. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 11 Apr 2000 02:24:30 -0500 Message-ID: <38F2BA8B.B3CE7292@SMTP.DeltaTel.RU> Date: Tue, 11 Apr 2000 09:39:23 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: DHCP API? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: > > "Ruslan R. Laishev" writes: > > > >PSC - you are listening ? > > > > Ruslan, > I don't mean to be offensive, but yes, of course we're listening. The > Info-* lists aren't official support channels, and the fact that you > get responses from engineers on nights and weekends is out of our free > time. Even the responses from the engineers you get during the day isn't > scheduled time, it's time that we choose to spend and have to make up that > time later to keep our scheduled tasks on time. > > You can't expect an immediate answer from through this channel, I'm sorry > that is what you have grown to expect from responses in the past, it's > not something that can happen on each and every post. No problem, Jeff, I understand how are busy PSC-engineereng at this time. If it preffered I'll contact by official way, through support@process.com. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +..... Kick ass VMS solution listening "Nightingales & Bombers" .....+ ================================================================================ Archive-Date: Tue, 11 Apr 2000 02:54:08 -0500 Subject: RE: MX problems since TCPware V5.4-3 From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <38f2cb1b$1@news.kapsch.co.at> Date: 11 Apr 2000 08:50:03 +0200 To: Info-TCPware@PROCESS.COM In article <009E8670.E30B8762.4@goat.process.com>, Hunter Goatley writes: >eplan@kapsch.net (Peter LANGSTOEGER) writes: >> >>Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? >> >No, I know of nothing that should cause MX problems. I thought so, too. >>I remember, having problems with MX deliveries, the first week after >>upgrading to TCPware V5.4-3 which disappeared without my intervention >>(this gave a bad feeling then, and again, when I read some days/weeks >>ago, that other users had strange errors with TCPware V5.4-3 and MX, too). >> >I don't remember those, but the problems sound like DNS response >issues and not anything directly related to MX. No. DNS was handled correctly. Mail was delivered almost correctly (so it seems by the time it took to get the message), but didn't complete, so message had to be retried (for the next 95 times) and then bounce back to the sender. >Did you check the MX_SMTP_LOCK_DIR: directory to see why those >messages were not going out? No Lockfiles. The mailserver was there, did respond and started to receive the mails. I think, I need a TCPIPDUMP on offhour times to prove it... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Tue, 11 Apr 2000 13:12:24 -0500 Message-ID: From: Jacobi Michael CRPH Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: MX problems since TCPware V5.4-3 Date: Tue, 11 Apr 2000 13:11:36 -0400 MIME-Version: 1.0 Content-Type: text/plain When I first attempted to upgrade to V5.4-3 from V5.3-2 & -3 I had a 'minor' problem on my VMS V7.1 systems - NO TCP connections would work when the VMS 7.1 host was originating the connection. I could telnet TO my systems, but I could not telnet FROM them! While this was going on I was seeing the same type of problems delivering mail via MX. Mike Jacobi NSWCCD SSES 96341 Shore based networking > -----Original Message----- > From: eplan@kapsch.net [SMTP:eplan@kapsch.net] > Sent: Tuesday, April 11, 2000 2:50 AM > To: Info-TCPware@PROCESS.COM > Subject: RE: MX problems since TCPware V5.4-3 > > In article <009E8670.E30B8762.4@goat.process.com>, Hunter Goatley writes: > >eplan@kapsch.net (Peter LANGSTOEGER) writes: > >> > >>Is there a known problem in TCPware V5.4-3 which effects MX mail delivery ? > >> > >No, I know of nothing that should cause MX problems. > > I thought so, too. > > >>I remember, having problems with MX deliveries, the first week after > >>upgrading to TCPware V5.4-3 which disappeared without my intervention > >>(this gave a bad feeling then, and again, when I read some days/weeks > >>ago, that other users had strange errors with TCPware V5.4-3 and MX, too). > >> > >I don't remember those, but the problems sound like DNS response > >issues and not anything directly related to MX. > > No. DNS was handled correctly. Mail was delivered almost correctly (so it > seems by the time it took to get the message), but didn't complete, so > message had to be retried (for the next 95 times) and then bounce back > to the sender. > > >Did you check the MX_SMTP_LOCK_DIR: directory to see why those > >messages were not going out? > > No Lockfiles. The mailserver was there, did respond and started to receive > the mails. > > I think, I need a TCPIPDUMP on offhour times to prove it... > > -- > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 > Network and OpenVMS system manager Fax. +43 1 81111-888 > FBFV/Information Services E-mail eplan@kapsch.net > <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN > A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" > "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 13 Apr 2000 06:53:17 -0500 From: adrian_parker@my-deja.com Reply-To: Info-TCPware@process.com Subject: Help with RCP command syntax Date: Thu, 13 Apr 2000 10:42:07 GMT Message-ID: <8d489u$rk$1@nnrp1.deja.com> To: Info-TCPware@PROCESS.COM Hi, Perhaps someone could help out with an RCP copy command. We want to copy VMS host to VMS host, both running TCPware 5.3-x, specifying a logical in both source and destination. This is what we've tried; $ rsh remnode show time 13-APR-2000 06:33:36 $ rcp remnode:"sys$login:test.txt" ":sys$login:test.txt" %TCPWARE-F-ENOTCONN, socket is not connected %TCPWARE-F-ENOTCONN, socket is not connected $ rcp remnode:"sys$login:test.txt" "sys$login:test.txt" %RCP-E-NOSUCHHOST, unknown host sys$login %RCP-E-NOSUCHHOST, unknown host sys$login $ rcp remnode:"sys$login:test.txt" "test.txt" This works (ie not specifying a logical in the destination). I have tried specifying rcp /novms but it doesn't make a difference. Thanks and regards, Adrian Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Thu, 13 Apr 2000 16:53:56 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8602558EBC@lespaul.process.com> From: Lauren Maschio Reply-To: Info-TCPware@process.com To: "'TCPware-Announce@PROCESS.COM'" Subject: Platinum Acquires Process Date: Thu, 13 Apr 2000 16:53:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear Customer: We have important news to share with you about Process Software and our commitment to you as a valued customer. Platinum Equity Holdings (www.peh.com) of Los Angeles has purchased the TCP/IP Internetworking software operations of Process Software Corporation. The new organization, which will retain the Process Software name, will continue to focus exclusively on meeting your expectations as the industry's premier provider of TCP/IP software for OpenVMS solutions, MultiNet and TCPware. The entire TCP/IP infrastructure will remain with Process Software as part of the transaction, ensuring that you will continue to receive the same outstanding products, service and support you've become accustomed to with Process Software. The remaining components of the company will be aligned to form "IPWorks," a new, separate organization that will be focused on software applications for the Internet. We are excited about the strength, stability, and leadership that Platinum will bring to Process Software. Platinum is a privately held investment corporation that specializes in acquiring and operating mission-critical technology organizations and technology-enabled service companies throughout the world. Platinum currently owns 15 technology-driven corporations featuring a workforce of nearly 10,000 employees and an established worldwide infrastructure in more than 100 countries. Our new parent company has been recognized as one of the largest and fastest growing privately held IT companies in the United States. Platinum's expertise, resources, and commitment will provide a solid foundation for Process Software. While this will certainly be a period of change for our company, our current product offerings will stay in place and serving you at the highest level will remain our total focus. Be assured, you will receive the same level of attention, and customer service excellence and expertise as before. While our operational strategy is evolving, our priorities are not. We would like to close by saying "thank you" for being a Process Software customer. We greatly appreciate your business. Your comfort and confidence in Process Software and its parent company, Platinum Equity Holdings, are extremely important to us. Both companies are well established, well funded and completely committed to you, our customer, and to the future development of our products. Sincerely, Dean Goodermote President and Chief Executive Officer Process Software Phil Norment Chief Operating Officer Platinum Equity Holdings ================================================================================ Archive-Date: Fri, 14 Apr 2000 05:10:11 -0500 From: "P.A. Oudakker" Reply-To: Info-TCPware@process.com Subject: Re: How to setup protocol "Netbios over TCP/IP (RFC1001,RFC1002,STD-19) " on OpenVMS ? Message-ID: Date: Fri, 14 Apr 2000 10:50:32 +0200 To: Info-TCPware@PROCESS.COM Try the easy way at: www.samba.org "Hermann Reisenbauer" wrote in message news:0E16861EE7BCD111BE9400805FE6841F0F0BCA17@c1s5x001.cor.srvfarm.origin-it .com... > We want to connect PCs to an OpenVMS system using this protocol. > > Please mail any hints and tips to: hermann.reisenbauer@at.origin-it.com > > Thanks ! > > > ================================================================================ Archive-Date: Tue, 18 Apr 2000 06:23:39 -0500 Message-ID: From: Kevin Phillip Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Subject: MGFTP V2.6-1 Date: Tue, 18 Apr 2000 11:21:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi there, I'm interested in upgrading to MGFTP v2.6-1, but I would like to read the release notes. Can you tell me where I can get a copy? Thanks, Kevin Phillip Systems Manager, Itex (FIT) Limited *********************************************************************** Any views expressed in this message are those of the individual sender, except where the sender states them to be the views of Itex Limited. This e-mail is intended only for the individual or entity to which it is addressed and contains information that is private and confidential. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error please delete it immediately and advise us by return e-mail to administrator@itexjsy.com. *********************************************************************** ================================================================================ Archive-Date: Tue, 18 Apr 2000 08:27:14 -0500 Date: Tue, 18 Apr 2000 7:26:19 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: KEVINP@ITEXJSY.COM Message-ID: <000418072619.202000c1@process.com> Subject: RE: MGFTP V2.6-1 Kevin Phillip writes: > >Hi there, > >I'm interested in upgrading to MGFTP v2.6-1, but I would like to read the >release notes. Can you tell me where I can get a copy? > The release notes can be found in the MGFTP.ZIP file. I've also placed a copy on FTP.WKU.EDU: ftp://ftp.wku.edu/vms/fileserv/mgftp026.release_notes Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 19 Apr 2000 10:04:57 -0500 Message-ID: <38FDB9DF.9C31A611@SMTP.DeltaTel.RU> Date: Wed, 19 Apr 2000 17:51:27 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: IPAW future directions Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi All, PSC! I known that in the next VMS release (7.3 - Kestrel, at spring 2000) will present LDAP server as a part of OS (covered by VMS license), is there any works in this direction on PSC? I just wondering :-) -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 19 Apr 2000 15:58:21 -0500 Date: Wed, 19 Apr 2000 15:57:03 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P050 To: TCPware-Announce@PROCESS.COM Message-ID: <01JOFC39PITU003678@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P050 Description: Fix for /IMAGE=SIZE on PUT and with TCPWARE_FTP__ROOT logical Release date: 19-APR-2000 Ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p050.zip To search the TCPware ECO database, please visit the following URL: http://www.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------------------- This version of teh eco fixes: FTP_SERVER.EXE: - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) ----------------------------------------------------------------------- FTP Patch kit (revision 5.0) for TCPware version 5.4-3 18-Apr-2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new versions of FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - A possible denial of service attack has been corrected. (DE 5347) To control how much time can elapse before the connection is killed if it is not successfully authorized as an FTP user define TCPWARE_FTP_IDLE_TIMEOUT. The format for this logical is the delta time (dddd hh:mm:ss.hh) that can elapse between when the connection is established and when it must be successfully logged in. The default value for this is 10 minutes. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 20 Apr 2000 15:12:15 -0500 Subject: Compaq Management Agents with TCPware ? From: eplan@kapsch.net (Peter LANGSTOEGER) Reply-To: Info-TCPware@process.com Message-ID: <38ff5522$1@news.kapsch.co.at> Date: 20 Apr 2000 21:06:10 +0200 To: Info-TCPware@PROCESS.COM Has anyone tried/succeeded to run the COMPAQ Management Agents for OpenVMS (current seems to be V2.0) with TCPware ? This are eSNMP agents (with some MIBs) which links in the SNMP package of UCX and TCPIP. Support for Multinet is said to be coming in a future release. So, what is with TCPware ? Does it work ? Will it ever work ? Why isn't TCPware mentioned in their docu/future-plans ? TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Thu, 20 Apr 2000 15:22:44 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8602455B5D@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Compaq Management Agents with TCPware ? Date: Thu, 20 Apr 2000 15:21:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Support for Compaq Management Agents for OpenVMS will be added to a future version of TCPware. -----Original Message----- From: eplan@kapsch.net [mailto:eplan@kapsch.net] Sent: Thursday, April 20, 2000 3:06 PM To: Info-TCPware@PROCESS.COM Subject: Compaq Management Agents with TCPware ? Has anyone tried/succeeded to run the COMPAQ Management Agents for OpenVMS (current seems to be V2.0) with TCPware ? This are eSNMP agents (with some MIBs) which links in the SNMP package of UCX and TCPIP. Support for Multinet is said to be coming in a future release. So, what is with TCPware ? Does it work ? Will it ever work ? Why isn't TCPware mentioned in their docu/future-plans ? TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Tue, 25 Apr 2000 14:02:06 -0500 Message-ID: From: "Garrido, Ramon, Mr, HQAFCEE" Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: SMTP / VMS Mail Date: Tue, 25 Apr 2000 13:00:05 -0500 MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === Running TCPWARE 5.4-3 on an Alpha VMS 7.1 1H2 When a SMTP% VMS Mail is received, the Date: displays "GMT" instead of "CST" (even though the time is correct BUT only if sent to the same VMS node, but if sent to MSOutlook, then GMT is translated to -5 hours). The TIMEZONE is Set to CST and all the logicals are assigned that way. How can I change the SMTP mail to show CST. I tried different way to assign TIMEZONE to be CST. The system was configured using CST. The system comes up as TIMEZONE -0600 (GMT). I changed it by Set TIMEZONE CST which shows -0600 (CST). I don't understand why this is not set from the very beginning. After doing this I even restarted SMTP, but nothing changes (GMT) when sending out SMTP% mail. Thanks, Ramon ================================================================================ Archive-Date: Tue, 25 Apr 2000 14:10:03 -0500 Date: Tue, 25 Apr 2000 13:08:36 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000425130836.202000c2@process.com> Subject: RE: SMTP / VMS Mail "Garrido, Ramon, Mr, HQAFCEE" writes: > >When a SMTP% VMS Mail is received, the Date: displays "GMT" instead of "CST" >(even though the time is correct BUT only if sent to the same VMS node, but >if sent to MSOutlook, then GMT is translated to -5 hours). The TIMEZONE is >Set to CST and all the logicals are assigned that way. This is a known problem. For now, just define the logical MULTINET_TIMEZONE to be "CST": $ define/system/exec multinet_timezone cst This will be corrected in a future ECO kit or TCPware release. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Thu, 27 Apr 2000 04:47:29 -0500 Message-ID: <3907FB43.90CA12D@SMTP.DeltaTel.RU> Date: Thu, 27 Apr 2000 12:33:07 +0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: TCPWare 5.4-3 & SMTP agent Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hello All! What mean "xxxxx.edu; Error receiving startup banner from host xxxxx.edu" ? I have seen very frequently this string. Entry Jobname Username Blocks Status ----- ------- -------- ------ ------ 105 SMTP-REQUEUE SYSTEM 4 Holding until 27-APR-2000 12:32:26.66 Submitted 27-APR-2000 12:22:26.66 /FORM=DEFAULT /PARAM=("xxxxx.edu; Error receiving startup banner from host xxxxx.edu") -- Regards. +.....................pure personal opinion..........................+ Free & commercial software for ISP -> HTTP://WWW.RadiusVMS.COM Cel:+7 (901) 971-3222, Fax:+7 (812) 115-1035 +............ Frying only on VMS, flying only by Su-27 .............+ ================================================================================ Archive-Date: Thu, 27 Apr 2000 09:11:05 -0500 Date: Thu, 27 Apr 2000 8:09:48 -0500 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <000427080948.202000ba@process.com> Subject: RE: TCPWare 5.4-3 & SMTP agent "Ruslan R. Laishev" writes: > >Hello All! > What mean "xxxxx.edu; Error receiving startup banner from host >xxxxx.edu" ? I have seen very frequently this string. > It means the SMTP agent connected to the remote system, but never received the greeting from it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Thu, 27 Apr 2000 10:00:03 -0500 Message-ID: From: "Clark, Steve" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: NFS connection limit Date: Thu, 27 Apr 2000 08:58:38 -0500 MIME-Version: 1.0 Content-Type: text/plain We have created a NFS share and have used the OpenVMS ACL's to limit the access to the NFS share to a specific group of people. System is running OpenVMS v7.2-1 (AXP) TCPware v5.3-2 Is there a way using that group to limit the number of active connections to the NFS share? (example: group has 15 people but the active limit needs to be 3 at any given time) Any help would be greatly appreciated. Thanks in advance. Steve Clark sclark@cessna.textron.com (316)517-7111 ================================================================================ Archive-Date: Thu, 27 Apr 2000 10:35:56 -0500 Message-ID: <39084FF5.E8D2B17F@PROCESS.COM> Date: Thu, 27 Apr 2000 10:34:29 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: NFS connection limit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > We have created a NFS share and have used the OpenVMS ACL's to limit the > access to the NFS share to a specific group of people. System is running > OpenVMS v7.2-1 (AXP) TCPware v5.3-2 > > Is there a way using that group to limit the number of active connections to > the NFS share? (example: group has 15 people but the active limit needs to > be 3 at any given time) > There is no way to limit the number of NFS connections and the protocol doesn't really lend itself to doing such. The NFS client just sends individual commands, like read data x-y in file z, or write data x-y to file z, there are no commands like open file, or close file, so the server never really knows who is 'accessing' the file at any point in time. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Thu, 27 Apr 2000 15:50:40 -0500 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: TCPWare 5.4-3 & SMTP agent Message-ID: Date: Thu, 27 Apr 2000 23:18:30 +0400 To: Info-TCPware@PROCESS.COM Hunter Goatley wrote in message <000427080948.202000ba@process.com>... >"Ruslan R. Laishev" writes: >> >>Hello All! >> What mean "xxxxx.edu; Error receiving startup banner from host >>xxxxx.edu" ? I have seen very frequently this string. >> >It means the SMTP agent connected to the remote system, but never >received the greeting from it. Thanks. > >Hunter >------ >Hunter Goatley, Process Software, http://www.process.com/ > http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 28 Apr 2000 17:08:52 -0500 Date: Fri, 28 Apr 2000 17:07:10 -0500 (EST) From: bryant@PROCESS.COM Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P051 To: TCPware-Announce@PROCESS.COM Message-ID: <01JORZ5BVH6Q003LON@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P051 Description: Logical name usage now works without an appended colon. Release date: 28-APR-2000 Ranking: 3 Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p051.zip To search the TCPware ECO database, please visit the following URL: http://www.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 5.1) for TCPware version 5.4-3 28-Apr-2000 Copyright (c) 2000, by Process Software Corporation This VMSinstallable saveset provides a new versions of FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made: FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) FTP_LISTENER.EXE - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) - A possible denial of service attack has been corrected. (DE 5347) To control how much time can elapse before the connection is killed if it is not successfully authorized as an FTP user define TCPWARE_FTP_IDLE_TIMEOUT. The format for this logical is the delta time (dddd hh:mm:ss.hh) that can elapse between when the connection is established and when it must be successfully logged in. The default value for this is 10 minutes. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) - A data corruption problem has been corrected. (DE 5298) - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) - Allow a logical to be used for CD without a terminating colon (DE 5755) After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Fri, 28 Apr 2000 17:32:16 -0500 From: goathunter@PROCESS.COM (Hunter Goatley) Reply-To: Info-TCPware@process.com Subject: Re: SMTP relay Date: Fri, 28 Apr 2000 20:27:03 GMT Message-ID: <3909f3e4.3360181@news.wku.edu> To: Info-TCPware@PROCESS.COM On Fri, 28 Apr 2000 10:33:32 -0700, "drod" wrote: >Hi all, > >Platform: Alpha 2100 >System: Open-VMS V6.2 > >TCPWare for OpenVMS V5.2-3 > >We are setup up with the "SMTP RELAY" = NONE (default) >Yet we can send email with a bogus login and password using our mail server >shown above. >When a test message is sent: >The recieved message's header shows: Recieved: from: our.org >(mail.our.org[our IP])... >This is something we would like to get resolved and NOT alow anyone to use >our mail server to send out mail. Upgrade to TCPware V5.4-3. The SMTP component in earlier versions did not have any anti-relay features built-in. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/