Archive-Date: Sun, 01 Dec 1996 00:01:39 CST Sender: owner-mx-list@wku.edu Date: Sun, 01 Dec 1996 00:01:21 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009AC2A3.3F70FCCB.142@wku.edu> Subject: MX-LIST Administrivia: Monthly Post Posting statistics for list MX-LIST during November 1996 Total number of posts: 25 Total number of posters: 18 Total number of subscribers: 298 Last modified: 28-SEP-1995 13:33 (Updated digest info) Welcome to MX-List@LISTS.WKU.EDU, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. MX-List postings are also available in a daily digest format. To subscribe to the digest, send the following command in the body of a mail message to MXserver@LISTS.WKU.EDU: SUBSCRIBE MX-List-Digest "Your real name here" The MX-List archives are maintained at ARCHIVES@LISTS.WKU.EDU. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@LISTS.WKU.EDU, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. MX itself is available via anonymous ftp from ftp.spc.edu in [.MX.MX041]. You can also get it via e-mail by sending the commands SEND MX and SEND FILESERV_TOOLS on separate lines in the body of a mail message to FILESERV@LISTS.WKU.EDU. To remove yourself from the mailing list, send the following command to MXserver@LISTS.WKU.EDU: SIGNOFF MX-List MXserver supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List DIGEST - to switch to digest mode SET MX-List NODIGEST - to switch to non-digest mode SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, Sr. OpenVMS Systems Programmer goathunter@MadGoat.com Process Software P.O. Box 51745 Bowling Green, KY 42102-6745 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Thu, 05 Dec 1996 09:01:23 CST Sender: owner-mx-list@wku.edu Date: Thu, 05 Dec 1996 14:46:16 BST From: John Powers Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: john.powers@blackwell.co.uk Message-ID: <009AC643.88331A80.2@blackwell.co.uk> Subject: SMTP server process keeps dying. We are having a problem with our SMTP server processes repeatedly dying. I have switched on debugging and found some snippets of interest. Here is the process log.. > 4-DEC-1996 15:20:35.45: MX SMTP Server (pid 2020403A) starting > 4-DEC-1996 17:01:44.65: MX SMTP Server (pid 2020403A) exiting, status = 10248074 Now, having a look at this status, I discovered.. > $ say f$message(%X10248074) > %STR-F-STRTOOLON, string is too long (greater than 65535) and this seems to tie in suspiciously well with the log of the last message processed.. > STM[3]: Send "220 guvnor.blackwell.co.uk MX V4.2 VAX SMTP server ready at Wed, 04 Dec 1996 17:01:00 BST" > STM[3]: Receive "HELO onecom.com" > STM[3]: Send "250 Hello, onecom.com" > STM[3]: Receive "MAIL From:" > STM[3]: Send "250 MAIL command accepted." > STM[3]: Receive "RCPT To:" > STM[3]: Send "250 Recipient okay (at least in form)" > STM[3]: Receive "DATA" > STM[3]: Send "354 Start mail input; end with ." > STM[3]: Receive "Received: from [208.4.223.225] by onecom.com" > STM[3]: Receive " (SMTPD32-3.02) id AAA996301C6; Thu, 28 Nov 1996 13:32:09 -0500" > STM[3]: Receive "Comments: Authenticated sender is " > STM[3]: Receive "From: chaspub@onecom.com" > STM[3]: Receive "To: CHASPUB@ONECOM.COM" > STM[3]: Receive "Date: Thu, 28 Nov 1996 13:00:49 +0000" > STM[3]: Receive "MIME-Version: 1.0" > STM[3]: Receive "Content-type: text/plain; charset=US-ASCII" > STM[3]: Receive "Content-transfer-encoding: 7BIT" > STM[3]: Receive "Subject: AMAZING$$$$$" > STM[3]: Receive "BCC: hvacreng@aol.com," > STM[3]: Receive " hvacrick@aol.com," > STM[3]: Receive " hvacsales@aol.com," > STM[3]: Receive " hvacsystem@aol.com," > STM[3]: Receive " hvactech@delphi.com," > STM[3]: Receive " hvaessen@wirehub.nl," > > [ .. over 3000 lines deleted here ..] > > STM[3]: Receive " i3urton@aol.com," > STM[3]: Receive " i3v1a@aol.com," and that's it. It never finishes processing this message. It looks to me as if MX is trying to glue all the BCC recipients in to one string and is hitting this limit. I am not familiar with the RFC specification, so I don't know if 65535 is a limit defined by the mail system, and this message is not adhering to the rfc standard, or it is an additional limit imposed by the limitations of VMS. In either case, crashing the server seems a drastic course of action. The nicest solution to this would be to bounce it back to the sender and tell them to adhere to the mail standards (if 65535 is a defined limit) - as given such a huge number of recipients, the message is almost certainly a worthless spam. If such long lists are allowed, then a long term solution will be needed, such as truncating the BCC list to a workable size. Looking at the help for the error message STRTOOLON message we get.. User Action: Do not specify string lengths greater than 65,535. Check that a concatenation operation will not attempt to create a string longer than 65,535. Unfortunately, my programming skills in BLISS have not yet been honed to the required standard, and I know Hunter is extremely busy and already has an enormous wish list of alterations. Consequently, I am looking for a workaround to stop these from breaking the server. Does anybody know of a way of intercepting these useless messages and trashing them before they ever get to the server? Or has anybody any other ideas on what to do? Many thanks for your help. John ----------------------------------------------------------------------------- John Powers - Blackwell's, Oxford - - "fee issuing thirty mails" (anag.) john.powers@blackwell.co.uk (Internet) Blackwells Booksellers - Visit our PSI%234284400179::TJGP (PSImail) home page: http://www.blackwell.co.uk/ ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 05 Dec 1996 10:09:31 CST Sender: owner-mx-list@wku.edu Date: Thu, 05 Dec 1996 09:09:19 -0700 (MST) From: "Michael L. Hitch" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC614.75EF3EA0.6@msu.oscs.montana.edu> Subject: RE: SMTP server process keeps dying. John Powers writes: > We are having a problem with our SMTP server processes repeatedly > dying. I have switched on debugging and found some snippets of > interest. ... > and that's it. It never finishes processing this message. It looks > to me as if MX is trying to glue all the BCC recipients in to one > string and is hitting this limit. I am not familiar with the RFC > specification, so I don't know if 65535 is a limit defined by the > mail system, and this message is not adhering to the rfc standard, > or it is an additional limit imposed by the limitations of VMS. In > either case, crashing the server seems a drastic course of action. It's crashing because of a limit in the OpenVMS string routines. > Unfortunately, my programming skills in BLISS have not yet been > honed to the required standard, and I know Hunter is extremely busy > and already has an enormous wish list of alterations. My BLISS programming skills are somewhat limited, but I have done some work with CMUIP and the old NEWSRDR. I got hit by the same type of message on a couple of our systems in the last few days. On the busy system, I run a Polycenter Scheduler job to check the various MX processes and automatically restart them. That job was originally only running every 4 hours - which meant that the system could be rejecting incoming mail for up to 4 hours. I have now been running that job every 15 minutes until the mailer sending the offending message finally gives up. This has finally pushed me to start looking at some kind of fix for this problem. I got the MX sources yesterday and think I know the place in the code that is crashing. I just installed BLISS and will shortly be attempting to rebuild MX. Once that's successful, I am going to try to fix the SMTP Server so that it doesn't crash. > Consequently, I am looking for a workaround to stop these from > breaking the server. Does anybody know of a way of intercepting > these useless messages and trashing them before they ever get to the > server? Or has anybody any other ideas on what to do? The only suggestion I've seen is to try to configure your TCP/IP to not allow connections from the offending address or network. I think this was accomplished by adding a dummy route for that IP network to an invalid gateway. This should cause the remote system to fail to make a connection to the SMTP server process. I attempted to do that for the message that's been giving me grief, but I was not able to figure out the IP address of the system sending the message. [The system was mis-identifying itself, so the name on the HELO record was invalid.] Michael --- Michael L. Hitch mhitch@msu.oscs.montana.edu Computer Consultant, Information Technology Center Montana State University, Bozeman, MT USA ================================================================================ Archive-Date: Thu, 05 Dec 1996 10:55:24 CST Sender: owner-mx-list@wku.edu Date: Thu, 05 Dec 1996 10:55:19 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC623.44A5CE31.7@ALPHA.WKU.EDU> Subject: RE: SMTP server process keeps dying. "Michael L. Hitch" writes: > > This has finally pushed me to start looking at some kind of fix for this >problem. I got the MX sources yesterday and think I know the place in the >code that is crashing. I just installed BLISS and will shortly be attempting >to rebuild MX. Once that's successful, I am going to try to fix the SMTP >Server so that it doesn't crash. > A quick-and-dirty fix was posted here just a couple of days ago. For those of you with the BLISS compiler (which should be everybody now!), you can implmeent this fix until MX V4.3 is released. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html -------------------------------------------------------------------------------- From: neill@yrl.co.uk (Neill Clift) Newsgroups: vmsnet.mail.mx Subject: MX server crashing. A hacky solution. Date: 27 Nov 96 16:59:05 +0000 Hello all, We are currently being plagued by a complete twat in the uk who sends mail messages to huge numbers of users advertising Nokia phones. This causes our MX SMTP server process to dies with an str$ error of string greater that 65535 bytes! this was causing us a real problem so I got the process under debug and put in a bit of defensive code. There is probably a better way of doing this to cover all the cases but this did get is past this message to receive the important stuff. I really hate it when you have to mess about because of somebody elses complete stupidity (the Nokia man). Anyway just in case its any use here is my quick hack to get past it: ************ File MX_SRCROOT:[MX.SMTP]SMTP_SERVER.B32;4 1250 if (curhdr[dsc$w_length] + str2[dsc$w_length] lss 32768) then 1251 begin 1252 STR$APPEND (CURHDR, %ASCID' '); 1253 STR$APPEND (CURHDR, STR2); 1254 end; 1255 END ****** File MX_SRCROOT:[MX.SMTP]SMTP_SERVER.B32;1 1250 STR$APPEND (CURHDR, %ASCID' '); 1251 STR$APPEND (CURHDR, STR2); 1252 END ************ Neill. ================================================================================ Archive-Date: Thu, 05 Dec 1996 12:35:32 CST Sender: owner-mx-list@wku.edu Date: Thu, 05 Dec 1996 11:35:01 MST From: cdooling@west.cscwc.pima.edu Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009AC628.D098B020.25@west.cscwc.pima.edu> Subject: MX problems -- smtp and uucp dying DATE SENT: 5-DEC-1996 11:30:31 We're running MX 4.2 on a VMS 5.5-2 system and Multinet 3.4. The MX had been running fine until last week. Now the smtp and uucp die every few minutes. MX-Watchdog is running, but apparently not often enough to restart MX processes. When it does, it runs out of global pages. I've increased the global pages and sections, but it doesn't appear to make any difference. This is a copy of the error message users receive when trying to send mail: (Note: rebooting the system works, but I can't do that every five minutes, which is all the longer MX process stay alive) > >I typed reply to an E-Mail message and got the following error message: >%MAIL-E-ERRACTRNS, error activating transport MX >%LIB-E-ACTIMAGE, error activating image $2$DIA0:[MX.][EXE]MX_MAILSHRP.EXE;7 >-SYSTEM-F-PROTINSTALL, protected images must be installed Any help? Thanks................. ------------------------------------------------------------------------------ Cindy Dooling WEST::CDOOLING PimaCommunityCollege cdooling@west.pima.edu 2202 W. Anklam voice: 520 884-6970 Tucson, Arizona 85709-0010 fax: 520 884-6033 http://west.pima.edu/~cdooling Nothing but Net *** No FEAR, just a healthy respect *** ------------------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 05 Dec 1996 14:04:58 CST Sender: owner-mx-list@wku.edu Message-ID: <199612051959.OAA11279@redstone.interpath.net> From: "Rich Hill" To: VMSnet@DRYCAS.CLUB.CC.CMU.EDU, MX-List@MadGoat.com Date: Thu, 5 Dec 1996 14:57:14 -0400 Subject: RMAIL command limitations? Reply-To: MX-List@MadGoat.com Content-Type: text What are the limitations within UUXQT and MX_RMAIL in regards to the size of the RMAIL command. Is there a maximum number of characters and/or addresses that can be processed? I have a connecting site that is using UUPC and is sending large RMAIL commands in the X file causing UUXQT to holler about a '* Bad X file...'. The 'large RMAIL command' is typically 400+ characters in length with 20+ addresses. We are running DECUS UUCP V2.0 and MX V4.2 on OpenVMS VAX 5.5-2. TIA Rich Hill -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Hill S I M Rich.Hill@sim.org Systems Engineer b y EasyLink: 62923838 SIM USA, Inc. P r a y e r Phone: 1-704-587-1462 Charlotte, NC since 1893 FAX: 1-704-587-1518 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [SC] Smiley captioned for the humor impaired. ================================================================================ Archive-Date: Thu, 05 Dec 1996 15:25:17 CST Sender: owner-mx-list@wku.edu Date: Thu, 05 Dec 1996 15:53:02 EST5EDT4,M4.1.0,M10.5.0 From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC64C.DC132F60.56@fred.bridgew.edu> Subject: RE: Mail Headers On rare occasions I see lines beginning with "X-envelope-To:" and even "Old-X-envelope-To:" They cause no problem, but I can't find any reference to x-envelopes in the RFCs, though there are plenty of references to "envelopes". Does anyone know what an "X-Envelope" is? How or when are they created? Or by what mail agents? In some cases the address following "X-envelope-To:" is unknown to the recipient of the message, who wonders where the address came from and whether she is doing something wrong. Any information would be appreciated. Thanks. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 05 Dec 1996 17:52:58 CST Sender: owner-mx-list@wku.edu From: dwing@tgv.com (Dan Wing) Subject: RE: SMTP server process keeps dying. Date: 5 Dec 1996 23:44:33 GMT Message-ID: <587mp1$nec@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AC614.75EF3EA0.6@msu.oscs.montana.edu>, "Michael L. Hitch" writes: > I attempted to do that for the message that's been giving me grief, but I >was not able to figure out the IP address of the system sending the message. >[The system was mis-identifying itself, so the name on the HELO record was >invalid.] If you have MultiNet you can watch with: $ MULTINET TCPDUMP/HEX/SNAP=1514 PORT 25 and then setup your black-hole route on your VMS machine (which can cause a denial of service attack if the remote mailer is really aggresive at sending SYNs) or block the network at your router. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Fri, 06 Dec 1996 03:35:43 CST Sender: owner-mx-list@wku.edu Date: Fri, 06 Dec 1996 04:35:33 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC6B7.61AC3BD4.30@bdsnet.com> Subject: RE: SMTP server process keeps dying. >In article <009AC614.75EF3EA0.6@msu.oscs.montana.edu>, "Michael L. Hitch" writes: >> I attempted to do that for the message that's been giving me grief, but I >>was not able to figure out the IP address of the system sending the message. >>[The system was mis-identifying itself, so the name on the HELO record was >>invalid.] > >If you have MultiNet you can watch with: > > $ MULTINET TCPDUMP/HEX/SNAP=1514 PORT 25 Yes, but on any reasonably busy system isn't this going to produce a staggering amount of log info to wade through if you logged it to a file? Or are you saying that he should run that command on a terminal and when the MX server dies, the last output on the screen would be from the offending site? I would think then that the desired data would be scrolled off of the screen by logging of subsequent attempts by "good" mailers to connect to the downed smtp server... ?? When we were getting hit by this it could sometimes be several hours or even a day or two before another offending message would appear. The MX debug logging was how we figured out the origin. The last entries in the log told the tale, and generated a lot less data then TCPDUMP would. The MX_WATCHDOG program in the MX [.CONTRIB] directory does a pretty good job of nailing things back up when they fall down. We modified it to work better in a cluster environment, and to mail the sysadmin if/when it detects missing MX process(es). >and then setup your black-hole route on your VMS machine (which can >cause a denial of service attack if the remote mailer is really >aggresive at sending SYNs) or block the network at your router. That's not good... :-) Once we identified the offending sites, we used this method to keep them away. The ref counts in MU/SHOW/ROUTE went pretty high for one of them, indicating that site was pretty persistent... we never noticed any adverse effects, though. A mailer would have to be really running amok to cause a denial of service wouldn't it? -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Fri, 06 Dec 1996 06:41:14 CST Sender: owner-mx-list@wku.edu Date: Fri, 06 Dec 1996 06:41:09 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC6C8.ED4DB0B2.15@ALPHA.WKU.EDU> Subject: RE: Mail Headers Scott McNeilly writes: > >On rare occasions I see lines beginning with "X-envelope-To:" and even >"Old-X-envelope-To:" They cause no problem, but I can't find any >reference to x-envelopes in the RFCs, though there are plenty of >references to "envelopes". Does anyone know what an "X-Envelope" is? >How or when are they created? Or by what mail agents? In some cases >the address following "X-envelope-To:" is unknown to the recipient of >the message, who wonders where the address came from and whether she is >doing something wrong. All "X-" headers are non-standard headers added by a mailer. (Prefixing a non-standard header with "X-" is the standard way to add a non-standard header. ;-) ) I don't know which one adds that, or what it means, except that I would imagine that the mailer is trying to report the envelope RCPT TO: address(es). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 06 Dec 1996 15:36:20 CST Sender: owner-mx-list@wku.edu From: dwing@tgv.com (Dan Wing) Subject: RE: SMTP server process keeps dying. Date: 6 Dec 1996 21:34:49 GMT Message-ID: <58a3hp$eut@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AC6B7.61AC3BD4.30@bdsnet.com>, Jim Bender writes: > >>In article <009AC614.75EF3EA0.6@msu.oscs.montana.edu>, "Michael L. Hitch" writes: >>> I attempted to do that for the message that's been giving me grief, but I >>>was not able to figure out the IP address of the system sending the message. >>>[The system was mis-identifying itself, so the name on the HELO record was >>>invalid.] >> >>If you have MultiNet you can watch with: >> >> $ MULTINET TCPDUMP/HEX/SNAP=1514 PORT 25 > >Yes, but on any reasonably busy system isn't this going to produce a >staggering amount of log info to wade through if you logged it to >a file? Or are you saying that he should run that command on a terminal and >when the MX server dies, the last output on the screen would be >from the offending site? I would think then that the desired data >would be scrolled off of the screen by logging of subsequent attempts >by "good" mailers to connect to the downed smtp server... ?? So write it to a file. On tgv.com the following creates only a few thousand blocks an hour, and we process about 5000 messages a day (averages to a few hundred messages an hour): $ MULTINET TCPDUMP/BINARY_OUTPUT=file/SNAP=1514 PORT 25 Then use the following command to analyze it: $ MULTINET TCPDUMP/AFTER=time/READ_BINARY=file where "time" is about a minute before the SMTP Server dies. >When we were getting hit by this it could sometimes be several hours >or even a day or two before another offending message would appear. >The MX debug logging was how we figured out the origin. That doesn't always work -- it depends on what is causing the problem. If it is a large CC list you'll catch it with MX debugging. But if it is something that happens before the application can start logging (say, for example, a SYN attack) then application logging won't help. The advantage of TCPDUMP is that it always works and always shows you what's happening on the wire -- you don't have to rely on debugging within an application. I run MX here (for our info-multinet mailing list) and I use both MX debugging and TCPDUMP to diagnose various problems. They both have their place. >The last >entries in the log told the tale, and generated a lot less data then >TCPDUMP would. > >The MX_WATCHDOG program in the MX [.CONTRIB] directory does a pretty >good job of nailing things back up when they fall down. We modified >it to work better in a cluster environment, and to mail the sysadmin >if/when it detects missing MX process(es). > >>and then setup your black-hole route on your VMS machine (which can >>cause a denial of service attack if the remote mailer is really >>aggresive at sending SYNs) or block the network at your router. > >That's not good... :-) Once we identified the offending sites, >we used this method to keep them away. The ref counts in >MU/SHOW/ROUTE went pretty high for one of them, indicating that >site was pretty persistent... we never noticed any adverse >effects, though. A mailer would have to be really running amok >to cause a denial of service wouldn't it? With MultiNet, 5 un-acked SYNs to any TCP port will cause subsequent SYNs to be dropped on the floor. UCX, TCPware, and Pathway also have similar limits, but I don't know what they are. MultiNet's backlog can be increased -- see a post of mine in the info-multinet archives (searchable on www.tgv.cisco.com) for details. Yes, a remote mailer (er, rather, the TCP implementation on the remote mailer) would have to be abnormally aggressive for this to cause a problem, or the remote mailer could be trying to spam you with two messages and two threads, doubling how many TCP connections it is trying to make with your system. Again, I'm not saying a black-hole route is bad and you should always block it at your router, just be aware that there is a possibility of increasing your exposure to a denial of service through that method. I have one black-hole route setup at our site right now to block a spamming site, for example; in about a month I'll remove it and it is easier than mucking with the router configuration (and I can give them a nice "550 rejected" message when they connect instead of silently dropping their packets). -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Fri, 06 Dec 1996 15:54:25 CST Sender: owner-mx-list@wku.edu From: dwing@tgv.com (Dan Wing) Subject: Re: MX problems -- smtp and uucp dying Date: 6 Dec 1996 21:23:35 GMT Message-ID: <58a2sn$eut@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AC628.D098B020.25@west.cscwc.pima.edu>, cdooling@west.cscwc.pima.edu writes: >DATE SENT: 5-DEC-1996 11:30:31 >We're running MX 4.2 on a VMS 5.5-2 system and Multinet 3.4. The MX had >been running fine until last week. Now the smtp and uucp die every few >minutes. MX-Watchdog is running, but apparently not often enough to >restart MX processes. When it does, it runs out of global pages. I've >increased the global pages and sections, but it doesn't appear to make >any difference. This is a copy of the error message users receive >when trying to send mail: (Note: rebooting the system works, but I >can't do that every five minutes, which is all the longer MX process >stay alive) > >> >>I typed reply to an E-Mail message and got the following error message: >>%MAIL-E-ERRACTRNS, error activating transport MX >>%LIB-E-ACTIMAGE, error activating image $2$DIA0:[MX.][EXE]MX_MAILSHRP.EXE;7 >>-SYSTEM-F-PROTINSTALL, protected images must be installed > >Any help? Thanks................. You rebooted after increasing global sections and pages, right ? Any errors when you startup MX (@sys$startup:mx_startup) ? -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Sat, 07 Dec 1996 01:18:20 CST Sender: owner-mx-list@wku.edu Date: Sat, 07 Dec 1996 01:18:13 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: MadGoat-Announce@MadGoat.com Message-ID: <009AC764.FAD5DEF7.1@ALPHA.WKU.EDU> Subject: MX V4.2 PATCH FILES AVAILABLE!!!! The "spam bug" appears to be showing up at more and more sites on a daily basis, so I've made the following images available for MX V4.2 sites. MX V4.3 is not yet ready, and I've not had time to make real patch kits, so I'm simply offering new .EXE files. - SMTP_SERVER.EXE SMTP_SERVER.ALPHA_EXE This new image fixes the "spam bug" in MX SMTP Server (where the server dies when an incoming message has an RFC822 header longer than 64K bytes). If such a header is present, MX SMTP Server will now add an "X-" header that indicates that fact. It will no longer die with a "STRTOOLONG" error. - MX_LOCAL.EXE MX_LOCAL.ALPHA_EXE This new image removes the 255-character line truncation on messages delivered via MX Local. While it is true that callable MAIL limits records to 255 characters, it actually imposes no such limit under certain conditions. In anticipation of that limit, MX was ensuring that message lines were not longer than 255 bytes. This restriction has now been lifted. Note that VMS Mail itself will still truncate lines to 510 characters on a READ (and on EXTRACT under VMS V7.0), so you may or may not be able to see really long lines. But they will be present, including in the MAIL$xxxx.MAI file. This image also adds RFC822 From: comments as a personal name to the VMS Mail From: line. For example: From: Hunter Goatley . Again, the patches are available using: ftp://ftp.wku.edu/mx/mx042/patch/smtp_server.alpha_exe ftp://ftp.wku.edu/mx/mx042/patch/smtp_server.exe ftp://ftp.wku.edu/mx/mx042/patch/mx_local.alpha_exe ftp://ftp.wku.edu/mx/mx042/patch/mx_local.exe http://www.wku.edu/www/madgoat/mx.html Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sat, 07 Dec 1996 14:44:21 CST Sender: owner-mx-list@wku.edu Date: Sat, 07 Dec 1996 20:43:18 +0100 From: Csg0070@Queens-Belfast.AC.UK Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU CC: M.Harron@Queens-Belfast.AC.UK, caoimhin@smo.uhi.ac.uk Message-ID: <009AC807.BDA25620.4@v2.qub.ac.uk> Subject: Why QUB refuses messages with 8-bit characters Although this is nothing directly to do with MX, some list-owners on MX-List have mentioned that messages sent to Queen's University are bounced by the QUB mail-hub nzambi if they contain an 8-bit character, even if they have a MIME header containing the keyword "8BITMIME". Here's an explanation of that behaviour provided by a member of QUB Computer Centre, and forwarded here with his consent. I'm just posting this for information, and, while I'm interested in comments, I don't want a war to start over it! > ... When a machine > capable of using RFC-1651 connects to another machine for the purpose of > delivering a message, a protocol exchange takes place to determine if the > receiving machine also implements the extensions. If it does then a further > exchange indicates which particular extensions (e.g. RFC-1652) are available. > RFC-1652 specifically states that:- > 'If a server SMTP does not support the 8-bit MIME transport extension > (either by not responding with code 250 to the EHLO command, or by not > including the EHLO keyword value 8BITMIME in its response), then the > client SMTP must not, under any circumstances, attempt to transfer a > content which contains characters outside the US-ASCII octet range > (hex 00-7F).' > It goes on to say that the client has two options which are to treat this as a > permanent error or to implement a gateway transformation to convert the message > into valid 7 bit MIME. Unhappily, the machines to which you refer above are not > complying with the standards as they are transmitting octets with the high-order > bit set when no appropriate protocol exchange has taken place. Basically, he's saying that the sender should check whether QUB supports 8BITMIME, and on finding that it doesn't, should take some other action (such as recoding the message in QP). On the question of adding support for 8BITMIME to nzambi - which at present supports RFC-821 - he says "I do not believe that a fully RFC-1652 compliant system has ever been written." Does anyone know of such a thing? At its most rudimentary, it seems to me it might allow through without alteration messages containing "8BITMIME" and "ISO-8859-1" in their MIME headers, while continuing to bounce messages containing 8-bit characters otherwise. Ciara/n O/ Duibhi/n. ================================================================================ Archive-Date: Sun, 08 Dec 1996 02:23:05 CST Sender: owner-mx-list@wku.edu Date: Sun, 08 Dec 1996 10:16:20 EST From: sysnaj@DALE.hadassah.org.il Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009AC879.52113B20.12@dale.hadassah.org.il> Subject: Patches to MX 4.2 >Subj: MX V4.2 PATCH FILES AVAILABLE!!!! > > >You can find these new images only on FTP.WKU.EDU in [MX.MX042.PATCH]. >The VAX images were linked under VAX/VMS V5.4, and the Alpha images >were linked under OpenVMS AXP V1.5. I *think* these images will also >work with MX V4.0 and MX V4.1, but if you're still running those, you >really should upgrade to MX V4.2 anyway. > Hello. Is there an available image for Alpha VMS (6.2) ? Thank you Najman Kahana Najman@hadassah.org.il +--------+------------------+------------------------------+---------------+ ! NAJMAN KAHANA ! Hadassah University Hospital ! thanks, ! ! Najman@hadassah.org.il ! Jerusalem, Israel ! we have our ! ! ! (visit our capital soon) ! own viruses ! +--------+------------------+------------------------------+---------------+ ================================================================================ Archive-Date: Sun, 08 Dec 1996 03:52:19 CST Sender: owner-mx-list@wku.edu Subject: Re: Why QUB refuses messages with 8-bit characters Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 08 Dec 1996 06:15:37 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: MX-List@WKUVX1.WKU.EDU In article <009AC807.BDA25620.4@v2.qub.ac.uk> Csg0070@Queens-Belfast.AC.UK writes: Although this is nothing directly to do with MX, some list-owners on MX-List have mentioned that messages sent to Queen's University are bounced by the QUB mail-hub nzambi if they contain an 8-bit character, even if they have a Mine are among those, because my signature contains one non-US-ASCII character. MIME header containing the keyword "8BITMIME". Uh, the MIME header is "8BIT". > 'If a server SMTP does not support the 8-bit MIME transport extension > (either by not responding with code 250 to the EHLO command, or by not > including the EHLO keyword value 8BITMIME in its response), then the > client SMTP must not, under any circumstances, attempt to transfer a > content which contains characters outside the US-ASCII octet range > (hex 00-7F).' This is a very unfortunate remnant from the fact that RFC-821 and RFC-822, which were written in 1982, defined the character set as being the codes 0-127 (decimal). I don't remember exactly how things were back then, but since ISO-8859-1 and friends came about by 1987, 8bitness can't have been totally foreign in 1982. In any case, it would have been oh so simple to make an RFC that just updated poor old 821 and 822 to allow 8bitness... But no, complicated solutions had to be crafted instead, and voilą!, we have RFC 1652, which defines the SMTP extension called 8BITMIME. Basically, he's saying that the sender should check whether QUB supports 8BITMIME, and on finding that it doesn't, should take some other action (such as recoding the message in QP). Yes, that is perfectly correct, when you follow the standards. However, many SMTP servers of today are configured in a forgiving way, simply because it means less hassle, both for the mail senders who don't have the software to create proper QP (which is a kludge in itself), or simply refuse to, and for system administrators who don't need to answer to all those question about why it doesn't work. AND let's not forget news->mail gateways that don't translate... On the question of adding support for 8BITMIME to nzambi - which at present supports RFC-821 Ahemm, it claims to support ESMTP, with the extension VRFY, SIZE and HELP, of which only SIZE is an extension to RFC 821... - he says "I do not believe that a fully RFC-1652 compliant system has ever been written." He hasn't seen the Unix weenies' old budy sendmail, then... At its most rudimentary, it seems to me it might allow through without alteration messages containing "8BITMIME" and "ISO-8859-1" in their MIME headers, while continuing to bounce messages containing 8-bit characters otherwise. Ahemm, 8BITMIME is not part of the headers. It's part of the conversation the SMTP sender has with the SMTP server. Now, nzambi is using an SMTP server called pp. Could it simply be that the software is built with the anti-8bit restriction, and that it's not possible to configured it to let 8bit characters pass by? Such software does exist, I've heard. Sorry about the rant, but I've been sick and tired for a long time, about the discussion on following a bunch of pretty crappy standards, when the solution is so darn simple. (BTW, I've just changed my signature so it won't contain any 8bitness, just for the hell of it...) -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://www.lp.se/~levitte for my public key. bastard@bofh.se ================================================================================ Archive-Date: Sun, 08 Dec 1996 04:53:34 CST Sender: owner-mx-list@wku.edu Date: Sun, 08 Dec 1996 02:52:55 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009AC83B.60396152.1@sacto.mp.usbr.gov> Subject: Re: Why QUB refuses messages with 8-bit characters > From: MX%"MX-List@MadGoat.com" 8-DEC-1996 02:24:12.40 > Subj: Re: Why QUB refuses messages with 8-bit characters > In article <009AC807.BDA25620.4@v2.qub.ac.uk> Csg0070@Queens-Belfast.AC.UK writes: > > Although this is nothing directly to do with MX, some list-owners on MX-List > have mentioned that messages sent to Queen's University are bounced by the > QUB mail-hub nzambi if they contain an 8-bit character, even if they have a > > Mine are among those, because my signature contains one non-US-ASCII character. > > MIME header containing the keyword "8BITMIME". > > Uh, the MIME header is "8BIT". > > > 'If a server SMTP does not support the 8-bit MIME transport extension > > (either by not responding with code 250 to the EHLO command, or by not > > including the EHLO keyword value 8BITMIME in its response), then the > > client SMTP must not, under any circumstances, attempt to transfer a > > content which contains characters outside the US-ASCII octet range > > (hex 00-7F).' > > This is a very unfortunate remnant from the fact that RFC-821 and RFC-822, > which were written in 1982, defined the character set as being the codes > 0-127 (decimal). I don't remember exactly how things were back then, but > since ISO-8859-1 and friends came about by 1987, 8bitness can't have been > totally foreign in 1982. In any case, it would have been oh so simple to > make an RFC that just updated poor old 821 and 822 to allow 8bitness... > But no, complicated solutions had to be crafted instead, and voilą!, we > have RFC 1652, which defines the SMTP extension called 8BITMIME. > I think that a good deal of the blame falls on the fact that many of the ARPANET machines of that era were of the PDP-10 family. The 10 was a 36 bit machine, and to store ASCII data, the most efficient encoding was to use five 7 bit bytes, left justified in a word. Data could have been encoded as four 8 bit or 9 bit bytes on the word, in fact we used the former mechanism when talking to the IMP - the data was packed as four 8 bit bytes, right justified as I recall. But encoding the data like that for normal use in the system would have been very wasteful, and memory was very expensive in those days. It's the only BAD standard that I can think of that the PDP-10 may have spawned, if indeed that was it's origin. -HWM ================================================================================ Archive-Date: Sun, 08 Dec 1996 09:55:01 CST Sender: owner-mx-list@wku.edu Date: Sun, 08 Dec 1996 09:54:56 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC876.5479E932.3@ALPHA.WKU.EDU> Subject: RE: Patches to MX 4.2 sysnaj@DALE.hadassah.org.il writes: > >>Subj: MX V4.2 PATCH FILES AVAILABLE!!!! >> >> >>You can find these new images only on FTP.WKU.EDU in [MX.MX042.PATCH]. >>The VAX images were linked under VAX/VMS V5.4, and the Alpha images >>were linked under OpenVMS AXP V1.5. I *think* these images will also >>work with MX V4.0 and MX V4.1, but if you're still running those, you >>really should upgrade to MX V4.2 anyway. >> > >Hello. > Is there an available image for Alpha VMS (6.2) ? > I guess I should have been more explicit. Sorry about that. The images will work on all versions of VMS equal to or higher than V5.4 (VAX) and V1.5 (Alpha). So the .ALPHA_EXE will work on all versions on OpenVMS Alpha. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 09 Dec 1996 07:02:28 CST Sender: owner-mx-list@wku.edu Date: Mon, 9 Dec 1996 13:57:42 +0100 (MET) From: PASZTOR Miklos Reply-To: MX-List@MadGoat.com To: Csg0070@Queens-Belfast.AC.UK, Richard Levitte - VMS Whacker CC: mx-list@madgoat.com Subject: Re: Why QUB refuses messages with 8-bit characters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 8 Dec 1996, Richard Levitte - VMS Whacker wrote: [...] |Now, nzambi is using an SMTP server called pp. Could it simply be that the |software is built with the anti-8bit restriction, and that it's not possible |to configured it to let 8bit characters pass by? Such software does exist, |I've heard. [...] Yep. We use PP here too at Helka.iif.hu, and our configuration allows 8 bit messages to get in. It was not the default though. Regards, Miklos ==================================================================== Pa'sztor Miklo's | E-mail: pasztor@sztaki.hu MTA SZTAKI/ASZI Budapest 1132 V. Hugo u. 18-22 | Tel: (36)-(1)-149-75-32 Institute for Computation and Automation, Hungarian Academy of Sciences ==================================================================== ================================================================================ Archive-Date: Mon, 09 Dec 1996 13:12:20 CST Sender: owner-mx-list@wku.edu Date: Mon, 09 Dec 1996 11:21:22 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009AC94B.925ADEC0.11@swdev.si.com> Subject: Re: Why QUB refuses messages with 8-bit characters Henry W. Miller (henrym@sacto.mp.usbr.gov) writes: >The 10 was a 36 bit machine, and to store ASCII data, the most efficient >encoding was to use five 7 bit bytes, left justified in a word. I typically used SIXBIT encoding, which allowed six characters per word. The Fortran compiler used SIXBIT, I believe, to keep variable names in single words. (This was an ANSI 1966 compiler.) -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 09 Dec 1996 16:13:34 CST Sender: owner-mx-list@wku.edu Date: Mon, 09 Dec 1996 22:13:10 +0100 From: Csg0070@Queens-Belfast.AC.UK Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AC9A6.A07DE3C0.3@v2.qub.ac.uk> Subject: Re: Why QUB refuses messages with 8-bit characters I've seen a couple of comments on this thread, quoting from others that I haven't seen. Remember, if you include an 8-bit character in your message (and don't recode to qp), no-one at this site will see it! Ciara/n O/ Duibhi/n. ================================================================================ Archive-Date: Tue, 10 Dec 1996 18:42:04 CST Sender: owner-mx-list@wku.edu From: dwing@tgv.com (Dan Wing) Subject: Re: Why QUB refuses messages with 8-bit characters Date: 11 Dec 1996 00:32:19 GMT Message-ID: <58kvej$f23@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AC807.BDA25620.4@v2.qub.ac.uk>, Csg0070@Queens-Belfast.AC.UK writes: >Although this is nothing directly to do with MX, some list-owners on MX-List >have mentioned that messages sent to Queen's University are bounced by the >QUB mail-hub nzambi if they contain an 8-bit character, even if they have a >MIME header containing the keyword "8BITMIME". Here's an explanation of that >behaviour provided by a member of QUB Computer Centre, and forwarded here with >his consent. I'm just posting this for information, and, while I'm interested >in comments, I don't want a war to start over it! When designing, implementing, or configuring systems, always try to use the "be conservative in what you send and be liberal in what you accept" philosophy. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Wed, 11 Dec 1996 16:10:41 CST Sender: owner-mx-list@wku.edu Date: Wed, 11 Dec 1996 16:10:21 -0600 From: eric lehto Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU Message-ID: <96Dec11.161000cst.18433@mail.digikey.com> Subject: mail attachments Anyone know if/how I can send a file as an attachment thru VMS Mail / MX 4.1 ? Some readers won't extract documents properly unless sent as attachments. I can upgrade MX if necessary. Thanks much for any suggestions. eric. -- Eric Lehto | Digi-Key Corporation | eric@digikey.com ================================================================================ Archive-Date: Wed, 11 Dec 1996 23:55:18 CST Sender: owner-mx-list@wku.edu Date: Thu, 12 Dec 1996 00:53:17 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: eric@digikey.com, hardis@garnet.nist.gov Message-ID: <009ACB4F.53A7C5C0.3@garnet.nist.gov> Subject: RE: mail attachments > Anyone know if/how I can send a file as an attachment > thru VMS Mail / MX 4.1 ? Some readers won't extract > documents properly unless sent as attachments. I can > upgrade MX if necessary. The notion of an e-mail "attachment" is a user-interface issue. MX does not provide a separate user interface to VMS Mail. Most commonly the files that are attached are documents from/for PCs. If this is the case, use a PC mail program such as Eudora or Claris EM@iler. MX will route such mail just fine, and you can use IUPOP3 (or another POP3 client program) to allow the PC users to pick up their mail from the VAX. If you really have to send a file from a VAX to another VAX, use ftp, image mode. - Jonathan ================================================================================ Archive-Date: Thu, 12 Dec 1996 08:58:14 CST Sender: owner-mx-list@wku.edu Date: Thu, 12 Dec 1996 15:55:55 +0100 (MET) From: PASZTOR Miklos Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: eric@digikey.com, hardis@garnet.nist.gov Subject: RE: mail attachments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Dec 1996, Jonathan E. Hardis wrote: [..] |If you really have to send a file from a VAX to another VAX, use ftp, image |mode. MAIL/FOREIGN works also fine. MX encodes this messages, so they are readable not just on VMS, but with any MIME complient UA. Miklo's ==================================================================== Pa'sztor Miklo's | E-mail: pasztor@sztaki.hu MTA SZTAKI/ASZI Budapest 1132 V. Hugo u. 18-22 | Tel: (36)-(1)-149-75-32 Institute for Computation and Automation, Hungarian Academy of Sciences ==================================================================== ================================================================================ Archive-Date: Thu, 12 Dec 1996 09:17:38 CST Sender: owner-mx-list@wku.edu Date: Thu, 12 Dec 1996 09:00:41 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: eric@digikey.com Message-ID: <009ACB93.69E83E20.14@swdev.si.com> Subject: RE: mail attachments Eric Lehto (eric@digikey.com) writes: >Anyone know if/how I can send a file as an attachment >thru VMS Mail / MX 4.1 ? Some readers won't extract >documents properly unless sent as attachments. I can >upgrade MX if necessary. VMS Mail (with or without MX) has no concept of attachments. The closest you can come is by using the /FOREIGN qualifier on the SEND. If MX is your transport, this will give you a BASE64-encoded document, which many user agents will interpret as an attachment. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 12 Dec 1996 11:05:02 CST Sender: owner-mx-list@wku.edu Date: Thu, 12 Dec 1996 11:04:52 CST From: Tom Chamberlain / 269GB Bartlesville / (918)661-9744 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: eric@digikey.com Message-ID: <009ACBA4.C36B3860.5@athena.ppco.com> Subject: RE: mail attachments eric lehto wrote: > Anyone know if/how I can send a file as an attachment > thru VMS Mail / MX 4.1 ? Some readers won't extract > documents properly unless sent as attachments. I can > upgrade MX if necessary. While I don't especially recommend or encourage the practice, I've had good success in sending "attachments" (to PC-based cc:Mail users, anyway) by uuencoding the file I want to "attach" and including it in the file I mail. You can "receive" attachments (provided you recognize them as such while reading your mail) by extracting the message to a file (".uue" is a good extension) and then uudecoding it. To help you recognize that the "attachment" has been uuencoded, look for a line similar to: begin 666 xxxxx The "666" is a unix-style file protection code, and "xxxxx" is the the name of the file that uudecode will create on your system. Following this "begin ..." header will be lines that (typically) begin with an uppercase "M" (a representation of the number of characters in the line), and a final line with just end on it. There's usually no need to remove mail headers or signature blocks before uudecoding the file. If you don't have uuencode/uudecode on your VAX, you can get UUCODE.ZIP from ftp.spc.edu in the [.MACRO32.SAVESETS] directory. You should be aware that a uuencoded file will be larger than its un-encoded counterpart and this may cause problems with mail systems that limit the size of messages. Also, consider that your recipient may not have the resources to properly interpret what you send. Hope this is useful. TomC ================================================================================ Tom Chamberlain Phone: (918) 661-9744 Phillips Petroleum Company FAX: (918) 661-1910 271 Geoscience Building email: twc@ppco.com Bartlesville, OK 74004 ================================================================================ Archive-Date: Mon, 16 Dec 1996 13:05:47 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 14:05:15 EST From: John Hasstedt Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACEE2.A03E28C0.19@nuclear.physics.sunysb.edu> Subject: minor bug in QUEUE SHOW There is a minor bug in the QUEUE SHOW command for entries involving the SITE interface. QUEUE SHOW/FULL shows the correct information: Entry: 10, Origin: [SITE] Status: FINISHED, size: 5191 bytes Created: 16-DEC-1996 13:42:34.23, expires 15-JAN-1997 13:42:34.23 Last modified 16-DEC-1996 13:42:41.69 Recipient #1: <_paul@nuclear.physics.sunysb.edu> Recipient #2: Entry: 15, Origin: [SITE] <> Status: FINISHED, size: 3217 bytes Created: 16-DEC-1996 13:22:36.34, expires 15-JAN-1997 13:22:36.34 Last modified 16-DEC-1996 13:22:45.25 Recipient #1: <_paul@nuclear.physics.sunysb.edu> Recipient #2: QUEUE SHOW shows either the source without the angle brackets or a date and part of a node: Entry# Status Size Source Agent Entry# Status Size ------ ------ ------- ------ ------- ------ ------ ------- 10 FINISH 5191 SITE jt@life.bio.sunysb.edu 15 FINISH 3217 SITE Mon, 16 Dec 1996 13:22:36 EST@by nuclear.physics.s This does not seem to cause any problems, but I thought I would mention it. ========================================================================== John Hasstedt Internet: John.Hasstedt@sunysb.edu Physics Department Phone: 516-632-8169 or 516-632-8153 State University of New York FAX: 516-632-8573 Stony Brook, NY 11794-3800 ================================================================================ Archive-Date: Mon, 16 Dec 1996 15:51:43 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 13:51:27 MST From: Ray Harwood -- Data Basix Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: rharwood@Basix.COM Message-ID: <009ACEE0.B24F3466.3@Basix.COM> Subject: Setting DNS timeout Why would anyone set their DNS expire to 5 minutes? SprintMail.COM does, and it's causing some occasional problems. Here's the scenario: (1) User types EMail to JoeSchmuch@SprintMail.COM (2) MX tries to do DNS lookup, but the DNS server is slow, so it times out. (3) MX marks DNS failure, and tries again in 30 minutes. (4) MX tries to do DNS lookup, but since the idiots at SprintMail have their DNS refresh set to FIVE MINUTES, their old lookup from try #1 is stale, so another DNS lookup is done... but their DNS server is slow, so ti times out. (5) Repeat steps 3-4 until DNS retry limit is exceeded. Now... if I do a MULTINET NSLOOKUP SPRINTMAIL.COM and then MCP QUE READY the failing entry number, it goes out fine (as long as no more than 5 minutes have elapsed between my NSL and the entry goes out). Short of asking the SprintMail folks to up their refresh timer (which I *have* done, with no response), is there a way to get MX to wait a little longer before giving up on the DNS lookup? Or is that a Netlib function? I'm running MX 4.2 on VMS 6.0, and Netlib 2.0I (I think -- I did an ANAL/IMAGE on the NETLIB_DIR EXE file to get that). This isn't a HUGE problem, but I'd appreciate any useful tips. I know we have some occasional DNS timeouts at University Medical Center (since we're behind a firewall which causes DNS lookups to be even slower), but most people have a refresh time greater than 30 minutes, so EMail goes out on the next try with no problem. Thanks! Regards, Ray ----- Ray Harwood | Data Basix | Internet Service Provider for Voice: (520)721-1988 | PO Box 18324 | Dialup, SLIP, & UUCP Services, FAX: (520)721-7240 | Tucson, AZ 85731 | And World Wide Web Pages -- RHarwood@Basix.COM | http://Basix.COM/ | Internet with a Personal Touch ================================================================================ Archive-Date: Mon, 16 Dec 1996 16:16:15 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 17:13:51 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: rharwood@Basix.COM, hardis@garnet.nist.gov Message-ID: <009ACEFC.F91ABAC0.20@garnet.nist.gov> Subject: RE: Setting DNS timeout > Why would anyone set their DNS expire to 5 minutes? SprintMail.COM does, > and it's causing some occasional problems. They don't. Refresh is 5 minutes; expiration is 7 days: SPRINTMAIL.COM origin = homesrvr1.a001.sprintisp.net mail addr = root.SPRINTMAIL.COM serial = 75 refresh = 300 (5 mins) retry = 600 (10 mins) expire = 604800 (7 days) minimum ttl = 300 (5 mins) > Short of asking the SprintMail folks to up their refresh timer (which I > *have* done, with no response), is there a way to get MX to wait a little > longer before giving up on the DNS lookup? Or is that a Netlib function? > > I'm running MX 4.2 on VMS 6.0, and Netlib 2.0I (I think -- I did an > ANAL/IMAGE on the NETLIB_DIR EXE file to get that). It's an "underlying TCP/IP package" function. For CMU/TEK, it's the NAMRES process. Netlib only provides the glue between the application (MX) and the TCP/IP transport package. I suppose that you could recompile NAMRES with the timeout as MAX(30, whatever-it-is-told), but this seems an awful lot of work. Why not use a PATH statement to send all mail destined to SPRINTMAIL.COM to some other host that's better behaved? (While ATTMAIL.COM would be the funny example, SPRINTISP.COM may be the better choice.) SPRINTISP.COM origin = homesrvr1.a001.sprintisp.net mail addr = root.sprintisp.net serial = 7 refresh = 10800 (3 hours) retry = 3600 (1 hour) expire = 604800 (7 days) minimum ttl = 86400 (1 days) - Jonathan ================================================================================ Archive-Date: Mon, 16 Dec 1996 20:18:30 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 19:00:38 MST From: Jim Savoy Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009ACF0B.E3CF5F86.40@hg.uleth.ca> Subject: mailing list acting up Hello everyone, We have been experiencing an unusual problem here with a particular mailing list. For reasons unknown it very rarely sends mail to any of the subscribers, save for the ones at our site (hg.uleth.ca). The strange thing is that it never even *tries* to send mail to the other subscribers. It just sits in the queue forever. The members of the list are trying to organize a conference in January and are getting a little ticked off at me as I try everything I can think of to get their mail to them. I turned on MX_MLF_DEBUG and MX_SMTP_DEBUG. This morning one of the subscribers sent a message at 11:28 and another different message at 11:37. The 11:28 did the usual thing, which is nothing (aside from sending mail to the people here at hg.uleth.ca). The 11:37 message worked just fine and everyone got it. But 4 out of 5 messages do not get sent. The activity of the 11:28 message (the message that failed) was recorded in an MX_MLF_LOG: -------------------------------- FAILED -------------------------------------- 16-DEC-1996 11:28:05.04 Processing queue entry number 275 16-DEC-1996 11:28:05.26 Checking local name: NAAEE97-2-L 16-DEC-1996 11:28:05.37 This is a mailing list. 16-DEC-1996 11:28:05.49 FORWARD_TO_LIST: Message is from: "Pamela J. Puntenney" 16-DEC-1996 11:28:05.49 CHECK_ACCESS: checking pjpunt@UMICH.EDU for access mask=00000002 16-DEC-1996 11:28:05.49 CHECK_ACCESS: Found address on subscriber list. 16-DEC-1996 11:28:05.49 CHECK_ACCESS: -- access granted under GROUP class. 16-DEC-1996 11:28:05.60 FORWARD_TO_LIST: calling FORWARD_MESSAGE to do the grunt work. 16-DEC-1996 11:28:05.84 FORWARD_MESSAGE: Forwarding queue entry number=277 16-DEC-1996 11:28:06.33 FORWARD_MESSAGE: Forwarding to: milt_mcclaren@SFU.CA 16-DEC-1996 11:28:06.33 FORWARD_MESSAGE: Forwarding to: carlisle@UNIXG.UBC.CA . . . 16-DEC-1996 11:28:06.40 FORWARD_MESSAGE: Forwarding to: lawsethd@SCDNAN.PBS.DFO.CA 16-DEC-1996 11:28:06.40 FORWARD_MESSAGE: Forwarding to: savoy@ACS.UCALGARY.CA 16-DEC-1996 11:28:07.41 All done with this entry. -------------------------------- FAILED -------------------------------------- NOTE: I have an account at acs.ucalgary.ca as well as at hg.uleth.ca, so I added myself to bottom of their list, since I know that the mail gets to subscribers at hg.uleth.ca but rarely to the outside world. I cannot provide info from the corresponding MX_SMTP_LOG because there isn't one! That's probably what is at the root of all of this. Why the SMTP agents (we have 5 of them running) ignore the queue entry I do not know. And they never retry sending either. It's as if the entry does not exist. I have no SMTP info to provide therefore, but I can show you the queue status from the 11:28 message: -------------------------------- FAILED -------------------------------------- Entry: 277, Origin: [Local] Status: IN-PROGRESS, size: 47600 bytes Created: 16-DEC-1996 11:28:05.69, expires 15-JAN-1997 11:28:05.69 Last modified 16-DEC-1996 11:28:13.35 SMTP entry #370, status: IN-PROGRESS, size: 45900 bytes Created: 16-DEC-1996 11:28:08.45, expires 15-JAN-1997 11:28:05.69 Last modified 16-DEC-1996 11:28:09.63 Recipient #1: , Route=SFU.CA Recipient #2: , Route=UNIXG.UBC.CA . . . Recipient #53: , Route=SCDNAN.PBS.DFO.CA Recipient #54: , Route=ACS.UCALGARY.CA -------------------------------- FAILED -------------------------------------- Hmm - no error message at the end. Any help would be much-appreciated. Below is the MX_MLF_LOG and MX_SMTP_LOG entries of the successful message that was sent at 11:37, if it's any help. Thanks! +++++++++++++++++++++++++++++++ SUCCEEDED ++++++++++++++++++++++++++++++++++ 16-DEC-1996 11:37:39.69 Processing queue entry number 279 16-DEC-1996 11:37:39.78 Checking local name: NAAEE97-2-L 16-DEC-1996 11:37:39.94 This is a mailing list. 16-DEC-1996 11:37:40.09 FORWARD_TO_LIST: Message is from: "Pamela J. Puntenney" 16-DEC-1996 11:37:40.09 CHECK_ACCESS: checking pjpunt@UMICH.EDU for access mask=00000002 16-DEC-1996 11:37:40.09 CHECK_ACCESS: Found address on subscriber list. 16-DEC-1996 11:37:40.09 CHECK_ACCESS: -- access granted under GROUP class. 16-DEC-1996 11:37:40.09 FORWARD_TO_LIST: calling FORWARD_MESSAGE to do the grunt work. 16-DEC-1996 11:37:40.21 FORWARD_MESSAGE: Forwarding queue entry number=282 16-DEC-1996 11:37:40.37 FORWARD_MESSAGE: Forwarding to: milt_mcclaren@SFU.CA 16-DEC-1996 11:37:40.38 FORWARD_MESSAGE: Forwarding to: carlisle@UNIXG.UBC.CA . . . 16-DEC-1996 11:37:40.38 FORWARD_MESSAGE: Forwarding to: lawsethd@SCDNAN.PBS.DFO.CA 16-DEC-1996 11:37:40.39 FORWARD_MESSAGE: Forwarding to: savoy@ACS.UCALGARY.CA 16-DEC-1996 11:37:40.93 All done with this entry. +++++++++++++++++++++++++++++++ SUCCEEDED ++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++ SUCCEEDED ++++++++++++++++++++++++++++++++++ 16-DEC-1996 11:37:43.81 Processing queue entry number 287 on node ADMIN1 16-DEC-1996 11:37:44.05 Recipient: , route=SFU.CA 16-DEC-1996 11:37:44.05 Recipient: , route=UNIXG.UBC.CA . . . 16-DEC-1996 11:37:44.06 Recipient: , route=SCDNAN.PBS.DFO.CA 16-DEC-1996 11:37:44.06 Recipient: , route=ACS.UCALGARY.CA 16-DEC-1996 11:37:44.06 SMTP_SEND: looking up host name SFU.CA 16-DEC-1996 11:37:44.06 SMTP_SEND: DNS_MXLOOK status is 00000001 16-DEC-1996 11:37:44.08 SMTP_SEND: Attempting to start session with ferrari.SFU.CA [142.58.110.11] 16-DEC-1996 11:37:44.17 SMTP_SEND: Connected 16-DEC-1996 11:37:44.41 SMTP_SEND: Rcvd: 220 ferrari.sfu.ca ESMTP Sendmail 8.7.6/SFU-2.7H ready at Mon, 16 Dec 1996 10:36:51 -0800 (PST) 16-DEC-1996 11:37:44.46 SMTP_SEND: Sent: HELO admin1.cc.uleth.ca 16-DEC-1996 11:37:44.53 SMTP_SEND: Rcvd: 250 ferrari.sfu.ca Hello admin1.cc.uleth.ca [142.66.4.7], pleased to meet you 16-DEC-1996 11:37:44.53 SMTP_SEND: Sent: MAIL FROM: 16-DEC-1996 11:37:44.82 SMTP_SEND: Rcvd: 250 ... Sender ok 16-DEC-1996 11:37:44.82 SMTP_SEND: Sent: RCPT TO: 16-DEC-1996 11:37:44.91 SMTP_SEND: Rcvd: 250 Recipient ok [rest deleted for brevity's sake, but it basically logged the same stuff for each user] +++++++++++++++++++++++++++++++ SUCCEEDED ++++++++++++++++++++++++++++++++++ - jim savoy - - university of lethbridge - - savoy@hg.uleth.ca - ================================================================================ Archive-Date: Mon, 16 Dec 1996 22:43:42 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 21:44:27 MST From: Jim Savoy Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009ACF22.C659989C.8@hg.uleth.ca> Subject: mailing list acting up I realize now that I didn't provide any details on our operating system and the version of MX mail we are running: OpenVMS version 6.2. A mixed-cluster (3 AXPs and 1 VAX). MX version 4.2 (agents running on 2 of the AXP machines). - jim savoy - - university of lethbridge - - savoy@hg.uleth.ca - ================================================================================ Archive-Date: Tue, 17 Dec 1996 01:12:37 CST Sender: owner-mx-list@wku.edu Date: Mon, 16 Dec 1996 23:12:16 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009ACF2F.0B0686B0.4@sacto.mp.usbr.gov> Subject: RE: mailing list acting up > From: MX%"MX-List@MadGoat.com" 16-DEC-1996 21:11:49.76 > Subj: mailing list acting up > I realize now that I didn't provide any details on our operating > system and the version of MX mail we are running: > > OpenVMS version 6.2. A mixed-cluster (3 AXPs and 1 VAX). MX version > 4.2 (agents running on 2 of the AXP machines). > > > - jim savoy - > - university of lethbridge - > - savoy@hg.uleth.ca - > Jim, What TCP/IP package(a) are you running? It kind of sounds like a name resolution problem. -HWM ================================================================================ Archive-Date: Tue, 17 Dec 1996 06:26:52 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 07:26:01 -0400 (EDT) From: "Steven Bryan 644.3921" Reply-To: MX-List@MadGoat.com Subject: ??? - Removing Mailing List Members? To: MX-List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Dear MX ListServer Managers, How does one remove a member from a list without actually having to log into that account and doing a "signoff"? Page 3-3 of the MX 4.2 Message Exchange Mailing List/File Server Guide shows an MLF MXSERVER command of "REMOVE list-name address[...]" with a description of "Control command: allows list owner to remove other users from the list." There is a similar MLF -Request command. I can't get either to work and suspect the MXSERVER version is a typo since remove there clearly removes lists, paths, alias, etc - not users from the list. Thanks in advance for what must be a quick, simple reply (if you were a seasoned MLF guru, not just getting started as I...!) Steven Bryan Network Software Manager the State of Ohio Dept. of Administrative Services Ohio Data Network 1320 Arthur E. Adams Drive Columbus, Ohio 43221 614.644.3921 614.752.6108 (Fax) bryan@ohio.gov ================================================================================ Archive-Date: Tue, 17 Dec 1996 07:39:18 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 07:39:12 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACF75.DC5E034B.1@ALPHA.WKU.EDU> Subject: RE: ??? - Removing Mailing List Members? "Steven Bryan 644.3921" writes: > >How does one remove a member from a list without actually having to log into >that account and doing a "signoff"? > >Page 3-3 of the MX 4.2 Message Exchange Mailing List/File Server Guide shows >an MLF MXSERVER command of "REMOVE list-name address[...]" with a >description of "Control command: allows list owner to remove other users >from the list." There is a similar MLF -Request command. I can't get >either to work and suspect the MXSERVER version is a typo since remove there >clearly removes lists, paths, alias, etc - not users from the list. > You're talking about MCP. MXserver is a mailing address on your system, and to that, you do mail commands like: REMOVE/NONOTIFY The address would be just MX%MXSERVER or . Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 17 Dec 1996 08:08:06 CST Sender: owner-mx-list@wku.edu Message-ID: <2.2.32.19961217140955.0068626c@medea.gfdi.fsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Dec 1996 09:09:55 -0500 To: MX-List@MadGoat.com From: "K. Convery" Reply-To: MX-List@MadGoat.com Subject: Re: ??? - Removing Mailing List Members? At 07:26 AM 12/17/96 -0400, you wrote: >Dear MX ListServer Managers, > >How does one remove a member from a list without actually having to log into >that account and doing a "signoff"? > >...text removed... > > Steven Bryan > Network Software Manager > the State of Ohio > Dept. of Administrative Services > Ohio Data Network > 1320 Arthur E. Adams Drive > Columbus, Ohio 43221 > 614.644.3921 > 614.752.6108 (Fax) > bryan@ohio.gov > > > > Send e-mail to the listname-Request@list.host.name with the line: remove /nonotify email@address.to.remove.here Note, you must send it from an account that owns the list (or I believe that system works too). Oh...and the remove line is in the body of the message not the subject. Kevin Convery System Manager FSU GFDI (904)644-2454 ================================================================================ Archive-Date: Tue, 17 Dec 1996 08:23:46 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 09:11:36 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: bryan@ohio.gov Message-ID: <009ACF82.C4BD9D20.18@swdev.si.com> Subject: RE: ??? - Removing Mailing List Members? Steven Bryan (bryan@ohio.gov) writes: >How does one remove a member from a list without actually having to log into >that account and doing a "signoff"? One way is with MLFAKE. See section 7.1 in the MX Management Guide. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 17 Dec 1996 08:42:25 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 06:41:39 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009ACF6D.D3328A10.15@sacto.mp.usbr.gov> Subject: RE: ??? - Removing Mailing List Members? > From: MX%"MX-List@MadGoat.com" 17-DEC-1996 05:34:13.97 > Subj: ??? - Removing Mailing List Members? > Dear MX ListServer Managers, > > How does one remove a member from a list without actually having to log into > that account and doing a "signoff"? > > Page 3-3 of the MX 4.2 Message Exchange Mailing List/File Server Guide shows > an MLF MXSERVER command of "REMOVE list-name address[...]" with a > description of "Control command: allows list owner to remove other users > from the list." There is a similar MLF -Request command. I can't get > either to work and suspect the MXSERVER version is a typo since remove there > clearly removes lists, paths, alias, etc - not users from the list. > > Thanks in advance for what must be a quick, simple reply (if you were a > seasoned MLF guru, not just getting started as I...!) > > Steven Bryan > Network Software Manager > the State of Ohio > Dept. of Administrative Services > Ohio Data Network > 1320 Arthur E. Adams Drive > Columbus, Ohio 43221 > 614.644.3921 > 614.752.6108 (Fax) > bryan@ohio.gov > > > Steven, Refer the the MX documentation on the MLFAKE program. Good luck, -HWM ================================================================================ Archive-Date: Tue, 17 Dec 1996 08:45:04 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 09:13:14 EST5EDT4,M4.1.0,M10.5.0 From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACF82.FF3989A0.93@fred.bridgew.edu> Subject: RE: ??? - Removing Mailing List Members? >From: "Steven Bryan 644.3921" >Dear MX ListServer Managers, > >How does one remove a member from a list without actually having to log into >that account and doing a "signoff"? >from the list." There is a similar MLF -Request command. I can't get >either to work and suspect the MXSERVER version is a typo since remove there >clearly removes lists, paths, alias, etc - not users from the list. You do not clearly tell us what you have done or what went wrong, but what you should have done is 1. Log in as the list owner. 2. Mail a message to mailinglistname-request@ohio.gov The text of the message should contain a line with the remove command REMOVE user@domain Be sure to spell the user's name exactly as appears on the list. That should do it. Usually failures are due to (1) not logging in as list owner (2) incorrect protection/permissions set on the mailing list (3) misspelling of username or address. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 17 Dec 1996 09:54:33 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 10:53:36 -0400 (EDT) From: "Steven Bryan 644.3921" Reply-To: MX-List@MadGoat.com Subject: Thanks! on the Removing a user command... To: MX-List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Got many answers showing multiple ways to remove a user from a list. Thanks to all for your help. Merry Christmas and have a great holiday season! ...Steven Bryan (Columbus, Ohio) ================================================================================ Archive-Date: Tue, 17 Dec 1996 15:16:48 CST Sender: owner-mx-list@wku.edu Subject: Re: ??? - Removing Mailing List Members? Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 17 Dec 1996 20:15:19 GMT To: MX-List@WKUVX1.WKU.EDU In article <2.2.32.19961217140955.0068626c@medea.gfdi.fsu.edu> "K. Convery" writes: Send e-mail to the listname-Request@list.host.name with the line: remove /nonotify email@address.to.remove.here Note, you must send it from an account that owns the list ^^^^ "as", really. Normally the same thing, but... (or I believe that system works too). Not necessarely. You can do it if you're one of the system users as MX sees it (MCR MX_EXE:MCP HELP DEF SYSTEM for more info). -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://www.lp.se/~levitte for my public key. bastard@bofh.se ================================================================================ Archive-Date: Tue, 17 Dec 1996 15:44:00 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 16:42:03 EST5EDT4,M4.1.0,M10.5.0 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACFC1.B1B231A2.48@usnews.com> Subject: MLF Process Crashes I have a new list that keeps crashing my MLF process. I defined MX_MLF_DEBUG on the system but still only get the message being forwarded and no more info as to why it aborts. This is a new list of 13,000+ entries, another list of 6,200+ works fine. Is there a limit on ther number of entries or bytes. I am using MX 4.2 on an AXP 2300 VMS 6.1. Begining of mx_mlf_dir:mx_mlf_log.log 17-DEC-1996 16:07:20.47 Processing queue entry number 10 17-DEC-1996 16:07:20.74 Checking local name: online 17-DEC-1996 16:07:20.74 This is a mailing list. 17-DEC-1996 16:07:23.14 FORWARD_TO_LIST: Message is from: editjones@usnews.com 17-DEC-1996 16:07:23.14 CHECK_ACCESS: checking editjones@USNEWS.COM for access mask=00000002 17-DEC-1996 16:07:23.14 CHECK_ACCESS: Access granted under WORLD class. 17-DEC-1996 16:07:24.80 FORWARD_TO_LIST: calling FORWARD_MESSAGE to do the grunt work. 17-DEC-1996 16:07:25.23 FORWARD_MESSAGE: Forwarding queue entry number=29 17-DEC-1996 16:07:25.71 FORWARD_MESSAGE: Forwarding to: 0001998364@MCIMAIL.COM 17-DEC-1996 16:07:25.72 FORWARD_MESSAGE: Forwarding to: 0006572811@MCIMAIL.COM End of mx_mlf_dir:mx_mlf_log.log 17-DEC-1996 16:07:37.99 FORWARD_MESSAGE: Forwarding to: sheri1@VOYAGER.NET 17-DEC-1996 16:07:37.99 FORWARD_MESSAGE: Forwarding to: sheri@CLOVER.NET 17-DEC-1996 16:07:37.99 FORWARD_MESSAGE: Forwarding to: sheri@SHIANET.ORG 17-DEC-1996 16:07:37.99 FORWARD_MESSAGE: Forwarding to: sherib@NETCOM.COM The last record forwarded is 11,513. Thanks! Joe ================================================================================ Archive-Date: Tue, 17 Dec 1996 16:51:30 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 14:50:37 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009ACFB2.211DCD90.27@sacto.mp.usbr.gov> Subject: RE: MLF Process Crashes > From: MX%"MX-List@MadGoat.com" 17-DEC-1996 14:21:28.86 > Subj: MLF Process Crashes I'd monitor that process and keep an eye on the WSEXTENT, WSQUOTA and PGFLQUO. > I have a new list that keeps crashing my MLF process. I defined MX_MLF_DEBUG > on the system but still only get the message being forwarded and no more info > as to why it aborts. This is a new list of 13,000+ entries, another list > of 6,200+ works fine. > > Is there a limit on ther number of entries or bytes. I am using MX 4.2 > on an AXP 2300 VMS 6.1. > > Begining of mx_mlf_dir:mx_mlf_log.log > -HWM ================================================================================ Archive-Date: Tue, 17 Dec 1996 16:51:44 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 16:51:37 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACFC3.07FB6609.5@ALPHA.WKU.EDU> Subject: RE: MLF Process Crashes Joe Macewicz writes: > >I have a new list that keeps crashing my MLF process. I defined MX_MLF_DEBUG >on the system but still only get the message being forwarded and no more info >as to why it aborts. This is a new list of 13,000+ entries, another list >of 6,200+ works fine. > >Is there a limit on ther number of entries or bytes. I am using MX 4.2 >on an AXP 2300 VMS 6.1. > There should be no limit, other than whatever memory quotas exist for the process. What does the MX_MLF_node.LOG show for the exit status of the process? Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 17 Dec 1996 17:30:24 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 16:31:07 MST From: Jim Savoy Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACFC0.2AECA9B4.196@hg.uleth.ca> Subject: RE: mailing list acting up >> OpenVMS version 6.2. A mixed-cluster (3 AXPs and 1 VAX). MX version >> 4.2 (agents running on 2 of the AXP machines). > Jim, > What TCP/IP package(a) are you running? It kind of sounds like > a name resolution problem. > -HWM We are running Multinet version 3.5. - jim savoy - - university of lethbridge - - savoy@hg.uleth.ca - ================================================================================ Archive-Date: Tue, 17 Dec 1996 19:13:11 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 18:49:14 EST5EDT4,M4.1.0,M10.5.0 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ACFD3.7648602A.152@usnews.com> Subject: RE: MLF Process Crashes Joe Macewicz writes: >> >>I have a new list that keeps crashing my MLF process. I defined MX_MLF_DEBUG >>on the system but still only get the message being forwarded and no more info >>as to why it aborts. This is a new list of 13,000+ entries, another list >>of 6,200+ works fine. >> >>Is there a limit on ther number of entries or bytes. I am using MX 4.2 >>on an AXP 2300 VMS 6.1. >> >There should be no limit, other than whatever memory quotas exist for >the process. What does the MX_MLF_node.LOG show for the exit status >of the process? 17-DEC-1996 16:00:16.43: MX MLF (pid 20600849) starting 17-DEC-1996 16:01:47.54: MX MLF (pid 20600849) exiting, status = 1C278034 ================================================================================ Archive-Date: Tue, 17 Dec 1996 20:03:23 CST Sender: owner-mx-list@wku.edu Date: Tue, 17 Dec 1996 20:55:55 -0500 (EST) From: "Harrington B. Laufman" Reply-To: MX-List@MadGoat.com Subject: Re: ??? - Removing Mailing List Members? To: MX-List@MadGoat.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Dec 1996, Steven Bryan 644.3921 wrote: > Dear MX ListServer Managers, > > How does one remove a member from a list without actually having to log into > that account and doing a "signoff"? Presuming that you are either an owner of the list, or a System (privileged) user, send mail to your mxserver with the command remove whichlist badguy@badplace.com in the body of the message. System users are SET and SHOWn from the MCP prompt (as are list owners, for that matter). The UNSUBSCRIBE command is used by a list subscriber. Harrington ================================================================================ Archive-Date: Wed, 18 Dec 1996 07:27:30 CST Sender: owner-mx-list@wku.edu Date: Wed, 18 Dec 1996 07:27:25 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: JOE@USNEWS.COM Message-ID: <009AD03D.60E8C453.15@ALPHA.WKU.EDU> Subject: RE: MLF Process Crashes Joe Macewicz writes: > >>>I have a new list that keeps crashing my MLF process. I defined MX_MLF_DEBUG >>>on the system but still only get the message being forwarded and no more info >>>as to why it aborts. This is a new list of 13,000+ entries, another list >>>of 6,200+ works fine. >>> >>There should be no limit, other than whatever memory quotas exist for >>the process. What does the MX_MLF_node.LOG show for the exit status >>of the process? > >17-DEC-1996 16:00:16.43: MX MLF (pid 20600849) starting >17-DEC-1996 16:01:47.54: MX MLF (pid 20600849) exiting, status = 1C278034 > $ set mess mx_msg $ write sys$output f$message(%x1C278034) %MX-F-MEMALLOC, error allocating memory from zone !AS $ So you're definitely running out of memory. I'd suggest you follow Henry's advice and bump the memory quotas for the process (in particular, I'd try WSEXTENT and PGFLQUO). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sat, 21 Dec 1996 12:51:32 EST Sender: owner-mx-list@wku.edu Date: Sat, 21 Dec 1996 13:51:29 -0500 From: OLDSDW@wofford.edu Reply-To: MX-List@MadGoat.com To: MX-LIST@LISTS.WKU.EDU Message-ID: <961221135129.22e0207b@wofford.edu> REVIEW MX-List ================================================================================ Archive-Date: Sat, 21 Dec 1996 12:59:05 EST Sender: owner-mx-list@wku.edu Date: Sat, 21 Dec 1996 13:59:02 -0500 From: OLDSDW@wofford.edu Reply-To: MX-List@MadGoat.com To: MX-LIST@LISTS.WKU.EDU Message-ID: <961221135902.22e0207b@wofford.edu> Subject: mailing list addresses setup I've been experimenting with setting up a mailing list using MX. The manual says "Four local addresses are set up for each mailing list: one for the list itself, a request address ..., an owner address ... When does this happen? I seem to have gotten only the first, the list address itself. ================================================================================ Archive-Date: Sat, 21 Dec 1996 17:34:11 EST Sender: owner-mx-list@wku.edu Date: Sat, 21 Dec 1996 17:34:07 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AD2ED.A18AD912.13@ALPHA.WKU.EDU> Subject: RE: mailing list addresses setup OLDSDW@wofford.edu writes: > > I've been experimenting with setting up a mailing list using MX. >The manual says "Four local addresses are set up for each mailing >list: one for the list itself, a request address ..., an owner address ... > > > When does this happen? I seem to have gotten only the first, the >list address itself. The others are not actually defined, but are automatically recognized by MX Router and MX MLF. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 23 Dec 1996 14:13:47 EST Sender: owner-mx-list@wku.edu From: goathunter@madgoat.com (Hunter Goatley) Subject: Re: Message to big Date: 23 Dec 1996 18:30:29 GMT Message-ID: <59mj45$a8c@news.wku.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article , kareem@email.labmed.umn.edu (Kareem Kazkaz) writes: > >I am running the mx smtp server (TCP/IP), and every once in a while it >quits, giving me this error message: > >%STR-F-STRTOOLON, string is too long (greater than 65535) [...] >So is the answer to my question in a FAQ somewhere, do I have to install >V4.2, or am I SOL? I'd be more than happy to do my own research if >somebody could point me the way. > You'll need to upgrade to MX V4.2 and install the SMTP_SERVER.[ALPHA_]EXE from ftp.wku.edu in [.MX.MX042.PATCHES]. That patch corrects the STRTOOLON bug in the SMTP server. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 23 Dec 1996 23:38:36 EST Sender: owner-mx-list@wku.edu Message-ID: Date: Mon, 23 Dec 1996 21:34:57 -0800 From: Dan Sugalski Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Subject: FORWARD_MESSAGE.B32 MIME-Version: 1.0 Content-Type: text/plain A while ago (couple'a months) I got a file from someone at TGV (now Cisco) (I think Dan Wing--it's really been a while). Anyway, I have this FORWARD_MESSAGE.B32 file that lets me set the number of recipients for an outgoing message. Way cool. What exactly should I *do* with this thing? I presume I need to compile it (with a BLISS compiler, so I'll probably need to take a trip to the MadGoat archives), but then what? Do I need to recompile & link MX? If so, can someone point me in the general direction I need to go? Thanks, Dan ================================================================================ Archive-Date: Tue, 24 Dec 1996 10:58:17 EST Sender: owner-mx-list@wku.edu Date: Tue, 24 Dec 1996 11:57:57 -0500 From: OLDSDW@wofford.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <961224115757.2500026d@wofford.edu> Subject: RE: mailing list addresses setup In experimenting with the move from MULTINET SMTP mail to MX mail for our external mail link from VMS mail, I apparently lost my POP server which a few people had been using. Is this a necessary consequence of the move or just something I messed up?? My original intent was to use only the MX-LIST part of MX and keep Multinet for the default mail for all users. This has not worked, apparently because I could not properly direct the incoming mail to the list to be handled by the MX mail. Even experimenting during this holiday has caused some difficulty for some users, but I may try one more time before school resumes. For a while, it seemed that I could have Multinet SMTP be the default and still allow individual users to select MX. Of course this did not solve my MX-LIST problem. Could this be solved by running MX in a special account as suggested in the manual and set the default mail server for that one account to MX ? ================================================================================ Archive-Date: Tue, 24 Dec 1996 23:01:51 EST Sender: owner-mx-list@wku.edu Date: Tue, 24 Dec 1996 18:07:38 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: OLDSDW@wofford.edu, hardis@garnet.nist.gov Message-ID: <009AD54D.CFD853A0.3@garnet.nist.gov> Subject: RE: mailing list addresses setup > In experimenting with the move from MULTINET SMTP mail to MX mail for > our external mail link from VMS mail, I apparently lost my POP server > which a few people had been using. Is this a necessary consequence of > the move or just something I messed up?? MX does not provide a POP server. Did Multinet? (I suspect it did.) Those of us who use MX also often use IUPOP3 as the POP server. > My original intent was to use only the MX-LIST part of MX and keep > Multinet for the default mail for all users. This has not worked, > apparently because I could not properly direct the incoming mail to > the list to be handled by the MX mail. You can have any number of out-going mail systems, but only one incoming (SMTP) mail system -- MX or Multinet, your choice. Of course, since the mailing list facility (MLF) component of MX requires you to receive incoming mail with MX, that may decide the question. (Actually, that's not precisely true. In theory it's possible for one mail package to transfer specific pieces of mail to the other package. MX has a callable entry point, MX_ENTER, for example. But this is a stretch.) - Jonathan ================================================================================ Archive-Date: Tue, 24 Dec 1996 23:42:20 EST Sender: owner-mx-list@wku.edu Date: Tue, 24 Dec 1996 21:42:03 PST From: javier@Kjsl.COM Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AD56B.C3EE720E.24@Kjsl.COM> Subject: RE: mailing list addresses setup >MX does not provide a POP server. Did Multinet? (I suspect it did.) MultiNet does have POP3 (and POP2) servers. >You can have any number of out-going mail systems, but only one incoming >(SMTP) mail system -- MX or Multinet, your choice. Of course, since the >mailing list facility (MLF) component of MX requires you to receive >incoming mail with MX, that may decide the question. You could have an SMTP server listening on some port other than 25, but that would be silly :) >(Actually, that's not precisely true. In theory it's possible for one mail >package to transfer specific pieces of mail to the other package. MX has a >callable entry point, MX_ENTER, for example. But this is a stretch.) We (TGV) do provide some customizable hooks into the SMTP mailer that we include with MultiNet and some sample code (look in the [.EXAMPLES] directory for USER_SMTP_DISPATCH.C in the MultiNet directory tree). But as the last poster said, it would be a stretch to get that much into it. If the concern of the original poster is to let the users continue to type SMTP%"..." to send Internet mail after installing MX, then this can be used as a quick-n-dirty solution after installing MX: $ define/system/executive smtp_mailshr mx_exe:mx_mailshr.exe With VMS 6.2 and later, one can define the mail transport to be MX%, so users can just type the remote address. Versions of VMS previous to 6.2 can be patched so MAIL can exhibit the same behavior, the MX distribution includes the necessary patch. -javier ================================================================================ Archive-Date: Wed, 25 Dec 1996 04:38:55 EST Sender: owner-mx-list@wku.edu Date: Wed, 25 Dec 1996 02:38:07 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009AD595.2001CE00.1@sacto.mp.usbr.gov> Subject: RE: mailing list addresses setup > From: MX%"MX-List@MadGoat.com" 24-DEC-1996 22:13:06.88 > Subj: RE: mailing list addresses setup > >MX does not provide a POP server. Did Multinet? (I suspect it did.) > > MultiNet does have POP3 (and POP2) servers. > > >You can have any number of out-going mail systems, but only one incoming > >(SMTP) mail system -- MX or Multinet, your choice. Of course, since the > >mailing list facility (MLF) component of MX requires you to receive > >incoming mail with MX, that may decide the question. > > You could have an SMTP server listening on some port other than 25, but that > would be silly :) > Yes and not. I've seen some packages where you can reconfigure the SMTP server (and client for that matter) to use a port other than 25. Usually for firewall purposes. My entire view of firewalls is that they are, but and large, unnecessary. Most systems give you the capability of blocking out services from specific addresses, either as a native function (as does MultiNet) or via an add-on package, such as TCPD for unix systems. NNTP, for example, via it's oen configuration files, allows you to block access for any domain or network that you do not want to allow access for. As per firewalls: most Internet security problems are due to unix problems. What do they market for firewall systems? unix systems! It's like giving the prison trustee the keys to the front gate! > >(Actually, that's not precisely true. In theory it's possible for one mail > >package to transfer specific pieces of mail to the other package. MX has a > >callable entry point, MX_ENTER, for example. But this is a stretch.) > > We (TGV) do provide some customizable hooks into the SMTP mailer that we > include with MultiNet and some sample code (look in the [.EXAMPLES] directory > for USER_SMTP_DISPATCH.C in the MultiNet directory tree). But as the last > poster said, it would be a stretch to get that much into it. > Actually, it might be possible since MultiNet allows for multiple logical and physical interfaces. It might be possible to have one flavor of SMTP server listening on one address, as a seperately defined domain name, than punt incoming mail to the mail package that runs on the other IP address/domain name. I've not tried this with the proposed configuration, but it should work. I did do something similar when I was running EXOS TCP on it's own Ethernet port on an old 780 years ago, and punted it's incoming mail to another mail system that was running under either MultiNet or CMU-TEK. > If the concern of the original poster is to let the users continue to type > SMTP%"..." to send Internet mail after installing MX, then this can be used as > a quick-n-dirty solution after installing MX: > > $ define/system/executive smtp_mailshr mx_exe:mx_mailshr.exe > > With VMS 6.2 and later, one can define the mail transport to be MX%, so users > can just type the remote address. Versions of VMS previous to 6.2 can be > patched so MAIL can exhibit the same behavior, the MX distribution includes the > necessary patch. > > > > > -javier -HWM ================================================================================ Archive-Date: Thu, 26 Dec 1996 17:14:04 EST Sender: owner-mx-list@wku.edu Message-ID: <32C29657.45CCA305@tmc.naecker.com> Date: Thu, 26 Dec 1996 15:14:31 +0000 From: Brad Hughes Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: vmsperl@hmivax.humgen.upenn.edu, mx-list@madgoat.com Subject: Perl and Mail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There was a thread recently in one of these two groups (actually it may have been the OSU server group) about sending an attachment with VMS mail. If you send an html attachment using Netscape Mail then a Content-Type mail header of text/html gets included with the rest of the headers. If you read that message with Netscape Mail it gets formatted (this is VMS Netscape we're using). We have production runs that produce html output that we'd like to mail out to people and have them read them as formatted html; since VMS mail at the dollar sign can't do it, there are, as I see it, three options: 1) get a VMS mailer that allows either attachments or specifying a Content-Type header. We use Multinet as our stack but I don't see where multinet's mm allows mailing files from the dollar sign (Javier?). 2) rebuild Perl using sockets, get Mailtools from CPAN, and build a mail message using Perl, a la Barr's article in the Spring 1996 Perl Journal. Got and built socketshr, rebuilt Perl, got the Mailtools module (and Net::Domain), tried to build, got sort of lost since I've never done this before and it complained about some things. 3) mail the URL of the html file out. The URL appears as a link in the mail message; people click on the link and the file pops up the browser. This option works, but is not the best solution. So... If no one on the mx-list can help with option 1, then I need to explore option 2 again. I'll compose a followup mail message to the vmsperl group with specifics as to what doesn't work. If someone there has already made it work, please let me know how... Thanks. ================================================================================ Archive-Date: Thu, 26 Dec 1996 17:18:01 EST Sender: owner-mx-list@wku.edu Date: Thu, 26 Dec 1996 17:17:27 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AD6D9.21C1A33D.21@ALPHA.WKU.EDU> Subject: RE: FORWARD_MESSAGE.B32 Dan Sugalski writes: > > A while ago (couple'a months) I got a file from someone at TGV (now >Cisco) (I think Dan Wing--it's really been a while). Anyway, I have this >FORWARD_MESSAGE.B32 file that lets me set the number of recipients for an >outgoing message. Way cool. This will be in MX V4.3. BTW, strictly speaking, distribution of that modified file is a violation of the MadGoat copyright on MX. Not complaining about Dan's making it available, just pointing out that redistributing modified sources is a no-no. >What exactly should I *do* with this thing? I presume I need to compile it >(with a BLISS compiler, so I'll probably need to take a trip to the MadGoat >archives), but then what? Do I need to recompile & link MX? If so, can someone >point me in the general direction I need to go? > You need to get the MX sources and recompile and relink it, yes. The sources are on ftp.wku.edu in [.MX.MX042]MX042_SRC.ZIP. You can find the BLISS compiler there in [.VMS.FREEWARE_CD.BLISS]. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sun, 29 Dec 1996 11:18:17 EST Sender: owner-mx-list@wku.edu Date: Sun, 29 Dec 1996 12:17:55 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009AD90A.C90A4630.10@bdsnet.com> Subject: Mystery file queue manager... Hi... For debugging purposes we wanted to turn off purging of the message queue. We tried suspending the FLQ processes, and killing them altogether, but something is still purgine the queue. This worked before... what is happening now? Baffled, Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Mon, 30 Dec 1996 12:49:16 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961230104532.007db1d0@stargate.lbcc.cc.or.us> Date: Mon, 30 Dec 1996 10:45:32 -0800 To: MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: RE: FORWARD_MESSAGE.B32 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Hunter Goatley >> >> A while ago (couple'a months) I got a file from someone at TGV (now >>Cisco) (I think Dan Wing--it's really been a while). Anyway, I have this >>FORWARD_MESSAGE.B32 file that lets me set the number of recipients for an >>outgoing message. Way cool. > >This will be in MX V4.3. Great. I think I'll wait until this hits the stands, rather than messing about myself. Any estimate on the release date? >BTW, strictly speaking, distribution of that modified file is a >violation of the MadGoat copyright on MX. Not complaining about Dan's >making it available, just pointing out that redistributing modified >sources is a no-no. Eeek. Didn't mean to get anyone in trouble, really... Dan ================================================================================ Archive-Date: Mon, 30 Dec 1996 13:08:54 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 14:06:35 -0500 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <961230140635.20405247@USNEWS.COM> Subject: Listserver and Eudora In the last couple of weeks I have had several individuals on our list complain that our list causes their PC's to crash when they download their mail from their server with pop3. The only common factor is that they are all using Eudora version 3.0. Has anyone else had this type of problem? I am using MX 4.2 and VMS 6.1. Thanks! Joe ================================================================================ Archive-Date: Mon, 30 Dec 1996 13:50:42 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 11:50:07 PST From: javier@Kjsl.COM Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AD9D0.10F473CE.40@Kjsl.COM> Subject: RE: Listserver and Eudora >In the last couple of weeks I have had several individuals on our list >complain that our list causes their PC's to crash when they download their >mail from their server with pop3. The only common factor is that they are >all using Eudora version 3.0. > >Has anyone else had this type of problem? I am using MX 4.2 and VMS 6.1. Keep in mind that MX does not include a POP3 server. I think you're a MultiNet user, and Eudora Pro 3.0 seems to work fine here at home (MultiNet 4.0a, VMS 6.2) and at work (TGV, so plenty of different combinations :) At any rate, it seems that this would be an Eudora problem... Cheers, -javier ================================================================================ Archive-Date: Mon, 30 Dec 1996 14:03:52 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 15:01:30 -0500 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <961230150130.20405247@USNEWS.COM> Subject: RE: Listserver and Eudora >>In the last couple of weeks I have had several individuals on our list >>complain that our list causes their PC's to crash when they download their >>mail from their server with pop3. The only common factor is that they are >>all using Eudora version 3.0. >> >>Has anyone else had this type of problem? I am using MX 4.2 and VMS 6.1. > >Keep in mind that MX does not include a POP3 server. > The users are not on my mail-server but are subscribers to our list which we send out with MX. The problem we have with Eudora 3.0 is from users on our list not our internal users. For our users V3.0 works fine and I cannot duplicate the problem locally. >I think you're a MultiNet user, and Eudora Pro 3.0 seems to work fine here at >home (MultiNet 4.0a, VMS 6.2) and at work (TGV, so plenty of different >combinations :) > >At any rate, it seems that this would be an Eudora problem... > ================================================================================ Archive-Date: Mon, 30 Dec 1996 14:14:45 EST Sender: owner-mx-list@wku.edu Message-ID: <32C7B253.362E3FB2@tmc.naecker.com> Date: Mon, 30 Dec 1996 12:15:15 +0000 From: Brad Hughes Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: MX-List@MadGoat.com Subject: Re: Listserver and Eudora References: <961230140635.20405247@USNEWS.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Macewicz wrote: > > In the last couple of weeks I have had several individuals on our list > complain that our list causes their PC's to crash when they download their > mail from their server with pop3. The only common factor is that they are > all using Eudora version 3.0. > > Has anyone else had this type of problem? I am using MX 4.2 and VMS 6.1. > > Thanks! > Joe Make sure you haven't done a MCP> set local/headers=top:none Netscape mail get confused when it doesn't find any mail headers; Eudora may do the same. ================================================================================ Archive-Date: Mon, 30 Dec 1996 14:36:29 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 12:35:55 PST From: javier@Kjsl.COM Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AD9D6.775BC1DE.100@Kjsl.COM> Subject: RE: Listserver and Eudora >The users are not on my mail-server but are subscribers to our list which >we send out with MX. >The problem we have with Eudora 3.0 is from users on our list not our >internal users. For our users V3.0 works fine and I cannot duplicate the >problem locally. OK, let me make sure I understand you correctly. You host a mailing list using MX. A subscriber, say johndoe@domain.com, retrieves his messages from his local host using Eudora, and it blows up when it gets to messages coming from the list? I've seen a problem where messages with a Date: header containing an invalid date would cause Eudora Light (ie, the freeware version) to blow chunks. In the particular case I'm referring to, a subscriber to a list hosted by me (ATC-L) sent a message with a Date: header that said something like 37-DEC-1669. Keep in mind that the Date: header is generated by the MUA in use by the original sender of the message. In the case I'm referring to, the header had been generated by someone running an old version of ELM hacked to run under and old version of HP-UX. If this is the problem you're seeing, and the message was originally sent from a VMS system running MX, then the Date: header would've been generated by MX, though you have to wonder about an MUA (Eudora, in this case) that can't tolerate a malformed header. -javier ================================================================================ Archive-Date: Mon, 30 Dec 1996 16:33:10 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961230142909.007ef2e0@stargate.lbcc.cc.or.us> Date: Mon, 30 Dec 1996 14:29:09 -0800 To: mx-list@madgoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: MX name resolution problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dunno if this is a known problem or not, but if DNS name lookup fails on the first address for a mailing list, it'll fail for all the rest that need DNS name lookup, even if the lookups succeed. (status code = 1 in the debug log files) A bug to squish for 4.3, perhaps? Dan ---------------------------------------------------------------------- Dan Sugalski This space Programmer Dude Intentionally Linn-Benton Community College Left blank sugalsd@stargate.lbcc.cc.or.us ================================================================================ Archive-Date: Mon, 30 Dec 1996 19:31:47 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 20:30:55 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: sugalsd@stargate.lbcc.cc.or.us, hardis@garnet.nist.gov Message-ID: <009ADA18.D29FCF80.4@garnet.nist.gov> Subject: RE: MX name resolution problem > Dunno if this is a known problem or not, but if DNS name lookup fails on > the first address for a mailing list, it'll fail for all the rest that need > DNS name lookup, even if the lookups succeed. (status code = 1 in the debug > log files) Are you sure about that? First, this might depend on (a) the version of Netlib, and (b) the underlying TCP/IP package. You mentioned neither. In my case (MX 4.1, Netlib 2.0, CMU/TEK TCP/IP), I send to addresses all the time that the CMU/TEK NAMRES process can't handle (DNS name lookup fails). These messages then get happily sent to the default router (since I have one configured -- do you?). - Jonathan ================================================================================ Archive-Date: Mon, 30 Dec 1996 21:20:24 EST Sender: owner-mx-list@wku.edu Date: Mon, 30 Dec 1996 22:12:43 -0500 Message-ID: <96123022124377@funyet.mro.dec.com> From: anderson@funyet.mro.dec.com (Paul Anderson) Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com Subject: Help text instead of unknown error? Hello, I've just installed MX V4.2 and have a question. When a user sends an unknown request, is there a way to return the HELP message describing what options are available instead of the less-friendly "unknown command" message? Paul __________________________________________________________________ Paul Anderson Digital Equipment Corporation Printing Systems technical support .mro.FUNYET::ANDERSON DTN 297.8927 anderson@funyet.mro.dec.com 508.467.8927 MRO1-2/J25 508.467.1310 fax ================================================================================ Archive-Date: Tue, 31 Dec 1996 10:23:15 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961231081911.0090d660@stargate.lbcc.cc.or.us> Date: Tue, 31 Dec 1996 08:19:12 -0800 To: "Jonathan E. Hardis" , MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: RE: MX name resolution problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:30 PM 12/30/96 EST, Jonathan E. Hardis wrote: >> Dunno if this is a known problem or not, but if DNS name lookup fails on >> the first address for a mailing list, it'll fail for all the rest that need >> DNS name lookup, even if the lookups succeed. (status code = 1 in the debug >> log files) > >Are you sure about that? Yep. >First, this might depend on (a) the version of Netlib, and (b) the >underlying TCP/IP package. You mentioned neither. In my case >(MX 4.1, Netlib 2.0, CMU/TEK TCP/IP), I send to addresses all the time that >the CMU/TEK NAMRES process can't handle (DNS name lookup fails). These >messages then get happily sent to the default router (since I have one >configured -- do you?). I should have been a little more specific about the error. Because of a bogus setup on our end, the first address in the list caused a DNS server failure error. The rest validated OK, (at least they returned status code 1, and I could look them up OK) but MX still marked them as having DNS lookup problems. It seems like that hard failure set a status code somewhere that never got reset. OTOH, my BLISS knowledge is pretty much non-existant, so there might be something more than this. Dan ---------------------------------------------------------------------- Dan Sugalski This space Programmer Dude Intentionally Linn-Benton Community College Left blank sugalsd@stargate.lbcc.cc.or.us ================================================================================ Archive-Date: Tue, 31 Dec 1996 10:57:45 EST Sender: owner-mx-list@wku.edu Date: Tue, 31 Dec 1996 08:56:49 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009ADA81.06120FAA.19@sacto.mp.usbr.gov> Subject: RE: MX name resolution problem > From: MX%"MX-List@MadGoat.com" 31-DEC-1996 08:46:14.72 > Subj: RE: MX name resolution problem > At 08:30 PM 12/30/96 EST, Jonathan E. Hardis wrote: > >> Dunno if this is a known problem or not, but if DNS name lookup fails on > >> the first address for a mailing list, it'll fail for all the rest that need > >> DNS name lookup, even if the lookups succeed. (status code = 1 in the debug > >> log files) > > > >Are you sure about that? > > Yep. > > >First, this might depend on (a) the version of Netlib, and (b) the > >underlying TCP/IP package. You mentioned neither. In my case > >(MX 4.1, Netlib 2.0, CMU/TEK TCP/IP), I send to addresses all the time that > >the CMU/TEK NAMRES process can't handle (DNS name lookup fails). These > >messages then get happily sent to the default router (since I have one > >configured -- do you?). > > I should have been a little more specific about the error. Because of a > bogus setup on our end, the first address in the list caused a DNS server > failure error. The rest validated OK, (at least they returned status code > 1, and I could look them up OK) but MX still marked them as having DNS > lookup problems. > > It seems like that hard failure set a status code somewhere that never got > reset. OTOH, my BLISS knowledge is pretty much non-existant, so there might > be something more than this. > > Dan > ---------------------------------------------------------------------- > Dan Sugalski This space > Programmer Dude Intentionally > Linn-Benton Community College Left blank > sugalsd@stargate.lbcc.cc.or.us Dan, I still don't think that you've told us what TCP package you are running. (or maybe you did and I missed it...) Anyway, there may be a workaround based upon that. -HWM ================================================================================ Archive-Date: Tue, 31 Dec 1996 11:07:02 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961231090316.00883a80@stargate.lbcc.cc.or.us> Date: Tue, 31 Dec 1996 09:03:16 -0800 To: MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: RE: MX name resolution problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 08:56 AM 12/31/96 PST, Henry W. Miller wrote: >Dan, > > I still don't think that you've told us what TCP package you are >running. (or maybe you did and I missed it...) Anyway, there may be a >workaround based upon that. Whups, sorry. Multinet 4.0A, VMS 7.1FT2, MX 4.2, NetLib from MX distribution. I'm not really expecting this to crop up again. I've only seen server failures like this for bogus configurations for locally served domains so, as long as I make sure things are set up right, this shouldn't happen again. Dan ================================================================================ Archive-Date: Tue, 31 Dec 1996 11:33:15 EST Sender: owner-mx-list@wku.edu Date: Tue, 31 Dec 1996 09:32:39 PST From: javier@Kjsl.COM Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009ADA86.06FF810E.32@Kjsl.COM> Subject: RE: MX name resolution problem >Whups, sorry. Multinet 4.0A, VMS 7.1FT2, MX 4.2, NetLib from MX >distribution. I'm not really expecting this to crop up again. I've only >seen server failures like this for bogus configurations for locally served >domains so, as long as I make sure things are set up right, this shouldn't >happen again. NetLib must be at version 2.0J at least for MultiNet 3.5A and later. Can you verify that you have at least this version? -javier ================================================================================ Archive-Date: Tue, 31 Dec 1996 11:39:03 EST Sender: owner-mx-list@wku.edu Date: Tue, 31 Dec 1996 09:37:39 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009ADA86.BA0E2A2A.45@sacto.mp.usbr.gov> Subject: RE: MX name resolution problem > From: MX%"MX-List@MadGoat.com" 31-DEC-1996 09:28:19.68 > Subj: RE: MX name resolution problem > At 08:56 AM 12/31/96 PST, Henry W. Miller wrote: > >Dan, > > > > I still don't think that you've told us what TCP package you are > >running. (or maybe you did and I missed it...) Anyway, there may be a > >workaround based upon that. > > Whups, sorry. Multinet 4.0A, VMS 7.1FT2, MX 4.2, NetLib from MX > distribution. I'm not really expecting this to crop up again. I've only > seen server failures like this for bogus configurations for locally served > domains so, as long as I make sure things are set up right, this shouldn't > happen again. > > Dan Dan, 1) Netlib has ben upgraded since the last MX release; check the usual MX distribution hosts for the latest version. Note that after you install the new NETLIB, you'll have to manually execute SYS$STARTUP:NETLIB_STARTUP.COM before restarting MX. 2) If you have not already done so, contact TGV Technical Support (MultiNet-VMS@TGV.COM) concerning the bind upgrade for MultiNet 4.0A. Good luck, -HWM ================================================================================ Archive-Date: Tue, 31 Dec 1996 12:10:12 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961231100624.00933e10@stargate.lbcc.cc.or.us> Date: Tue, 31 Dec 1996 10:06:24 -0800 To: MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: RE: MX name resolution problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:32 AM 12/31/96 PST, javier@Kjsl.COM wrote: >>Whups, sorry. Multinet 4.0A, VMS 7.1FT2, MX 4.2, NetLib from MX >>distribution. I'm not really expecting this to crop up again. I've only >>seen server failures like this for bogus configurations for locally served >>domains so, as long as I make sure things are set up right, this shouldn't >>happen again. > >NetLib must be at version 2.0J at least for MultiNet 3.5A and later. Can you >verify that you have at least this version? Humm. I installed the NetLib from the MX 4.2 distribution. The docs say 2.0I. I think I'll take a trip to the FTP site and pull the latest version, just in case. (2.0I has been working just fine with MN 3.5B and 4.0A, FWIW) Dan ---------------------------------------------------------------------- Dan Sugalski This space Programmer Dude Intentionally Linn-Benton Community College Left blank sugalsd@stargate.lbcc.cc.or.us ================================================================================ Archive-Date: Tue, 31 Dec 1996 12:19:23 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19961231101533.008e0620@stargate.lbcc.cc.or.us> Date: Tue, 31 Dec 1996 10:15:34 -0800 To: MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: RE: MX name resolution problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:37 AM 12/31/96 PST, Henry W. Miller wrote: >1) Netlib has ben upgraded since the last MX release; check the >usual MX distribution hosts for the latest version. Note that after you >install the new NETLIB, you'll have to manually execute >SYS$STARTUP:NETLIB_STARTUP.COM before restarting MX. Going out to get it right now. >2) If you have not already done so, contact TGV Technical Support >(MultiNet-VMS@TGV.COM) concerning the bind upgrade for MultiNet 4.0A. I think I will. Up 'til now I hadn't thought about getting a patch for it. I've been spending too much time with unsupported code lately, I think. (Not MX--other stuff) Dan